MetaFrame XP server farms can be partitioned into multiple logical segments called "zones." Every server farm has at least one zone (which is created by default when the server farm is established). As an administrator, you can add additional zones and reconfigure existing MetaFrame XP farm servers so that they belong to zones other than the default zone.
Server farm zones in MetaFrame XP serve two purposes:
- Zones allow for efficient collection and aggregation of MetaFrame XP server statistics.
- Zones allow for efficient distribution of server farm configuration changes.
As you have probably guessed, zones are intended to allow server farms to grow efficiently. Large server farms that have their zones properly designed will allow end users to have quick and efficient logons and server connections. A server farm that is partitioned into multiple zones can contain many more servers than a farm that has only one zone. Server farm zones only affect the technical communication aspects of server farms. Zone configuration does not affect any administration or security components.
All MetaFrame XP servers must belong to a server farm, and every server farm must have at least one zone. Therefore, every MetaFrame XP server must also belong to a zone. One zone can contain up to 100 MetaFrame XP servers before performance dictates that more zones should be created. However, this does not necessarily mean you must wait until you have 100 servers before you should create more zones. In the real world, your network architecture will drive the number of zones that you will create.
Each MetaFrame XP server monitors itself for many events, including user logons, logoffs, connections, disconnections, and its server load and performance-related statistics. This self-monitoring is necessary for load-balancing and license tracking to work. Each server actively tracks its own statistics and sends periodic reports to a central location. It is not practical for every single MetaFrame XP server to notify every other MetaFrame XP server in the farm each time one of these user or performance metrics changes. (This is how MetaFrame 1.8 worked and is the reason why it didn't scale very well.) However, it's important that all MetaFrame XP servers know the current status of all the other servers so that farm-wide load balancing and license tracking can function.
As shown in Figure 3.10 (on the next page), a lot of network communication occurs between MetaFrame XP servers in a zone. Considering the fact that the environment in the diagram is made up of only nine servers, you can imagine how much communication would take place if this environment was made up of twenty or thirty servers. This is where zones become necessary.
Figure 3.10: The communication between multiple servers in one zone
A server farm zone is a logical group of MetaFrame XP servers. These MetaFrame XP servers exclusively communicate user load, performance, and licensing statistics with each other. One chosen server within each zone communicates with one chosen server from each of the other zones. Within this model, only one server from each zone sends server-to-server communications throughout the farm, instead of every single MetaFrame XP server trying to communicate with one single MetaFrame XP server.
The "chosen" MetaFrame XP server that communicates with other zones is known as the Zone Data Collector (ZDC). There is only one ZDC per zone, and every zone must have one. The ZDC is the server responsible for knowing all up-to-date statistics about every MetaFrame XP server in the zone, including user load, performance load, and license usage. Whenever any of these monitored parameters changes on any MetaFrame XP server, that server sends notification of the change to its local zone's ZDC. The ZDC then notifies all other ZDCs of the other zones in the farm.
All ZDCs from each zone within a server farm maintain an open connection with all other ZDCs in the farm, forming a hierarchical communication chain that ultimately touches every MetaFrame XP server in the farm.
Figure 3.11 (facing page) shows what the server from Figure 3.10 would look like if it was partitioned into multiple zones. As you can see, network communication is vastly reduced when compared to the diagram that only had one zone.
Figure 3.11: Multiple MetaFrame XP servers in multiple zones
Because each ZDC must maintain an open link to all other ZDCs in the farm, you should try to keep the total number of zones in the farm as low as possible while still having enough zones to be efficient. There is a fine line between too many zones and not enough. We'll take a more in-depth look at this in a bit. For now, remember that any time a user logs on or off, connects or disconnects, or any server load changes, server updates are sent to all ZDCs in the entire farm.
Zone Data Collector (ZDC)
The Zone Data Collector is a role that one MetaFrame XP server performs for each zone within a server farm. You do not have to explicitly configure a server to be a ZDC, because anytime there is more than one MetaFrame XP server in a zone an election takes place to choose the one server that will act as the ZDC. You can, however, change the election preferences of individual servers to affect the outcome of an election, essentially allowing you to select which server you would like to become the ZDC. These preferences range from "most preferred" to "least preferred." Election preference settings are set via the Citrix Management Console (CMC) in the server farm's properties box. (CMC | Farm | Properties | Zone | Highlight Server | Preference)
Zone Data Collector Elections
Zone elections take place automatically within each zone to designate the MetaFrame XP server that will act as the Zone Data Collector. The outcome of the election is decided by the following three criteria, listed in order of precedence:
- Software version number. (The newest version will always win.)
- Manually configured election preference. (As configured in the CMC.)
- Host ID. (The highest host ID will win.)
As you can see by the election criteria, the software version number carries a higher precedence than the manually configured preference in the CMC. This is like an insurance policy, just in case Citrix ever decides to make any radical changes to the operation of the ZDC (in the form of a hotfix or service pack, for example). By designing the election criteria this way, Citrix ensures that the ZDC will always be the most up-to-date server in the zone. As an administrator, it is important to remember this version precedence, especially when you are testing new or beta versions of MetaFrame XP software. If you install a new test version of MetaFrame XP into an existing production zone, the test server will become the ZDC because it will be a newer build than your existing production MetaFrame XP servers. Of course, this can easily be avoided by installing test servers into their own server farms, or at least their own zones.
The final election criterion, the "host ID" parameter, is essentially a tie-breaker if the first two items are the same on more than one server. The host ID is a random number that is generated when MetaFrame XP is installed. The server with the highest host ID will win the ZDC election. You cannot change the host ID. If you would like to change the outcome of an election then you should simply change the "Election Preference" parameter of a server in the CMC.
Now that you understand how the outcome of a ZDC election is determined, let's look at what causes an election to take place.
There are several events that initiate a ZDC election, as outlined below. Any one of these "triggers" can cause an election and there is no order or precedence. Any MetaFrame XP server can call an election by sending out an "election request." Election requests are sent out when any of the following events occur:
- A MetaFrame XP server loses contact with the ZDC. (That MetaFrame XP server will send out an election request.)
- The ZDC goes off-line. (If the ZDC is shut down gracefully it will send out an election request before it shuts down its local IMA service. If the ZDC is unexpectedly shut down then the next MetaFrame XP server that tries to send an update to it will notice that the ZDC is gone and will send out the election request.)
- A new server is brought online. (It sends out an election request as soon as the local IMA service is started.)
- An election is invoked manually by an administrator. This is done with the "querydc -e command." (The server where this command is executed sends out an election request.)
- The configuration of a zone changes (when a MetaFrame XP server is added or removed, or a new zone is created). The server that receives the update from the CMC sends out an election request. Depending on the servers affected by the change, election requests could be sent out to multiple zones.
After a ZDC election is complete, if a new server is elected as the ZDC then every other MetaFrame XP server sends the new ZDC its complete status information. If the newly-elected ZDC is the same server as before the election, the other MetaFrame XP servers are smart enough not to resend their information because they know that the ZDC has their up-to-date information from just before the election.
Remember that each ZDC maintains connections to all other ZDCs in the farm. If a ZDC loses an election, it notifies the ZDCs in other zones that it is no longer the ZDC for that zone. If a ZDC goes off-line, ZDCs from other zones figure out that there is a new ZDC when the new ZDC begins contacting them for information.
If you're familiar with MetaFrame 1.8, then you know about the ICA browser service and the ICA master browser elections. Zones and ZDCs perform similar functions (but are much faster and more reliable). Also, unlike MetaFrame 1.8, there are no backup zone data collectors in MetaFrame XP.
Communication between MetaFrame XP servers and the ZDC
The ZDC maintains the dynamic information of all the MetaFrame XP servers in the zone. Each MetaFrame XP server in the zone notifies the ZDC immediately when any of the following events occurs:
- There is an ICA session logon, logoff, disconnect, or reconnect.
- The server or application load changes.
- Licenses change (used, released, added, or removed).
- A MetaFrame XP server comes online or goes off-line.
- Any published application's settings change.
- A MetaFrame XP server has an IP or MAC address change.
All of this information is collectively known as "session data." No session data is stored permanently on the ZDC. It is all kept in memory for use only by the IMA service. You can view any of this data at any time with the queryds command-line utility.
If a ZDC does not receive any communication from a MetaFrame XP server in its zone after 60 seconds, the ZDC will perform an "IMA Ping" to determine whether the server is still online. You can change this interval by adding the following registry value:
Data: The interval in milliseconds, entered in hex notation. (The 60 second default would be 60,000 milliseconds, or 0xEA60 in hex.)
When entering the registry value, remember that you can use the Windows calculator to convert from decimal to hex. (View Menu | Scientific | Enter your decimal number | click the "hex" button.)
Communication between Zone Data Collectors
As soon as a ZDC receives an update from a MetaFrame XP server, it forwards the information to all other ZDCs in the farm. If the ZDC fails to connect to one of the other ZDCs, it will wait five mintues and then try again. This five-minute interval is also controllable via the registry:
Data: The interval in milliseconds, entered in hex notation. (The 300 second default would be 300,000 milliseconds, or 0x493E0 in hex.)
Looking at the large amount of frequently-changing session data that a ZDC must deal with leads to one question:
Should you build a dedicated Zone Data Collector?
Once your environment grows larger than a few MetaFrame XP servers you may begin to wonder whether you should build a "dedicated" MetaFrame XP server that acts only as a zone data collector without hosting any user sessions.
The ZDCs of larger zones can get very busy. Building a dedicated server is a good way to minimize the risk that a busy zone will impact live user sessions due to a MetaFrame application server that is too busy acting as ZDC.
There are no hard numbers to dictate the point at which you should build a dedicated ZDC. In the real world, if a zone has more than ten servers or so, people tend to build a dedicated ZDC. Of course hardware is always getting faster and faster, so this number may change.
If you are at the point where you don't know whether or not you need a dedicated ZDC, the best thing to do is to look at the performance of the server acting as the ZDC and compare it to servers that are not acting as the ZDC. Refer again to the previous section for a list of how much work the ZDC must do.
If you don't want to dedicate one server to be the ZDC, there is a trick that you can use to still get the best performance possible. All you have to do is pick the server that you want to be your ZDC and configure it for the "most preferred" election preference in the CMC. Then, configure the load balancing for that server so that it takes on fewer users than your other servers. (See Chapter 15 for details.) Doing this will ensure that your ZDC is not impacted by user sessions, allowing the ZDC to perform its tasks as needed.
On the other hand, if you decide to create a dedicated ZDC, the process for configuring it is simple: Install MetaFrame XP on the server; add it to your farm and zone; configure it for the "most preferred" ZDC preference in the CMC; and don't publish any applications to it.
If you build a dedicated ZDC, be sure to remember that you must install any Citrix hotfixes or Service Packs to your dedicated ZDC first, otherwise you run the risk that your dedicated ZDC could lose a ZDC election to a more up-to-date server somewhere else.
Advantages of Building a Dedicated ZDC
- You won't have to worry about the ZDC overhead impacting one of your production MetaFrame XP servers that is hosting user sessions.
- Because MetaFrame XP licensing is connection-based, your dedicated ZDC will not require a Citrix license.
Disadvantages of Building a Dedicated ZDC
- You will need to find, buy, steal, or otherwise acquire an extra server.
- You will need to buy a Microsoft Windows server license for that server.
Why should you care about zone design?
Proper zone design is important. There are several areas that are directly affected by the number of zones and the location of the zone data collectors. These areas include:
- WAN performance.
- Application enumeration.
- Application connection speed.
- Farm change propagation speed.
In a large environment with multiple WAN locations, you need to consider the network bandwidth cost of placing separate zones at each WAN point. Because every ZDC establishes a connection with every other ZDC in the farm, and because all ZDCs update each other whenever anything happens, too many zones will adversely affect WAN bandwidth with all the ZDC traffic. This means that fewer zones are better.
When users request a list of available MetaFrame XP applications, the zone data collector is contacted to return the list of applications that are available to that user. If the ZDC is far away or too busy (because the zone is too large), the user will have to wait a long time for the ZDC response that provides them with their application list. This means that more zones are better.
Application Connection Speed
When users connect to published load-balanced applications, the ZDC is contacted to find out which MetaFrame XP servers run the application and which server has the lightest load. As with application enumeration, if the zone data collector is far away or busy, the user will have to wait a long time for the ZDC response that allows them to attach to the appropriate MetaFrame XP server to start their application session. This also means that more zones are better.
Farm Change Propagation Speed
Any farm-wide configuration changes that are made in the Citrix Management Console must be propagated down to every MetaFrame XP server in the farm. Fortunately, the Zone Data Collectors are leveraged for this update. The ZDCs receive the updates from the server running the CMC and forward the changes to the MetaFrame XP servers in their respective zones. The more zones there are, the faster these updates reach every MetaFrame XP Server. This means that more zones are better, but this is not as important as the first three factors.
As you have seen, there are advantages and disadvantages that will apply no matter how many zones you have.
What are the zone design options?
After the complete analysis of how zones work, everything that they affect, and everything that can affect them, it's finally appropriate to look at the options available when designing zones. There are really only two choices.
With a server farm that spans multiple, physical locations, you can:
- Configure one zone that spans physical locations.
- Configure each location to be its own zone.
Let's look at the details of each option.
Option 1. Create One Zone
Because a server farm zone does not have to be confined to a single geographic location, it's possible to limit WAN communications between locations by creating a large zone that includes MetaFrame XP servers from multiple locations. This is clearly evident back in Figures 3.10 and 3.11.
However, potentially severe consequences could result if only one zone is created for multiple locations. Since this one zone will have only one ZDC, user logons and application enumerations could be slow since each of these actions requires contact with the ZDC which could be on the other side of the WAN. Also, because the ZDC is responsible for distributing farm configuration changes to all MetaFrame XP servers in the zone, one giant zone will force the ZDC to communicate with every single MetaFrame XP server in the zone, potentially sending the same change across the WAN multiple times. (This fact can be seen in the case study at the end of the chapter.)
Advantages of Creating One Zone that Spans Multiple Sites
- All session update information is only sent across the WAN once, to the zone data collector.
Disadvantages of Creating One Zone that Spans Multiple Sites
- User logons, queries, and application enumerations could be slow if the zone data collector is far away from the users.
- More traffic could be generated by MetaFrame XP server-to-ZDC session information updates than is saved by having one zone.
- The MetaFrame XP server-to-ZDC session update information cannot be configured, timed, parsed, queued, or limited (unlike ICA Gateway traffic in MetaFrame 1.8). This is because by definition, it is assumed that all servers in one zone are well-connected, and that bandwidth is plentiful and cheap.
- Farm configuration changes must traverse the network once for every server, because having one zone removes the hierarchy.
Obviously, there can be substantial network performance degradation if only one zone is created when multiple zones are needed.
Option 2. Create Multiple Zones
Splitting a farm into multiple zones is a logical option, especially for larger environments. However, you need to be careful that you do not create too many zones.
Because all ZDCs maintain open connections to all other ZDCs, updates are continually sent between zones. This can affect performance if the bandwidth between zones is limited. There is no way to cut down these updates (unless a third party Quality of Service device is used, like those from Packateer or Sitara. These devices are discussed in Chapter 6.)
Advantages of Creating Multiple Zones
- Local zones allow for fast user logons, application queries, and available application enumerations.
Disadvantages of Creating Multiple Zones
- All background information is replicated to all zone data collectors. (Such is the price for having continuous local, up-to-date information about all zone servers.)
- All zone data collectors need direct access to all other zone data collectors.
In general, you should be careful that you do not create too many zones. Don't create another zone just for the sake of having it, because too many zones can actually hurt your network performance more than not having enough zones.
Considerations when Designing your Zones
Remember that the way you design your zones does not affect the management of the server farm. The number and locations of zones should be based purely on technical factors, which is why the factors listed here are technical. The answers to the following three questions will directly affect zone traffic, and therefore zone design:
- In what ways will users access the applications?
- How many servers are there?
- What is the bandwidth and connectivity between servers?
User Access to Applications
The ways that users access their MetaFrame XP applications and the configuration of those applications will help you determine your zone design. The following four items need to be considered:
- Number of users. The more users there are, the more zones are needed, as more ZDCs will be needed to service user requests.
- Length of the average session. If users log on to their applications and stay on all day, no session information will change on the MetaFrame XP servers and the ZDC will not be contacted, allowing for larger zones. If users log on and off constantly, ZDC updates will be frequent, causing more ZDC load and requiring smaller zones (more ZDCs).
- Number of simultaneous logons. ZDCs are used most heavily as users enumerate and connect to MetaFrame XP servers. Thousands of users logging in simultaneously may overwhelm one ZDC. If all your users start working at the same time, you may need more zones.
- Number of load-balanced published applications. More applications require more zones because there is more application information that must be updated across the farm via the ZDCs.
When designing zones, you need to consider everything that communicates with the ZDC. In general, the more IMA communication going on inside the farm, the more ZDCs are needed, which means more zones.
Number of MetaFrame XP Servers
One zone can support about 100 servers. This is not a hard limit, but rather a practical performance-based limit determined by internal Citrix research. If you have more than 100 servers in a single zone, you will most likely need to partition it into two zones. Of course, servers will continue to get faster, which means that by the time you are reading this, you can probably build a ZDC powerful enough to support more than 100 servers. At that point, however, you will probably have other reasons to create multiple smaller zones.
Bandwidth and Connectivity Between MetaFrame XP Servers
The available bandwidth between MetaFrame XP servers needs to be assessed when looking at zone design. Keep in mind that every dynamic change to any MetaFrame XP server in the environment is sent first to a local ZDC, which in turn sends the change to the all other ZDCs in the farm. Consider the environment in Figure 3.12:
Figure 3.12: A single server farm with servers separated by WAN links
This WAN environment is configured with MetaFrame XP servers in three separate locations. If three zones are created, every time a dynamic event (such as a user logon) occurs, the local ZDC will send that event to ZDCs in the other two zones. This single event ends up crossing the WAN link two times, once to each other zone data collector. If, instead, the environment is configured as a single zone (with one ZDC), every time a dynamic event occurs, the event traverses the WAN link only once to the central ZDC. The downside to the single zone is that when any information is needed from the ZDC (such as for a user logon), the information may be across the WAN, instead of local (because the ZDC may be across the WAN). It is this balance that you must consider when designing zones.
Usually, you will end up creating a unique zone for each physical network location within a server farm. However, this does not always have to be the case. You can configure any server to be a member of any zone. Zone boundaries do not have to fall in line with IP subnets or network segments.