Geeks With Blogs

News Clicky Web Analytics

web stats View David Caddick (davidcaddick@gmail.com)'s profile on LinkedIn

Search this Site!

Locations of visitors to this page
View My Stats eXTReMe Tracker
This posting is provided "AS IS" with no warranties, and confers no rights. The opinions expressed within are my own and should not be attributed to any other Individual, Company or the one I work for. I just happen to be a classic techie who is passionate about getting things to work as they should do (and are sometimes advertised and marketed as being able to?) and when I can I drop notes here to help others falling in to the same traps that I have fallen in to. If this has helped then please pass it on - if you feel that I have commented in error or disagree then please feel free to discuss with me either publically or privately? Cheers, Dave

Thin Clients, VDI and Linux integration from the front lines.... Raw and sometimes unedited notes based on my experiences with VMware, Thin Clients, Linux etc.

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 Citrix , IT Management , Real Cool Stuff , Microsoft Tips , Security | Back to top


Comments on this post: Citrix Access Gateway Scalability - Technical Design Considerations for AG and AAC for 10,000 Users and above (Hint - use Netscaler? ;-)

# re: Citrix Access Gateway Scalability - Technical Design Considerations for AG and AAC for 10,000 Users
Requesting Gravatar...
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

Left by Shaun Attwood on Jul 03, 2006 10:40 AM

# re: Citrix Access Gateway Scalability - Technical Design Considerations for AG and AAC for 10,000 Users
Requesting Gravatar...
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? ;-)
Left by Dave Caddick on Jul 03, 2006 12:01 PM

# re: Citrix Access Gateway Scalability - Technical Design Considerations for AG and AAC for 10,000 Users and above (Hint - use Netscaler? ;-)
Requesting Gravatar...
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.
Left by Leo on Jul 16, 2006 3:17 AM

Your comment:
 (will show your gravatar)


Copyright © Dave Caddick | Powered by: GeeksWithBlogs.net