Something we all have struggled with is how a XenApp farm communicates internally (Okay maybe not all of us, but some 🙂 ). There are a lot of services and roles involved, and unless you have done your research it can be troublesome to get the overview you need.
So hopefully you will be able to understand a bit more about how xenapp communicates after you have read this post.
First there are a couple of terms that you need to know.
Zones
A zone is a grouping of XenApp servers that communicate with a common data collector. In large farms with multiple zones, each zone has a server designated as its data collector. Data collectors in farms with more than one zone function as communication gateways with the other zone data collectors. The data collector maintains all load and session information for the servers in its zone. All farms have at least one zone, even small ones. The fewest number of zones should be implemented, with one being optimal. Multiple zones are necessary only in large farms that span WANs.
Data Store port 1433 for MSSQL server
The data store is the database where servers store farm static information, such as configuration information about published applications, users, printers, and servers. Each server farm has a single data store.
This usually resides on a MSSQL server.
Data Collector
A data collector is a server that hosts an in-memory database that maintains dynamic information about the servers in the zone, such as server loads, session status, published applications, users connected, and license usage. Data collectors receive incremental data updates and queries from servers within the zone. Data collectors relay information to all other data collectors in the farm. By default, the data collector is configured on the first server when you create the farm, and all other servers configured with the controller server mode have equal rights to become the data collector if the data collector fails. When the zone’s data collector fails, a data collector election occurs and another server takes over the data collector functionality. Farms determine the data collector based on the election preferences set for a server. Applications are typically not published on the data collector.
Web Interface
The Web Interface is where where users access their applications using either Receiver (PNagent service site) or a Web browser.
Citrix XML Broker and the Web Interface
The Citrix XML Broker functions as an intermediary between the other servers in the farm and the Web Interface. When a user authenticates to the Web Interface.The XML Broker Receives the user’s credentials from the Web Interface and queries the server farm for a list of published applications that the user has permission to access. The XML Broker retrieves this application set from the Independent Management Architecture (IMA) system and returns it to the Web Interface.
Independent Management Architecture (IMA) port 2512
Is a service that is used for transferring the background information between Xenapp servers, including server load, current users and connections, and licenses in use.
Independent Computing Architecture (ICA) port 1494
Is a protocol that is used for client-to-server connections.
Local Host Cache (LHC)
A local cache of the data store, which allows a server to function in the absence of data store.
I have setup a basic diagram here, which contains a basic setup in Xenapp. Which consists of a
1 * data collector
1 * data store
1 * web interface
And a bunch of Xenapp servers.
And of course we have the users that connect from the wan to the servers.
So lets go trough a couple of scenarios.
What happens when you add a new server to this farm (lets say server 4)
1: Server 4 via the IMA service establishes a connection to the data store for the farm. The service then downloads the information it needs to initialize. It also check that the data in the LHC is current.
2: When the IMA service is the started, it registers with the data collector for the farm and publishes what applications the server is contributing to.
What happens when a client connects to a server? (lets say client 1)
1: The client requests the data collector to resolve the published application to the IP address of the least loaded servers in the farm.
2: The Data collector checks what server has the published applications available, and has the least load.
3. The client then connects to the least loaded server returned by the data collector.
4. The member server then updates its information to the data collector via the IMA service.
What happens if the Data collector goes down ?
1. Data collector server goes down.
2. The servers in the zone recognize that the data collector has gone down and start the election process. In this example the back up data collector is elected as the new data collector for the zone.
3. The member servers in the zone then send all of their information to the new data collector for the zone. This is a function of the number each server has of sessions, disconnected session, and applications.
4. In turn, the new data collector replicates this information to all other data collectors in the farm.
(Incase you have to set a preferred backup data collector) http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-console-zones-config-v2.html
Even if a Data collector is unavailable the servers will continue to function. The users that are already logged in will not be affected.
What happens if a update a setting on a Xenapp server?
1. you make some changes in the Appcenter Server Console affecting all the servers in the farm.
2. The server that the Appcenter Console is connected to updates its LHC and write the change to the data store via IMA.
3. The member server then forwards the change to the data collector for the zone in which it resides. The data collector updates its LHC.
4. The data collector in turn forwards the change to all the member servers in its zone. All servers update their LHCs with the change.
What happens if the Data store goes down ?
1. Data store Server goes down (And you have a backup from the Data store available, If you don’t you would have to recreate all the farm settings) dsmaint backup takes a backup of the data store.
2. Run a dsmaint migrate to migrate the settings to a new data store.
Even if a Data store is unavailable the LHC contains enough information about the farm to allow normal operations for an indefinite period of time. However, no new information can be published, or added to the farm, until the farm data store is online.
If you need to start from scratch with a new data store, prepare a new data store the way you did before configuring XenApp and run the Server Configuration Tool from any farm server. After running the Server Configuration Tool, manually reenter the lost settings. If you use the same name as he previous data store, you do not need to reconfigure the farm servers.