This section describes a disaster recovery method that consists of relocating Exchange virtual servers to a different Windows cluster. See the following topics for more information:
The following paragraphs summarize a disaster recovery scenario that uses SnapManager and SnapMirror in a clustered environment.
The configuration consists of a Windows cluster with Microsoft Exchange and NetApp products at a production site along with a different but similarly configured cluster at a disaster recovery (DR) site. There are likely to be numerous DR sites, geographically remote from one another.
The Exchange data and the SnapManager backup sets are stored on Data ONTAP LUNs. The backup sets are asynchronously mirrored from the production site to the DR sites using SnapMirror. SnapManager for Exchange is used for Exchange backup and recovery as well as to drive the SnapMirror replication schedule. SnapDrive is used for LUN provisioning and management.
In the event of a disaster, an Exchange virtual server can fail over from the production site to a DR site and then, after the original production site has been repaired, the DR site can fail back to the production site. Exchange data that changed while running at the DR site is mirrored back to the production site and retained.
Before you begin configuring your production and DR sites, ensure that you complete the prerequisite tasks described in this section.
Each Windows host system must be installed with the following:
Note
Data ONTAP 7.1 introduced functionality that enables faster restore times, which is recommended for use with SnapManager. SnapManager 3.2 supports SnapDrive 4.1 only, which in turn supports Data ONTAP 7.0.x and 7.1.
Each Windows cluster must meet the following requirements:
Although this document describes how to move an Exchange virtual server from one Windows cluster to another in a Microsoft and NetApp environment, it does not describe how to restore the supporting Windows infrastructure.
For more information about Exchange disaster recovery and its dependencies, see the following Microsoft articles:
The production and DR sites can consist of one or more Windows clusters running one or more Exchange virtual servers where each cluster has one or more nodes (two nodes or more are recommended). Data storage for Exchange is provided by one or more storage systems. The following example shows a two-node production Windows cluster running one Exchange virtual server on each node. The DR Windows cluster contains a single node. There is one storage system at each site.
The production and DR sites are set up with storage system volumes of identical sizes. Initially, SnapMirror relationships are configured between the source volumes on the production site and destination volumes on the DR sites. While in production, data is mirrored from SnapMirror source volumes at the production site to SnapMirror destination volumes at each of the DR sites.
If a disaster occurs at the production site, you can fail over operations to one of the DR sites. After the original production site is repaired, the DR site can fail back to the production site and the data will be mirrored back in the opposite direction using SnapMirror.
To properly configure Windows clusters, you need to understand the proper location of quorum disks:
If you use a Data ONTAP LUN as a quorum disk, that LUN must reside on a storage system at the same site where the Windows cluster itself resides:
Standardizing across all clusters (at the production site and at all DR sites) on an identical mapping of LUN names to drive letters can simplify disaster recovery activities, from initial configuration through maintenance, failover, and failback.
For example, the following mapping of LUN names and drive letters could be adopted by the database administrators at the production site and each DR site.
Note
If you adopt the best practice of keeping detailed and up-to-date notes about your DR plans, remember to keep a printed hardcopy.
Exchange performance might be significantly lower at the DR site than at the production site:
Because of this, you should be aware that Exchange performance at the DR site could be significantly lower than would be expected at the production site.
To configure the production and DR sites, complete the following steps.
Complete the following steps at the production site.
| 1 |
Configure a Windows cluster and then install Windows Server on all nodes of the cluster, but do not install or configure Exchange yet. Note For details about configuring the cluster, refer to Microsoft documentation. |
|
| 2 |
Using the Cluster Administrator, create a cluster resource group named "Exchange" for the Exchange cluster resources. Note |
|
| 3 |
Create a new "IP address" cluster resource in the Exchange DR cluster group. Note |
|
| 4 |
Create a new "Network Name" cluster resource in the Exchange DR cluster group. Note |
|
| 5 |
Install SnapDrive on all cluster nodes, following the instructions in the SnapDrive Installation and Administration Guide. |
|
| 6 |
If using iSCSI, establish an iSCSI connection from one of the production site cluster nodes to the production storage system. |
|
| 7 |
On a SnapMirror source volume on the production storage system, create LUNs to store the following: To do this, complete the following steps:
|
|
| 8 |
On a SnapMirror source volume on the production storage system, create a separate LUN to store the "Exchange data directory":
Later, when you create the Exchange System Attendant cluster resource for the first time, you will be prompted for this LUN. This LUN will also be used for the Exchange SMTP and MTA queues and Microsoft Search. SnapManager can be used later to configure the SMTP and MTA locations, if desired. Note |
|
| 9 |
Install Exchange on all nodes in the cluster and then apply any Exchange service packs to all nodes in the cluster. Note |
|
| 10 |
Using the Cluster Administrator, do the following:
|
|
| 11 |
Install and configure SnapManager on all nodes of the cluster. |
|
| 12 |
Make the cluster node you are working on the owner of the Exchange cluster resource group:
|
|
| 13 |
Verify that the Exchange virtual server at the production site is up and running: |
|
| 14 |
Create a SnapManager backup and confirm that SnapMirror is functioning properly. There are three ways to check that SnapMirror replication occurred:
|
|
Look at the backup report for the backup that was just run. The following text will appear toward the end of the report:
*** REQUEST SNAPMIRROR UPDATE AFTER BACKUP ***
Starting SnapMirror update...
Querying disk list for SnapMirror update...
Requesting SnapMirror update for LUN [I:] on volume [exch_db] of storage system [exch-dr-filer]...
Request for SnapMirror update for LUN [I:] was completed successfully.
Requesting SnapMirror update for LUN [L:] on volume [exch_logs] of storage system [exch-dr-filer]...
Request for SnapMirror update for LUN [L:] was completed successfully.
This is an example of the events that might be seen when there are two volumes in use:
Event Type: Information
Event Source: SnapDrive
Event Category: SnapMirror event
Event ID: 144
Date: 7/14/2005
Time: 2:08:47 PM
User: N/A
Computer: EXCHANGE
Description:
A SnapMirror update request to destination (exch-filer:exch_db) was successfully sent.
Event Type: Information
Event Source: SnapDrive
Event Category: SnapMirror event
Event ID: 144
Date: 7/14/2005
Time: 2:08:50 PM
User: N/A
Computer: EXCHANGE
Description:
A SnapMirror update request to destination (exch-filer:exch_logs) was successfully sent.
Using a web browser, bring up FilerView on the storage system that is the SnapMirror destination:
Example: http://dr_filer/na_admin
There can be numerous DR sites around the globe. To prepare the DR sites for disaster recovery, complete the following steps at each DR site.
Attention
Only one Exchange virtual server with a given network name can be online at a time, otherwise connectivity issues will arise.
| 1 |
Install Windows Server on all nodes of the cluster and then configure the default cluster group, but do not install or configure Exchange yet. Note For details about configuring the cluster, refer to Microsoft documentation. |
|
| 2 |
Install SnapDrive on all cluster nodes, following the instructions in the SnapDrive Installation and Administration Guide. |
|
| 3 |
If using iSCSI, establish an iSCSI connection from one of the cluster nodes at this DR site to the DR storage system. Note |
|
| 4 |
Install Exchange on all nodes in the cluster and then apply any Exchange service packs to all nodes in the cluster. Note |
|
|
Create the cluster resource group and install SnapManager for Exchange |
||
|
Although it saves time if you create this cluster resource group and the cluster resources prior to disaster, it is not a requirement. You can choose to postpone performing the remaining steps in this procedure until you need to fail over to this DR site. |
||
| 5 |
Using the Cluster Administrator, create a cluster resource group named "Exchange DR" for the Exchange cluster resources. Note |
|
| 6 |
Create a new "IP address" cluster resource in the Exchange DR cluster group. Note |
|
| 7 |
Using the Cluster Administrator, do the following:
|
|
| 8 |
Do not add Exchange cluster resources yet. This is done later, as part of the recovery procedure. |
|
| 9 |
Install SnapManager for Exchange on all nodes of the cluster, but do not configure it yet. |
|
At the DR site to which you want to fail over, perform the following steps.
| 1 |
Ensure that the Exchange cluster group at the production site is offline. Note |
|
| 2 |
If the DR cluster will take over the Exchange services within one hour of the time that the production site went offline, use the Active Directory Users and Computers MMC to reset the machine account for the Exchange virtual server. If you fail to do this, you might encounter client authentication issues. Attention |
|
| 3 |
If the production cluster is different from the DR cluster, update the DNS record for the virtual Exchange server's network name with the IP address at the production cluster. Note |
|
| 4 |
Using the Cluster Administrator, check the Network Name cluster resource in the Exchange DR cluster resource group to ensure that the correct name is in use. It must exactly match the network name that was in use for the Exchange virtual server at the production site. |
|
| 5 |
If, when this DR site was brought online, the cluster resource group was not created and SnapManager for Exchange was not installed, do so now:
|
|
| 6 |
Using SnapDrive, do the following:
|
|
| 7 |
Using the Cluster Administrator, add the Exchange System Attendant cluster resource. This creates the remaining resources automatically and uses all of the same drive letters. You will not be able to change them. |
|
| 8 |
Install and configure SnapManager on all nodes of the cluster. |
|
| 9 |
Make the cluster node you are working on the owner of the Exchange cluster resource group:
|
|
| 10 |
Perform a SnapManager for Exchange restore operation with the following options selected: |
|
| 11 |
Verify that the virtual Exchange server on the DR cluster is up and running: |
|
| 12 |
If the cluster is configured with SMTP or HTTP virtual server cluster resources, these resources could fail shortly after you bring them online. To prevent this from happening, follow the steps in Changing the IP addresses of SMTP and HTTP virtual server cluster resources before proceeding. |
|
| 13 | ||
| 14 |
If you expect the DR cluster to remain online for any length of time, use SnapManager to configure reoccurring scheduled backup jobs. For details, see Appendix , Backing up databases. |
|
Here is an example of a configuration at the DR site:
To fail back to the production site, complete the following steps.
| 1 |
Before proceeding with this failback procedure, be sure that any LUN clone split operations have completed. The LUN clone split functionality, introduced in Data ONTAP 7.1, supports significantly faster online Snapshot copy restore times when using SnapManager or SnapDrive to restore. This functionality is enabled by default. To check that any LUN clone split operations have completed, use the storage system's lun clone split status command, or by viewing the Operation Status column in the SnapDrive MMC. For detailed information about this command, see the Data ONTAP 7.1 Block Access Management Guide for iSCSI and FCP. Attention |
|
| 2 | ||
| 3 |
Prevent further user access by bringing the Exchange cluster resources offline, but leave the physical disk cluster resources online for the next step. |
|
| 4 |
To ensure that you can bring the Exchange databases back online at the production site without first having to perform a SnapManager restore operation, verify that each Exchange database is in a consistent state. To do this, use the Exchange Server Database Utilities (Eseutil.exe) tool with the /mh option to view the header of each Exchange database and then check the value displayed next to "State" in the command output. The following example shows the Eseutil /mh command run against the database priv1.edb, located in the directory I:\EXCHSRVR\mdbdata. Only the first part of the command output is shown here: C:\Program Files\Exchsrvr\bin> eseutil /mh I:\EXCHSRVR\mdbdata\priv1.edb Microsoft(R) Exchange Server Database Utilities Version 6.5 Copyright (C) Microsoft Corporation. All Rights Reserved. Initiating FILE DUMP mode... Database: I:\EXCHSRVR\mdbdata\priv1.edb File Type: Database Format ulMagic: 0x89abcdef Engine ulMagic: 0x89abcdef Format ulVersion: 0x620,11 Engine ulVersion: 0x620,11 Created ulVersion: 0x620,11 DB Signature: Create time:05/06/2005 16:35:18 Rand:2129456 Computer: cbDbPage: 4096 dbtime: 136725 (0x21615) State: Clean Shutdown Note Repeat this step for every database you need to bring back online at the production site. |
|
| 5 |
Use the Cluster Administrator to delete the Exchange System Attendant cluster resource in the Exchange DR cluster resource group. This deletes all of the Exchange cluster resources, but the Physical Disk, IP, and Network Name resources remain intact. Attention The following error might appear in the Windows Application Event Log: Event Type: Error Event Source: MSExchangeCluster Event Category: Services Event ID: 1027 Date: 6/23/2005 Time: 4:46:46 PM User: N/A Computer: EXCHSRVR Description: SA: System Attendant resource has been deleted improperly. The objects in Active Directory corresponding to this Exchange Virtual Server have not been removed. If you unintentionally deleted the System Attendant resource, you can restore it and its dependent resources to their original configuration by re-creating the System Attendant resource using the same parameters as before. If you want to remove the Exchange Virtual Server corresponding to this System Attendant resource, you have to re-create the System Attendant resource with the same parameters as before and then select the option "Remove Exchange Virtual Server" in the context menu of the group or System Attendant resource using the Cluster Administrator tool. For more information, click http://www.microsoft.com/contentredirect.asp. Data: 0000: 00 00 00 00 .... |
|
| 6 |
Mirror the modified Exchange data on the SnapMirror destination volumes at the DR site back to the SnapMirror source volumes at the production site. |
|
|
The original SnapMirror source volumes and Snapshot copies remain intact |
Go to Step 7. | |
|
The data on the original SnapMirror source volume or the volume itself was lost |
Go to Step 17. | |
|
If the original SnapMirror source volumes and Snapshot copies remain intact |
||
| 7 |
Mirror only the changed blocks on the DR storage system volumes back over to the production storage system volumes. To do this, go to the original SnapMirror source storage system command line interface and, for every volume that is being used by this Exchange/SnapManager configuration, issue the snapmirror resync command to mirror only the changed data at the DR site back to the production site. Suppose you have an Exchange/SnapManager configuration with two volumes. In this example, the storage systems at the production site and the DR site are named prod_filer and dr_filer, respectively, and the volume names on both storage systems are db_vol and logs_vol. The following sequence of two commands illustrates how the resync command might be issued for this example configuration: prod_filer> snapmirror resync -S dr_filer:db_vol prod_filer:db_vol prod_filer> snapmirror resync -S dr_filer:logs_vol prod_filer:logs_vol |
|
| 8 |
Monitor the status of the operation by using the snapmirror status command on the production storage system, and do not proceed until the SnapMirror "State" is "Snapmirrored" for all volumes in this configuration. Note |
|
| 9 |
Use SnapDrive to update the mirror. You can do this using either the SnapDrive graphical user interface (MMC) or the SnapDrive command-line interface (sdcli.exe). Only one mirror update per storage system volume is required; it is not necessary to perform an update for each drive letter. When SnapDrive is used to perform a SnapMirror update, updating a single LUN on a given volume actually updates all of the LUNs on the volume. |
|
| 10 |
Monitor the status of the operation by using the snapmirror status command on the production storage system, and do not proceed until the SnapMirror "State" is "Snapmirrored" for all volumes in this configuration. |
|
| 11 |
At the production storage system, break the reverse SnapMirror relationship. You can do this using either the snapmirror break command or FilerView. The data that changed at the DR site is now mirrored back to the production site. |
|
| 12 | ||
| 13 |
Reinstate the original SnapMirror relationship. To do this, issue another snapmirror resync command, but this time from the DR storage system. The following sequence of two commands illustrates how the snapmirror resync command might be issued. Following is an example of how this command might look using the example storage system and volume names used in Step 7. dr_filer> snapmirror resync db_vol dr_filer> snapmirror resync logs_vol |
|
| 14 |
Confirm that the SnapMirror relationship has been re-created in the original direction:
|
|
| 15 |
Go to Step 23 to finish the failback to the production site. |
|
|
If the data on the original SnapMirror source volume or the volume itself was lost |
||
| 16 | ||
|
Go to Step 17. | ||
| ||
| 17 |
Create a new SnapMirror relationship in the reverse direction (from the SnapMirror destination volume at the DR site back to the SnapMirror source volume at the production site) and then initialize the mirror. This transfers all data from the original SnapMirror destination volume at the DR site back to the original SnapMirror source volume at the production site. This can be done using the storage system's command line or by using the FilerView graphical user interface. To do this using FilerView, complete the following steps:
|
|
| 18 |
Using SnapDrive, update the mirror. This can be done using the SnapDrive GUI (MMC) or the command line (sdcli.exe). It is not required that an update be performed for each drive letter. Rather, only one update per storage system volume is required. When SnapDrive is used to perform a SnapMirror update, updating a single LUN on a given volume actually updates all of the LUNs on the volume. |
|
| 19 |
Confirm that all data has been mirrored back to the repaired original SnapMirror source volume. |
|
| 20 |
Break the mirror using the snapmirror break command or FilerView. |
|
| 21 |
Un-configure the reverse SnapMirror relationship. This can be done using the storage system's a line or by using the FilerView graphical user interface. To do this using FilerView, complete the following steps:
|
|
| 22 |
Reestablish the original SnapMirror relationship in the original direction so that data from the production storage system is mirrored to the DR storage system. This can be done using the storage system's snapmirror resync command or by using the FilerView graphical user interface. Perform this task on the DR storage system.
|
|
| 23 |
Launch the Cluster Administrator on one of the nodes at the DR site: |
|
| 24 |
If the DR cluster will take over the Exchange services within one hour of the time that the production site went offline, use the Active Directory Users and Computers MMC to reset the machine account for the Exchange virtual server. If you fail to do this, you might encounter client authentication issues. Attention |
|
| 25 |
If the production cluster is different from the DR cluster, update the DNS record for the virtual Exchange server's network name with the IP address at the production cluster. Note |
|
| 26 |
Verify that the DR site is in the same state that it was in prior to the disaster: |
|
| 27 |
To complete the failback, bring back online the LUNs belonging to the Exchange virtual server and the original MSCS cluster group. |
|
|
The original Windows cluster at the production site was not lost |
Proceed to Clean up the cluster physical disk resources. | |
|
The original Windows cluster at the production site was lost |
Proceed to Recreate the cluster resource group and the Exchange virtual server. | |
Follow these steps to complete the failback if the Windows cluster at the production site is operational and both the Exchange cluster resource group and the Exchange cluster resources exist.
In this case, the cluster physical disk resources need to be cleaned up in case the cluster physical disk resources are in a failed state at the production site.
| 1 |
Using the Cluster Administrator, do the following: The Exchange System Attendant cluster resource requires a dependency on at least one physical disk resource. This step will allow you to delete all but one of the physical disk resources. |
|
| 2 |
If any of the LUNs that were removed as dependencies are still mounted, use SnapDrive to disconnect them |
|
| 3 |
Using SnapDrive, do the following:
|
|
| 4 | ||
| 5 |
Using SnapDrive, do the following:
|
|
| 6 |
Go back to the Cluster Administrator and replace the System Attendant dependency on the last LUN. |
|
| 7 |
Verify that the configuration is correct by running through the SnapManager Configuration Wizard. Be sure to save any changes if they need to be made. |
|
| 8 |
If the cluster is configured with SMTP or HTTP virtual server cluster resources, these resources could fail shortly after you bring them online. To prevent this from happening, follow the steps in Changing the IP addresses of SMTP and HTTP virtual server cluster resources. |
|
| 9 |
Using the Cluster Administrator, bring the Exchange cluster group online. |
|
| 10 |
If the MS Search Instance cluster resource fails to come online, use SnapDrive to restore the LUN that was configured for the Exchange "data directory." These files need to be kept on a separate LUN from the Exchange database, transaction logs, and the SnapManager SnapInfo directory. Choose the most recent Snapshot copy with the "eloginfo__" prefix. Note |
|
| 11 |
Perform a SnapManager for Exchange restore operation using the Snapshot copy you created at the beginning of the failback procedure and with the following options selected: |
|
| 12 |
Verify that the virtual Exchange server on the production cluster is up and running: |
|
| 13 |
Continue with the recurring scheduled backup jobs that were in place prior to the failover. |
|
Follow these steps to complete the failback if the Windows cluster at the original production site was lost and needs to be rebuilt from scratch.
In this case, the cluster resource group and the Exchange virtual server have to be re-created.
| 1 | ||
| 2 |
Configure the default cluster group so that you have a working cluster without Exchange. Note For detailed information about configuring the cluster, refer to Microsoft documentation. |
|
| 3 |
Using the Cluster Administrator, create Exchange cluster resource group. |
|
| 4 |
Install SnapDrive on all cluster nodes, following the instructions in the SnapDrive Installation and Administration Guide. |
|
| 5 |
If using iSCSI, establish an iSCSI connection from one of the cluster nodes at the production site to the production storage system. |
|
| 6 | ||
| 7 |
Install Exchange plus any service packs on all nodes of the cluster. The same service pack must be applied that was in use at the original production cluster and the DR cluster. |
|
| 8 |
Using the Cluster Administrator, create an "IP Address" cluster resource in the Exchange cluster group. |
|
| 9 |
If this IP address is different from that of the DR cluster or the original production cluster, update the DNS record for the virtual Exchange server's network name. Note |
|
| 10 |
Using the Cluster Administrator, do the following:
|
|
| 11 |
If the cluster is configured with SMTP or HTTP virtual server cluster resources, these resources could fail shortly after you bring them online. To prevent this from happening, follow the steps in Changing the IP addresses of SMTP and HTTP virtual server cluster resources before proceeding. |
|
| 12 |
Install and configure SnapManager on all nodes of the cluster. |
|
| 13 |
Perform a SnapManager for Exchange restore operation using the Snapshot copy you created at the beginning of the failback procedure and with the following options selected: |
|
| 14 |
Verify that the virtual Exchange server on the production cluster is up and running: |
|
| 15 |
Use SnapManager to re-create the automated backup jobs, described in the SnapManager for Exchange Installation and Administration Guide. |
|
After a failover or failback, the SMTP and HTTP virtual server cluster resources might fail after being online for a few minutes if both of the following conditions are true:
If these resources fail, the following events appear in the Windows application event log:
Event Type: Error
Event Source: MSExchangeCluster
Event Category: Services
Event ID: 1005
Date: 8/25/2005
Time: 3:44:04 PM
User: N/A
Computer: EXCHSRVR1
Description:
SMTP Virtual Server Instance (EVS1): The IsAlive check for this resource failed.
For more information, click http://www.microsoft.com/contentredirect.asp.
Data:
0000: 4c 27 00 00 L'..
Event Type: Error
Event Source: MSExchangeCluster
Event Category: Services
Event ID: 1005
Date: 8/25/2005
Time: 3:44:07 PM
User: N/A
Computer: EXCHSRVR1
Description:
Exchange HTTP Virtual Server Instance (EVS1): The IsAlive check for this resource failed.
For more information, click http://www.microsoft.com/contentredirect.asp.
Data:
0000: 4c 27 00 00 L'..
To prevent the SMTP or HTTP virtual server cluster resources from failing after a cluster failover or failback, update the IP address as described in the two procedures that follow.
For the SMTP resource, complete the following steps.
For the HTTP resource, complete the following steps.
Copyright © 1994-2006, Network Appliance, Inc. All rights
reserved.
Part No. 215-01873_A0
File: recover5.htm
Last updated: 28-Mar-2006 11:31:05