Reference Architecture NetScaler 8.

Consulting Solutions

NetScaler Global Server Load Balancing for Presentation Server Deployments

Overview
Users should not be required to manipulate the infrastructure in order to have their applications successfully delivered. The infrastructure should flex and twist based on the needs of the user and the current infrastructure state. If users are located in London, should they be sent to the same systems as users located in Sydney or New York? Hopefully not! Organizations continue to rely upon global deployments of Citrix Presentation Server to host their most critical business applications. The speed and resiliency of these systems is paramount to the overall efficiency of the users. Users should be guaranteed their application delivery requests are made successfully and seamlessly regardless of the state of the overall environment. A truly resilient application delivery infrastructure should include the following capabilities: Users should be sent to the best worldwide site based on current computing availability Users should not be required to change their workflow or manipulate the system to have the best computing experience

These requirements are not unreasonable; in fact, they are some of the most common requirements related to proper global Presentation Server farm design. The remainder of this reference article will show how many of the most common resiliency issues that plague Citrix Presentation Server and Citrix Access Gateway deployments can be resolved with the use of sense and respond technologies found in NetScalers Global Server Load Balancing.

Initial Architecture
In the initial architecture, an organization chose to create a multi-farm infrastructure due to geographical considerations. Users would be located globally, and the organization wanted to give the users the best application delivery experience available. The following details the characteristics about the environment: Farm Characteristics: Both farms are hosting the same applications. Users would be able to log into any farm and still be delivered their applications. Accessibility Characteristics: To be delivered the applications, an end user would go to a central web site where they would select the geography they are currently in. This selection would route them to the appropriate Presentation Server farm. Load Balancing: o o Users will be load balanced across multiple Access Gateways within a site via DNS round robin. Web Interface will load balance between the XML Brokers with the built in load balancing functionality of Web Interface.

Figure 1 - Initial Architecture 1 The initial architecture, although functional, does pose some challenges to the organization, including: DNS Round Robin: DNS round robin is not an intelligent solution as it routes users between systems without verifying if the system or service is available. In a situation with two Access Gateways, if one Access Gateway was offline, 50% of the user community would be denied delivery of their applications. Multi-Level Monitoring: Access Gateway can only be assigned a single address for Web Interface. If Access Gateways Web Interface is offline, users would still be routed to the Access Gateway, but would not be able to launch new applications as that functionality is offline. Intelligent Monitoring: Simply because a Windows service is in the running state does not guarantee the service is responsive and responding with appropriate information. If the XML Service entered an unresponsive state, the Web Interface could be stuck waiting for a response, resulting in a poor application delivery experience for the user. Workflow Interruption: If any critical component at Site B fails, the entire site would be unavailable as each component requires the other components for proper application delivery. To work around the failure, users would be required to change their workflow and select a different site. Configuration Inconsistencies: A consistent configuration is the easiest to manage, maintain and troubleshoot. However, the current architecture has similar devices with dissimilar configurations.

This architecture includes serious risks for any organization that relies upon Presentation Server to deliver their most critical applications to end users. However, Citrix NetScaler Application Switch, when integrated properly, can provide the resiliency and continuity required. With the inclusion of NetScaler and minor reconfiguration of the Presentation Server, Access Gateway and Web Interface components, the environments resiliency will dramatically improve. Additionally, the risks identified with the initial architecture will be mitigated. The remaining sections explain how the configuration changes impacts the architecture.

A Resiliant Architecture
The steps required to reconfigure the initial architecture to a resilient architecture encompasses three phases:
1

Site B only has a single Access Gateway, Web Interface and XML Service server for simplicity. In an actual production environment, this would represent a single point of failure and would not be recommended.

Phase I: Server Load Balancing Configuration Phase II: Farm Reconfiguration Phase III: Global Server Load Balancing Configuration

Server Load Balancing

The first phase of building the resilient architecture is to overcome the single points of failure inherent with the initial configuration. The NetScaler Application Switch can provide server load balancing capabilities for the critical components of a Presentation Server deployment, which includes Citrix Access Gateway, Web Interface and the Presentation Server XML Broker. Figure 2 depicts the location of the NetScaler devices with regards to the initial architecture. NetScaler is load balancing the appropriate components, but the load balanced pools are not being used for traffic until the farm is reconfigured in Phase II.

Figure 2 - Integration of NetScaler 2 With the inclusion of server load balancing, NetScaler will provide intelligent load balancing to the following components: Access Gateway: Using a single virtual server name and virtual IP address, users will be routed to the most appropriate Access Gateway at the site. NetScaler will employ a monitor to verify the Access Gateway is alive and able to accept user connections. If the monitor reports back with a failure, NetScaler will automatically route new connections to the remaining Access Gateway for the site. Web Interface: Users will be delivered their application list via Web Interface. NetScaler will create a single virtual server name and virtual IP address for the Web Interface load balanced pool. To validate Web Interface is running and responsive, NetScaler will use a specialized monitor to verify the Web Interface site is responding. If the server is responding, but the Web Interface site address (URL) is not, users will not be directed to the Web Interface until the state of the site returns to normal. XML Broker: Using a single virtual server name and IP address, the Web Interface will be able to request application enumerations from an available XML Broker. To validate the XML Broker is running and responsive, NetScaler will use a specialized monitor to verify the XML Broker responds with information about a published application in the Presentation Server farm. This helps overcome the challenges of disruption when the XML Broker is running, but unresponsive.

NetScaler utilizes a set of custom monitors, services and virtual servers to create intelligent load balancing pools, which will be used by each component to help overcome the initial risks. The architecture for NetScalers load balancing implementation is displayed in Figure 3.

Note that the three virtual servers in Error! Reference source not found. are all implemented on the same NetScaler Application Switch, which can be implemented as a single device, or as a high availability pair of NetScalers.

Figure 3 - NetScaler Load Balancing Architecture

Farm Reconfiguration
Once NetScaler has been configured to provide Server Load Balancing for the core components of a Presentation Server deployment, a few modifications are required to the overall configuration of Access Gateway and Web Interface. When these changes are complete, the architecture will resemble Figure 4

Figure 4 - Server Load Balancing The configuration changes allows Access Gateway and Web Interface to use the virtual server addresses for the critical components. Once complete, the items within Site A are fully setup for intelligent load balancing. This architecture overcomes the following architecture challenges: DNS Round Robin: Users are no longer pointing to a DNS entry that is load balanced across multiple Access Gateways via the Round Robin method. Instead, users access the virtual address for the Access Gateway load balanced pool. If Access Gateway is offline or not responding, the device is automatically removed from the load balanced pool. Configuration Inconsistencies: With the use of load balanced pools, Access Gateway configurations within Site A are identical. Initially, Access Gateway was configured to only point to one of the two Web Interface servers. With the inclusion of a load balanced pool, Access Gateway points to the virtual address instead of the physical address, thus eliminating the need for multiple configurations within a site. Intelligent Monitoring: With specialized monitors, NetScaler is able to determine and verify the components are available and responding. In order for the Web Interface servers to be considered available, the server must be responding and the Web Interface site must be available. Likewise, in order for the XML Broker to be considered available, the XML Broker must respond and provide details about a published application. This essentially eliminates the occurrence of being directed to a service that is running but not functioning.

Global Server Load Balancing

The final phase for building a multi-site resilient architecture is to provide proximity and cross-site availability intelligence. This functionality will automatically direct users to the most responsive site with available resources. The NetScaler Global Server Load Balancing feature can be leveraged to direct users to an available datacenter. The Global Server Load Balancing feature is based on NetScalers ability to act as an authoritative DNS server and provide users with an IP address to an available site. Figure 5 gives an overview of the Global Server Load Balancing traffic flow:

Figure 5 - GSLB Data Flow

1. Client makes a DNS request for cag.citrixlab.com 2. The corporate DNS server specifies cag.citrixlab.com as a forwarding domain and hands the request to one of the two NetScalers for resolution 3. The NetScaler at Site A responds to the DNS request. Depending on the global server load balancing method used (static or dynamic proximity), the NetScaler responds with the most appropriate IP address of the Access Gateway virtual server. In the example depicted in Figure 5, it chose Site B with an address of 10.7.128.189. 4. The client connects to the load balancing virtual server at Site B on 10.7.128.189 In order to provide intelligent global server load balancing, users should only be directed to sites where all relevant services are available. It is not sufficient to simply monitor the health of the Access Gateway devices, as it is possible that other critical components such as the Web Interface servers or the XML Brokers have failed, resulting in users being denied delivery of their applications. If any critical component were to become unresponsive, the entire site should be marked as unavailable. This solution can be easily achieved by adding explicit monitors to the global server load balancing services on the NetScaler devices in Site A and Site B. A diagram of the load balancing and global server load balancing architecture is shown in Figure 6.

Figure 6 - Global Server Load Balancing Architecture With the global server load balancing added into the architecture, the following risks are mitigated: Multi-Level Monitoring: The global server load balancing implementation not only determines if the load balanced component (Access Gateway) is available, but also if other required components (Web Interface and XML Broker) are available. This reference architecture defined three layers of availability. If any one layer fails, the entire site will fail, resulting in seamless re-routing of all new connections to an available site. Intelligent Monitoring: The same specialized monitors used in Phase I: Server Load Balancing are also applicable to Phase III: Global Server Load Balancing. The multi-level monitoring employed in this reference architecture utilizes the intelligent monitors to verify Web Interface is running with an available site as well as the XML Broker responding with information. This helps to eliminate being routed to a site with disrupted services. Workflow Interruption: With the inclusion of global server load balancing, users can travel anywhere and be delivered applications in the best possible way without modifying the system. Users will no longer be required to

select their preferred location, the system will sense and respond automatically and seamlessly based on location and availability. Only requiring users to follow a single workflow will help simplify the environment.

Conclusion
Stability, usability and availability are all concerns for global deployments of Citrix Presentation Server and Citrix Access Gateway. How do organizations overcome unforeseen issues? How do users continue to function when there is a disruption in the services of application delivery? The answer is with a proper analysis and design of the environment and the inclusion of advanced technologies like NetScalers Global Server Load Balancing. This article showed the power features like server load balancing and global server load balancing can have to an enterprise implementation of Presentation Server and Access Gateway. With the tightly integrated solution, a typical environment, which requires altering user behavior, can be converted to one that can automatically continue to deliver applications to users when resources or entire sites go offline. This solution not only provides fault tolerance, but it also keeps workers productive, the IT organization optimized and saves the organization millions of dollars in lost revenue in the event of system downtime due to site failures. Actual installation and design consideration articles should be referenced before implementing a similar solution. These documents can be found in the Citrix knowledgebase: Global Server Load Balancing for Presentation Server Deployments Design Considerations Global Server Load Balancing for Presentation Server Deployments Implementation Guide

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 Florian Becker Daniel Feller Daniel Feller Florian Becker Daniel Feller 1.0 Removed configuration details to include in a new implementation guide October 19, 2007 Version 0.1 0.2 .5 Change Log NetScaler and GSLB Details Presentation Server/Access Gateway/Web Interface details First Draft Date August 28, 2007 August 31,2007 September 11, 2007

851 West Cypress Creek Road

Fort Lauderdale, FL 33309

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.