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
Prerequisites for setting up the RDS for the primary and secondary zones
Before you run the Setup Replicated Data Set Wizard, verify the following:
Verify that the intended Primary host is connected to VEA, if you are configuring the RDS from a remote client or from a host that is not the Primary.
Verify whether the IP version preference is set before you configure replication.
If you specify host names when you configure replication, Volume Replicator resolves the host names with the IP addresses associated with them. This setting determines which IP version Volume Replicator uses to resolve the host names.
Use one of the following methods to set the IP preference:
Veritas Enterprise Administrator (VEA) GUI - select the appropriate options on the Control Panel > VVR Configuration > IP Settings tab.
Run the vxtune ip_mode [ipv4 | ipv6] command at the primary site as well as the secondary site.
Verify that the data volumes are not of the following types as Volume Replicator does not support these types of volumes:
Storage Foundation (software) RAID 5 volumes
Volumes with a Dirty Region Log (DRL)
Volumes that are already part of another RVG
For the Replicator Log volume, in addition to the above types, make sure that the volume does not have a DCM
Volumes names containing a comma
Secondary volume of a size smaller or greater than that on the Primary
Verify that the disk group is imported and the volumes are mounted in the primary and secondary zone.
Verify that you have configured security for Volume Replicator.
Verify that the VxSAS account has been configured with the same username and password for all the hosts, which are intended to be a part of the same RDS.