Best Practices for Exchange 2010
We’ve seen a lot of interest in Microsoft® Exchange 2010 since its availability was announced last November. Part of the interest is being driven by Exchange 2003 users. With Exchange 2003 reaching end of life, many of these users are planning to upgrade directly to Exchange 2010.
Exchange 2010 also offers significant new features that are undoubtedly fueling interest, including:
Of course, there are other new features as well (for more details on new features in Exchange 2010, see this TechNet article.), but many of the features I’ve outlined above have direct implications for storage. NetApp® best practices for Exchange have been updated substantially as a result. In this article, I’ll discuss three issues that are critical for deploying Exchange 2010 with NetApp storage:
You can find more details on these and other topics, including storage layout, sizing, and capacity planning, in a recently published technical report, “Storage Efficiency and Best Practices for Microsoft Exchange Server 2010.”
Microsoft has made significant changes to the high-availability architecture for Exchange 2010. Local continuous replication (LCR), cluster continuous replication (CCR), standby continuous replication (SCR), and single copy cluster (SCC) from Exchange 2007 are no longer available. (If you’re an Exchange 2007 user, a previous Tech OnTap article described the use of these features with NetApp.)
To replace the server and data resiliency options of earlier versions of Exchange, Microsoft implemented the database availability group (DAG). The DAG uses the same log shipping capability that was used in CCR. A DAG consists of two to 16 mailbox servers. Each mailbox server can hold one or more active or passive copies of a database. Each database has a separate status, so one server can host copies of multiple databases and only have some of those copies active at one time.
The DAG uses a new Exchange component called Active Manager. The Active Manager facilitates failover and failback. In the event of a failure (including a failure in underlying storage or storage connectivity), Exchange 2010 "promotes" one of the copies of the database to active status; the mailbox role then takes up the task of serving up the mailboxes on that database. Failover occurs in less than 30 seconds.
NetApp has established a number of best practices associated with deploying DAGs:
HA Deployment Scenarios
When extending a DAG across multiple sites, NetApp recommends at least three mailbox servers as well as three copies of each mailbox database, two in the primary site and one in the secondary site. This provides high availability within the primary site as well as disaster recovery. This can be configured either using a three-node DAG or a two-node local DAG plus NetApp SnapMirror® to replicate Exchange data to a remote. Because of the SnapMirror thin replication technology and network compression, this can be a preferred alternative in situations where network bandwidth is limited or latency is high. (For a DAG, the latency must be less than 250 milliseconds.)
Figure 1) High availability and DR using a two-node Exchange 2010 DAG combined with NetApp SnapMirror.
Virtualizing Exchange environments can deliver significant benefits, including reduced server hardware costs, power and space savings, improved server utilization, rapid server provisioning, improved availability, and increased efficiency. When virtualizing Exchange 2010 roles, NetApp recommends that each role be separated onto a different physical server so there is not a failure of any particular role in the event of a host-server failure. For example, deploying one CAS, one hub, and two mailbox servers per host server provides a good mix in terms of disbursement of roles.
A recent Tech OnTap article provided design guidelines for virtualizing Microsoft Exchange and other Microsoft applications. For additional information and recommendations for virtualizing Exchange 2010 services, you should also look at this recent Microsoft TechNet article.
Virtualizing your Exchange environment can provide you more options for protecting the availability of Exchange, and—because it reduces the cost of server deployment—it can make high availability (HA) more affordable. NetApp storage in a virtualized Exchange environment can further reduce costs because of proven storage efficiency.
Improving Storage Efficiency and Decreasing Cost
Using your storage optimally is always important. Because Exchange 2010 requires multiple copies of an Exchange database for HA and disaster recovery (DR), you will want to be sure you are storing those copies as efficiently as possible.
NetApp storage provides a number of storage efficiency technologies that can significantly reduce the amount of storage your Exchange environment requires whether you implement Exchange 2010 on physical or virtual servers. The more of these technologies you use, the greater the aggregate benefit in terms of storage savings.
With the trend toward larger mailbox sizes and the decreased I/O profile of Exchange Server 2010, SATA might be a viable solution in many Exchange environments. Although the SATA disks might be a good fit for performance and capacity, NetApp recommends that when using SATA disks for Exchange deployments, they should be used in conjunction with Flash Cache and in a DS4243 disk shelf.
Table 1) Probability of data loss using SATA disks and various types of RAID.
To streamline management and data protection of Exchange environments, NetApp created SnapManager for Exchange software. SnapManager for Exchange automates complex, manual, and time-consuming processes associated with the backup, recovery, and verification of Exchange Server databases and uses Snapshot technology to reduce backup times to seconds and restore times to minutes. NetApp Single Mailbox Recovery software makes it possible to recover and restore individual mailboxes, messages, or attachments quickly without disrupting other Exchange users. The ability to quickly and easily restore to different points in time provided by SnapManager for Exchange makes keeping a “lag” copy of the database unnecessary, saving additional storage.
If you’re thinking about moving to Exchange 2010, paying attention to a few best practices can make a big difference in the success of your deployment. High availability, virtualization, and storage efficiency are all important considerations. This article is only intended to give you a first step in the right direction. To learn more about these topics and to find out about layout, sizing, and capacity planning, check out TR-3824.
Got opinions about Exchange 2010?
Ask questions, exchange ideas, and share your thoughts
online in NetApp Communities.