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
Reviewing a standalone Exchange Server configuration
A "standalone" Exchange server is a server that is installed and deployed in a production environment but is not configured for high availability.
The following figure illustrates a standalone Exchange configuration where System1 and System2 are mailbox servers hosting a set of mailbox databases. System3 is a spare server that may run other application services. The mailbox databases, DB1, DB2, DB3 and DB4 reside on storage that is accessible only to the respective local systems. DB3 and DB4 volumes are not accessible from System1; DB1 and DB2 volumes are not accessible from System2.
When this standalone Exchange setup is configured for HA, each of the mailbox servers become part of a cluster, the mailbox databases are moved to a shared storage that is accessible to all the mailbox servers, the databases are then managed by a VCS service group that consists of a set of cluster nodes.
The following figure illustrates the standalone Exchange configuration after it is made highly available. Mailbox servers System1 and System2 each host an Exchange service group that contains a set of mailbox databases. The spare server, System3, now acts as a mailbox server.
System1 and System3 are part of service group Exch_SG1; System2 and System3 are part of service group Exch_SG2. Thus, System3 now acts as target failover node for both System1 and System2. If System1 faults, the mailbox databases DB1 and DB2 are moved to System3 and all client requests are directed to the mailbox server on System3. Similarly, if System2 faults, service group Exch_SG2 is brought online on System3 enabling continuous access to mailbox database DB3 and DB4. If System1 and System2 fault at the same time, both the service groups are brought online on System3. All the mailbox databases are active on System3.