Overview

The Mailbox Server role primarily serves the purpose of hosting mailbox databases and providing access to the mailboxes contained within. In this post, we will focus on several key elements of Mailbox Server Design:

• Storage Design: Not only must we plan and allocate sufficient storage capacity to ensure that the environment can scale to support the increase in size and number of mailboxes in use, we also need to pay careful attention to the type of storage infrastructure we decide to use, be it Direct Attached Storage (DAS) in each server or disks consolidated in a SAN or other storage appliance. We also need to consider the type of disk technology we adopt, such as SCSI, SATA, Fibre Channel (FC) or even Solid State Drives (SSD). Each decision point has the potential to impact performance, cost, complexity and a number of other factors in our overall design.
• Fault Tolerant Design: Users need constant access to their mailboxes and to be able to send and receive messages. A crucial element of a resilient and fault tolerant messaging system depends on it’s ability to survive failures at multiple levels, including logical or physical corruption of a mailbox, loss of a database, a server and even an entire site. We will focus on Server build, quantity and placement, DAG design and other availability features.

Before we start

There are a couple of considerations that I want to point out before you try applying this design towards your implementation. I’ve listed them below:

• Timing: I’m writing this post at a time when Exchange 2013 hasn’t seen major deployment across the industry yet. Also, there aren’t many tools out there at this time to assist in calculating buil sizes for Exchange 2013, which we anticipate will be released in the coming months by Microsoft.
• Exchange 2010 reference: I will be using Microsoft’s Exchange 2010 Mailbox Server Role Requirements calculator tool to build this design. Performance improvements in Exchange 2013 over it’s previous version mean that the calculator will give me exaggerated values for a number of key metrics such as disk IOPS (a measure of the speed of data transfer ) and spindle allocation (the number of physical disk drives that we want to spread across our blog). This isn’t a bad thing, it just means that our design will probably call for more disks and storage that would probably be required which we can think of as a buffer. I update this post when the new calculator comes out. But in the mean time, you should use the version which can be downloaded here.
• Virtualization: As stated in the previous post, we will be deploying out Mailbox Servers in a virtual environment. This is an important consideration because we will need to consider additional resource overhead for the Virtual Hypervisors.

Design Parameters

Prior to assembling our design, we need to identify what possible constraints there may be. Constraints could include budget which will affect the number of servers and size and type of disks used, or available bandwidth for replication between datacenters. The following information has been collected from the existing messaging environment as well as high level design specifications for the Exchange 2013 implementation.

With a total of 9000 mailboxes, designing a fault tolerant system woud require further input from the business, including existing SLAs and any key performance indicators (KPIs) that are relevant to the business. The following parameters have been collected after a number of interviews with key stakeholders:

Sizing Assumptions

With our basic design parameters in place, we are ready to begin assembling our design. We commence at the mailbox level and work our way upwards, looking at the database, server, DAG and then site level.

1. Mailbox Design

The basic component of our design comprises of a mailbox. With a mailbox size of 5GB, we need to factor in additional overheads and also accommodate for growth. The actual mailbox size on disk is calculated by the following formula:

Mailbox Size = Mailbox Size Limit + Whitespace + Dumpster Size

Where,

Mailbox Size Limit = 5120 MB

Whitespace = 100 messages per day X 100/1024 MB = 9.7MB
Dumpster Size = (100 messages per day X 100/1024 MB X 30 days) = 293 MB

Total Mailbox Size = 5120 + 9.7 + 293 = 5423 MB or 5.3GB

2. Database Design

The mailbox database design needs to meet the performance requirements of Chimp Corp while providing high availability for mailbox data and fault tolerant capabilities should the need arise. Exchange Server 2013 allows multiple copies of mailbox databases to be distributed across any of the servers within a Database Availability Group (DAG). A component of Exchange 2013 called the Active Manager determines the active mailbox database out of a set of copies and if required initiates the failover of the database copy to another server.

The Mailbox Database size has been restricted to units of 1TB based on the amount of time it would take for reseeding of a restored database. Given that the average on-disk mailbox size is 5.3GB the ideal allocation of mailboxes per database must be calculated, factoring overheads and growth.

The Maximum Database Size can be used to derive the optimal number of mailboxes as follows:

Maximum Database Size = (Number of Mailboxes * Ave Mailbox Size) + 20% Overhead

1TB = (Number of Mailboxes * 5.3GB) * 1.2

Solving above, this gives us the number of mailboxes per database = 160

We also need to factor in 20% growth in the number of mailboxes across our messaging environment, therefore the optimal allocation of mailboxes per database is:

160 / 120% = 134 mailboxes allocated per database

Based on this figure, we can now calculate the total number of databases

3. Database Availability Group Design

This design comprises of two DAGs deployed across two datacenters in an Active/Active configuration. This configuration allows the active mailboxes to be spread across the datacenter sites, with each DAG hosting active databases in each datacenter site. The design requires a total of 12 Exchange Server 2013 mailbox servers (6 mailbox servers per DAG).

To maintain Chimp Corp’s requirements for availability of the messaging environment, a total of 6 copies per database will be deployed in each DAG (one of which is a lagged copy). The table below lists the high-level configuration requirements for Chimp Corp Database availability group, derived from the Microsoft Exchange Mailbox Server Role Requirements Calculator.

* Note that values factor an estimated 50% IOPS improvement over Exchange 2010, from figures derived in the Storage Calculator for Exchange 2010.

4. Data Disk Partition Requirements

The disk partition assignments for Exchange are optimized for the underlying hardware infrastructure, taking into account vendor hardware recommendations for Exchange 2013. As mailbox storage is provisioned via SAN, it is assumed that the underlying SAN infrastructure will provide a sufficient degree of hardware fault tolerance and therefore there is no need to adhere to a Microsoft recommended LUN to Database ratio of 2:1. Databases are provisioned into groups of 8 per individual storage LUN as depicted below:

5. Database Distribution on the Servers

This section details the preferred sequence numbers of the mailbox databases servicing Chimp Corp Database Availability Group. To facilitate deployment and planning, Mailbox Databases have been categorized into groups of 8, which conveniently map to the physical hardware LUN groupings of 8 databases per LUN (see previous section).

An active copy of each database group is hosted on an individual server in order to evenly distribute load. Each database has a minimum of one redundant one copy and one redundant offsite copy as well as an offsite lagged copy. Database allocations are illustrated in the table below:

As the design encompasses 2 DAGs, the database allocation for the second DAG will mirror the design described above.

6 Lagged Database Copies

Lagged Database copies will be implemented with a lag period of 24 hours. A dedicated lag server will be configured in the alternate datacenter site for each DAG for the purpose of hosting the lag database copies.

Note:  A lagged mailbox database copy can be activated to a specific point in time by first suspending the lagged database copy via the Suspend-MailboxDatabaseCopy CMDlet and then running the ESEutil.exe command to replay selected log files into the database to return it to a required restore point. 

7 Datacenter Activation Coordination (DAC) mode

The Datacenter Activation Coordination mode is a high-availability feature designed for use in Database availability groups that span across multiple sites. This mode is disabled by default and needs to be enabled.

DAC mode is used to prevent “Split Brain Syndrome”, in which connectivity between datacenters is lost but both datacenters are still functioning. If the DAG in one datacenter loses connectivity with the other site and tries to bring online any database copies that were active in the other datacenter, the environment will now have multiple active copies of the same database.  Under DAC, any mailbox databases that were active in an alternate site will not be automatically mounted until all other members of the DAG can be contacted, also known as the “Mummy may I” protocol. DAC is activated as follows:

8 Mailbox Storage Quotas

Chimp Corp ITS has defined a requirement that the mailbox size limited to 5 GB per mailbox for all user classes.  Implementing mailbox quotas reduces the risks associated with unexpected growth in mailbox database size and provides a reliable maximum disaster recovery timeframe based on assumptions that a mailbox database size cannot exceed 1TB in size. Several parameters can be configured below to facilitate

9 Public Folder Design

Public Folders will be required as part of the design in order to support access to Free/Busy information during the period of migration and coexistence. In Exchange 2013, public folders have now been integrated into Exchange databases and are hosted inside of a public folder mailbox. Client access to public folders is enabled via web-based RPC calls over HTTP to CAS servers which then proxy the communications to a hosted Mailbox server. Public folders are now fully integrated with the replication and high availability of Exchange Mailbox Servers and DAG and no longer utilize a separate replication mechanism. Office 365 now fully supports modern Public folders to provide users with the functionality of public folders that they like.

Changes in Public Folder architecture in Exchange 2013 mean that since only a single active copy of a mailbox database can be available at any time, public folder mailboxes should be collocated as close to users as possible. In the Chimp Corp design, low latency connections between datacenters minimizes this issue.

Conclusion

In this section, we covered several design considerations when it comes to implementing a Mailbox Server Design in Exchange 2013. Standardization is key, as it supports the scalability and predictability of the messaging system. We start by defining mailbox sizes that represent the various user classes in the messaging environment. Mailbox sizes can be used as basic building blocks which we can subsequently use to define optimal mailboxes to allocate per databases, DAG design and finally server allocation.

References

Exchange team blog article explaining the Exchange Mailbox Server Role Requirements Calculator here.