NetScaler SDX Instance Resource Assignment Guide 1 of 2

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:

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.

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.

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

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

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

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

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