vSZ 5.2.1 System Resource Plan
vSZ Deployment Requirements
Hypervisor Hardware Performance Requirements
CPU Performance Requirement
IO performance requirement detail
Network Latency Requirement between vSZ nodes
High Scale - Maximum number within a cluster
Essential - Maximum number within a cluster
Public Cloud Platform - Instance Resource Type
High Scale:
Essential:
Recommended Machine type for GCP
Note
Alto - Maximum number within a cluster
Change Log of vSZ Resource Plan
AP/Switch resource table
AP and Switch resource table for 1 and 2 nodes
AP and Switch resource table for 3 and 4 nodes
SZ Events/Alarms Capacity Limitation
SZ Applications Detail Attributes
History (for original 7 resource levels for AP count - vSZ-E: 100, 1000; vSZ-H: 100, 500, 1000, 2500, 10000)
vSZ Deployment Requirements
Hypervisor Hardware Performance Requirements
vSZ require enough hardware resource to sustain the service. vSZ can't support deployment in low performance hypervisor.
vSZ need deploy on dedicated hardware resource to avoid different VM instance grab CPU/IO resource and impact vSZ stability in one
hypervisor, especially deployment thousands of APs per node.
vSZ need reach both CPU and IO requirement. Please follow "How to benchmark vSZ CPU/IO Performance" chapter to measure the private
hypervisor performance
Disks IO is most important in vSZ cluster. Disk IO is the slowest subsystem in a server, which means that write-heavy clusters can easily saturate
their disks, which in turn become the bottleneck of the cluster.
Hypervisor CPU/IO Requirements - Private Hypervisor
CPU Performance Requirement
CPU single core events per second/per core need > 180 events/sec
IO performance requirement detail
vSZ require high IO performance deploy environment. Please measure hypervisor IO performance before deployment. vSZ IO throughput
requirements :
IO requirement per resource level - Please refer to the resource level table column "Disk IO Requirement" .
Avoid network-attached storage (NAS/SAN). People routinely claim their NAS/SAN solution is faster and more reliable than 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 - Preallocated/Eager Zeroed/Fixed Size is required to provide good performance and low latency for IO.
Please avoid to use "Thick Provision Lazy Zeroed/Dynamic Expanding" to impact IO performance. [*]
How to benchmark vSZ CPU/IO Performance
vSZ setup process will detect the IO performance at first setup step
Please use SZ CLI in debug-tools->system->system performance. The command will run system benchmark on CPU and IO for vSZ.
Network Latency Requirement between vSZ nodes
A fast and reliable network is obviously important to performance in a distributed system. Low latency helps ensure that nodes can communicate easily,
while high bandwidth helps shard movement and recovery. Avoid clusters that span multiple data centers, even if the data centers are located in close
proximity. Definitely avoid clusters that span large geographic distances.
vSZ requirement low network latency between vSZ nodes on the control & cluster interface network. vSZ can't support deployment in high network latency
environment.
vSZ interface network latency between nodes
Cluster Interface network latency need < 60 ms
High Scale - Maximum number within a cluster
AP count
range
Maximum
UE
Nodes
per
# of maximum AP per
SZ node
Cluster
(w/o switch)
From
To
10,0
01
30,0
00
300,000
4
20,0
00
200,000
3
10,0
00
100,000
1-2
2,501 5,000
50,000
1,001 2,500
50,000
501 1,000
101
1
5,001
AP/Switch
Capacity Ratio
vCPU[2]
Maximum
Switch
(w/o AP)
10,000
RAM Disk
Size
Disk IO
Requirement[1]
Preserved Event
/Alarm Days
Concurrent CLI
Connection
Resource
Level
Logic
Processor
GB
GB
MiB/s
Max
Max
24
48
600
45
3/7 Days
4
8
5:1
6,000
5:1
4,000
10,000
5:1
2,000
24
48
600
45
3/7 Days
4
7
1-2
5,000
5:1
1,000
12
28
300
30
3/7 Days
2
6.5
1-2
2,500
5:1
500
6
22
300
25
3/7 Days
2
6
20,000
1-2
1,000
5:1
200
4
18
100
20
3/7 Days
2
5
500
10,000
1-2
500
5:1
100
4
16
100
15
3/7 Days
2
4
100
2,000
1-2
100
5:1
20
2-4
13
100
15
3/7 Days
2
3
Preserved Event
/Alarm Days
Concurrent CLI
Connection
Resource
Level
Essential - Maximum number within a cluster
AP count
range
From
Maximum
UE
To
Nodes
per
# of maximum AP per
SZ node
(w/o Switch)
AP/Switch
Capacity Ratio
Maximum
Switch
Cluster
1,025 3,000
60,000
4
2,000
40,000
3
501 1,024
25,000
1-2
101
500
10,000
1-2
1
100
2,000
1-2
(w/o AP)
1,024
vCPU
RAM
Disk
Size
Disk IO
Requirement
Logic
Processor
GB
GB
MiB/s
Max
Max
8
18
250
20
7 Days
2
5:1
600
5:1
400
3
1,024
5:1
204
8
18
250
20
7 Days
2
2
500
5:1
100
4
16
100
15
7 Days
2
1.5
100
5:1
20
2-4
13
100
15
7 Days
2
1
Public Cloud Platform - Instance Resource Type
High Scale:
AP count
range
From
Maximum
UE
To
Nodes
per
# of maximum AP per
SZ node
Cluster
(w/o switch)
30,0
00
300,000
20,0
00
200,000
3
10,0
00
100,000
1-2
10,000
3,001 6,000
60,000
1-2[4]
1,001 3,000
30,000
501 1,000
101
1
10,0
01
6,001
4
Maximum
Switch
Recommended Machine Type
for AWS
Recommended Machine type
for AZure
Disk IO
Requirement
GB
(w/o AP)
6,000
10,000
Minimum Disk
Size
600
c4.8xlarge (36 vCPU/60 GB
RAM)
F32s_v2 (32 vCPU/64 GB RAM)
45
2,000
c4.8xlarge (36 vCPU/60 GB
RAM)
F32s_v2 (32 vCPU/64 GB RAM)
600
45
6,000
1,200
c4.4xlarge (16 vCPU/30 GB
RAM)
F16s_v2 (16 vCPU/32 GB RAM)
300
35
1-2
3,000
600
m4.2xlarge (8 vCPU/32 GB
RAM)
D8s_v3 (8 vCPU/32 GB RAM)
300
25
20,000
1-2
1,000
200
r4.xlarge (4 vCPU/30.5 GB
RAM)
E4s_v3 (4 vCPU/32 GB RAM)
100
20
500
10,000
1-2
500
100
m4.xlarge (4 vCPU/16 GB RAM)
D4s_v3 (4 vCPU/16 GB RAM)
100
15
100
2,000
1-2
100
20
r4.large (2 vCPU/15.25 GB
RAM)
DS11_v2 (2 vCPU/14 GB RAM)
or
D4s_v3 (4 vCPU/16 GB RAM)
100
15
Nodes
per
# of maximum AP per
SZ node
(w/o Switch)
4,000
Essential:
AP count
range
From
To
Maximum
UE
Cluster
Maximum
Switch
(w/o AP)
Recommended Machine Type
for AWS
Recommended Machine type
for AZure
Disk IO
Requirement
Minimum Disk
Size
GB
3,000
60,000
4
2,000
40,000
3
501 1,024
25,000
1-2
1,024
101
500
10,000
1-2
1
100
2,000
1-2
1,025
600
1,024
20
250
D8s_v3 (8 vCPU/32 GB RAM)
20
250
m4.xlarge (4 vCPU/16 GB RAM)
D4s_v3 (4 vCPU/16 GB RAM)
15
100
r4.large (2 vCPU/15.25 GB
RAM)
DS11_v2 (2 vCPU/14 GB RAM)
or
D4s_v3 (4 vCPU/16 GB RAM)
15
100
m4.2xlarge (8 vCPU/32 GB
RAM)
D8s_v3 (8 vCPU/32 GB RAM)
204
m4.2xlarge (8 vCPU/32 GB
RAM)
500
100
100
20
400
Recommended Machine type for GCP
GCP support "Custom Machine Type w/ Skylake or later". Please follow the vCPU/Memory number based managed AP number in chapter "High
Scale - Maximum number within a cluster" & "
Essential - Maximum number within a cluster".
Note
[1] Required Disk Type
AWS: General Purpose SSD (gp2)
GCE: SSD
Azure: Standard-SSD
[2] None supported machine type
AWS: a1, t2, t3
Azure: A-series, B-series,
[3] If CPU computing performance is not good as recommended, the 2 cores CPU setting can't be supported. Please upgrade to 4 cores instead
of 2 cores in this case.
[4] The 6000 AP resource profile 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.
User could skip this setup validation and user has to understand the risk user skip. In high APs deployment environment, high IO performance is
required.
CLI # debug
CLI(debug)# debug-tools
(debug tool-set) system $ use sz
(debug tool-set) sz $ skip-setup-capability-check
Alto - Maximum number within a cluster
Currently Alto resource plan is same as vSZ High Scale, please refer vSZ High Scale resource plan, thanks.
Change Log of vSZ Resource Plan
[1] Modify the public cloud support resource plan table to match public cloud official resource type.
AP/Switch resource table
Please refer [SZ/Switch-M] Management capacity design for AP/Switch capacity determining rule.
SZ5.1 support dynamic(linear) AP/Switch capacity base on capacity ratio. No fix AP/Switch mode, only mix mode and AP/Switch
support number base on total amount connect AP/Switch capacity.
Capacity Ratio
High scale profile with higher switch support capacity ratio to "5 : 1" form "8 : 1".
vSZ-H L6 ~ L8
5 : 1 (10000 AP : 2000 Switch)
Example:
1. 200 Aps + 100 switches (1:5)
200 x 1 + 100 x 5 = 700 (Total Capacity) - This requirement could use L5, due to total capacity is smaller than 1000.
2. 400 Aps + 10 switches (1:5)
400 x 1 + 10 x 5 = 450 (Total Capacity) - This requirement could use L4, due to total capacity is smaller than 500
AP and Switch resource table for 1 and 2 nodes
Profile
Capacity
1 Node/2 Nodes
AP Mode
Ratio
Switch Mode
SZ100
1,024
0
5:1
0
204
SZ144
2000
0
5:1
0
400
SZ300
10,000
0
5:1
0
2000
vSZ-E L1
100
0
5:1
0
20
vSZ-E L1.5
500
0
5:1
0
100
vSZ-E L3
1,024
0
5:1
0
204
vSZ-H L3
100
0
5:1
0
20
vSZ-H L4
500
0
5:1
0
100
vSZ-H L5
1,000
0
5:1
0
200
vSZ-H L6
2,500
0
5:1
0
500
vSZ-H L6.5
5,000
0
5:1
0
1000
vSZ-H L8
10,000
0
5:1
0
2000
AP and Switch resource table for 3 and 4 nodes
Profile
Capacity
3 Nodes
AP
4 Nodes
Ratio
Switch
(Total Capacity)
AP
Ratio
Switch
(Total Capacity)
SZ100
2,000
5:1
400
3,000
5:1
600
SZ144
4,000
5:1
800
6000
5:1
1200
SZ300
20,000
5:1
4000
30,000
5:1
6000
vSZ-E L3
2,000
5:1
400
3,000
5:1
600
vSZ-H L8
20,000
5:1
4000
30,000
5:1
6000
SZ Events/Alarms Capacity Limitation
Model
AP Capacity
Preserved
Event Max Rate
Per node (Events/sec)
Event/Alarm Days
SZ100
1,024
7 Days
30
SZ144
2000
7 Days
60
SZ300
10,000
3/7 Days
450
vSZ-E L1
100
7 Days
5
vSZ-E L1.5
500
7 Days
15
vSZ-E L3
1,024
3/7 Days
30
vSZ-H L3
100
3/7 Days
5
vSZ-H L4
500
3/7 Days
15
vSZ-H L5
1,000
3/7 Days
30
vSZ-H L6
2,500
3/7 Days
75
vSZ-H L6.5
5,000
3/7 Days
150
vSZ-H L8
10,000
3/7 Days
300
SZ Applications Detail Attributes
vSZ Essential
(AP-Number)_(UE-Number)
100_2k
500_10k
1k_20k
DB - Cassandra
1280m
1536m
1536m
DB - Elastic Search [2]
1280m
1792m
2048m
Configurer
128m
128m
128m
Communicator
320m
384m
512m
CLI
250m
250m
300m
EventReader
consolidated
consolidated
consolidated
Scheduler
consolidated
consolidated
consolidated
Greyhound
consolidated
consolidated
consolidated
Northbound
consolidated
consolidated
consolidated
StatsHandler
consolidated
consolidated
consolidated
Subscriber Management (IDM)
320m
320m
320m
Core
1536m
1536m
1792m
SCG Universal Exporter
384m
512m
512m
Tomcat
1536m
1536m
1792m
Switchm
256m
384m
512m
Redis
50m
250m
500m
INITDATA
512m
512m
512m
vSZ High Scale
(AP-Number)_(UE-Number)
100_2k
500_10k
1k_20k
2.5k_50k
5k_50k
10K_100K
DB - Cassandra
1280m
1536m
1536m
1792m
1792m
2048m
DB - ElasticSearch
1280m
1792m
2048m
2048m
2048m
4096m
Configurer
128m
128m
128m
128m
256m
256m
Communicator
320m
384m
512m
512m
768m
768m
CLI
250m
250m
300m
300m
300m
300m
Event Reader
consolidated
consolidated
consolidated
consolidated
consolidated
512m
Scheduler
consolidated
consolidated
consolidated
consolidated
consolidated
1024m
Greyhound
consolidated
consolidated
consolidated
consolidated
consolidated
512m
Northbound
consolidated
consolidated
consolidated
consolidated
consolidated
768m
StatsHandler
consolidated
consolidated
consolidated
consolidated
consolidated
1024m
Subscriber Management (IDM)
320m
320m
320m
320m
512m
512m
Core
1536m
1536m
1792m
1792m
1792m
N.A.
SCG Universal Exporter
256m
384m
384m
384m
384m
384m
Tomcat
1536m
1536m
1792m
1792m
2048m
2048m
Switchm
256m
384m
512m
768m
1024m
2048m
Redis
50m
250m
500m
1250m
1250m
2560m
INITDATA
512m
512m
512m
512m
1024m
1024m
Alto
(AP-Number)_(UE-Number)
All applications
100_2k
500_10k
1k_20k
2.5k_50k
Same as vSZ-H
5k_50k
10K_100K
Subscriber Management (IDM)
Disabled
SNMP
Disabled
SCG Enterprise
(AP-Number)_(UE-Number)
sz100(1k_20k)
DB - Cassandra
2048m
DB - Elastic Search
2048m
Configurer
256m
Communicator
512m
CLI
300m
Event Reader
consolidated
Scheduler
consolidated
Greyhound
consolidated
Northbound
consolidated
StatsHandler
consolidated
Subscriber Management (IDM)
1024m
Core
1792m
SCG Universal Exporter
512m
Tomcat
2048m
Switchm
512m
Redis
500m
INITDATA
1024m
SCG Carrier
sz300(10K_150K)
Resource management script would SKIP
and read default configuration from .cnf files
DB - Cassandra
2048m
DB - Elastic Search
4096m
Configurer
256m
Communicator
768m
CLI
300m
Event Reader
512m
Scheduler
1024m
Greyhound
512m
Northbound
768m
StatsHandler
1024m
Subscriber Management (IDM)
512m
Core
N.A.
SCG Universal Exporter
512m
Tomcat
2048m
Switchm
2048m
Redis
4096m
INITDATA
1024m
SSHD Memory Usage Estimation
(AP-Number)_(UE-Number) 10K_100K 100_2k 500_10k 1k_20k 1024_25k 2.5k_50k 5k_50k
SSHD (Total)
SSHD (Per one AP)
History (for original 7 resource levels for AP count - vSZ-E: 100, 1000; vSZ-H: 100, 500, 1000,
2500, 10000)
Release
Memory
Change
CPU
Change
3.0
114
48
3.1
120
+5%
48
-
3.2
123
+3%
50
+4%
3.4
147
+20%
50
-
3.5
148
+1%
50
-
3.6
148
-
50
-
5.0
148
-
50
-
5.1
148
-
50
-
5.1.1
148
-
50
-
5.1.2
148
-
50
-