Data Collector:
Every Zone in a MetaFrame farm consists of one data collector. If a new MetaFrame server joins the zone or the current data collector is unavailable then an election is triggered to determine a data collector. When a zone elects a new data collector, it uses a preference ranking of the servers in the zone. Each zone has four levels of preference for election of data collectors and every server is assigned a preference level. The preference levels, in order from highest to lowest preference, are:
Most Preferred
Preferred
Default Preference
Not Preferred
By default, a MetaFrame server is set to the Default Preference setting. This is the case for all server except the for the first server added to the zone, in which it is set to Most Preferred and it is set to be the zones initial data collector.
To designate a specific server as the data collector you will want to set the election preference for the server to Most Preferred and all other servers to something lower.
If you do not want a server to be a data collector then you will need to set the preference to Not Preferred.
If you create a new zone, the first server that you move to the new zone becomes the zones data collector, and its preference level is set to Most Preferred.
Note: As discussed in the design phase, when the server farm exceeds five or more servers or it is experiencing high session traffic, you can reduce the possibility of data collector performance issues and sluggish farm enumeration by setting up MetaFrame XP server as a data collector or what I like to call a Control Server. This server will be dedicated for acting as the data collector so you will NOT want to publish any applications to it.
New Data Collector Election Process
When a communication failure occurs between a member server and the data collector for its zone or between data collectors, the election process begins in the zone. Here are some examples of how ZDC elections can be triggered and a high level of summary of the election process. A detailed description of this process and the associated functions used is further below in this document.
1. The existing data collector for Zone 1 has an unplanned failure for some reason, that is, a RAID controller fails causing the server to blue screen. If the server is shutdown gracefully, it triggers the election process before going down.
2. The servers in the zone recognize the data collector has gone down and start the election process.
3. The member servers in the zone 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 replicates this information to all other data collectors in the farm.
Important: The data collector election process is not dependent on the data store.
Note: If the data collector goes down, sessions connected to other servers in the farm are unaffected.
Misconception: “If a data collector goes down, there is a single point of failure.”
Actual: The data collector election process is triggered automatically without administrative intervention. Existing as well as incoming users are not affected by the election process, as a new data collector is elected almost instantaneously. Data collector elections are not dependent on the data store.
Detailed Election Process:
As we know, each server in the zone has a ranking that is assigned to it. This ranking is configurable such that the servers in a zone can be ranked by an administrator in terms of which server is most desired to serve as the zone master. “Ties” between servers with the same administrative ranking are broken by using the HOST IDs assigned to the servers; the higher the host ID, the higher-ranked the host.
The process that occurs when an election situation begins is as follows:
1. When a server comes on-line, or fails to contact the previously-elected zone master, it starts an election by sending an ELECT_MASTER message to each of the hosts in the zone that are ranked higher than it.
2. When a server receives an ELECT_MASTER message, it replies to the sender with an ELECT_MASTER_ACK message. This ACK informs the sender that the receiving host will take over the responsibility of electing a new master. If the receiving host is not already in an election, it will continue the election by sending an ELECT_MASTER message to all of the hosts that are ranked higher than itself.
3. If a server does not receive any ELECT_MASTER_ACK messages from the higher-ranked hosts to which it sent ELECT_MASTER, it will assume that it is the highest ranked host that is alive, and will then send a DECLARE_MASTER message to all other hosts in the zone.
4. When a server that has previously sent an ELECT_MASTER message to the higher-ranked host(s) in the zone receives an ELECT_MASTER_ACK from at least one of those hosts, it enters a wait state, waiting for the receipt of a DECLARE_MASTER from another host. If a configurable timeout expires before this DECLARE_MASTER is received, the host will increase its timeout and begin the election again.
At the conclusion of the election, each host will have received a DECLARE_MASTER message from the new zone master.
Every Zone in a MetaFrame farm consists of one data collector. If a new MetaFrame server joins the zone or the current data collector is unavailable then an election is triggered to determine a data collector. When a zone elects a new data collector, it uses a preference ranking of the servers in the zone. Each zone has four levels of preference for election of data collectors and every server is assigned a preference level. The preference levels, in order from highest to lowest preference, are:
Most Preferred
Preferred
Default Preference
Not Preferred
By default, a MetaFrame server is set to the Default Preference setting. This is the case for all server except the for the first server added to the zone, in which it is set to Most Preferred and it is set to be the zones initial data collector.
To designate a specific server as the data collector you will want to set the election preference for the server to Most Preferred and all other servers to something lower.
If you do not want a server to be a data collector then you will need to set the preference to Not Preferred.
If you create a new zone, the first server that you move to the new zone becomes the zones data collector, and its preference level is set to Most Preferred.
Note: As discussed in the design phase, when the server farm exceeds five or more servers or it is experiencing high session traffic, you can reduce the possibility of data collector performance issues and sluggish farm enumeration by setting up MetaFrame XP server as a data collector or what I like to call a Control Server. This server will be dedicated for acting as the data collector so you will NOT want to publish any applications to it.
New Data Collector Election Process
When a communication failure occurs between a member server and the data collector for its zone or between data collectors, the election process begins in the zone. Here are some examples of how ZDC elections can be triggered and a high level of summary of the election process. A detailed description of this process and the associated functions used is further below in this document.
1. The existing data collector for Zone 1 has an unplanned failure for some reason, that is, a RAID controller fails causing the server to blue screen. If the server is shutdown gracefully, it triggers the election process before going down.
2. The servers in the zone recognize the data collector has gone down and start the election process.
3. The member servers in the zone 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 replicates this information to all other data collectors in the farm.
Important: The data collector election process is not dependent on the data store.
Note: If the data collector goes down, sessions connected to other servers in the farm are unaffected.
Misconception: “If a data collector goes down, there is a single point of failure.”
Actual: The data collector election process is triggered automatically without administrative intervention. Existing as well as incoming users are not affected by the election process, as a new data collector is elected almost instantaneously. Data collector elections are not dependent on the data store.
Detailed Election Process:
As we know, each server in the zone has a ranking that is assigned to it. This ranking is configurable such that the servers in a zone can be ranked by an administrator in terms of which server is most desired to serve as the zone master. “Ties” between servers with the same administrative ranking are broken by using the HOST IDs assigned to the servers; the higher the host ID, the higher-ranked the host.
The process that occurs when an election situation begins is as follows:
1. When a server comes on-line, or fails to contact the previously-elected zone master, it starts an election by sending an ELECT_MASTER message to each of the hosts in the zone that are ranked higher than it.
2. When a server receives an ELECT_MASTER message, it replies to the sender with an ELECT_MASTER_ACK message. This ACK informs the sender that the receiving host will take over the responsibility of electing a new master. If the receiving host is not already in an election, it will continue the election by sending an ELECT_MASTER message to all of the hosts that are ranked higher than itself.
3. If a server does not receive any ELECT_MASTER_ACK messages from the higher-ranked hosts to which it sent ELECT_MASTER, it will assume that it is the highest ranked host that is alive, and will then send a DECLARE_MASTER message to all other hosts in the zone.
4. When a server that has previously sent an ELECT_MASTER message to the higher-ranked host(s) in the zone receives an ELECT_MASTER_ACK from at least one of those hosts, it enters a wait state, waiting for the receipt of a DECLARE_MASTER from another host. If a configurable timeout expires before this DECLARE_MASTER is received, the host will increase its timeout and begin the election again.
At the conclusion of the election, each host will have received a DECLARE_MASTER message from the new zone master.
No comments:
Post a Comment