There have been a lot of queries regarding deploying Exchange in a Multi-site/data replication environment. I'll try to answer some of them here.
Deployment Guidelines
The Deployment Guidelines for Exchange Server Multi-Site Data Replication whitepaper summarizes best practices around Exchange data replication solutions; and includes with a step by step deployment plan. The focus of the whitepaper is on synchronous replication, where it has been called out in certain sections; but the best practices are applicable to all replication mechanisms.
Support Policy
To clarify Exchange replication support boundaries between Microsoft and third party vendors, we have published the following KB article: Multi-site data replication support for Exchange 2003 and Exchange 2000 In summary, Microsoft supports the data being replicated synchronously; where in an asynchronous replication environment, the third party vendors will provide support for the replicated data.
Common Questions
1. Do we discourage customers from deploying an Exchange asynchronous replication solution?
Microsoft does not encourage nor discourage customers from deploying asynchronous data replication solutions. It is a business decision to choose how to achieve data redundancy and the tolerance for potential data loss. However, before making data replication technology decisions, customers should be clearly informed about the suitability of the technology for the intended purpose. The whitepaper and the KB article contain information that may be useful to customers in making such determinations. This is general information, however, and customers should contact vendors to obtain more specific information.
For example, consider the issue of replication write ordering. As a general guideline, Microsoft advises that it is critical to preserve correct write ordering. With regard to a specific solution, it is the customer's responsibility to get assurance from the vendor that this requirement is met. Customers must also be aware of the support boundaries between Microsoft and the third party vendors.
2. What are the important tests that need to be covered before deployment?
Testing should be done in each of these categories:
• Storage Reliability: At the least, common hardware failures should be simulated. If the data is replicated asynchronously, then testing should include verification of the replicated databases after simulating sudden primary storage failures. The goal of this testing is to find out any caveats which may cause data corruption.
For example, one issue that has been seen with some solutions is that replicated data may be stored in a cache at the primary site but is not immediately transferred to the replication site. When the cache becomes full; it may convert the data changes into a bitmap, and lose the time stamp and ordering for each data write. This could potentially lead to data corruption if the full bitmap is not updated on the remote site after a failure.
• Performance: The majority of data replication solutions have occasional or steady performance impact experience and overhead. Careful testing is required to validate that the solution provides acceptable end user performance in both average and peak load conditions. This is applicable to both synchronous and asynchronous environment. Synchronous solutions typically have larger impact than asynchronous solutions. However, if insufficient cache or improper links are used in the solution design, asynchronous replication can also produce poor performance results.
.
• Backup strategy: The importance of having a backup plan in addition to data replication is explained in the whitepaper. The testing is to ensure their backup plan is adequate and the storage is designed to support such plan.
• Disaster Recovery plan: Replicating data is only the first step in a disaster recovery plan. It is necessary to have a disaster recovery plan that describes step by step how to bring the replicated data online in the time window defined by your SLA.
3. What tools can I use for the testing?
There are a couple of tools developed by Microsoft Exchange team which can be used to perform the testing mentioned above.
i. Jetstress: Simulate Exchange I/O using ese.dll. This tool is easy to setup and run. It should be used to validate the storage performance and reliability.
ii. Loadsim: Simulate MAPI clients. This tool requires an Exchange topology setup, along with a number of client machines to run. The setup may take longer, but user gets a picture of overall Exchange performance.
4. What is our support for replicating cold data?
When discussing data replication, both the whitepaper and the KB refer to "hot" data. I.e. the data being replicated is also being accessed by the Exchange application.
Cold data refers to data has committed to the disk locally and is not being accessed by the Exchange application. e.g. The data has been backed up using VSS or streaming backup software. There are solutions provided by third party vendors which replicate cold data asynchronously to a secondary site. The benefit of such solution is to provide a second copy of the data for a standby DR solution.
Microsoft supports the replication or copying of "cold" data, provided that the Exchange data was backed up using a supported backup methodology. For example, if the database is backed up using VSS, the VSS solution must comply with KB 822896.
5. If the customer is deploying geo-clustering, do they still need a backup plan?
Yes. Geo-clustering provides site resiliency, but not cold data recovery and retention. Having an adequate backup plan allows you to restore the database to a past point in time. This may be necessary to meet legal requirements, to recover inadvertently deleted data or to recover from a database corruption.
6. Do we have any recommended storage design samples?
Each customer's Exchange profile is different; therefore, there is no cookie cutter method to generate a generic storage design. The responsibility to provide a customized storage solution typically resides with the storage vendor. Microsoft Consulting Services (MCS) can be engaged to review designs and work with storage vendors to provide advice about best practices for Exchange.
- Jian Yan
