Xenapp’s datacollector election process is a wonderfully simple process but can be influenced by a few different factors so designing your xenapp zones is a critical task. A zone datacollector is a master xenapp server that is elected to receive and replicate changes to the zone it is in with other master datacollectors within other zones in the farm.
The master datacollector receives changes such as user logon/logoff details, server load etc etc. These changes are sent by the member servers in the zone to the master so that those changes may be replicated to other zone masters within the farm.
Zone datacollector preference can be set within the xenapp console, however as well as the datacollector preference a host id is assigned to each server as they join the farm which is also taken into account if the preference settings do not resolve the election process to a single host. Also taken into account is the software version of the xenapp server but this as a moot point as its a really bad idea to be running mismatched software versions on a xenapp farm.
The election process
When a xenapp server starts up or fails to contact an already elected zone datacollecor, it initiates the election process by sending an ELECT_MASTER message to each of the xenapp servers in the zone that are ranked higher than itself.
When a higher ranked server receives a ELECT_MASTER message it replies to the originating server with an ELECT_MASTER_ACK message and then also sends an ELECT_MASTER message to the xenapp servers with a higher ranking than itself.
This process continues until a xenapp server does not receive an ELECT_MASTER_ACK message which means that there are no xenapp servers higher up the chain than the final server sending the ELECT_MASTER message. The final xenapp server then declares itself to be the master zone datacollector and sends a DECLARE_MASTER message to all the other servers within the zone.
nb. When a server sends the ELECT_MASTER message the server then goes into a wait state, if the DECLARE_MASTER message is not received within the default timeout period of the wait state then the server will send the ELECT_MASTER message again and lengthen the wait state.
After the DECLARE_MASTER message is received the xenapp member servers send all of their information to the new master zone datacollector for replication the new master zone datacollector functions as expected.
During the election process (which is generally a fraction of a second) there is no interruption to service for existing or new logons to the servers within the zone. The datastore also is not required for any point of this process.
The Xenapp election preference setting is generally used to assign a ranking to servers within the farm, so setting setting one server to be the “most preferred” will naturally ensure that it has the highest ranking, but if 2 xenapp servers are given the same preference level then the uniquely defined HOST ID that is assigned to xenapp servers as they initially enter the farm will be used to resolve conflicts.
