Most systems that use Microsoft Cluster Server (MSCS--formerly code-named Wolfpack) come from one of Microsoft's early adopter partners. Microsoft worked with several vendors to develop MSCS, including Digital Equipment, Compaq/Tandem, HP, Data General, NCR, IBM, Fujitsu, Sequent, Siemens Nixdorf, and Dell Computer. Microsoft validated these vendors' products as capable of supporting MSCS. Vendors prepackage these clustered solutions, with additional storage options available. Prepackaged solutions include servers; Windows NT Server, Enterprise Edition (NTS/E) with MSCS; dual NICs; and shared and non-shared storage. Most of these preconfigured systems use an internal EIDE boot drive with NTS/E loaded on it and some type of external chassis for the shared SCSI storage devices (including the Quorum Resource drive or volume).
The Quorum Resource is the cluster's database; it contains all the information on the cluster and cluster resources. The Quorum Resource is typically a dedicated volume or drive that belongs to the first node to form the cluster. If the first node fails, the Quorum Resource transfers to the surviving node. In MSCS Phase 2, you can designate a hierarchy of nodes to own the Quorum Resource if a failover occurs. The Quorum Resource is part of the shared-storage bus (typically SCSI), and it shouldn't store cluster-aware application data or NTS/E files.
Microsoft-validated systems are based on specific configurations (e.g., CPU, BIOS, Fibre Channel-to-SCSI, host bus adapter--HBA). Thus, the systems have numerous configuration control issues associated with clustering. Vendors supply these systems with optimal-length cabling and active terminators. The systems often include redundant power supplies and other critical components. The systems are fully configured, with few variables to introduce. End users must load and administer only the applications they want to run on the cluster. This situation is ideal because making changes to shared SCSI storage environments can be tricky.
Vendors such as Digital StorageWorks, CLARiiON, and IBM offer validated storage options that are compatible with certified MSCS clusters. (For resources on storage and clusters, see the Storage and Cluster Resource List, page 138.) These storage offerings are typically external RAID or just a bunch of disk (JBOD) systems that have shared SCSI or Fibre Channel (FC) interconnects and can support comprehensive clustering environments that require protected storage and high performance.
Despite the emphasis on prepackaged or preconfigured systems, many end users, vendors, and resellers will want to upgrade existing systems to NTS/E and MSCS. Whether you use a preconfigured system or develop your own, you must focus on several storage-related areas. These issues include the shared-SCSI bus, advanced MSCS storage options, and MSCS storage management.
Shared SCSI Pragmatics and Pitfalls
Shared SCSI clusters use multiple initiators (i.e., SCSI HBAs) that arbitrate over the bus to access and control targets (i.e., drives). Digital and Compaq/
Tandem pioneered this technique's use on high-end clustering systems using initiators and targets that they designed for this purpose.
Two challenges in shared SCSI are powering up the drives simultaneously via their respective owners and keeping initiators from locking preferred owners out of shared drives (i.e., unequal access). These problems often coexist, with one problem masking the other. Screen 1 shows how these startup problems appear under the Cluster Administrator. Disk U is failed, and disk V is offline. You can often correct this problem by manually transferring drive ownership back and forth until you disable the Failure/Offline flag. This is an easy solution, but it isn't possible during un-
attended failback.
SCSI hubs and switches. Digital and GigaLabs have announced the availability of several hubs and switches you can use with conventional SCSI interconnects. These hubs and switches behave like their networking equivalents to resolve problems. The devices overcome SCSI (especially Ultra SCSI) cable-length limitations, enable disaster-tolerant multiple-node clustering, and provide support for remote vaulting and mirroring. Hubs and switches eliminate the need to use Y cables or tri-link connectors with active terminators or SCSI devices that feature dual ports. Figure 1 shows a two-node cluster with conventional SCSI architecture, Figure 2 shows hub architecture, Figure 3, page 137, shows switching architecture, and Figure 4, page 137, shows a conventional SCSI architecture, also with non-shared storage.
Previous
Register
