Microsoft Cluster Server (MSCS—aka Wolfpack) introduced the concept of server clusters that support application high availability to the Windows arena in the days of Windows NT 4.0. Clusters have come a long way since then. Today, in addition to the Microsoft Cluster service offering, many third-party vendors offer mature clustering products that make implementing a high-availability solution a much less grueling experience than it used to be. Let's look at the architectures and technologies that these third-party products employ.
High-Availability Architectures
High-availability server clusters have in common a concept of multiple servers, each communicating with one another and acting as cluster nodes. When one node's failure causes an application to fail, another cluster node takes over processing the application and end users can continue working. For this process to work, the application must run properly on both the primary node (on which the application runs before the failure) and the standby node (on which the application runs after the failure). Application data is central to any application, and the method for letting both the primary node and the standby node access application data is a key distinguishing factor among high-availability architectures.
Microsoft Cluster service and some of its competitors support a shared-storage configuration, in which the nodes of a cluster have connections to the same disk storage systems—most often a Storage Area Network (SAN). Microsoft Cluster service also supports SCSI-based two-node clusters, in which each node connects to the same SCSI bus. Whether SAN or SCSI-based, each node can view and use the volumes defined on the attached storage as if they were volumes on a locally installed disk drive. When the primary node fails, the standby node takes control of the data volume (and other resources associated with the application, such as IP addresses, NetBIOS names, and share names) and starts the application. These systems must arbitrate disk-volume ownership to ensure that only one server is able to write to the volume at a time. Successful operation of a shared-storage cluster requires hardware components that work well together. For Microsoft Cluster service, Microsoft certifies certain hardware configurations, which it publishes in the cluster section of the Windows Catalog (for Windows Server 2003) or Hardware Compatibility List (HCL—for Windows 2000 Server). Links to these lists are available at http://www.microsoft.com/whdc/hcl/default.mspx. Some of the other clustering products discussed here also require Microsoft-certified hardware, although not always the cluster-certified configurations.
Shared-storage configurations avoid data consistency and integrity problems because all nodes work with the same copy of the data. However, shared-storage configurations are typically more expensive than replication-based configurations (which I discuss later), and a shared SAN or SCSI bus imposes strict distance limits. Unless you use high-end SAN hardware with WAN mirroring features, all the nodes of a cluster must be at the same site; thus, you're susceptible to a disaster that affects more than just one cluster node.
Replication-based high-availability solutions use data replication and mirroring to copy application data across a network to storage controlled by another server. Because the data traverses a network, transactions require time and network bandwidth; thus, data consistency and integrity can be a problem. On the plus side, replication-based solutions don't require cluster-certified hardware configurations and replicated cluster nodes can play a part in a disaster-recovery scenario.
Replication, mirroring, and synchronization all refer to the copying of data from a source to a target, but people don't always use the terms exactly the same way. Replication always means the ongoing copying of a write request to a backup volume. Mirroring and synchronization often refer to the initial instance of copying data from a source storage device to the target storage. Sometimes, though, mirroring also refers to the ongoing process of keeping the source and target in sync as normal application processing occurs. Resynchronization refers to the process that brings a mirrored copy up-to-date following some kind of break in communication between the two servers—for example, as part of a failback procedure following a failover. A partial resynchronization can occur if the server running the application keeps track of which blocks of data on a volume have changed—only the changed blocks need to be sent to the mirrored volume. Partial resynchronization can be much faster and use less WAN bandwidth than a full remirroring of a volume.
Synchronous and asynchronous replication describe when the data is actually written to the target volume. In synchronous replication, I/O system drivers intercept write requests to the source volume and send a copy of the write requests to the target system. Only after the source system receives confirmation that the data was successfully written to storage at the target does the source system write the data to its own storage. This approach ensures that the target system always has a complete and accurate copy of the source system’s data. Synchronous replication can be slow, especially when the target system sits on the other end of a WAN link. Slow I/O leads to poor application response time, so administrators and application designers must carefully evaluate where synchronous replication is appropriate in a high-availability strategy.
Asynchronous replication affords greater speed at the cost of more uncertainty about the state of the data at the target volume. In asynchronous replication, the source volume completes writes immediately without waiting for confirmation of successful writes at the target system. Writes are sent to the target volume according to rules implemented by the replication engine. Many replication engines send and complete writes to the target volume as quickly as server resources and network bandwidth allow. Other replication engines can limit the network bandwidth used by replication traffic or schedule replication. VERITAS Software's VERITAS Storage Foundation for Windows supports what the vendor calls soft synchronous replication, which uses synchronous replication until the network path used for replication fails, then starts queuing the write requests so that application processing can continue.
Which data does replication send to the target volume? Disk volumes are divided into data blocks of a uniform size. The file system (e.g., NTFS, FAT) decides how these data blocks are used. Some blocks hold file data. Others hold file metadata—that is, filenames, security attributes, file data block locations. Still other blocks hold volume metadata, such as the volume name, which blocks are in use or free, or which blocks are bad and unusable. Some replication engines intercept writes to the volume at the block level. Block replication engines don’t care what's stored on the volume or even about the volume organization. They seek to ensure that block for block, the target volume is identical to the source volume. This relatively simple replication scheme ensures that all data on the volume is replicated to the target volume. However, an application often doesn’t use all the data that the volume holds, and sending it uses up valuable bandwidth.
Previous
