Professional Documents
Culture Documents
NetScaler 8 - Design Considerations
NetScaler 8 - Design Considerations
Consulting Solutions
NetScaler Global Server Load Balancing for Presentation Server and Access Gateway (All Editions) Deployments
Overview
Simply deciding to use Server Load Balancing (SLB) and Global Server Load Balancing (GSLB) for Citrix Presentation Server and Citrix Access Gateway deployments is easy. Designing your solution to fit with your business needs requires an understanding of your current architecture, which will likely impact the final implementation of the solution. This article covers the design considerations you must take into account when pursuing the GSLB integrated solution with Presentation Server environments. Topics for consideration are: Presentation Server farm architecture SSL versus non-SSL monitors Server Load Balancing method Global Server Load Balancing method Active/Passive sites Load Balancing Access Gateway Enterprise Edition
Access Gateway Standard Edition and Access Gateway Enterprise Edition terminology and graphics are used interchangeably within this document. Design considerations apply for both editions unless specified otherwise.
Start
Application Launch
Done
Figure 1 - Site-Application Launch Process Flow Note: The determination of the appropriate site occurs before the user selects their application. Depending on the Presentation Server architecture selected, users would end up with different application sets within Web Interface or end up having the Presentation Server sessions cross the WAN link and then cross the public link. These challenges are discussed in the following subsections.
Site A
WAN
94 : 14 ICA
ICA :1 49
Site B
Figure 2 - Single Cross-Site Farm Architecture The following list describes the characterization of the architecture: Both sites are part of the same Presentation Server farm Many applications are delivered through Presentation Server from both sites A few applications are only delivered with Presentation Server from one site. Certain applications have back-end systems (databases)
Each site has its own point of presence into the environment through a local Access Gateway
The goal with a single, cross-site farm is to have users directed to the best site and have as many applications as possible delivered from the closest site. Users should only be delivered applications from the remote site(s) if the local site is unable to fulfill the user request. For this architecture to function, the farm must be capable of communicating cross-site. This means IMA communication must be supported across the WAN. Also, the GSLB feature of NetScaler is informing the user which Access Gateway is most preferred through the different load balancing criteria utilized. The Access Gateway the user is sent to through load balancing is the users point of presence into the production environment for the duration of the session. To better understand this, take the following as an example: NetScaler tells User A to connect to Site A, where the user establishes a session to Site As Access Gateway. User A selects Application B for delivery. Application B is capable of being delivered from either site, but a server in Site B has the least load. Site As Access Gateway delivers Application B from a Presentation Server in Site B due to Presentation Server load balancing. This means the application delivery protocol, ICA, will cross the WAN link for the duration of the Presentation Server session.
Ideally, Application B would have been delivered from a Presentation Server in Site A as it is local to the users pointof-presence into the environment. By incorporating the Zone Preference and Failover functionality and with a minor Web Interface modification, this preferred delivery process can be achieved. Zone Preference and Failover will deliver applications from the most preferred zone (location) based on policy configurations. This can be achieved by doing the following: Create Presentation Server zones for each site and include the respective Presentation Server in the correct zone. Web Interface can create a dynamic client name beginning with WI_. By slightly modifying the Web Interface configuration, the WI_ can be changed to WA_ for Site As Web Interface Servers and WB_ for site Bs Web Interface servers. o On Site As Web Interface, find the C:\inetpub\wwwroot\citrix\accessplatform\app-data\site\serverscripts\session.aspfx file. Modify the line from deviceInfo.setClientName( clientName ) To: deviceInfo.setClientName( clientName.Replace("WI_","WA_") ); o On Site Bs Web Interface, modify the line from deviceInfo.setClientName( clientName ) To: deviceInfo.setClientName( clientName.Replace("WI_","WB_") ); Create two new Presentation Server Policies: o Zone Preference Policy Site A: Preferred Zone: Zone A Backup Zone 1: Zone B Applied this policy to: Client names with WA_* o Zone Preference Policy Site B: Preferred Zone: Zone B Backup Zone 1: Zone A
Applied this policy to: Client names with WB_* This solution will keep users application delivery local to their point-of-presence unless the local Presentation Servers are unable to service the request, which will deliver applications from the next preferred zone.
ICA: 1494
Site A
Access Gateway Web Interface Data Collector Application Silo Replication Traffic Application 1 Backend Application 2 Backend
NetScaler
Site B
WAN
Access Gateway Web Interface ICA: 1494 Data Collector Application Silo Application 2 Backend
Figure 3 - Multiple Cross-Site Farm Architecture Even though this architecture has multiple farms, the overall goal is to have Presentation Server sessions stay local to the site, thus eliminating ICA from the WAN link. This goal has some technical challenges that must be addressed to provide a usable solution. A user can access any application regardless of the site they have established a session to. If an application has a corresponding back-end database, the application, regardless of site, must be able to contact the back end. The two options to overcome this requirement are The Presentation Server can access the application backend over the WAN link. This will undoubtedly result in poor application performance as the data requests and responses must cross the WAN link. The poor performance can be mitigated by implementing either NetScaler and/or WANScaler, depending on the type of traffic being generated. The application back end could be replicated across the WAN link to the remote site. This would improve application performance from the Presentation Server. However, the replication of data could consume the WAN link. This risk can be potentially overcome by utilizing WANScaler between sites to compress and optimize the communication.
Summary
The previous two sections explained the architecture and challenges with a single, cross-site farm and multiple, singlesite farms. The decision on the most appropriate solution will be based on the technical characteristics and the business needs. Regardless of the option selected, the following table will help guide the decision by focusing on the overall benefits and considerations for both options. Benefits Single, Cross-Site Farm
Only one farm to manage and maintain Applications can be hosted in any site No requirement for cross-site replication of application data A WAN link is not needed for intra-farm communication User stays local to the site for the duration of the Presentation Server session Might not require cross-site replication of application data
Considerations
Must allow for intra-farm communication going between sites ICA sessions will cross WAN link versus public link All farms must support the same applications Must optimize access to back-end data that is opposite the WAN link from the Presentation Servers Must optimize the replication of application backend data if the organization requires the Presentation Server access back-end data locally
If the environment cannot implement a WAN optimization, compression, and caching solution like NetScaler or WANScaler, a single, cross-site farm is the best solution as it overcomes the most challenges.
In a large percentage of environments, organizations protect the Access Gateway to Web Interface communication with SSL certificates but do not protect the Web Interface to XML Broker communication. This implementation results in a challenge with the configuration of GSLB. In the end, the goal of Global Server Load Balancing is to provide an IP address for the preferred sites Access Gateway. However, it would be unwise to present a user with an IP address for a site if there are no Web Interface servers or XML Broker servers available. This requires the GSLB decision to take into account the availability of these resources as well.
Certain versions of NetScaler experience this design requirement whereas other versions do not. This section will help overcome potential challenges. 3 This section is only focusing on Access Gateway Standard Edition. The concepts can be used with Access Gateway Enterprise Edition if needed.
A GSLB service will represent a site. This service will take into account the availability of Access Gateway devices, Web Interface servers and XML Broker servers through the use of monitors. Because the service is load balancing Access Gateway devices, the service will operate on SSL_Bridge port 443 as the Access Gateway device must be the SSL endpoint. Certain versions of NetScaler require that any monitor bound to a SSL GSLB service must also be SSL. This is not a problem if Web Interface and the XML Broker servers are secured with server certificates, but in most cases they are not. This type of implementation will not allow for a multi-layer site monitoring for GSLB unless changes are made to the environment. There are essentially two options: Secure the Web Interface and the XML Broker servers with server certificates. This would allow NetScaler to monitor these servers with secured monitors over SSL. Create a NetScaler SSL secured virtual server (vserver) for the corresponding unsecured services (Web Interface and XML Broker). The SSL secured vserver will perform SSL offloading, allowing the unsecured services to continue using HTTP 80.
Web Interface
Web Interface
Service_xml_a_01 172.17.2.28 SSL_Bridge Port 443 GSLB Virtual Server vgslb cag.citrixlab.com GSLB Service gslb_cag_a SSL_BRIDGE 443 172.17.1.12 Monitor gslb_mon_xml_a SSL 172.17.1.28 Site A Vserver_xml 172.17.1.28 SSL_BRIDGE Port 443 Service_xml_a_02 172.17.2.29 SSL_Bridge Port 443
XML Service
XML Service
Service_cag_02 172.17.2.30 SSL_Bridge Port 443 Monitor gslb_mon_cag_a SSL 172.17.1.30 vserver Vserver_CAG 172.17.1.30 SSL_BRIDGE Port 443 Service_cag_01 172.17.2.31 SSL_Bridge Port 443
Access Gateway
Access Gateway
Figure 4 - Secure Web Interface and XML Broker The GSLB Service, operating on SSL_Bridge port 443, will monitor the three sets of components vservers for resource availability (vserver_web, vserver_xml and vserver_cag). Because each vserver is operating on port 443, the corresponding monitors will also operate on port 443. These three monitors can be bound to the GSLB service for the site as there is congruency between the monitor configurations. This solution will require modifications to the Web Interface and XML Broker servers. Also, new server certificates must be generated and installed on the Web Interface and XML Broker servers. Finally, if an enterprise Certificate
Authority (CA) was used to generate the server certificates, the enterprise CA root certificates must be set up and installed on the appropriate devices (Access Gateway, Web Interface, client devices) to complete the SSL communication.
Site A Vserver_web 172.17.1.26 HTTP Port 80 Monitor gslb_mon_web_a SSL 172.17.1.26 vserver Dummy_SSL_Web_A 172.17.1.26 SSL Port 443
Web Interface
Web Interface
vserver Dummy_SSL_XML_A 172.17.1.28 SSL Port 443 Site A Vserver_xml 172.17.1.28 HTTP Port 80
XML Service
XML Service
Service_cag_02 172.17.2.30 SSL_Bridge Port 443 Monitor gslb_mon_cag_a SSL 172.17.1.30 vserver Vserver_CAG 172.17.1.30 SSL_BRIDGE Port 443 Service_cag_01 172.17.2.31 SSL_Bridge Port 443
Access Gateway
Access Gateway
Figure 5 - SSL Offload VServers A new server load balancing vserver (dummy_ssl_web_a and dummy_ssl_xml_a) can be created that operates on SSL port 443, while a second vserver (vserver_web and vserver_xml) using the same virtual IP address and load balancing the same services will operating on HTTP port 80. Monitors for GSLB will be created that operate securely and monitor the vservers that are secured with SSL port 443. In order to complete this configuration, NetScaler uses a self-signed certificate for the dummy SSL vservers. Those vservers will be able to monitor the unsecured server load balancing services operating on HTTP port 80 (service_wi_a_01, service_wi_a_02, service_xml_a_01 and service_xml_a_02). This solution required no modifications to the Web Interface or XML Broker servers. The only certificates required were requested and generated from the NetScaler and only installed on the NetScaler.
based upon what is being load balanced and the types of sessions the server maintains. The following recommendations are for a standard Presentation Server environment:
Alternative Method
Round Robin, Least Response
Justification
Being used purely for ICA encapsulation with SSL, a single end-point will create a single TCP connection to Access Gateway. Access Gateway will then connect to the amount of Presentation Servers on the backend required to fulfill the endpoint's request. As each endpoint creates a single connection, the least connection load balancing method will help to ensure that all Access Gateways are balanced equally. However, if Access Gateway is being used in full SSL-VPN mode, another load balancing method is recommended as additional protocols and ports connecting to Access Gateway could result in uneven performance across devices.
Web Interface
Web Interface is a light Web application, meaning that users do not interact with the site and the site has minimal resource impact. The most important thing from a users perspective when being load balanced to a Web Interface server is that they are being directed to the fastest responding system. By using the Least Response Time load balancing method, users should receive the fastest possible service at that particular time. Requests to the XML Broker directly impact the speed of application enumeration and application launch. Having NetScaler determine the server with the fastest responding XML Broker will help to improve performance.
XML Broker
Least Connections Least Response Least Bandwidth Least Packets Proximity Based
Active-passive sites
Many organizations employ an Active-Passive model when it comes to disaster recovery. In an Active-passive model, one site is always used for user sessions, while a secondary site is used only in the event of a failure at the active site. In essence, the request would resemble the following flow identified in Figure 6.
Figure 6 - Active-passive 1. User makes a request, which goes to the users configured DNS server. 2. The DNS server forwards the request onto NetScaler in Site A, which acts like an authoritative DNS server. The DNS server is also configured with the NetScaler at Site B as a secondary forwarding entry in the event that the NetScaler in Site A is down. 3. NetScaler identifies the site is not able to service the request with the active site and the user is forwarded onto the passive site. However, with a default implementation of Global Server Load Balancing, the site will result in an Active-Active configuration. With minor changes to the Global Server Load Balancing configuration, NetScaler can be used to provide Active-Passive failover between sites. There are a few ways of achieving this functionality and the remainder of this section will discuss two options. Backup Domain Backup Virtual Server
Backup Domain
The easiest method for providing an Active-Passive configuration with Global Server Load Balancing is to utilize the Backup IP option within the GSLB domains configuration. In this configuration, there is only a single GSLB virtual server. Each GSLB service corresponds to a single site. There can be any number of active sites, but only one passive site. As shown in Figure 7, there is one active site (service_vgslb_a) and one passive site (service_vgslb_b). Only the active sites service should be bound to the GSLB virtual server, while the passive sites service is left unbound.
10
Figure 7 - GSLB Services The next step in the configuration is to update the Backup IP for the domain name used by the GSLB virtual server. The Backup IP address should be the IP address used for the passive site. This configuration must be completed at all sites.
When all bound services for the virtual server are offline, NetScaler will respond to the domain request with the IP address configured as the Backup IP. This configuration is a last-ditch option; it assumes the passive site will be available in the event of a disaster at the active site. As soon as any active site comes back online, all new requests will be sent to the active site, bypassing the passive site.
11
Figure 9 Virtual Servers The passive sites virtual server is only bound to the GSLB service corresponding to the passive site, while the active site virtual server is bound to the GSLB service for each active site. This can be seen in Figure 10 Active Site Passive Site
12
Also, only the active sites virtual server contains the domain name, while the passive site is blank. This can be seen in Figure 11. Active Site Passive Site
Figure 11 - Domain Name The next step required to set up an Active-passive configuration takes place within the Advanced tab for the active sites virtual server configuration. An option is available to select another virtual server to act as a backup in the event that the primary virtual server has no services available. By specifying the passive sites virtual server, an Activepassive configuration is complete. Active Site Passive Site
Figure 12 - Backup VServer Selecting the Disable Primary When Down option keeps the backup virtual server (passive site) active when the primary site comes back online. This level of control was not possible with the Backup Domain option detailed earlier.
13
High Availability
In many situations, the goal of load balancing is to provide fault-tolerance in the event of a system failure and not to increase scalability. Scalability concerns when using Access Gateway Enterprise Edition can be overcome by purchasing a larger, more powerful device. By purchasing a bigger device, every user in an organization can potentially be supported from a single device. To provide fault-tolerance, a second device should be purchased and configured for High Availability. With a High Availability configuration, one Access Gateway device (passive) will monitor the second Access Gateway device (active). Session tables and configurations are kept synchronized between the two devices. If the passive device sees a failure of the active device, the passive immediately takes over the responsibility of the active device and re-establishes the sessions on the users behalf. Most users are unaware of the failure as their sessions stay active even though they were transferred between two Access Gateway devices. High Availability is the simplest solution to provide Access Gateway fault-tolerance.
Site A
Figure 13 - Front-End Load Balancer This type of configuration is easy to understand from a configuration and architecture standpoint as the components are separate. However, this solution can be costly as it does require the purchase of at least one additional NetScaler device per site (two if High Availability is used, which is highly recommended).
4
This section is only for Access Gateway Enterprise Edition. Access Gateway Standard Edition does not have this particular design decision.
14
Figure 14 - GSLB Architecture The following explains the architecture: SiteA has two Access Gateway devices, which means there should be two GSLB Services (gslb_cag_a and gslb_cag_b). GSLB_CAG_A o o o Verifies Access Gateway #1 is available with the gslb_mon_a_1 monitor Verifies at least one Web Interface is available at the site by using the gslb_mon_web_a monitor. This monitor is probing the Web Interfaces load balancing virtual server. Verifies at least one XML Broker is available at the site by using the gslb_mon_xml_a monitor. This monitor is probing the XML Brokers load balancing virtual server.
GSLB_CAG_B o o Verifies Access Gateway #2 is available with the gslb_mon_a_2 monitor Verifies at least one Web Interface is available at the site by using the gslb_mon_web_a monitor. This monitor is probing the Web Interfaces load balancing virtual server. This is the same monitor used for Access Gateway #1.
15
Verifies at least one XML Broker is available at the site by using the gslb_mon_xml_a monitor. This monitor is probing the XML Brokers load balancing virtual server. This is the same monitor used for Access Gateway #1.
Although this solution utilizes additional GSLB Services, it is effective at load balancing SSL VPN connections to multiple Access Gateway devices while still using any number of load balancing methods like round robin, least response time, and so on.
16
Notice The information in this publication is subject to change without notice. THIS PUBLICATION IS PROVIDED AS IS WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT. CITRIX SYSTEMS, INC. (CITRIX), SHALL NOT BE LIABLE FOR TECHNICAL OR EDITORIAL ERRORS OR OMISSIONS CONTAINED HEREIN, NOR FOR DIRECT, INCIDENTAL, CONSEQUENTIAL OR ANY OTHER DAMAGES RESULTING FROM THE FURNISHING, PERFORMANCE, OR USE OF THIS PUBLICATION, EVEN IF CITRIX HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES IN ADVANCE. This publication contains information protected by copyright. Except for internal distribution, no part of this publication may be photocopied or reproduced in any form without prior written consent from Citrix. The exclusive warranty for Citrix products, if any, is stated in the product documentation accompanying such products. Citrix does not warrant products other than its own. Product names mentioned herein may be trademarks and/or registered trademarks of their respective companies. Copyright 2007 Citrix Systems, Inc., 851 West Cypress Creek Road, Ft. Lauderdale, Florida 33309-2009 U.S.A. All rights reserved.
Version History
Author Daniel Feller Version 1.0 Change Log Document completed Date December 3, 2007
954-267-3000
http://www.citrix.com
Copyright 2007 Citrix Systems, Inc. All rights reserved. Citrix, the Citrix logo, Citrix ICA, Citrix MetaFrame, and other Citrix product names are trademarks of Citrix Systems, Inc. All other product names, company names, marks, logos, and symbols are trademarks of their respective owners.