Connecting to a Cluster | Microsoft Application Center 2000 Resource Kit 2001

Launched from the console tree, or from a pop-up dialog box if the server you're working on isn't already part of a cluster, the Connect to Server dialog box prompts you for the name of a server in the cluster to which you want to connect. As shown in Figure 4.3, additional inputs include:

An option button that allows you to either manage the cluster for the server you specify (enabled by default), or manage a single server—as would be the case if you wanted to work with only one cluster member. If you click Manage the specified server only and the specified server is a cluster controller, Application Center opens up a member-only view of the controller.
A check box that, when enabled, allows you to submit authentication information to the server to which you want to connect.

Figure 4.3 The Connect to Server dialog box

After you click the OK button, the user interface tool checks the local membership list to determine if the server whose name you provided is part of an existing cluster. (It also retrieves the name of the current cluster controller, if it exists.) If the server that you identified isn't already a cluster member, you're given the option of joining a cluster or creating a new cluster.

NOTE
When you connect to the localhost, the credentials of the logged on user will be used for any connections to the local host. If you enter localhost for a computer that is a member server and click Manage cluster for the specified server, the logged on credentials are used for a local connection to obtain the controller name. After the controller name is obtained, supplied credentials are used for a connection to the controller.

The Controller Discovery Protocol (CDP)
The various Application Center services need a reliable way of discovering which server is the current controller in a cluster. The CDP provides the means for polling a cluster to determine which server is the controller, as well as whether the controller is available. Each member of the cluster executes the CDP every four minutes to verify which server is the cluster controller.
Without going into too much detail, the CDP works as follows.

Whenever a server (S0) needs to determine which machine is the current controller, it executes the CDP. First, S0 looks in its own configuration store to get a list of cluster members (for example, S1…Sn). Then, server S0 contacts each member in turn and requests two pieces of information that help identify the cluster controller: the controller name and the version number associated with that name.

The server doing the CDP determines which server is the cluster controller on the basis of the version numbers it receives. For example, let's say that server S2 identifies server S7 with a version number of 8 as the controller, and server S3 identifies server S5 with version number of 9 is the controller. The CDP decides that the server with the higher version number, in this case S5, is the cluster controller.
In cases where a consistent controller can't be discovered—two different servers have the same version number, for example—the cluster goes into a controller-less state (which occurs rarely). If this happens, manual intervention is required to designate one of the servers as the cluster controller. The subsequent cluster synchronization will update the cluster configuration settings in the configuration store for each member. Then, the CDP can be run against a fresh list that contains the servers and their version numbers.

Now let's examine cluster creation in detail, a process that is very interesting because it accomplishes two tasks: cluster creation and cluster load balancing configuration.