Background Services | Microsoft Application Center 2000 Resource Kit 2001

In addition to the services we've described, there are background services that Application Center runs, namely cluster time synchronization and reliable name resolution.

Cluster Time Synchronization Service

Application Center provides its own mechanism for ensuring that the internal clocks of all the cluster members are synchronized. The main reason for doing this is to ensure that monitoring and performance data that is logged is time stamped accurately. This is particularly important with performance data, which is collected across the cluster and aggregated.

NOTE
This is not a native operating system service but is provided by the Application Center Cluster Service.

A cluster member's clock may get out of synchronization with the other members because:

A user modifies the time setting manually.
An application updates the clock.
There is an electrical problem, such as a CMOS battery failure, which prevents the clock from getting incremented correctly.

The Cluster Time Synchronization Service keeps the cluster member clocks synchronized by replicating the controller's date and time setting:

At the startup of cluster services on the controller
At the startup of cluster services on a member
At 60-minute intervals
Whenever there is a cluster controller change

The design criteria for the Cluster Time Synchronization Service is to keep all member clocks set to within +/- 5 seconds of the time on the controller. However, this level of accuracy may not always be possible because:

CPU utilization on the controller is so high that obtaining the system date and time may take an unusually long time.
CPU utilization on a member may be so high that the time service "set" operation may take an unusually long time.
Network latency may cause significant delays in propagating the time setting to all the cluster members.

The time synchronization service is enabled and disabled in the metabase by setting MD_WEBCLUSTER_DO_TIME_SYNC to 1 or 0 (/AppCenter/Cluster, property ID (5739), type DWORD).

This ability to toggle time synchronization is necessary because it allows you to take advantage of the Reliable Time Service (RTS) of a domain controller, which you should use if you're using Kerberos V5 authentication. (It's possible to break Kerberos V5 authentication because the Cluster Time Synchronization Service is unaware of time settings on the domain controller or ticket granter.) Other situations that may require disabling of the Cluster Time Synchronization Service is the presence of conflicting software services, such as some virus checkers.

At cluster creation time, Application Center checks to see whether the computer that will become the controller is part of a domain. It the controller is part of a domain, the configuration flag is set to 0; if it isn't, this flag is set to 1.

NOTE
The Cluster Time Synchronization Service is active under the same conditions as the System Application, which is to say date and time is synchronized even if a member is out of the synchronization loop. For more information, see Chapter 6, "Synchronization and Deployment."

Reliable Name Resolution Service

The Reliable Name Resolution Service ensures that cluster administration services, such as the Cluster Service and the Synchronization Service, only use the back-end network adapters for their traffic. The main reason for this requirement is that network connections on the front-end adapter can be torn down at any time—specifically when TCP/IP or NLB configuration settings get altered. A second, but equally important consideration, is the segregation of production and administration traffic, either for reasons of performance or security. The Reliable Name Resolution Service also helps to ensure that Application Center services do not try to communicate with unusable IP addresses.

The Reliable Name Resolution Service addresses traffic control issues in the following manner.

The service creates, stores, and maintains a list of back-end adapters in the metabase. This list, which contains adapter GUIDs, is populated during cluster creation and member addition. If NLB is used on the cluster, cluster services will initialize the list to include the GUIDs of all the adapters that do not have NLB bound to them. In the case of no load balancing, the list will include the GUIDs of detected adapters. The Cluster Service reads this configuration entry at startup and respects this entry by:
- Only registering adapters in the list for Application Center NetBT-based name resolution. Therefore, the name revolver will return IP addresses only for the adapters with GUIDs in the list.
- Registering all adapters that are not bound to NLB for reliable name resolution (if Cluster Service encounters a problem reading the configuration entry).
Inter-cluster reliable name resolution. The Reliable Name Resolution Service runs on every active cluster member and is used to support the following activities:
- Name registration: On startup, the service registers a special NetBT name on all adapters whose GUIDs appear in the metabase back-end adapter list. A thread is set to wake up every 30 minutes to renew this name registration. If NetBIOS over TCP/IP is disabled for all the adapters in the list, the Cluster Service logs a warning to Application Center Event and Performance Logging. (This warning indicates that NetBIOS should be enabled on at least one NLB adapter.) In this case, NetBIOS over TCP/IP is automatically re-bound to the adapter if NetBT-based name resolution is enabled via the metabase entry.
- Hosts file update: For each cluster member there is a periodic broadcast name resolution for other cluster members. This contains a list of their back-end IP addresses, which the Reliable Name Resolution Service uses to update the local hosts file with mappings that resolve each member name to the back-end IP address that was found in the list.
NOTE
Both the time (in seconds) between host file updates and the update mechanism itself can be controlled via metabase entries. The update interval, which is set to 5 minutes by default, can be changed by editing the 57448 entry. The minimum legal value is greater than or equal to 60 seconds. You can disable the update mechanism by setting the 57449 entry to False.