Storage Foundation and High Availability Solutions 8.0.2 HA and DR Solutions Guide for Microsoft SQL Server - Windows
- Section I. Getting started with Storage Foundation and High Availability Solutions for SQL Server
- Introducing SFW HA and the VCS agents for SQL Server
- How is application availability achieved in a VMware virtual environment
- Notes and recommendations
- How VCS monitors storage components
- Deployment scenarios for SQL Server
- Reviewing the active-passive HA configuration
- Reviewing a standalone SQL Server configuration
- Reviewing the campus cluster configuration
- Reviewing the Replicated Data Cluster configuration
- About setting up a Replicated Data Cluster configuration
- Disaster recovery configuration
- Reviewing the disaster recovery configuration
- Notes and recommendations for cluster and application configuration
- Configuring disk groups and volumes for SQL Server
- About managing disk groups and volumes
- Configuring the cluster using the Cluster Configuration Wizard
- Installing SQL Server
- Completing configuration steps in SQL Server
- Introducing SFW HA and the VCS agents for SQL Server
- Section II. Configuring SQL Server in a physical environment
- Configuring SQL Server for failover
- About configuring the SQL Server service group
- Configuring the service group in a non-shared storage environment
- Configuring an MSDTC Server service group
- Configuring campus clusters for SQL Server
- Configuring Replicated Data Clusters for SQL Server
- Setting up the Replicated Data Sets (RDS)
- Configuring a RVG service group for replication
- Configuring the resources in the RVG service group for RDC replication
- Configuring the VMDg or VMNSDg resources for the disk groups
- Configuring the RVG Primary resources
- Adding the nodes from the secondary zone to the RDC
- Verifying the RDC configuration
- Configuring disaster recovery for SQL Server
- Setting up your replication environment
- About configuring disaster recovery with the DR wizard
- Configuring replication and global clustering
- Configuring the global cluster option for wide-area failover
- Testing fault readiness by running a fire drill
- About the Fire Drill Wizard
- Prerequisites for a fire drill
- Preparing the fire drill configuration
- Deleting the fire drill configuration
- Configuring SQL Server for failover
Campus cluster failover using the ForceImport attribute
Automated recovery is handled differently in a VCS campus cluster than with a VCS local cluster. The outcomes of failure situations depend on the settings for the ForceImport attribute of the VMDg resource. To ensure proper failover in a VCS campus cluster, you must verify the value of the ForceImport attribute.
You can set this attribute as follows:
ForceImport set to 1 automatically forces the import of the disk groups to the other node
ForceImport set to 0 does not force the import
The advantage of automatic failover in the event of site failure comes at the cost of potential data loss if all storage and network communication paths between the sites are severed. Choose an option that is suitable given your cluster infrastructure, uptime requirements, and administrative capabilities.
You can use the VCS Java Console or command line to modify the ForceImport attribute. For more information on modifying ForceImport:
See Setting the ForceImport attribute to 1 after a site failure.
The following table lists failure situations and the outcomes depending on the settings for the ForceImport attribute of the VMDg resource.
Table: Failure situations in a VCS campus cluster
Failure Situation | ForceImport set to 0 (import not forced) | ForceImport set to 1 (automatic forced import) |
---|---|---|
1) Application fault May mean the services stopped for an application, a NIC failed, or a database table went offline. | Application automatically moves to another node. | Service Group failover is automatic on the standby or preferred system or node.Service Group failover is automatic on the standby or preferred system or node. |
2) Server failure May mean a power cord became unplugged or a failure caused the system to stop responding. | Application automatically moves to other node. 100% of the disks are still available. | Service Group failover is automatic on the standby or preferred system or node. 100% of the mirrored disks are still available. |
3) Failure of disk array or all disks Remaining disks in mirror are still accessible from the other site. | No interruption of service. Remaining disks in mirror are still accessible from the other node. | The Service Group does not failover. 50% of the mirrored disk is still available at remaining site. |
4) Zone failure Complete Site failure, all accessibility to the servers and storage is lost. | Manual intervention required to online the Service Group at remaining site. Can not automatically import 50% of mirrored disk. | Automatic failover of Service Group to online site. Force Import must be set to True before site failure to ensure VCS can import 50% of mirrored disk. |
5) Split-brain (loss of both heartbeats) If the public network link serves as a low-priority heartbeat, the assumption is made that the link is also lost. | No interruption of service. Can't import disks because the original node still has the SCSI reservation. | No interruption of service. Failover does not occur due to Service Group resources remaining online on the original nodes. Example: Online node has SCSI reservation to own disk. |
6) Storage interconnect lost Fibre interconnect severed. | No interruption of service. Disks on the same node are functioning. Mirroring is not working. | No interruption of service. Service Group resources remain online, but 50% of the mirror disk becomes detached. |
7) Split-brain and storage interconnect lost If a single pipe is used between buildings for the Ethernet and storage, this situation can occur. | No interruption of service. Cannot import with only 50% of disks available. Disks on the same node are functioning. Mirroring is not working. | Automatically imports 50% of mirrored disk to the alternate node. Disks online for a short period in both locations but offlined again due to IP and other resources being online on original node. No interruption of service. |