InfoScale™ 9.0 Storage Foundation and High Availability Solutions 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
- 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
Reinstating faulted hardware in a campus cluster
Once a failure occurs and an application is migrated to another node or site, it is important to know what will happen when the original hardware is reinstated.
The following table lists the behavior when various hardware components affecting the configuration (array or disks, site hardware, networking cards or cabling, storage interconnect, etc.) are reinstated after failure.
Table: Behavior exhibited when hardware is reinstated
Failure Situation, before Reinstating the Configuration | ForceImport set to 0 (import not forced) | ForceImport set to 1 (automatic force import) |
---|---|---|
3) Failure of disk array or all disks Remaining disks in mirror are still accessible from the other site. | No interruption of service. Resync the mirror from the remote site. | Same behavior. |
4) Site failure All access to the server and storage is lost. | Inter-node heartbeat communication is restored and the original cluster node becomes aware that the application is online at the remote site. Resync the mirror from the remote site | Same behavior. |
5) Split-brain situation (loss of both heartbeats) | No interruption of service. | Same behavior. |
6) Storage interconnect lost Fibre interconnect severed. | No interruption of service. Resync the mirror from the original site. | Same behavior. |
7) Split-brain situation and storage interconnect lost | No interruption of service. Resync the mirror from the original site. | VCS alerts administrator that volumes are online at both sites. Resync the mirror from the copy with the latest data. |
The numbers 3 through 7 in the previous table refer to the scenarios in Campus cluster failover using the ForceImport attribute.
Situations 1 and 2 have no effect when reinstated. Keep in mind that the cluster has already responded to the initial failure.
While the outcomes of using both settings of the ForceImport attribute for most scenarios are the same, the ForceImport option provides automatic failover in the event of site failure. This advantage 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.