XenApp member servers replicate their dynamic data to the Zone Data Collector designated for their zone. XenApp uses a star topology for replication among zones, each ZDC replicates all of its zone dynamic data to all other ZDCs in the farm. Thus, it is important to design zones so that there is adequate bandwidth among ZDCs.
When designing zones, the most important variables to consider are latency and bandwidth. If organization has branch offices with low bandwidth or unreliable connectivity, do not place those branch offices in their own zone. Instead, group them with other sites with which they have the best network connectivity. When combined with other zones, this might form a hub-and-spoke zone configuration.
Citrix recommends to have only one zone in a farm unless it has servers in geographically distributed sites. In large environment with data centers on different continents, grouping geographically-related servers in zones can improve farm performance. Citrix does not recommend exceeding 5 zones and max number of zones can be created is limited to 20.
The hardware resources of all data collectors in the farm are sized to accommodate the largest zone. Since data collectors must manage the global state of the farm, they require the same processing capability of the other data collectors in the farm regardless of the size of their particular zone.
The average user session consumes approx 1.6 KB of memory on the data collector. The average server consumes approx 210 KB of memory on the data collector.
Data collector will send an IMAPing every 60 seconds to ensure that the member server is still up and available to service user requests. Likewise, data collectors will perform an IMAPing to each other every 60 seconds to ensure the remote zones are still available.
If ZDC does not receive an update within the configured amount of time from a member server (default 1 minute) in its zone, it sends a ping (IMAPing) to the member server in question. This timeframe can be configured in:
If ZDC does not receive an update within the configured amount of time from a peer ZDC server, it does not continually ping the “lost” ZDC. It waits a default of 5 minutes, which is configurable in:
Note: Reference http://support.citrix.com/article/CTX112525/
During normal farm operation, each Citrix server access the data store every 30 minutes to ensure their LHC is current. During server startup, the IMA Service queries the data store for initialization to ensures the LHC is consistent with the data store. This is the most CPU-intensive action for the data store.
A Farm with 1000 servers, 1000 published applications, 100 worker groups and 10 load evaluators, the IMA data store size requirement will be approximately 500 MB.
The license server uses approximately 4.5KB of memory for every session license and 39KB of memory for every start-up license that is in-use. The license server is capable of processing 248 license check-out requests per second. Over the course of 30 minutes, a single license server would be able to handle 446,400 users login.
XenApp server establishes a static connection to the license server and checks out a Citrix startup license when it is brought online. It consumes 1.68 KB of bandwidth and occurs for every server in the farm. When users login, the XenApp server requests a license from the license server. It consumes 1.04 KB of bandwidth for a license check-out request or check-in request.
Every XenApp servers will contact the license server in every 5 minutes plus interval to ensure its availability and its called as heartbeat . It consumes 366 bytes of bandwidth for each server. The grace period of the License server is 720 Hrs.
Intel Xeon dual core 2.2 GHz server with 2GB of RAM and HyperThreading turned on can handle 9.2 user requests per second.
Worker groups and their memberships are cached in memory in every IMA service for performance. This results in an increase in memory consumption of 8 KB for every worker group in the farm.
When Citrix policies are managed from the AD domain group policy, the sequence of policy refresh and update is as follows:
1. Change is made on the GPMC
2. Within 1½ to 2 hours, member servers pull and apply updates
3. Every 3 hours, AD replication occurs between domain controllers
4. Within 1½ to 2 hours, remote member servers pull and apply updates
When Citrix policies are managed from the XenApp management console, the sequence of policy refresh and update is as follows:
1. Change is made in AppCenter Console
2. Member server writes the policy change to the DS and updates its LHC
3. All servers pull policy information from the DS and updates their LHCs
4. within 1½ to 2 hours, member servers apply updates to the registry