Storage Foundation and High Availability Solutions 7.4 HA and DR Solutions Guide for Microsoft Exchange 2010 - Windows
- Section I. Introduction and Concepts
- Introducing Storage Foundation and High Availability Solutions for Microsoft Exchange Server
- How VCS monitors storage components
- Introducing the VCS agent for Exchange 2010
- Introducing Storage Foundation and High Availability Solutions for Microsoft Exchange Server
- Section II. Configuration Workflows
- Configuring high availability for Exchange Server with InfoScale Enterprise
- Reviewing the HA configuration
- Reviewing a standalone Exchange Server configuration
- Reviewing the Replicated Data Cluster configuration
- Reviewing the disaster recovery configuration
- Disaster recovery configuration
- Notes and recommendations for cluster and application configuration
- Configuring disk groups and volumes for Exchange Server
- About managing disk groups and volumes
- Configuring the cluster using the Cluster Configuration Wizard
- Using the Solutions Configuration Center
- Configuring high availability for Exchange Server with InfoScale Enterprise
- Section III. Deployment
- Installing Exchange Server 2010
- Configuring Exchange Server for failover
- Configuring the service group in a non-shared storage environment
- Configuring campus clusters for Exchange Server
- Configuring Replicated Data Clusters for Exchange 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 RVG Primary resources
- Adding the nodes from the secondary zone to the RDC
- Verifying the RDC configuration
- Deploying disaster recovery for Exchange Server
- Reviewing the disaster recovery configuration
- Setting up your replication environment
- Configuring replication and global clustering
- Configuring the global cluster option for wide-area failover
- Possible task after creating the DR environment: Adding a new failover node to a Volume Replicator environment
- Testing fault readiness by running a fire drill
- About the Fire Drill Wizard
- About post-fire drill scripts
- Prerequisites for a fire drill
- Preparing the fire drill configuration
- Running a fire drill
- Deleting the fire drill configuration
- Section IV. Reference
- Appendix A. Using Veritas AppProtect for vSphere
- Appendix B. Troubleshooting
- Appendix A. Using Veritas AppProtect for vSphere
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. |