With the approaching end of life date for XenApp 5, one of my customers is currently designing their XenApp 6.5 farm and asked for some assistance calculating the amount of data that would be replicated between each zone data collector.

 

Let’s detail the existing environment:

  • XenApp 5 Feature Pack 2
  • Hotfix Rollup Pack 7
  • 350 servers
  • 14 zones in 10 countries globally.
  • Core farm infrastructure (SQL publisher datastore, licence server) located in the same datacentre as the “UK 5″ zone.

 

Here are the zone names and the average number of user logons per day.

 

Zones Logons per day
Australia 400
Singapore 300
UK 1 500
UK 2 150
UK 3 100
UK 4 150
UK 5 1000
Belgium 100
Spain 150
Sweden 100
Italy   1 150
Italy   2 100
Netherlands 2000
Norway 300

 

The customer has had 4 years of good service from their XenApp 5 farm, and plans to replace the farm with a XenApp 6.5 environment following broadly the same design principles.  One key change that the customer will benefit from is the removal of the many SQL replicas that they maintained to provide datastore services for their more remote datacentres.  The XenApp 6.5 design is intended to use a single SQL server (SQL cluster to be precise) to host the datastore, and make use of the new Controller/Worker functionality within XenApp to dramatically reduce the amount of data that needs to be read across the WAN for the IMA startup process.

 

The customer had a specific question about the amount of data that would be replicated between the zone data collectors during normal farm operation.   I soon found that while we document the communication process flows and the quantities of data that are replicated, I could not find a complete worked example with real numbers.  So here we go.

 

IMA uses event-driven data replication.  By this I mean “when something happens in one part of the farm the rest of the farm needs to know about it”.  In this blog post I am not going to discuss data that is written into the datastore, for example when an application is published or a server is added to the farm.  Instead I will focus on those farm changes that cause Zone Data Collectors to push data to each other.  The key session events are:

 

Event Data transmitted (approximate)
Connect 0.19 Kb
Disconnect 0.51 Kb
Reconnect 0.29 Kb
Logoff 0.31 Kb

 

So let’s look at event-driven data replication a bit more closely.  What are we saying here?

 

When a session is started, information is pushed from the ZDC for that zone to all other ZDCs.  So each ZDC will send 0.19KB of data to all other ZDCs in the farm.

 

For my customer’s environment this means that the “pushing” ZDC will send 0.19 x 13 = 2.47 KB of data, but each “receiving” ZDC only receives 0.19KB of data.

 

When calculating the amount of data to be sent and received over each WAN link, we must consider how often the users start sessions and how often they log off per day.  Each user is likely to log on and off at least once per day (note that if they turn their workstation off they are disconnecting from their session which will still send some data over the WAN).  Lets assume that each user logs on in the morning, disconnects and reconnects once during the day (lunchtime?) and then logs off at the end of the day.  How will these numbers look?

 

 

DATA SENT
Zones Logons per day Data sent over WAN link for session startData in KB = number of logons x 0.19 x 13 Data sent over WAN link for disconnectData in KB = number of disconnects x 0.51 x 13 Data sent over WAN link for reconnectData in KB = number of reconnects x 0.29 x 13 Data sent over WAN link for logoffData in KB = number of logoffs x 0.31 x 13 Total quantity of data sent by Zone Data Collector   in KB
Australia 400 988 2652 1508 1612 6760
Singapore 300 741 1989 1131 1209 5070
UK 1 500 1235 3315 1885 2015 8450
UK 2 150 370.5 994.5 565.5 604.5 2535
UK 3 100 247 663 377 403 1690
UK 4 150 370.5 994.5 565.5 604.5 2535
UK 5 1000 2470 6630 3770 4030 16900
Belgium 100 247 663 377 403 1690
Spain 150 370.5 994.5 565.5 604.5 2535
Sweden 100 247 663 377 403 1690
Italy   1 150 370.5 994.5 565.5 604.5 2535
Italy   2 100 247 663 377 403 1690
Netherlands 2000 4940 13260 7540 8060 33800
Norway 300 741 1989 1131 1209 5070
5500
DATA RECEIVED
Zones Logons per day Data Received over WAN link for session startData in KB = number of logons outside of this zone x   0.19 Data Received over WAN link for disconnectData in KB = number of disconnects outside zone x   0.51 Data Received over WAN link for reconnectData in KB = number of reconnects x 0.29 Data Received over WAN link for logoffData in KB = number of Logoffs x 0.31 Total quantity of data Received by Zone Data   Collector in KB
Australia 400 969 2601 1479 1581 6630
Singapore 300 988 2652 1508 1612 6760
UK 1 500 950 2550 1450 1550 6500
UK 2 150 1016.5 2728.5 1551.5 1658.5 6955
UK 3 100 1026 2754 1566 1674 7020
UK 4 150 1016.5 2728.5 1551.5 1658.5 6955
UK 5 1000 855 2295 1305 1395 5850
Belgium 100 1026 2754 1566 1674 7020
Spain 150 1016.5 2728.5 1551.5 1658.5 6955
Sweden 100 1026 2754 1566 1674 7020
Italy   1 150 1016.5 2728.5 1551.5 1658.5 6955
Italy   2 100 1026 2754 1566 1674 7020
Netherlands 2000 665 1785 1015 1085 4550
Norway 300 988 2652 1508 1612 6760
5500

 

 

Some cautionary notes:

 

These calculations show the total amount of data sent and received per ZDC.  For my customer each Zone is in a separate data centre with a WAN link connecting that data centre to the rest of the world, hence I have considered ZDC data to be equal to WAN link data.

 

These calaculations show the total quantity of data for our fictitious scenario where users only logon, logoff, disconnect and reconnect once per day.

 

These calculations show the total data transmitted per day.  We would expect each zone to have peaks and troughs in terms of logon and logoff activity, for exmaple during shift changes or Start-Of-Day and End-Of-Day.

 

 

A note about Inter-Site Replication Links/Replication Topologies etc.

When planning a XenApp farm, or trying to visualise the communication, it is tempting to try to map the functionality to Active Directory.  To do this however is false.  XenApp does not have an equivalent to the inter-site topology generator, analysing the farm structure and implementing the most efficient data replication structure.  With XenApp every ZDC needs to communication with every other ZDC.

 

If you want a mathematical understanding of XenApp replication, consider reading the wikipedia articles about Mesh networks, and fully-connected networks.  Remember, every ZDC needs to know what is happening in all the other zones in the farm.

 

 

References:

 

XenApp 6.5 Enterprise Scalable XenApp Deployments – http://support.citrix.com/article/CTX131102

 

Communication Bandwidth Requirements and Application of IMA Bandwidth Formulas on XenApp for Windows Server 2003  http://support.citrix.com/article/ctx114843

 

Improving Farm Performance and Resiliency with Hotfix Rollup Pack 3 – http://support.citrix.com/article/CTX119922