Presentation Server Communication Bandwidth Requirements and Application of IMA Bandwidth Formulas

Summary

This section discusses the bandwidth requirements for normal communication in a Presentation Server environment. This information can be used to determine potential bandwidth requirements for WAN-based farms. Data has been gathered from tests performed in the Citrix eLabs using a Microsoft SQL 2005 data store. The results below may not hold true for all situations. Recommendations vary based on how much bandwidth is being used by other network applications.

Bandwidth of Server to Data Store Communication

The amount of data (in kilobytes) read from the data store during the startup of a Presentation Server is approximated by the following formulas:

Citrix Presentation Server 4.5: KB Read = 416.8 + (2.04*(Srvs -1))

Citrix Presentation Server 4.0: KB Read = 436 + 3.15*(Srvs -1)

MetaFrame Presentation Server 3.0: KB Read = 431 + 3.15*(Srvs -1)

Where:
Srvs = Number of servers in the farm
Apps = Number of published applications in the farm

The amount of data read from the data store can require higher bandwidth as the farm size increases and certain actions are executed, especially when several servers are started simultaneously. Most network traffic consists of reads from the database. Citrix recommends that the data store be replicated across all high latency or low bandwidth links. A replicated data store allows all reads to occur on the network local to the Presentation Server, resulting in improved farm performance.

If performance across the WAN is an issue, and having a replicated database at each site is cost-prohibitive, analyze the WAN links for alternative solutions. The IMA service start time ranges from a few seconds to several minutes. When the amount of data requested from the data store by the IMA service is greater than the size of the pipe between WAN segments, IMA waits for all of the data, resulting in longer startup time.

Note: A third-party solution can be used to dedicate a certain size pipe for exclusive use by database traffic to avoid network flooding in WAN environments.

When the IMA service takes a long time to start after a restart, an error can display on the console of the server stating that the IMA service could not be started. The event log can have a message that states that the IMA service hung on starting. These errors are benign. The IMA service starts properly after the requests to the data store are serviced.

Bandwidth of Data Collector Communication

To maintain consistent information between zones, data collectors must relay information to all other data collectors in a farm. The tables on the following pages illustrate the impact to network traffic.

The tables below list the amount of data transmitted for session-based events.

Citrix Presentation Server 4.5 Sharing load information

Citrix Presentation Server 4.5 NOT Sharing load information

Citrix Presentation Server 4.0 Sharing load information

Citrix Presentation Server 4.0 NOT Sharing load information

MetaFrame Presentation Server 3.0

Each time these events occur, the member server sends data to the zone’s data collector, which sends data to all other data collectors in the farm.

The following tables list the amount of data sent by one data collector to another when operations are performed by the Presentation Server Console on servers that reside in different zones. Due to migrations in functionality from the Presentation Server Console and the Access Management Console, network behavior may vary from previous platforms.

Citrix Presentation Server 4.5

Citrix Presentation Server 4.0

MetaFrame Presentation Server 3.0

Limit the use of zones to avoid the cost associated with the replication of zone data.

The bandwidth consumed when you publish an application varies depending on the number of servers in the server farm. In general, the amount of bandwidth consumed increases 466 bytes for every additional server in the server farm. Starting a new server generates the most amount of traffic to the other data collectors. Starting a new server generates about 4.56KB worth of traffic to the data collector in a default configuration.

Note: You can use a third-party solution to dedicate a pipe for IMA traffic, which uses port 2512 by default, to avoid flooding the network in WAN environments.

Application of IMA Bandwidth Formulas

The following sections illustrate the application of the IMA bandwidth formulas.

Initial Boot of a Presentation Server Farm

When a Presentation Server is booted, it must initialize the IMA Service during start up and it must also register with the data collector for the zone in which it resides.

Communication occurs in the following sequence of events:

IMAService establishes a connection to the data store for the farm. IMAService will then download the information it needs to initialize. It will also make sure the data contained in its LHC is current.

After IMAService is initialized, the member server will register with the data collector for the zone. This is a function of the number of published applications the server is contributing to.

Next the data collector will need to relay all of the updated information written by the member servers in the zone to ALL other data collectors in the farm to keep them in sync with each other. The data collector-to-data collector updates are a function of the amount of information that is updated by the member server. The data collectors will only replica the delta, or items that have changed, they do not replicate all of their tables every time an update is sent.

Note: In this example there are only two zones, so the data collector must only replicate the updates it receives from the member servers once to the other data collector. If there were 3 zones, it would have to replicate the same information twice. This causes higher bandwidth consumption and places a higher load on the data collectors in the farm.

Initial boot of a Presentation Server Farm

Note: License communication is not included in this slide. To see the bandwidth utilized for contacting the license server, please see the article License Server Scalability.

Idle Farm Communication

There is a small amount of overhead that IMA must use. The figure above shows the communication that must take place on a farm once it is up and running.

As discussed previously, every 30 minutes IMA performs a coherency check between the member server’s Local Host Cache (LHC) and the data store. If neither has changed, this operation only consumes about 500 bytes of bandwidth. If the check determines that something has changed, the member server will search through the various contexts within the data store to determine what has changed in order to update the information in the LHC.
In order to make sure the Presentation Servers in its zone are functional and able to contribute to published applications, the data collector will send an IMAPing to each of the member servers in its zone, if it has not received an update from the member server within the last 60 seconds. The data collector will also ask the member server for its server load if it has not received a load update within the past 5 minutes.
Finally the data collectors will perform an IMAPing to the other data collectors in the farm to ensure they are still data collectors, and to ensure they are still operational if they have not received an update in the last 60 seconds.

Farm Communication

Event Based Communication

Most IMA traffic is a result of the generation of events. When a client connects, disconnects, logs off, etc. the member server must update information with the data collector in its zone. The data collector in turn must replicate this information to all the other data collectors in the farm. When "Load Share information across zones" is disabled event based communication is reduced by approximately 300 bytes.

The client requests the data collector to resolve the published application to the IP address of the least loaded servers in the farm.

The client will then connect to the least loaded server returned by the data collector.

The member server will then update its information to the data collector for its zone.

The data collector will then forward this information to all the other data collectors in the farm.

Important: Notice in the communication diagram there is no communication to the data store. Connections are independent of the data store and can occur when the data store is not available. Connection performance is not affected by a busy data store.

Example of a client logon event

New Data Collector Election

When a communication failure occurs between a member server and the data collector for its zone or between data collectors, the election process will be initiated. For example:

1. The existing data collector for Zone 1 has an unplanned failure for some reason, i.e. a RAID controller fails causing the server to blue screen. If the server is shutdown gracefully, it will trigger the election process before going down.


2. The servers in the zone will recognize the data collector has gone down and will 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 will 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 will replicate this information to all other data collectors in the farm.

Important: There is a misconception that if a data collector goes down, there is a single point of failure. If the data collector goes down, sessions connected to other servers in the farm are unaffected. The data collector election process is triggered automatically without administrative intervention. Existing, as well as incoming users are not affected by the election process; a new data collector is elected almost instantaneously. Data collector elections are not dependent on the data store.

Example of communication of a farm after a new data collector is elected

LHC Change Events

When configuration changes are modified in the Presentation Server Console the changes are propagated across the farm using directory change notification broadcasts. These broadcasts take place when a change is made that is under 64Kb in size. In Presentation Server 3.0 and earlier, the broadcast would occur if the change was under 10Kb in size. These broadcasts help to minimize WAN traffic and alleviate contention on the data store. The propagation of the change notification is not guaranteed. If a server misses a change notification it will pick up the change the next time it does a LHC coherency check.

Note: Almost all IMA changes are under 64Kb in size.

Example:

The administrator makes a change in the Presentation Server Console affecting all the servers in the farm.

The server that the Presentation Server Console is connected to will update its LHC and write the change to the data store.

The member server will then forward the change to the data collector for the zone in which it resides. The data collector will update its LHC.

The data collector in turn will forward the change to all the member servers in its zone and all other data collectors in the farm. All servers will update their LHCs with the change.

The data collectors in the other zones will in turn forward the update to all the member servers in their zones, and they will subsequently update their LHCs.

Example of LHC change events communication

More Information

See Advanced Concepts Guide - Citrix Presentation Server, Platinum Edition for a list of additional Advanced Concepts Guide articles.