NetScaler Sizing is a subject often regarded as an Art and not Science. One would always be best off if they let the SE size the platform needed, and in this blog I will overview the process and science involved. No warranty is implied and no expected recommendation output comes from this blog. Careful consideration is the key here, and your NetScaler SE should double check any sizing selections.

With TriScale, NetScalers can scale in three ways: Scale Up, Scale Out, and Scale In. This flexibility is great to enable changes, though we want to start on the appropriately sized platform from the beginning. We size to the applications expected load, and add any headroom for anticipated growth to be covered in the initial acquisition. Scale Up, or Pay-Grow enables a platform (VPX or Appliance) to move up in throughput and feature editions after the initial acquisition, to the platform limits. Scale In and Scale Out can address architectures, redundancy, and provide for growth and consolidation of platforms. One can consolidate several smaller platforms with Scale In, running individual instances of NetScaler over the SDX Appliance, and even consolidate other 3rd party workloads. One can also cluster multiple appliances to Scale Out and grow past a platform’s Pay-Grow limits with Clustering, add Active-Active N+1 redundancy, manage as a single instance, etc…

In establishing your list of applications and expected load, maximize your value and consider all of your needs and possible NetScaler use cases. A specific project may complement a larger need, one may want to add SQL traffic and use DataStream, 3rd party workloads on SDX, HDX Insight and AppFlow visibly, SSL Offload, WebApplicationFirewalling, compression offload for HTTP, Integrated Caching for HTTP and SQL, SSL Proxy for ICA protocol, Microsoft Application Delivery, XenMobile and Micro VPN,… or maybe you are a 4G LTE carrier interested in SIP and Diameter, or maybe you are a Web2.0 shop looking for long lived connection offload, or….       Part of the trouble in documenting the science is the flexibility and diversity of use cases. The point I wish to make is that you want to list up your use cases before you size. Consider the value of a visit from your NetScaler SE and Account Team. Often a feature overview at the whiteboard or a collaborative presentation, in person or via GoToMeeting, can help identify the many values of NetScaler for a given organization. Once you have your use cases and some information on the applications, you can proceed with instance sizing. Also, if you need to run a given instance past its’ platform license limit, you can use a burst license to exceed for 90 days. Expect to see an event that the platform license limit was met. NetScalers can run at maximum CPU and similar conditions, though it is good to size and plan for peak traffic.

Other factors also come into play when sizing, like application silos for budget and change control, security practices, and a possible fleet of smaller instances. Selecting a platform or platform sizing may be driven by a desire for multiple smaller boxes, though this is not necessary. Before the SDX and SRIOV technologies, many would resist a single platform spanning security zones. With the SDX, your Internal, External, and DMZ can all be serviced with the same appliance because discrete instances are separate and the ports are mapped directly to the VM Instance. Single Root IO Virtualization sets the Input/Output ports directly on the VM, making it logically look completely like separate platforms, with no inter-instance security concern. One will also want to consider application silos when sizing. Another SDX bonus is that with separate instances we can upgrade and config one application without impacting another. We would not need to test Application A with config changes on Application B because they each are separate instances. No need to have a change control procedure expand beyond department boundaries or line of business. Security Zones and Change Control used to drive separate platforms, but now more consolidation can be realized safely and securely. One more consideration is the Cisco vPath capability. With vPath, the DataCenter can chain services by adding them to the workload/Application Server’s Port Profile. For a given VM we could chain NetScaler services, ASA Firewalling, and more. The NetScaler’s Web Application Firewall could prevent hacking, and the ASA could protect with application aware and statefull protections. The NS App FW and ASA Network FW compliment and provide an example of service chaining without designing the network with the services (ASA and NetScaler) between the application and network. vPath gets the traffic to the service nodes and back for a more simple, SDN kind of design. With vPath, your architecture could drive more towards a fleet of smaller instances. I think it is worth considering the architectures as it directly impacts sizing and platform selections.

Instance and platform sizing consists of the total platform capacity, and instances you plan to run. Different applications and use cases will drive different key metrics found in the datasheet, like HTTP Transactions per Second, SSL Transactions with 2048bit certs, SSL VPN Concurrent Users for ICA Proxy use case, instances of NetScaler per SDX Platform, etc… When you size each use case, they can be aggregated into an instance or MPX unit, or as multiple instances on an SDX. Note that the SDX enables Platinum features for all instances. With NetScaler MPX, VPX, and NetScaler1000v, one can select Standard, Enterprise, or Platinum feature editions. Also notable, the SSL TPS and VPN Capacity is much less on VPX when compared with the MPX and SDX Appliances which offer hardware SSL Offload.

Feature Editions: Standard, Enterprise, and Platinum are also described in the datasheet. For example, Web Application Firewall will protect your Web Applications HTML and XML from the OWASP top 10, and from information leakage like Credit Card numbers, and the Integrated Cache for 50% NetScaler Disk as a Cache for Web and SQL objects are cool Platinum Features to look for. Global Server Load Balancing, which makes your sites and applications redundant between data centers automatically, AAA4TM, which can take login credentials before providing the application and share SSO, and Web Compression are all good examples of Enterprise Features. Standard Edition includes Load Balancing and Content Switching for Web and SQL, Secure Reverse proxy, … (lots of stuff). Standard Edition covers for the Citrix “Access Gateway” or NetScaler Gateway ICA/SSL Proxy Use case for XenApp & XenDesktop and High Availability for XA/XD

For the Citrix ICA/SSL Proxy Use case for XenApp & XenDesktop, the SSL VPN users per platform on the datasheet is key. Also, the platform throughput is noteworthy. Universal Access Licenses are also available per user, to enable Smart Access for end point scanning, and other SSL-VPN functionality. For ICA bandwidth, check the following blog/blogs/2013/08/27/get-up-to-speed-on-xendesktop-bandwidth-requirements/.

You may want to add Citrix HDX Insight to provide NetFlow, well actually AppFlow, export of ICA session details over IPFIX. Check with your NetScaler SE for the latest sizing with HDX AppFlow enabled, and expect a modest bump up over the ICA/SSL VPN user recommended numbers. We also have a use case for NetScaler to sit transparently inline and provide HDX Insight AppFlow Export called transparent mode and sized similarly. The HDX Sizing Guide is posted for Internal and Partner Access.

Remember, NetScaler was born for the Layer7 Request Switching with HTTP use case to scale up Web Servers, and scale out with Server Load Balancing behind the Secure Reverse Proxy. Straight up Web Applications are sized by bandwidth, HTTP transactions per second, SSL TPS, and these are on the datasheet. Also, the Enterprise Edition and Advanced Edition Features may drive more metrics to consider. Compression Throughput, Integrated Caching projections for disk use,… If you have multiple web applications, try to add them all up per instance you will run them on.

SQL and Datastream sizing is to be considered if you will also add Secure Reverse proxy and balance your SQL. Add Integrated Caching and Scale your Database even further.

Consider your utilization for throughput if you are sizing up Link Load Balancing and Cloud Bridge Connector.

Web Application Firewall sizing will help as you provide anti-hacking protections and approach PCI or HIPPA Regulation Compliance for your Web Apps. Your NetScaler SE can access the specifics throughput metrics per platform and we measure WAF throughput for basic and advanced protections. Advanced protections use more resources as they remember across many sessionless HTTP transactions and can enforce consistency and behavior in a sessionized and advanced manner. Remember, NetScaler added the  Positive Security Model and Learning WAF in 2005 with Teros. With Cisco’s Snort Signatures we also have negative enforcements for the best hybrid model. So gather how much throughput of Basic and Advanced protected applications you have and get your NetScaler SE to check the internal datasheet. Also, basic and advanced protections are detailed in article CTX117471. We have an AppExpert Template for WAF in front of Citrix StoreFront and other applications, and one can start with a Hybrid Posture on any Web Application.

XenMobile with NetScaler is sized under another guide and handled by the Citrix Mobility SE.

What other use cases do we have… I am sure there are nearly infinite ways to set the NetScaler into action, and these above are a few of the common ones. If you can consolidate applications into one instance of NetScaler, then add the use cases together and pick a platform. If you need SDX, the work is similar. For other use cases, remember the throughput limits of a platform, and it is always good to get a SE opinion.

Remember to consider your physical and network connectivity. Ports and SFPs. Power cord preferences maybe?… Dual power supplies needed, if on the small end of the platforms? Along the Pay-Grow theme, one could pick up a Burst License and if they hit the Platform License Limit, they can exceed it to the top tier of the Appliance for 90 days.

Lots of variables and no clear math or slide-ruler guide can fit all the use cases. This blog is a shot at how it is done, and I hope the community will comment and improve this blog for our collective use. Mileage may vary, consult your SE for the best recommendations. Don’t size off this and find any errors, but preferable check by the Citrix Account Team and Partner for the safe guidance and a recommendation you can depend on.