TechAgility

Technical Design Considerations for AG and AAC for 10,000 Users 
The two following pages detail the caveats and considerations that need to be addressed when designing an AG and AAC Implementation for up to 10,000 Users

· It should be kept in mind that these details were documented as of January 2006 and as such there have been some changes since then.

· It was anticipated that Citrix would be making reasonable efforts to improve the number of *Tunnels* available to the AG, however as they now have the Netscaler line of products it would seem unlikely that this will be improved on – however Citrix typically likes to announce new products and or improvements to existing products at their US based iForum scheduled later this year and it’s no secret that Citrix is highly likely to be releasing a version 4.5 of something? So perhaps we might see some improvements?

· The AG Enterprise Edition **may** possibly be referring to the new Netscaler VPN Hardware Appliances of the 7000 and 9000 models as these units are capable of supplying up to 2,500 and 5,000 VPN Connections – HOWEVER – these are NOT COMPATIBLE with the AAC and end point analysis functionality, as such they will be considered as not in scope for the purposes of this document.

· It is also somewhat remote that the AAC Functionality will ever be aligned with the Netscaler products due to fundamental differences in both the Architecture and the underlying OS. It seems I might have been off the mark on this – but as to when this might be achieved might be derived from directly from the market? I would suggest that the more people who want to install large installations and want/demand this sort of functionality the more Citrix will focus on getting it out?

Please let me know if this is incorrect, but my current understanding is that the AG is based on Linux? and the Netscaler is based on BSD?

· It is probably also worth pointing out that this design document/brief has already been used as the basis of a Pilot project nearing it’s rollout phase for a customer in North America – more details available on request, just drop me a note?

Technical Details of the Citrix Access Gateway (CAG):

·   2000 is the number of tunnels that a CAG can handle at any one time

·   A tunnel is a connection between a client application and a server application provided by the CAG

·   2000 is a hard limit (imposed by the choice of Architecture, HW and underlying OS), each tunnel takes a little memory and at 2000 tunnels the appliance runs out of memory

·   An ICA session should only use 1 tunnel (assuming session sharing is working) so you can get 2000 users on a gateway
*NOTE regarding Sessions* Be aware that in the unlikely event that a user is initiating multiple sessions from PNAgent, PNClient, Web Interface, ICA Files Then each will "consume" a separate session as session sharing is not possible between different clients – this is by design!

·   In VPN mode each user is likely to use a lot more tunnels than 1, for example a test system is using 3 connections to the exchange server from outlook, so this is 3 tunnels consumed, so if your users are just using email you have already bought the number of concurrent users on the appliance down to around 650, as well as this my system also has 3 other tunnels open to various servers on the corporate network and I am doing nothing other than email

·   You can see how many tunnels your system has open to various servers by using the netstat command

·   The appliance scalability will go down considerably (possibly dramatically??) if they start using kiosk mode, this is running a session on the appliance so you see the same issues that you do with a  terminal server, I have been told that you should not expect more than around 25 users on an appliance if they are all using kiosk mode (PS. I believe that Kiosk mode is being phased out?)
– however I have not seen any official figures So to accurately estimate how many appliances you are going to need you will first have to find out what the full VPN users are doing from remote locations and make an estimate of how many tunnels they are going to use. You will also have to see how they are using ICA, e.g. do they have applications silo’d on servers (please see note above re:sessions – same catch22 – just different way of being caught?) , if so then the ICA sessions may end up using more than one tunnel as they may not be able to session share. Ideally you would run some sort of pilot to get typical user use cases so that you can make an educated estimate on the number of appliances.

Some example numbers would be:

Example 1:
10000 users
90% ICA, 10% full VPN
ICA = 1 tunnel
Full VPN = 10 tunnels (assuming outlook and a couple of other client server apps)
Tunnels = (9000 x 1) + (1000 x 10) = 19000
Assuming 50% concurrency, tunnels = 9500

So 5 appliances per site would just cover it, it would be safer to go with 6 to give a little more flexibility

Example 2:
10000 users
90% ICA, 10% full VPN
ICA = 2 tunnels (due to silo’d apps)
Full VPN = 10 tunnels (assuming outlook and a couple of other client server apps)
Tunnels = (9000 x 2) + (1000 x 10) = 28000
Assuming 50% concurrency, tunnels = 14000
So 7 appliances per site would just cover it, it would be safer to go with 8 to give a little more flexibility

Example 3:
10000 users
80% ICA, 20% full VPN
ICA = 1 tunnel
Full VPN = 10 tunnels (assuming outlook and a couple of other client server apps)
Tunnels = (8000 x 1) + (2000 x 10) = 28000

Assuming 50% concurrency, tunnels = 14000

So 7 appliances per site would just cover it, it would be safer to go with 8 to give a little more flexibility

Example 4:
10000 users
80% ICA, 20% full VPN
ICA = 2 tunnels (due to silo’d apps)
Full VPN = 10 tunnels (assuming outlook and a couple of other client server apps)
Tunnels = (8000 x 2) + (2000 x 10) = 36000

Assuming 50% concurrency, tunnels = 18000

So 9 appliances per site would just cover it, it would be safer to go with 10 to give a little more flexibility

posted on Wednesday, June 28, 2006 12:26 PM

Feedback

# re: Citrix Access Gateway Scalability - Technical Design Considerations for AG and AAC for 10,000 Users 7/3/2006 10:40 AM Shaun Attwood

This is a good starting point for scaling the CAGs. Have you got a similar document for the Advanced Access Control servers?
Have you got more details of the customer in North America regarding scalability / sizing ?
Thanks
Shaun
Remove Comment 83918

# re: Citrix Access Gateway Scalability - Technical Design Considerations for AG and AAC for 10,000 Users 7/3/2006 12:01 PM Dave Caddick

Hi Shaun,
I’ve sent an email your way, if I’ve got the right address?
The main point that causes the issue with sizing is a limitation within the CAG/Net6 Appliance (based as it is on the SuperMicro HW) in that it’s underlying O/S is derived from FreeBSD. (It’s either that or BeOS, I can’t remember which - but as far as I am aware the AG uses one and the Netscaler uses the other)
OK, clear as mud so far? ;-))
My understanding is that this limitation is essentially down to the memory side of things trying to keep track of the various "tunnels". As such my thinking is that the AAC Servers shouldn’t be too hard pressed as they would appear to only come in to play during the initial creation of the sessions, although this would obviously depend on how much Administrators/Security want to call or use the "watch for a bad process/executable"?
I hope that makes some kind of sense?
Remove Comment 83928

# re: Citrix Access Gateway Scalability - Technical Design Considerations for AG and AAC for 10,000 Users and above (Hint - use Netscaler? 7/16/2006 3:17 AM Leo

Hi,
The AG uses Linux Redhat 8 and the NetScaler is based on FreeBSD in conjunction with a proprietary kernel that does the Request Switching.
Newer models of the AG will be using FreeBSD and (I think model 5000) also run of the NetScaler hardware platform.
Clearly having same hardware and OS will mean that the products will merge in some sort of form.
Same story goes for the Terros application firewall that will first move to the FreeBSD/NetScaler HW platform and then be integrated into the NetScaler and avaialable as a licenses option.
Leo.
Remove Comment 85337

written by dcaddick

I Had a client ring in with an issue today, although they are still testing, they wanted to be sure that the Speed Screen Latency was enabled for the users testing from Johannesburg, Sth Africa. They pointed out that they had already checked CTX103204 and CTX344154.
I had a quick check of these and then rang him back and we initiated a GoToAssist Session. I explained the background of the template.ica file as it has been used in the older NFuse Implementations and how it is now based on the default.ica file in ver.4. I also pointed out that there is also the three other "templates" for the ica file depending on the bandwidth available (high, medium and low), and how these can be set by the user under "Advanced Settings" prior to login.
Interestingly the details in the CTX344154 actually appear to be incorrect, although it states in CTX344154 that these ZL States can be set under the [NFuse_IcaWindow] the default.ica file actually states in the preamble at the start of the file that all NFuse_XXX settings are ignored. When we examined the default.ica file for Low Bandwidth the details for the ZL States are just set under the general [Application Settings](?)
After I discussed this with the client he decided that for the moment the default.ica file has been modified to add
ZLKeyboardMode=1
ZLMouseMode=1
so that all users will have this setting enforced. I also pointed out to the client that he really should then check this is the case with further testing to ensure that this is the case. We were unable to test this reliably from his PC at the time due to the fact that he had been running PNAgent on it also and this had appeared to cause some instability on his PC but not others.
I also pointed out that if he wanted to seriously stress test this component/function then he might check out something like www.shunra.com who do have trial copies of their product available that can mimic high latency connections to validate their checks.
+++++++++++++++CTX344154 Details+++++++++++++++++++++++++++++++
To enable SpeedScreen Latency Reduction for NFuse / Web Interface applications, modify the Template.ica (default.ica in Web Interface 4.x) file with the following entries under the [NFuse_IcaWindow] section.

[NFuse_IcaWindow]
ZLKeyboardMode=1
ZLMouseMode=1

Now when you open ICA Connection Center, you will see SpeedScreen Latency Reduction = ON.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Hopefully this is of some help to others? and I’ll chase up the typo(?) with Citrix tomorrow

written by dcaddick