A First Look at Exchange 2010

Anyone dedicated to trivia will note that the code name for Microsoft Exchange Server 2007 was Exchange 12, but the next major release of its mail server has been code named Exchange 14. Microsoft skipped 13 for the same reason that many hotels don’t have a thirteenth floor—superstition! Exchange 14 is expected to ship in late 2009 and have a final name of Microsoft Exchange Server 2010. Exchange 2010 follows up the architectural changes made in Exchange 2007 with some big updates of its own to give the product better performance and make it more resilient and easier to manage. The most important changes fall broadly into the categories of an Information Store refresh, a new approach to high availability, management and administration updates, and messaging compliance improvements.

Enhancements to the Store
Exchange has always been a challenging application for storage because the I/O profile of a busy mailbox server consists of many random small I/O operations rather than the predictable I/O patterns you see in other database-centric applications. This situation can be explained by the huge variety of messages that an Exchange server handles—from the simple, one-line message sent to a single recipient to the multimegabyte message (including attachments) sent to nested distribution lists. Obviously these transactions create radically different I/O demands.

Microsoft greatly reduced disk I/O with Exchange 2007, largely by trading the extra memory made available by using the 64-bit platform to cache as much Store data as possible. This process resulted in a significant I/O reduction per active mailbox—except in the case of large mailboxes. The problem with large mailboxes is that users tend to keep thousands of items scattered around hundreds of folders. The more items and folders in a mailbox, the more work the Store has to do to organize and maintain the indexes that underpin the mailbox. Windows Desktop Search with its Microsoft Office Outlook integration lets users become even less organized: If they forget where something is in their large folder structure, it’s easy to perform a search to find the desired item.

So, although Exchange 2007 made real improvements by optimizing Store caching, human behavior meant that further work was necessary for Exchange to effectively support very large mailboxes. As it happens, Microsoft had previously assessed whether they could move the underlying Store database engine from Extensible Storage Engine (ESE) to Microsoft SQL Server. The engineering investment to make this change proved too great, which is why Exchange still uses ESE. However, the investigation reviewed some fundamental aspects of the Store database, including its schema and tables. As a result, some changes to aid performance were included in Exchange 2007, notably the increase in page size from 4KB to 8KB and smoother I/O transactions. Further performance improvements in Exchange 2010 include:

• Increased page size from 8KB to 32KB—With this change, more data can be stored in a single page, avoiding the need to scatter across the database the pages required for a single item, including any attachments.
• Header data for all mailbox items is stored in a single database table—This change makes the database more efficient because it can process a single table for a mailbox during a client session instead of accessing different tables for different mailbox folders. A side effect of this schema change is that Exchange no longer uses Single Instance Storage (SIS) to keep just one copy of message content per database. Most servers support multiple databases, so the efficiency gained from SIS is less and less as time goes on.
• The Store compresses attachments—Microsoft calculates that the CPU time spent compressing and decompressing attachments is less than the work required to manage the storage of very large uncompressed data within the database. This change also reduces the overall size of Exchange databases, which speeds up operations such as backups.
• The Store updates views (indexes) only when they're accessed—An Outlook client can create many different views for a folder on the fly (e.g., items ordered by subject), and the Store maintains these views within the database. The Store ages unused views out after 40 days, but it needs to maintain views until then. Updating views only when needed eliminates a lot of background processing.

Microsoft’s initial performance results indicate that the new Store generates substantially fewer I/O operations than its Exchange 2007 equivalent. Reducing I/O lets servers support more mailboxes as well as allowing additional flexibility in storage options. Traditionally, large mailbox servers have used high-end storage configurations such as SANs to deliver excellent I/O performance with maximum reliability. If Exchange 2010 delivers a smaller I/O footprint and better resilience, system designers might be tempted to use lower-cost Serial ATA (SATA) and Just a Bunch of Disks (JBOD) storage. Companies that use SANs can continue to do so, especially when they’ve made that choice because they manage storage centrally rather than on an application by application basis. Microsoft’s drive to support lower cost storage through better I/O performance is a good thing, but changes will still occur in the code before Exchange 2010 ships, so we’ll have to wait a bit to know how to optimize storage for production environments.

High Availability at the Core
Exchange 2007 introduced log shipping to let administrators replicate data to local disks (local continuous replication—LCR), to another node in a cluster (cluster continuous replication—CCR), and to a server in another data center (standby continuous replication—SCR). Microsoft builds off this log shipping technology to make high availability a core characteristic of Exchange 2010. Microsoft is shaking up Exchange’s high availability feature set through four key steps:

• The concept of storage groups is eliminated, so the database becomes the management unit to plan high availability around—this is a sensible step given that log replication works only for a storage group containing a single database.
• Single copy clusters are eliminated and not supported in Exchange 2010. Microsoft is moving toward the idea that maintaining multiple copies of data on multiple servers delivers better high availability than attempting to update a single copy of data. Microsoft has also removed LCR from Exchange 2010 because log replication on the same server delivers limited value.
• Exchange 2010 introduces Database Availability Groups (DAGs), which are groupings of up to 16 servers in which some or all of the databases are marked for replication to one or more other servers. Microsoft uses some components of Windows clustering (e.g., heartbeats, the file share witness) to connect servers within the DAG, which can span physical locations. The big feature is that you can replicate databases to multiple servers within the DAG through log shipping, so locations within a DAG must share sufficient network resources to be able to copy logs quickly enough so that queues of unplayed logs don't build up; think of this requirement as being similar to that of SCR today. Replication targets are chosen at the database level rather than the server level, so you can replicate different databases from a server to different servers within the DAG. For example, a server in New York that has two databases could replicate one database to a server in Los Angeles and the other to a server in Seattle. The live database is referred to as the master; if a problem occurs with the master database, a component called the Active Manager switches to one of its replicas and makes it the live master. Microsoft includes management for DAGs in Exchange 2010's version of Exchange Management Console (EMC) and adds Exchange Management Shell (EMS) commands, so you can control DAGs through the GUI or the command line.
• A new component in Exchange 2010 called the RPC Client Access Layer upgrades the Client Access server role so that all client connections flow through a predictable point in the network. With the potential for live copies of databases switching between servers, clients can become confused when they attempt to connect to a mailbox. Exchange 2007 introduced the Client Access role, which manages connections from all clients except MAPI (i.e., Outlook). In Exchange 2010, the Client Access role determines which server currently hosts the live copy of a mailbox by reference to the DAG information, which is held in Active Directory (AD), and is therefore able to redirect clients when a database has been switched.