SDX Instance Resource Assignment Guide 1 of 2
Memory and vCPU Requirements for NetScaler VPX
https://support.citrix.com/article/CTX139485
Article | Configuration | 28 found this helpful | Created: 06 Feb 2014 | Modified: 10 Jul 2018
Applicable Products
- NetScaler 12.1 12.0 11.1 11.0 10.5
Information
This article contains information about the license, memory, and Packet Engines (PEs) requirements for a generic NetScaler VPX appliance.
Memory and vCPU Requirements for NetScaler VPX
The NetScaler appliance instantiates the number of PEs based on the number of vCPUs, memory, and licenses. Because of the nature of communication processing between PEs, when a VPX instance is running with multi-PE, the associated vCPUs are reported as 100% busy by the hypervisor performance monitoring tools.
The following table lists the number of PEs that can be configured for a NetScaler VPX appliance, based on the available memory and licenses. The number of vCPUs that you assign must be one more than the number of PEs specified in the table.
| Memory | 2GB | 4GB | 6GB | 8GB | 10GB | 12GB | 14GB | 16GB | 18GB | 20GB | 22GB | 24 GB | 26GB | 28GB | 30GB |
| License | |||||||||||||||
| VPX-10 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| VPX-200 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| VPX-1000 | 1 | 2 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 |
| VPX-3000 | 1 | 2 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 |
| VPX-8000 | 1 | 2 | 3 | 4 | 5 | 5 | 5 | 5 | 5 | 5 | 5 | 5 | 5 | 5 | 5 |
| VPX-5000 | 1 | 2 | 3 | 4 | 5 | 5 | 5 | 5 | 5 | 5 | 5 | 5 | 5 | 5 | 5 |
| VPX-10G | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 9 | 9 | 9 | 9 | 9 | 9 |
| VPX-15G | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 11 | 11 | 11 | 11 |
| VPX-25G | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |
Note: The number of vCPUs = the number of PEs+1. For example, if you have installed a VPX-3000 license and 6 GB memory is available, to add three PEs you must allocate four vCPUs.
Important! Multiple PEs are supported on NetScaler VPX appliance hosted on XenServer and VMware ESX. Also multiple PEs are supported on NetScaler VPX 10.5 build 53.9 onwards for Microsoft Hyper-V.
----------------------------------------------------------------------
Manage crypto capacity
https://docs.citrix.com/en-us/sdx/12-1/crypto-management.html
Starting with release 12.1 48.13, the interface to manage crypto capacity has changed. With the new interface, the Management Service provides asymmetric crypto units (ACUs), symmetric crypto units (SCUs), and crypto virtual interfaces to represent SSL capacity on the NetScaler SDX appliance. Earlier crypto capacity was assigned in units of SSL chips, SSL cores, and SSL virtual functions. See the Legacy SSL chips to ACU and SCU conversion table for more information about how legacy SSL chips translate into ACU and SCU units.
By using the Management Service GUI, you can allocate crypto capacity to the NetScaler VPX instance in units of ACU and SCU.
The following table provides brief descriptions about ACUs, SCUs, and crypto virtual instances.
Table. Unit crypto units
| New crypto units | Description |
|---|---|
| Asymmetric crypto unit (ACU) | 1 ACU = 1 operation per second (ops) of (RSA) 2 K (2048-bit key size) decryption. For further details, refer to ACU to PKE resource conversion table. |
| Symmetric crypto unit (SCU) | 1 SCU = 1 Mbps of AES-128-CBC + SHA256-HMAC @ 1024B. This definition is applicable for all SDX platforms. |
| Crypto virtual interfaces | Also known as virtual functions, crypto virtual interfaces represent the basic unit of the SSL hardware. After these interfaces are exhausted, the SSL hardware cannot be further assigned to a NetScaler VPX instance. Crypto virtual interfaces are read-only entities, and the NetScaler SDX appliance automatically allocates these entities. |
View crypto capacity of the SDX appliance
You can view the crypto capacity of the SDX appliance in the dashboard of the NetScaler SDX GUI. The dashboard displays the used and available ACUs, SCUs, and virtual interfaces on the NetScaler SDX appliance. To view the crypto capacity, navigate to Dashboard > Crypto Capacity.
Allocate crypto capacity while provisioning the NetScaler VPX instance
While provisioning a NetScaler VPX instance on NetScaler SDX, under Crypto Allocation, you can allocate the number of ACUs and SCUs for the NetScaler VPX instance. For instructions to provision a NetScaler VPX instance, see Provisioning NetScaler Instances.
To allocate crypto capacity while provisioning a NetScaler VPX instance, follow these steps.
Log on to the Management Service.
Navigate to Configuration > Citrix ADC > Instances, and click Add.
-
Under Crypto Allocation, you can view the available ACUs, SCU, and crypto virtual interfaces. The way to allocate ACUs and SCUs differs depending on the SDX appliance:
a. For the appliances listed in the Minimum value of an ACU counter available for different SDX appliances table, you can assign ACUs in multiples of a specified number. SCUs are automatically allocated and the SCU allocation field is not editable. You can increase ACU allocation in the multiples of the minimum ACU available for that model. For example, if minimum ACU is 4375, subsequent ACU increment is 8750, 13125, and so on.
Example. Crypto allocation where SCUs are automatically assigned and ACUs are assigned in multiples of a specified number.
Minimum value of an ACU counter available for different SDX appliances table
| NetScaler SDX platform | ACU counter minimum value |
|---|---|
| 22040, 22060, 22080, 22100, 22120, 24100, 24150 (36 ports | 2187 |
| 8400, 8600, 8010, 8015 | 2812 |
| 17500, 19500, 21500 | 2812 |
| 17550, 19550, 20550, 21550 | 2812 |
| 11500, 13500, 14500, 16500, 18500, 20500 | 2812 |
| 11515, 11520, 11530, 11540, 11542 | 4375 |
| 14xxx | 4375 |
| 14xxx 40S | 4375 |
| 14xxx 40G | 4375 |
| 14xxx FIPS | 4375 |
| 25xxx | 4375 |
| 25xxx A | 4575 |
b. For the rest of the SDX platforms, which are not listed on the above Minimum value of an ACU counter available for different SDX appliances table, you can freely assign ACUs and SCUs. The NetScaler SDX appliance automatically allocates crypto virtual interfaces.
Example. Crypto allocation where both ACU and SCUs are freely assigned
4./ Complete all the steps for provisioning the NetScaler instance, and click Done. For more information, see Provisioning NetScaler Instances.
View crypto hardware health
In Management Service, you can view the health of the crypto hardware provided with the NetScaler SDX. The health of the crypto hardware is represented as Crypto Devices and Crypto Virtual Functions. To view the health of the crypto hardware, navigate to Dashboard > Resources.
Points to note
Keep the following points in mind when you upgrade the NetScaler SDX appliance to 12.0 57.xx and higher versions.
Only the SDX user interface gets upgraded, but the hardware capacity of the appliance remains the same.
The crypto allocation mechanism remains the same, and only the representation on SDX GUI changes.
Crypto interface is backward compatible, and it does not affect any existing automation mechanism that uses NITRO interface to manage the SDX appliance.
Upon SDX appliance upgrade, the crypto assigned to the existing VPX instances does not change; only its representation on Management Service changes.
ACU to PKE resource conversion table
| NetScaler SDX platform | ACU | RSA-RSA1K | RSA-RSA2K | RSA-RSA4K | ECDHE-RSA | ECDHE-ECDSA |
|---|---|---|---|---|---|---|
| 22040, 22060, 22080, 22100, 22120, 24100, 24150 (36 ports) | 2187 | 12497 | 2187 | 312 | 256 | 190 |
| 8400, 8600, 8010, 8015 | 2812 | 17000 | 2812 | 424 | 330 | N/A |
| 11515, 11520, 11530, 11540, 11542 | 4375 | 25000 | 4375 | 625 | 512 | 381 |
| 22040, 22060, 22080,22100, 22120 (24 ports) | 4375 | 25000 | 4375 | 625 | 512 | 381 |
| 17500, 19500, 21500 | 2812 | 17000 | 2812 | 424 | 330 | N/A |
| 17550, 19550, 20550, 21550 | 2812 | 17000 | 2812 | 424 | 330 | N/A |
| 11500, 13500, 14500, 16500, 18500, 20500 | 2812 | 17000 | 2812 | 424 | 330 | N/A |
| 14xxx, 14xxx 40G, 25xxx, 25xxx A | 4375 | 25000 | 4375 | 625 | 512 | 381 |
| 14xxx FIPS | 4375 | 25000 | 4375 | 625 | 512 | 381 |
| 14xxx 40S | 4375 | 25000 | 4375 | 625 | 512 | 381 |
| *89xx (8910, 8920, 8930) | 1000 | 4615 | 1000 | 136 | 397 | 4949 |
| *26xxx (26100, 26160, 26200, and 26250) | 1000 | 4615 | 1000 | 136 | 397 | 4949 |
| *15000 50G | 1000 | 4615 | 1000 | 136 | 397 | 4949 |
*On these platforms the PKE numbers are minimum guaranteed values.
How to read the ACU to PKE resource conversion table
The ACU to PKE resource conversion table is based on the following points:
Management Service helps allocate Crypto Resources to each individual VPX. Management Service cannot allocate or promise performance.
Actual performance varies depending on packet size, cipher/Keyex/HMAC (or their variations) used, and so on
The following example helps you understand how to read and apply the ACU to PKE resource conversion table.
Example. ACU to PKE resource conversion for the SDX 22040 platform
Allocation of 2187 ACUs to a Netscaler VPX instance on an SDX 22040 platform allocates crypto resource equivalent to 256 ECDHE-RSA operations or 2187 RSA-2K operations and so on.
Legacy SSL chips to ACU and SCU conversion table
------------------------------------------------------
SDX Instance Resource Assignment Guide 1 of 2
AUG 3, 2017 https://www.citrix.com/blogs/author/andrewsc/
Introduction
After buying a pair of Citrix NetScaler SDXs, installing them into a rack and powering them up, what is the next step?
The next steps would always be to access the management instance, the ‘Service Virtual Machine’ (SVM) and start creating Virtual NetScaler instances on the physical SDX platforms.
To get the best resilience, it’s smart to have two physical SDX platforms within a data center and pair a couple of virtual instances into a High Availability arrangement (so they are Active/Backup for the workload) active on the two separate physical systems. The option to cluster instance is also available should an Active/Active arrangement be required.
This provides a non-service impacting design that can be flexed as needed to deliver service. This can then be made highly available across sites using something like Global Server Load Balancing.
Figure 1 A NetScaler SDX, with a single virtual instance
In terms of a quick start process, there are documents online that describe how to create new instance, if they need reviewing it is possible to read the notes here:
http://docs.citrix.com/en-us/sdx/12/configuring-managing-netscaler-instance.html
The purpose of this document is to provide guidance on how to carve up the resources available on a SDX system, and what the various options are for creating a new instance(s).
The workload itself for which the new instance is required should also be taken into account when estimating the sizing, as different workloads have different requirements from the platform. One of the key benefits of the SDX is the option to revise allocation as needed, so to some extent it would be possible to make a rough estimate initially and then revise this up or down as needed. Using either the inbuild dashboard for monitoring or using NetScaler Management and Anaytics System to get a view across multiple appliances.
Note: This document will refer to the entities that exist on the SDX as ‘Virtual Instances’ specifically rather than a ‘NetScaler VPX’. Citrix does also sell a NetScaler VPX product, this is a product designed for a range of commercial hypervisors. As a result, in terms of available performance, the virtual instance on the SDX is very different from that available on other platforms. A SDX virtual instance is capable of much higher loading.
Assumptions
It is assumed that:
- The reader understands the assignment of compute resources in a hypervisor based system.
- The reader has some familiarity with the NetScaler Application delivery controller.
NetScaler SDX Models.
This docuement will provide details for the following six SDX systems in the table below:
| SDX system | Instances available in Shipped appliance | Maximum number of instances | Throughput | Platform limit |
| 8015 system | 2 | 5 | 15Gbps | 15Gbps |
| 11515 series | 5 | 20 | 15Gbps | 42Gbps |
| 14020 series | 5 | 25 | 20Gbps | 100Gbps |
| 17550 series | 5 | 40 | 20Gbps | 50Gbps |
| 22040 series | 20 | 80 | 40Gbps | 120Gbps |
| 24100 series | 40 | 80 | 100Gbps | 150Gbps |
Table 1 SDX models
As we have four newer appliances, there will be a separate blog with the details for those systems soon:
The platform limit is the capability that the platform has for throughput flexibility, so how much more can the back plane transfer with the appropriate platform license. As can be seen from the table, these system have great flexibility and so make an excellent starting point for driving up ADC density and so saving cost on things like maintenance.
When buying a SDX there are a couple of choices to add instances, these can be added packs of 3 or 5. Once the packs are added it’s just a question of resource division to define what is allocated to the number of instances that are available. Also, some appliances have slightly different initial instance counts, so you may be getting more to play with.
How resources are assigned to Virtual instances
Inside the SVM management console there are a number of tabs that can be used to verify what the status of the SDX appliance system currently is, choosing the ‘Dashboard’ tab allows the SDX resources to be viewed.
The following screen shot shows an old 20500 platform with 3 x 5 instance packs and the relative throughput available (this is a 50Gbps appliance) and that throughput that is remaining ( just 33Gbps of throughput ) for assignment to new instances. It should be noted that when a virtual Instance is created most of those resources are hard-allocated, generally there is no overcommitment of resources on the SDX. However, there are some exceptions to this rule.
Figure 2 20500 SDX resources
In the example above, the SDX has eight Virtual NetScaler instances that have been created. Some are active and some are down. There are a number of choices when creating an instance, CPU, memory,throughput and SSL core assignment. So, in this case the SDX is hosting a number of Virtual Instances totalling 17GB of throughput with 7 SSL cores assigned for SSL processing along with 24GB of system memory.
These values were assigned via a wizard, which is located under a tab called “Configuration”. This tab houses the various controls the set-up and configure the SDX appliance. The wizard can be used to create new instances and re-configure existing instances.
For example after changing the base platform license to enable more platform throughput with a simple software key it might be necessary to revise the resources available to a running virtual instance. The revision maybe to add or remove throughput capacity to an instance, whatever the administrator needs to manage available resources and workloads.
The following screen shots show the Provisioning Wizard assigning those values, this provisioning wizard is the same for any SDX system. The only difference between models is the resources and throughput available for assignment.
A note on the Docs page points out that most changes don’t require that the instance is rebooted. However If the following parameters are modified: number of SSL chips, interfaces, memory, and feature license, the NetScaler instance implicitly stops and restarts to bring these parameters into effect.
| Step | Description | Rationale |
| 1. | Assigning an Instance name, management address details, feature set, administration profile and description.
|
Basic information for instance, included is the option to provision a Standard, Enterprise or Platinum feature license if that is all that is required. |
| 2. | Assigning of available resources, so in this case memory, SSL cores, throughput allocation mode (fixed or burstable), minimum throughput (MBps), maximum burst throughput (Mbps), Burst priority, PPS and CPU affinity and core assignment.
|
Assigning the capability to the instance for a given requirement. |
| 3. | Creation of an instance specific administration account.
|
A dedicated account for instance management. |
| 4. | Mapping the network connection to the instance
|
This allows the instance to have network connectivity from the SDX base platform. |
| 5. | The last step confirms the details and commits the changes, if an invalid setup has been requested it will be flagged by the wizard at this point.
|
Process completes, errors need to be corrects before being committed with finish. |
Table 3 Instance creation
Available resources and assignment
In Step 2 of the previous section, we had this screen shot:
Figure 3 Instance sizing
This is the important part of the Virtual Instance wizard in terms of resource assignment, as this is where its relative performance gets defined.
Here is a table showing the available resources per SDX system.
| SDX system parameter | 8015 system | 11515-11542 systems | 14020-14100 systems | 17550-21550 systems | 22040-22120systems | 24100,24150 systems |
| CPU type | 1 x four core | 2 x Six core | 2 x Six core | 2 x Six core | 2 x Eight core | 2 x Eight core |
| Available memory | 32GB | 48Gb | 64Gb | 96Gb | 256GB | 256Gb |
| SSL Cores | 4 | 16 | 16 | 36 | 128 | 32 |
| Throughput | 15Gbps | 15-42Gbps | 20-100Gbps | 20-50Gbps | 40-120Gbps | 100-150Gbps |
| CPU Cores including management | 4 | 12 | 12 | 12 | 16 | 16 |
| CPU Cores that are available for allocation | 3 | 10 | 10 | 10 | 14 | 14 |
Table 4 A summary of SDX platform capabilities
The SDX system has just two limits, throughput and instances; everything else is purely dependent on those values. The following sections will detail the specifics around each resource type and how they are related.
It is worth keeping in mind that the SDX is a resource pool, decisions made during the assignment of resources may alter the available resources left to assign to new instances. The sizing metrics available for say the SDX11515 quote this as a 20 instance system with its full allocation of instance packs.
When allocating resources, the options selected below may mean that this is something less than 20 instances for a particular deployment. Here is the details of the various options available:
Memory assignment
| SDX system parameter | 8015 system | 11515-11542 systems | 14020-14100 systems | 17550-21550 systems | 22040-22120systems | 24100,24150 systems |
| Available memory | 32GB | 48Gb | 64Gb | 96Gb | 256GB | 256Gb |
Table 5 Available memory for SDX platforms
Type of allocation? This resource is hard allocated, it is not possible to over commit this resource on the SDX.
On each SDX platform the amount of memory is the same for entry versions as it is for the top version in a particular series. So, the 11515 ships with 48Gb of memory and this is available irrespective of the version purchased (11515 or 11542). The SVM does need a small amount of memory to operate so this leaves around 4Gb less than the memory installed in the system for assignment to instances.
There are some constraints in relation to SSL cores. Memory and SSL Cores are interlinked, so when assigning each SSL core it will be necessary to assign 1Gb of memory per core.
SSL Cores
| System parameter | 8015 system | 11515-11542 systems | 14020-14100 systems | 17550-21550 systems | 22040-22120 systems | 24100,24150 systems |
| SSL Cores | 4 | 16 | 16 | 16 | 128 | 32 |
Table 6 SSL Cores available for SDX platforms
Type of allocation? This resource is hard allocated, it is not possible to over commit this resource on the SDX. As previously stated the SSL core and the memory assignment are related.
The actual number of SSL cores available for assignment is not dependent on the platform license that has been purchased, although SSL performance is related to throughput, more throughput will allow a higher processing of SSL traffic.
There is an option to create a virtual instance that has no dedicated SSL cores assigned, in this case software based SSL will be used. Software based SSL will get processed by the CPU. As a result, it may have less overall performance compared to an instance with dedicated SSL core(s) again depending on the traffic profile.
In this case, the term ‘SSL Core’ is used to represent an assignment in hardware of a number of Cavium cores. Different appliances have more Cavium cores which then operate in cryptographic blocks which are used to from virtual functions. The representation of them as SSL Cores in the SVM is for guidance.
Throughput
| system parameter | 8015 system | 11515-11542 systems | 14020-14100 systems | 17550-21550 systems | 22040-22120 systems | 24100,24150 systems |
| Throughput | 15Gbps | 15 – 42Gbps | 20-100Gbps | 20-50Gbps | 40-120Gbps | 100-150Gbps |
Table 7 Throughput available for SDX platforms
Type of allocation? This resource can be hard-allocated or set to be burstable; the throughput is measured as the sum of the received traffic into the NetScaler. Exceeding a specified value will trigger the appliance to drop traffic on the fixed setting. When using the burstable option, options are available to allow over commitment of throughput above the set throughput value that is required. The burst priority then sets which instance take precedence when two instances both need a set burst amount.
To be clear, the ‘burst’ value is the value in addition to the minimum throughput to provide the maximum that the instance can flex up to. Billing metrics can be used to track how often this happens, so allowing the usage to be tracked.
Figure 4 Burst tracking on an instance
In terms of assigning the required throughput per instance, the overall platform license will determine what is available before instances are created, so this might be 15Gb or 150Gb for example, using Pay-As-You-Grow this can change with the specific SDX that has been obtained.
CPU core assignment
| system parameter | 8015 system | 11515-11542 systems | 14020-14100 systems | 17550-21550 systems | 22040-22120 systems | 24100,24150 systems |
| CPU Cores including management | 4 | 12 | 12 | 12 | 16 | 16 |
Table 9 CPU cores available for SDX platforms
Type of allocation? This really depends on the choices made in the wizard, if resources are hard allocated this will reduce the number of cores that can be shared between remaining instances on the SDX system. All cores are available for a given platform across all licenses for that platform.
Regarding number of cores available for shared instances. There is no limit to assign a single core for shared instances. Instead, the appliance attempts to use all available cores (that haven’t been allocated for dedicated instances) for shared instances and distributes instances across these cores.
So, if you have 10 physical cores available on the appliance and you create 10 shared instances, each shared instance gets its own physical core. But when the number of shared instances start to exceed the number of available cores, then the same physical core is shared amongst multiple instances. So, in the above example, the 11th instance shares a physical core with the 1st instance, the 12th with the 2nd and so forth.
In short, the appliance follows a best-fit algorithm for shared instances based on the number of available cores. This also gives the user the ability to mix and match dedicated and shared instances. For example, the user can create 5 dedicated instances with one core each, and 10 shared instances to be allocated across the remaining 5 cores.
The CPU cores assigned relates directly to the number of packet engines that will be assigned (maximum) to the virtual instance running on the SDX appliance.
Figure 5 SDX Core assignment
Here is a screen shot of the option to set processor affinity (see above). This screen shot was taken from a 11500 appliance, the actual number of cores that can be assigned will vary based on the processors in the appliance. Larger systems (22000 systems for example) will allow up to 7 dedicated cores to be assigned.
It should be noted that if cores are dedicated to virtual instances, the number of instances that can be created will be reduced. This is because when the cores have a 1:1 relationship to a virtual instances they are no longer available to be shared between instances. Typically, the actual core allocation cannot span CPU Sockets on platforms with multiple physical CPUs. This means that the core allocation is dependent on prior core allocations and available cores on a per physical CPU basis. As an example, creating two virtual instances on a 11515 appliance each with 5 dedicated cores uses all of the available cores.
Note1 – The cores listed in this document are the physical cores that are available in the system. Hyper-threading will mean that the SDX24040 for example, will appear to have 32 cores. This screen shot below, shows this.
Summary
This document has defined the various options for assigning compute resources to a NetScaler SDX virtual instance, this is purely to make a good initial estimation for the instance. Re-running the provisioning wizard allows for dynamic changes to be applied, without impacting live service.
Further information can be found online: http://docs.citrix.com/en-us/sdx/12/sdx-introduction.html
============= End