InfoScale™ 9.0 Storage Foundation and High Availability Solutions Microsoft Clustering Solutions Guide for Microsoft SQL Server - Windows
- Introducing SFW solutions for a Microsoft cluster
- Planning for deploying SQL Server with SFW in a Microsoft cluster
- Workflows for deploying SQL Server with SFW in a Microsoft cluster
- Configuring SFW storage
- Tasks for configuring InfoScale Storage
- Planning for SFW cluster disk groups and volumes
- Considerations when creating disk groups and volumes for a campus cluster
- Considerations when creating volumes for a DR configuration using Volume Replicator replication
- Viewing the available disk storage
- Creating dynamic cluster disk groups
- Adding disks to campus cluster sites
- Creating dynamic volumes for high availability clusters
- Creating dynamic volumes for campus clusters
- Implementing a dynamic mirrored quorum resource
- Installing SQL Server and configuring resources
- Configuring disaster recovery
- Tasks for configuring the secondary site for disaster recovery for SQL Server
- Verifying the primary site configuration
- Creating a parallel environment for SQL Server on the secondary site
- Volume Replicator components overview
- Setting up security for Volume Replicator
- Creating resources for Volume Replicator
- Configuring Volume Replicator: Setting up an RDS
- Creating the RVG resource
- Setting the SQL server resource dependency on the RVG resource
- Normal Volume Replicator operations and recovery procedures
- Appendix A. Configure InfoScale Storage in an existing Microsoft Failover Cluster
Cluster ownership of the quorum resource
The Microsoft clustering challenge/defense protocol uses a low-level bus reset of the SCSI buses between the computers to attempt to gain control of the quorum resource.
After a SCSI bus reset, the reservation that each server had been holding on the quorum disk is lost. Each server has about 10 seconds to re-establish that reservation, which would in turn let the other servers know that it is still functioning, even though the other servers would not necessarily be able to communicate with it.
If the active cluster server does not re-establish the SCSI reservation on the quorum resource within the time limit, the applications that were on the server transfer to the server that establishes the SCSI reservation first. The new server servicing the application may now be a bit slower, but clients still get their applications serviced. The Internet Protocol (IP) address and network names move, applications are reconstituted according to the defined dependencies, and clients are still serviced, without any question as to the state of the cluster.
The challenge/defense protocol is more complex when the quorum device is a volume in a Storage Foundation disk group. For a server to take ownership of the disk group containing the cluster quorum device, SFW on that server must successfully import the disk group, obtaining SCSI reservations on more than half of its disks.
Because a campus cluster configuration has an even number of disks on each site, failover cannot occur automatically. After a site failure, you must use the manual CLI command vxclus enable to bring the cluster disk groups online on the secondary node.