Implementing Cluster Service
| After an organization decides to cluster an application or service using Cluster Service, it must then decide which cluster configuration model best suits its needs. MSCS can be deployed in three different configuration models that will accommodate most deployment scenarios and requirements. The three configuration models include the single-quorum device cluster, single-node cluster, and the majority node set cluster. The typical and most common cluster deployments are configured using the single-quorum device cluster. The Single-Quorum Device ClusterThe single-quorum device cluster configuration model is composed of two or more server nodes that are all connected to a shared storage device. In this model, only one copy of the quorum data is maintained and is housed on the shared storage device, as shown in Figure 31.1. All cluster nodes have access to the quorum data, but the quorum disk resource runs only on one node of the cluster at a time. Figure 31.1. Two-node single-quorum device cluster. This configuration model is best suited for applications and services that provide access to large amounts of mission-critical data and require high availability. When the cluster encounters a problem on a cluster group containing a shared storage disk resource, the cluster group is failed over to the next node and made available with almost no disruption. When the cluster group is back online, all the data is once again available after a short disruption in service. Typical services deployed using this cluster configuration model include file, messaging, and database servers. The Single-Node ClusterThe single-node cluster configuration model was created to serve many purposes. First, a single-node cluster can run solely on local disks, but it can also use shared storage. When creating a single-quorum cluster, the administrator must first create a single-node cluster but with a shared disk quorum. The single-node cluster can also use the local quorum resource, which is usually located on internal disk storage. The local quorum resource is a great benefit for cluster application development because only a single server with internal disk storage is needed to test cluster applications. One last point to add about this model is that because there is only one node, the cluster will not use or provide failover. If the single node is down, all the cluster groups are unavailable. The Majority Node Set ClusterThe Majority Node Set (MNS) cluster is the third configuration model and represents the future of clustering, as shown in Figure 31.2. MNS can use shared storage devices, but this capability is not a requirement. In an MNS cluster, each node maintains a local copy of the quorum device data in a specific Majority Node Set resource. Windows Server 2003 Enterprise supports up to four nodes per cluster, and Datacenter supports up to eight nodes. Because each node maintains a local copy of the quorum and a shared storage device is not necessary, MNS clusters can be deployed across a WAN in a geographically distributed environment. Windows Server 2003 supports up to two separate sites for MNS, and because the cluster IP will need to fail over across sites, the sites either need to be bridged or a virtual private network (VPN). Another viable option is having Network Address Translation (NAT) installed and configured for failover for proper IP recovery to occur. The latency between the cluster nodes for private communication must not exceed 500 milliseconds; otherwise, the cluster can go into a failed state. Figure 31.2. Two-site, four-node Majority Node Set cluster. An MNS cluster will remain up and running as long as the majority of the nodes in the cluster are available. In other words, to remain operational, more than half of the nodes must be up and running. For instance, in a four-node cluster, three nodes must remain available, or the cluster will fail. If an administrator configures a three-node cluster, two nodes must remain up and running. Both the three-node and four-node clusters can tolerate only a single node failure. If you are considering or requiring availability provided by MNS, it is recommended to always purchase at least one additional node when planning for an MNS cluster. This node can be used in the lab for application testing, including testing patches and application updates, or it can be configured in a cold-standby state that can be added to a cluster when a single node fails. An MNS Cluster ScenarioAn MNS cluster model supports geographically distributed clusters. This means that in a three-node cluster deployment, you can deploy two nodes in Site A and one node in Site B. A spare server will be kept at Site B to join the cluster if necessary. When a single node fails in Site A, the cluster remains up and running because the majority of the nodes are still running, even though they are running in separate sites. If the node in Site B fails, the cluster will remain running on the two nodes at Site A. If a major disaster or power outage is encountered at Site A, the cluster will fail because only one node is running at Site B. To bring the cluster back online, you can restore one of site A's nodes at the Site B location using the spare server. This gives you the two nodes you need to make the three-node MNS cluster operational. In the same scenario, if you deploy a four-node cluster with two nodes at each site, a single site failure will result in the cluster failing and require an additional server to restore a third and required node. So, if you want to properly plan for a site outage using a four-node MNS cluster, you would need to have a spare server in each location, making the total six servers for a four-node cluster. MNS is a great choice for geographically distributed clusters, but you must follow these rules to deploy the clusters properly:
MNS clusters represent the future of clustering, and several developments will be made along the way to simplify installations and deployment. Microsoft recommends that MNS clusters be deployed only on hardware supported by the server and storage device vendors for use with geographically distributed MNS clusters. Choosing Applications for Cluster ServiceMany applications can run on Cluster Service, but it is important to choose those applications wisely. Although many can run on MSCS, the application might not be optimized for clustering. Work with the vendor to determine requirements, functionality, and limitations (if any). Other major criteria that should be met to ensure that an application can benefit and adapt to running on a cluster are the following:
Those cluster-aware applications meeting all the preceding criteria are usually the best applications to deploy in a cluster configuration. Many services built into Windows Server 2003 can be clustered and will fail over efficiently and properly. If a particular application is not cluster-aware, be sure to investigate all the implications of the application deployment on the Cluster server. Note If you're purchasing a third-party software package for MSCS, be sure that both Microsoft and the software manufacturer certify that it will work on a Windows Server 2003 cluster; otherwise, support will be limited when troubleshooting is necessary. Shared Storage DevicesShared disk storage was a requirement for all previous releases of MSCS until Windows Server 2003. Now only the traditional design of a single quorum device cluster has such a requirement, but a shared storage device can be a part of any cluster configuration. In the past, storage area networks (SANs) were used to satisfy the shared storage device requirement. The logical volumes created in the SAN device must be configured and recognized as basic disks by the Windows Server 2003 operating system. Windows Server 2003 identifies the logical volumes on the SAN by their disk signatures, and each volume is treated as a separate disk by MSCS. Currently, dynamic disks are not supported for shared disk volumes. SCSI SAN units are supported on two-node clusters, but for clusters with more than two nodes, fiber channel is the preferred method of connecting cluster nodes to the shared storage. Using a single fiber channel, Windows Server 2003 can access both shared and nonshared disks residing on a SAN. This allows both the shared storage and operating system volumes to be located on the SAN, giving administrators the flexibility of deploying diskless servers. Of course, the SAN must support this option, and the boot drives must be assigned exclusive access for individual cluster nodes through proper disk zoning and masking. Consult SAN vendor documentation and check the Cluster HCL on the Microsoft Web site to find approved SAN devices. The Cluster server uses a shared nothing architecture, which means that each cluster resource can be running on only one node in the cluster at a time. When a disk resource is failed over between nodes, the SAN device must be reset to accommodate the mounting of the disk on the remaining node. If the SAN device is used by more than just cluster nodes, SAN communication can be disrupted to other servers if the SAN is not configured to reset only the targeted logical unit number (LUN) as opposed to resetting the entire bus. Windows Server 2003 supports targeted LUN resets, and SAN vendor documentation should be reviewed to ensure proper zoning and masking of the SAN device. Multipath I/OWindows Server 2003 supports multipath I/O to external storage devices such as SANs. This allows for multiple redundant paths to external storage, adding yet another level of fault tolerance. This capability is now achieved through redundant fiber channel controller cards in each cluster node. Volume Shadow Copy for Shared Storage VolumeThe Volume Shadow Copy (VSS) service is supported on shared storage volumes. Volume Shadow Copy can take a point-in-time snapshot of an entire volume, enabling administrators and users to recover data from a previous version. The amount of disk space used for each copy can be minimal, so enabling the service can add data fault tolerance and reduce recovery time of a file or folder. Volume Shadow Copy should be tested thoroughly on a disk containing enterprise databases such as Microsoft SQL 2000 prior to implementation to ensure that it can provide fault tolerance and recoverability as required and to ensure that databases do not suffer corruption as a result of a rollback to a previous version of the database file. Single-Quorum Cluster ScalabilityThe single-quorum cluster is composed of independent server nodes that all connect to a share's storage device such as a SAN. Table 31.1 specifies the minimum and maximum number of nodes and types of storage communications allowed in a single-quorum cluster.
|
EAN: 2147483647
Pages: 499