|
|
Management & Control Services (MCS) can be installed on multiple servers across your network, creating what is referred to as a server cluster. Installing an MCS server cluster, rather than just a standalone MCS server, provides server scalability, fail-over protection, and load balancing (with the use of a 3rd-party hardware or software HTTP router).
Within an organization, the first instance of MCS that is installed is referred to as the Management and Control Server. There is only one Management and Control Server, through which all interaction with MCS within the cluster takes place. By default, the Management and Control Server is a member of the "MCS cluster," regardless of whether or not additional MCS servers are actually installed. If additional MCS servers are installed, the MCS server becomes the primary server for the MCS cluster.
To create a server cluster, you can install one or more additional servers, referred to as configuration servers, after installing the Management and Control Server. A configuration server provides the same functionality as the Management and Control Server, but does not include a user interface (console). Instead, all configuration is performed using the Management and Control Server, as the primary server for the MCS cluster, and the configuration data is automatically replicated across all configuration servers.
You can access the MCS console from a configuration server just as you do from the Management and Control Server, but the console request is automatically redirected to the Management and Control Server.
Within each server cluster, there is one primary server and one or more secondary servers. By default, the Management and Control Server acts as the primary server for the (default) MCS cluster. If you create additional clusters, the option of whether to install MCS as a primary or secondary server is presented during the MCS installation process. The primary server acts as the main point of interaction between its cluster and the MCS Cluster. Configuration for the additional cluster can be performed either through the Management and Control Server or through the primary server for the cluster.
A simple MCS server cluster is illustrated below.
Benefits of server clustering include:
 |
All servers in your cluster must run on the same Web application server and under the same operating system. For example, if the Management and Control Server is running on a WebLogic application server installed under Windows 2000, all configuration servers must also be running on WebLogic under Windows 2000. In addition, you must specify the same configuration options (for example, port numbers) for each server installation. |
Also, as mentioned above, the MCS server cluster implementation relies on a third-party hardware or software HTTP router, which you may already have in place in your organization. The router must be able to route HTTP requests uniformly between the servers, and should detect out-of-service conditions within the server cluster.
As mentioned above, you are not limited to using just one server cluster on your network—MCS allows you to create multiple clusters, each containing a primary configuration server and one or more secondary configuration servers. You could, for example, create a separate server cluster to support each server application that will provide access to client configurations. Doing so would help segregate the server usage to a particular set of users, or to a particular application.
A multiple MCS server cluster arrangement is illustrated below.
The default name of the first server cluster you install is "MCS Cluster," whether it contains just one server (Management and Control Server), or multiple servers. You can name any additional server clusters you create as you install them (for example, "Accounting Cluster" or "Development Cluster").
When you install an MCS server cluster, all configuration changes take place through the Management and Control Server or, in the case of an additional cluster, through the cluster's primary server. Configuration data is then dynamically replicated across all configuration servers in the cluster, ensuring that all active servers have access to the latest configuration data.
Each configuration server "checks in" with the primary server when it is started. For this reason, the primary server should be started first, followed by any configuration servers. If a configuration server is started before the primary server, it cannot check in immediately.
Configuration servers continue to check in with the primary server hourly, so within an hour the primary server will be aware of all of its configuration servers. In the interim, changes that occur on the primary server are not replicated to configuration servers.
When a change is made to the configuration data on the Management and Control Server or other primary server, MCS notifies all configuration servers to start replication. This replication occurs after a 1 minute delay so that multiple changes can be replicated at one time. This optimizes replication, but it also means that the servers can be out of sync for 60 seconds while the replication process completes.
If the primary server for a specific cluster ever goes off-line, each configuration server continues to use its locally-stored configuration data until the primary server is reinstated. While the primary server is off-line, no configuration changes are allowed. If a configuration server goes off-line, it will automatically receive any pending configuration updates as soon as it is reinstated.
 |
Since each server in the cluster maintains an identical copy of the configuration data, any server can be used to restore the master database for the cluster in the event of a Management and Control Server or other primary server failure. |
 |
