NetScaler Sizing Guide intro
About a year ago Citrix started with the NetScaler Tri-Scale method to scale up, in or out the Citrix NetScaler platform. Although this sounds great and gives you an option to pay-as-you-grow we all understand that we should take proper care for initial sizing. Doing so makes sure your users won’t be disappointed and plain simply pay less $$$.
My focus for this article is small to midrange sized Citrix NetScaler platforms up to the MPX 8600 6 Mbit/s. My experience is based on projects within the Netherlands and unfortunately for me this is as big as it gets. This doesn’t mean you can’t use the information when sizing larger platforms. This is also the reason why you will not find any information about clustering in this article.
This article is a follow up on two earlier articles mainly focused on the performance and sizing of a virtual (VPX) Citrix NetScaler
Access Gateway, now called NetScaler Gateway.
This leads to questions about why there is a difference in theoretical and practical numbers. I’m not Google and therefore can’t answer them all but I will try to answer some of them.
To be able to choose between the different Citrix NetScaler platforms and models we need to know what’s on the market. As you all know Citrix NetScaler comes in three platform flavors called the V(irtual)PX, M(Physical)PX and SDX.
Each of the three platforms come in different editions mainly focused on total amount of bandwidth.
The difference in VPX and MPX mainly is about SSL transactions as the MPX has dedicated Offload capabilities where the VPX, obviously, has not.
When choosing between platform and models there are three important choices:
- Are you allowed to virtualize DMZ functionality; If not the answer is always MPX
- The amount of Bandwidth;
- The amount of SSL transactions.
Citrix NetScaler Bandwidth
Looking at bandwidth each platform and model has its restrictions so it’s highly important to know the bandwidth expectations for your needs. These bandwidth figures are not limited to expected technical limits, the license will actually block bandwidth above the given numbers. Packets will not be dropped but queued which keeps it working but essentially kills user experience.
Figure 2. NetScaler MPX bandwidth comparison. Note that there are heavier MPX models available.
Looking at these figures the choice is quite easy, make sure you know your bandwidth needs and choose wisely according to official specifications.
The hardest choice to make is based on the amount of SSL Transactions per second you are expecting to handle on the NetScaler platform.
To be able to properly choose between different platforms and models we need to understand the anatomy of a SSL Transaction. There are a huge amount of documents available and I’ve read some of them. I will try to sum it up just for the sake of this article. I will add some of the links at the bottom of this article.
When we talk about an SSL transaction we are talking about everything in between the start of an SSL session to the point the SSL session is closed.
- Session start, SSL Handshake;
- Exchange of data over SSL;
- Session closure.
The first step is the most computationally expensive part of an SSL session, the SSL handshake, where the SSL server and the SSL client agree on a number of parameters that establish the security of the connection. This is also the phase where the dedicated SSL Offload capabilities do most of their work.
This is interesting because it’s not as easy as this may sound. Properly written applications would keep the SSL session open even if it might not uses it for a short while. Badly written applications may open and close the SSL session with every single thing they do and therefore taking up way more resources you’d expect!
The second step still uses the SSL Offload capabilities but needs way less performance as the SSL Handshake.
When properly sizing for the amount of SSL transactions we should be looking more at new SSL sessions instead of the total amount of transactions per second. The amount of SSL transactions grows with each different model starting from 1.500 on the MPX 5550 to 9.000 on the MPX 8600. The VPX however has a set number of 500 new SSL requests/second. The amount is much lower in regard to the MPX because of no dedicated SSL Offload capabilities. The VPX number is however a number that best fits a whole range of physical platforms a VPX is able to run on. Because SSL transactions uses CPU these numbers may be a lot higher depending on the actual CPU used. We can therefor safely assume 500 is the minimum amount of SSL sessions/second and may be a lot higher when using a new CPU type and reserving cycles on the hypervisor layer.
Another thing about SSL transactions is that the higher the amount of bits used the more performance it will use. This is not a linear process so when we migrate from 1k to 2k the performance difference is much higher then from 512b to 1k. Remember this because we will eventually migrate to 4k certificates as well!
Final Conclusion on Citrix NetScaler sizing
After this article I guess you are at least beginning to understand that it’s hard to give you one size fits all answers on the correct Citrix NetScaler platform and model. What I hope for is that you now know what to investigate and be able to make this decision for your self.
A funny detail is that Citrix actually just changed the specification sheets for the VPX appliances. Now talking about New SSL sessions per second instead of SSL transactions per second. Something they didn’t do for the MPX, yet?
There is one more thing you should really consider when you’re are going for a MPX 5xxx model. These models only have a single PSU while all the higher models have two. This shouldn’t be a problem when doing HA but if you are only going to use a single device it might be better to pick up a MPX 7500/8200 with 2 PSU’s.
Please leave a comment if you need more information or have information that we can add to the article!
E2EVC NetScaler presentation by Simon Barnes
The Anatomy of an SSL Handshake