Virtual SmartZone Deployment Requirements
Hypervisor Hardware Performance Requirements and Limitations
Deployment Requirements for vSZ Efficiency and Reliability
vSZ, the leading network management solution, operates optimally when deployed on appropriate hardware resources. Following the deployment requirements ensures efficient and reliable performance:
- Hypervisor Hardware
Resource Dependency:
vSZ demands sufficient hardware resources for service stability. It is not compatible with hypervisors that offer low performance. Deploying vSZ on insufficient hardware risks degraded performance and service interruptions.
The hardware must reserve sufficient CPU and memory resources for the hypervisor OS. The CPU and memory cannot be fully allocated to the vSZ node.
- Shared Hypervisor Hardware
Limitations:
- Sharing hypervisor hardware among multiple vSZ instances is not recommended. Each vSZ VM must be deployed on dedicated hardware to prevent resource contention, especially in deployments with thousands of devices.
- A single hypervisor hardware failure could lead to the loss of vSZ N-1 redundancy capability, potentially jeopardizing the entire vSZ cluster and causing service disruptions
- Service disruptions in vSZ can be attributed to the shared hypervisor hardware. Therefore, it is essential to segregate these instances onto different hypervisor hardware to effectively prevent such interruptions.
- RUCKUS discourage deploying different services alongside vSZ on the same hypervisor hardware.
- CPU and I/O Requirements: For optimal performance, vSZ VMs are required to adhere to specific CPU and I/O standards. Benchmarking the CPU and I/O performance of the private hypervisor ensures compatibility with vSZ deployment standards. Disk I/O is critical for vSZ cluster performance; any inadequacy in disk I/O capabilities can result in performance bottlenecks.
Hypervisor Hardware Performance Risk Scenarios
- Running multiple vSZ instances on a shared hypervisor may lead to conflicts over CPU and I/O resources, potentially impacting stability, especially in large-scale deployments.
- Deploying vSZ on a low-performance hypervisor may result in frequent service outages or sluggish performance due to resource constraints.
- Failure in meeting CPU and I/O requirements may lead to suboptimal vSZ performance, including network latency, packet loss, or service downtime during peak usage periods.
- The performance of shared hypervisor hardware may vary, affecting CPU, I/O, and network bandwidth during unexpected situations.
- Failure to reserve sufficient CPU and memory resources for the hypervisor OS will cause performance issues and unexpected problems for running vSZ nodes.
Hypervisor CPU/IO Requirements - Private Hypervisor
- CPU single core events per second/per core need > 180 events/sec
- Required CPU level is higher than the Intel Xeon CPU E5-4620 v4 with 2.10 GHz
IO performance requirement detail
vSZ require high IO performance deploy environment. Measure the hypervisor IO performance before deployment. vSZ IO throughput requirements :
- IO requirement per resource level - Refer to the Disk IO Requirement column in the resource table.
- Avoid network-attached storage (NAS/SAN). The general claim is that the NAS/SAN solution is faster and more reliable than the local drives. NAS/SAN is often slower, displays larger latencies with a wider deviation in average latency, and is a single point of failure.
- Virtual Disk - RUCKUS recommends Thick Preallocated/Eager
Zeroed/Fixed Size to provide good performance and low latency for IO. Avoid
using “Thin Provision “or "Thick Provision Lazy Zeroed/Dynamic Expanding" as
it could impact IO performance. [*].
[*] If there are limitations with the virtualization platform and Thin or Thick Provision/Lazy Zeroed/Dynamic Expanding is the only available option, you can skip the initial validation setup under the understanding of the potential risk of low performance. In a high APs deployment environment, high IO performance is required.
1-vSZ# debug 1-vSZ(debug)# debug-tools [Change to system] Welcome to Debug CLI Framework! (debug tool-set) system $ use sz [Change to sz] (debug tool-set) sz $ skip-setup-capability-check [Execution Done!] (debug tool-set) sz $
Network Latency Requirement between vSZ nodes
A fast and reliable network is important for performance in a distributed system. Low latency helps ensure that nodes can communicate easily, while high bandwidth helps shared movement and recovery. Avoid clusters that span multiple data centers, even if the data centers are located in close proximity. It is highly recommended to avoid clusters that span large geographic distances.
vSZ requires low network latency between vSZ nodes on the control & cluster interface network. vSZ cannot support deployment in high network latency environment.
vSZ interface network latency between nodes: Cluster Interface network latency need < 34 ms.
Before upgrading vSZ to this release, verify that the virtual machine on which vSZ is installed has sufficient resources to handle the number of APs, wireless clients and ICX Switches that you plan to manage. See the resource tables below for the required virtual machine system resources.
The vCPU, RAM, and Disk Size values are interconnected and must fulfill the minimum requirements within each resource level. When adjusting any of these parameters, all three values must be equal to or greater than the requirements of an existing Resource Level. For instance, considering vSZ-H Resource Level 5, if the number of vCPUs is increased from 4 to 6 or more, the RAM must be adjusted to 22GB or more, and the Disk Size must be adjusted to 300GB or more, ensuring compatibility with or exceeding all the minimum values of Resource Level 6. Failure to meet the minimum requirements of level 6 will result in the vSZ remaining at level 5.
Workaround: When deploying vSZ on Nutanix it is recommended to allocate more memory for vSZ usage. For a 10K AP resource level, setup needs 24 core CPU and 50 GB (+2GB) memory to control. Alternatively decrease to 25% AP deployment in vSZ resource level. For example, 7500 AP in 10K AP resource level.
Warning: These vSZ required resources may change from release to release. Before upgrading vSZ, always check the required resource tables for the release to which you are upgrading.
Note: When initially building up the network it can use a higher Resource Level than needed for the number of APs first deployed, if all the three parameters (vCPU, RAM and Disk Size) match exactly with that higher Resource Level.
Attention: It is recommended that there should be only one concurrent CLI connection per cluster when configuring vSZ.
In the following tables the high scale resources are broken into two tables for easy readability. These tables are based on the AP Count Range.
vSZ High Scale required resources
vSZ High Scale required resources
In the following tables the essential scale resources are broken into two tables for easy readability. These tables are based on the AP Count Range.
vSZ Essentials required resources
vSZ Essentials required resources
Note: [1] - vSZ-H and vSZ-E have different report interval. For example, AP sends the status to vSZ-E every 90 seconds but to vSZ-H it is sent every 180 seconds, which means that vSZ-E need more RAM in scaling environment based on the resource level.
[2] - NICs assigned to direct IO cannot be shared. Moreover, VMware features such as vMotion, DRS, and HA are unsupported.
Public Cloud Platform - Instance Resource Type
In the following tables the high scale resources are broken into two tables for easy readability. These tables are based on the AP Count Range.
vSZ High Scale
vSZ High Scale
In the following tables the essential scale resources are broken into two tables for easy readability. These tables are based on the AP Count Range.
vSZ Essentials required resources
vSZ Essentials required resources
- Note:
- [1] - Increase the vSZ total memory
2~4 GB when running on special or extreme deploy environment when vSZ raise
a memory exceed (90%) alarm. For example:
- Deploy 4-node vSZ cluster on Nutanix with full 30K AP capacity.
- One vSZ node down in 4-node vSZ cluster to long term sustain 30K AP
in 3 alive vSZ nodes.
The solution should be recovered the fail vSZ node as soon as possible. But if user need run 3 nodes with 30K AP in long term sustain, it need to increase the vSZ memory to run.
- All APs with full statistic reports (AVC, HCCD, UE, ...) to the controller on full load stress condition.
- [2] - Required Disk Type
- [3] - If deployed hardware CPU computing performance is not good as recommended in 100 AP resource level, the 2 cores CPU setting cannot be supported. Upgrade to 4 cores instead of 2 cores in this case.
- [4] - If deployed hardware CPU computing performance is not good as recommended Hypervisor (like Hyper-V) in 4-CPU setting to support 1000K AP, upgrade to 6 cores instead of 4 cores in this case.
- [5] - The resource level 6.6 - 6000 AP resource profile level could support to 4-nodes cluster. The total number of supported APs will be up to 18,000 APs in a 4-node vSZ cluster.
- [6] - Resource level 9 is added for situations where resource level 8 cannot sustain the load. It is introduced when level 8 reaches its upper bound in handling heavy loads, especially in fully-loaded vSZ environments. These environments might include configurations with 30,000 access points across thousands of zones, along with resource-intensive features like HCCD, SCI, and MLISA. This upgrade is crucial to ensure optimal performance under such demanding conditions, thereby enhancing the vSZ’s ability to effectively manage complex networks.
- The 6000 AP resource profile level could support to 4 nodes cluster. The total supported AP number will be up to 18,000 APs in a 4-node vSZ cluster.
- Workaround if virtualization platform always need Thin Provision/Lazy Zeroed/Dynamic Expanding case.
Change Log of vSZ Resource Plan
- New support for 3000, 6000 APs resource level for more flexible deployment and better cost effectiveness for customer.
- Due to system limitation for the minimum disk requirement, the base disk size requirement is increased from 100 GB to 150 GB on low level resource profile. This has no impact to upgrade from the previous version. For a new vSZ setup, follow the new disk size specified in the resource table. For an existing vSZ setup, shutdown the VM and increase the disk size.
- As the resource level has hit the system limitation in some case, for the vSZ-E 1024 APs resource level memory is increased from 18 GB to 20 GB. No impact for user to upgrade from previous version. User need to change only the memory setting when encountering memory usage alarm exceeding 90%.
- Adding additional notes vSZ memory required in extreme vSZ deployment and cases.
- New session, vSZ-H instance Resource Allocate Instruction, is added.