NetScaler Sizing for a Gateway use case.

Hello!

I had a question from a Distributor about sizing NetScaler physical appliances for Citrix workloads, it got me thinking:

Has this not been covered already?

I then used a popular search tool in conjunction with a browser and got only a few links, which surprised me. As a result I thought I would create something to help with the sizing process. As there are quite a few variables.

What do you mean Citrix/NetScaler don’t know what the sizing should be?

Well, the problem is that, virtualisation environments can be deployed with some very different users cases. This variability can make it tricky to know what you might need for one customer vs another.

Here is a sample to explain that!

Customer X, has a need for a SSL VPN solution for port 22 switch access for a number of network engineers. Could the CLI be the future? Actually, they will be doing kore automation, but sometimes things require a cli session. No published desktop, they will just connect and run Putty (or something similar).

Customer Y, has a bunch of CAD designers, they use some 3D modelling tools that render graphically the new Space Shuttle. There are plans for day trips to the ISS…

Customer X and Y will have quite different demands on the infrastructure that will be needed.

Who is this for?

Anyone who needs a NetScaler to use the Gateway module to allow external (typically) user access to a Citrix environment.

Pre-requisites

As part of this piece, there will need to be some details known ahead of the purchase of the NetScaler. In some cases, these details will be well understood, in others there might need to be some estimations made to cater for the expected loading.

1. What is the expected user count.
2. Number of entry points.
3. Platform, form factor
4. User profile(s) and the related session
5. Capabilities.

Constraints

In some cases there are specific requirements that environments need to adhere to based on the kind of business that they customer operates in. This typically, might require a certain type of appliance.

For example, there are FIPS based appliances that adhere to the FIPS standard. You can read a bit more about that here. This is typically for US based entities, but can sometimes be a requirement elsewhere too. Customers usually state it up front.

Sizing - how big does the box need to be?

The following sections will expand on the various pre-requisites above. I will use Acme as my sample company, they have these parameters:

10000 Citrix users, 2 Dc’s using Citrix DaaS and they are looking for hardware..

How many users will there be in this setup??

This should be a simple question, that are some specific things that might need to be considered when sizing the remote user loading. Before the pandemic, the typical Citrix concurrency would have been well within the Citrix user count. This is typically higher now, with possibly more users working from remote locations. There are also options within new Citrix license models to have higher user counts added as required. This can happen at any time. User sizing needs to include some space for these kinds of situations.

Entry points and SLA

There has been a statement that there are two data centres in this customer setup, listed above. Thinking about the user count, what happens when DC1 gets taken off line by some sort of natural disaster/fire etc. Will it be expected that all the users will be served out of DC2? Alternatively, will things be different? The Service Level requirement(SLA) is sometimes modified when the first DR issue is invoked. This might be different for different customers.

For example, Acme’s 10,000 users could be split between two main DC's(an active-active arrangement), the SLA for Acme states that only half the users are expected to be served by the surviving DC if there is a DC failure. In some cases, having a second ‘issue’, they loose DC1 for instance, then there is a flood in DC2 - the SLA becomes ‘best effort’. How unlucky could they be?

Platform type, form factor.

In this case the customer has asked for hardware, there are a two different new platform types and quite a few older appliances that could still be used for a gateway workload. Each appliance has a data sheet specification which offers a simple Gateway estimate within the specs. This can be a good starting point, you can take a look here for the complete current sheet. If you need an older one, doing an online search is pretty good for finding them.

Here is an extract of current data sheet, with the Gateway number highlighted.

In this case, the number has a ‘up to….’ format. This assumes the license used will be the biggest for that system and the user sessions are of a typical size. This is helpful then, just not deployment specific.

In terms of other NetScaler Platform Options there are:

• VPX on commodity hypervisor(KVM, Nutanix, Hyper-V, XenServer.
• VPX on Cloud, AWS, Azure and GCP.
• MPX Physical.
• SDX Physical.
• BLX.

SDX hardware.

These have the same hardware specs as the MPX, they just slap a hypervisor (XenServer!) under the covers. Typically, the hypervisor adds a little bit of an over head, just a few percent. The difference between MPX and SDX figures are quite small.

The other thing to keep in mind is that in some cases, to get all the resources for the SDX to serve users might require two virtual instances on the system.

VPX, on the various platforms

These, up until recently, only processed traffic in the Virtual Cores. 14.1 has added the support for Intel QAT cards. This could offer (on-Prem) the ability to give the SSL performance a bit of a boost as they are similar to the SSL/TLS offload cards on the SDX/MPX systems.

Also, Universal Hybrid Multi Cloud has the ability to add vCPU cores by just adding additional memory to the virtual machine. This could also be handy if you need more cores to precess your HDX traffic.

BLX, with DPDK support

BLX has recently had Gateway added to its feature set, it runs in Linux, so there is a big dependency on that host. DPDK adds better core processing, again which could be handy for HDX traffic.

User profiles

In the section above I talked about user Profiles, Customer X and Customer Y. In your deployment there may be some different types of user using the system in different ways. Profiling users can help understanding the load from each. What are the users doing? What does the session size look like?

As I said above, with Citrix, people can use it in lots of different ways. This can have a dramatic effect on the HDX session size. These session sizes are per user and per app.

Published app - 20kbps

Published desktop - 60kbps-400kbps

Published desktop with video - 400kbps -1meg/s

Nvidia Grid session - 20meg - per user.

The Citrix version can also play a part in this.

Using an existing NetScaler system

If there is an existing system, that maybe needs to be replaced, it is possible to get stats from that to see what the load looks like. ICA and throughput metics can be verified and used..

NetScaler GUI

Active Users

Navigate to Citrix Gateway > Monitoring Connections > Active User Session. This shows the list of active user sessions on the Citrix Gateway.

HDX/ICA Users

Navigate to Citrix Gateway > Monitoring Connections > ICA Connection. This shows a list of users who have an ICA connection open through?Citrix Gateway.

NetScaler CLI

Active Users

Run the following command to view list of active user sessions on the Citrix Gateway: show aaa session?

HDX/ICA Users

Run the following command to view list of users who have an ICA connection open through?Citrix Gateway. show vpn icaConnection

There is also Reporting dashboard on the NetScaler, take a look at ICA sessions (one report) and throughput (a separate report). Taking the throughput, dividing by the users gives you an approximate per user loading.

NetScaler Console

This is a good resource to see the same stuff on Console

https://docs.netscaler.com/en-us/netscaler-application-delivery-management-software/current-release/analytics/hdx-insight/view-reports-metrics/user-view-reports-and-metrics.html

Capabilities

I have assumed that all the users are doing HDX proxy, there might be some VPN users on the same setup, this might require some capacity too.

Sizing SSL VPN users is also a bit tricky, just make some assumptions about the ‘typical users’. I usually look at using 400kbps for SSL VPN sessions, as that builds in some capacity.

Would you like to supersize that Sir?

What if the requirement is really big, say bigger that a individual appliance that is available? There are a few options to scale up a deployment to suit whatever you need. A point to keep in mind though, building something that covers, say 50,000 users concurrently might require a suitable building block.

Use a three MPX 16k’s and set them up with GSLB, GSLB gives you scale out options and the ability to build in resilience to the solution.

Objections?

This all looks very complicated, why not just go with:

1. Gateway service! Its a check box, I don’t need to think about it. That is true, Gateway Service(GaaS) is simple and offers a useful solution. There are customers that I talk to that need dedicated infrastructure, GaaS has a shared model, as such it doesn’t suit everyone(logs are shared). Also, you cannot do other services, like SSL VPN at the same time, which might be a requirement.
2. Something else? When using NetScaler with NetScaler Console you get a full view of who connects to what when, a powerful double act.

An Example for Acme

There are a number of factors in the sizing requirements of NetScaler for Citrix workloads. As of today, we sell two physical appliances a 9100 and a 16000. Acme were looking for a solution. I thought some hardware would be good option.

Option 1: In this case I will go with:

• 4 x NetScaler MPX91xx with UHMC for the software entitlement. I can then flex up the throughput to go to whatever I need. I can dial in 95G per box if needed.
• These appliance come with dual power supplies and a lifetime RMA for the hardware.
• My network racks have Cisco switch with 25G ports, creating a couple of LACP channels on each with plenty of connectivity will cover the connections.

Option 2: In this case I will go with:

• 4 x NetScaler SDX16xxx with UHMC for the software entitlement. I can then flex up the throughput to go to whatever I need. I can dial in 250G per box if needed.
• These appliance come with dual power supplies and a lifetime RMA for the hardware.
• My network racks have Cisco switch with 100G ports, creating a couple of LACP channels on each with plenty of connectivity will cover the connections.

What about going Virtual?

Option 3: In this case I will go with:

• UHMC includes 1000G of throughput capacity for the software entitlement to allow the creation of up to 999 VPX appliances. I can then flex up the throughput of each instance to go to whatever I need. In this case the VPX can scale from 10meg up to 100G per instance, so pick your size!
• As they process the load in software cores, slapping on a load of memory would give me a massive number of cores per system. If I need better TLS performance I can add a QAT card. Read me.
• I hope my hypervisor has some decent connections to my Cisco/Juniper/other switches!

Summary

It seems complicated, but it is just a case of working out the type of user load you have and wrapping up the service in some resilience to ensure availability. Hopefully, this was useful to someone.