Understanding High Availability Factors

  • Article

This topic discusses several high availability factors that will affect your overall mailbox server architecture.

Mailbox Resiliency

With Exchange Server 2010, you can choose to deploy your mailbox server infrastructure either in a stand-alone implementation or with mailbox resiliency. Exchange 2010 has been re-engineered around the concept of mailbox resiliency, in which the architecture has changed so that automatic failover protection is now provided at the individual mailbox database level instead of at the server level.

If you select a solution that makes use of mailbox resiliency, you have several choices in terms of architecture:

  • By deploying multiple database copies, you can:
    • Design a solution that mitigates the most common reasons for using a backup. Database copies provide protection against hardware, software, and datacenter failures.
    • Increase your database sizes up to 2 terabytes because your recovery mechanism is another database copy and not restoration from backup.
    • Consider storage architecture alternatives like JBOD (Just a Bunch of Disks), if you deploy three or more database copies.
  • By distributing active databases across all the servers that participate within a database availability group (DAG), you can maximize the efficiency of your hardware. See the next section of this topic for more information.

For more information, see Planning for High Availability and Site Resilience and Understanding Backup, Restore and Disaster Recovery.

Hosting Active and Passive Database Copies on the Same Server

A key aspect to Exchange 2010 Mailbox capacity planning is determining how many database copies you plan to activate on a per-server basis when configured for mailbox resiliency. A range of designs is available, but we recommend the following models.

Design for All Database Copies Activated   

In this capacity planning model, you design your server architecture to handle 100 percent of all hosted database copies becoming active. For example, if your server hosts 35 database copies, then you design the processor and memory to accommodate all 35 databases being active during the peak period.

Of the two models discussed in this topic, this model provides the better availability along with better client performance characteristics. However, this model does have a higher server capital cost.

Design for Targeted Failure Scenarios   

In this model, you design your server architecture to handle the active mailbox load during the worst failure case you plan to handle. There are many factors to consider in this model, including site resiliency; RAID storage vs. JBOD; database availability group (DAG) size; and database copy count.

A simple rule is to design as follows:

  • Automatic single node failure in two-node configurations
  • Double node failure in three-server configurations (manual activation for second failure)
  • Automatic double node failures where the DAG has four or more nodes

The appropriate number of database copies is required in each of the above scenarios, and the copies must be randomly and evenly distributed.

If you choose this capacity planning model, we strongly recommend that you restrict the number of databases that can be activated per server so the server doesn't exceed the number of active databases it was designed to service (and, as a result, provide a poor client experience).

You can restrict the number of databases by configuring the maximum active databases setting. You can configure this limit in the Exchange Management Shell by running: Set-MailboxServer -MaximumActiveDatabases. Configure this limit on each server in the DAG to match the maximum active databases the deployment was sized for. For more information, see Set-MailboxServer.

This capacity planning model provides a balance between capital costs, availability, and client performance characteristics.

For more information, see Database Availability Group Design Examples.