Exchange 2010 is a significant upgrade from Exchange 2007 and Exchange 2003, yet along with the product’s new capabilities, there are a few major changes. Microsoft has removed what used to be key features of Exchange in this latest product iteration. In this article, I explain what’s changed and how it might affect your upgrade planning.
In Exchange 2007, when a user sent a message with an attachment to 1,000 users, only a single copy of that attachment was stored in the Exchange database; pointers were then used to point individual mailboxes to those shared attachments. With Exchange 2007, Microsoft took the first steps toward the eventual elimination of single-instance storage by not “single-instancing” message bodies. Prior to Exchange 2007, everything — messages and attachments — was single-instanced.
Over the years, the capacity of new hard drives has gone through the roof, whereas overall disk performance has accelerated at a comparative snail’s pace. Exchange 2010’s capacity vs. performance choice falls squarely on the performance side of the equation with significant improvements in overall I/O being the result. Another result is that Exchange 2010 supports a broader array of storage devices, including less expensive SATA disks. However, this also means that each time a user sends out a message with a 10 MB attachment, you can truly multiply that message size by the recipient count as the overall impact to the database size. To help counter this issue, Exchange databases are now compressed, at least to a point; messages headers and bodies are compressed but attachments are not.
Planning impact: Make sure you plan for adequate storage and understand that you now pay for each and every byte or each and every message and attachment. Exchange 2010’s support for SATA disks should help keep costs in line.
Planning impact: Overall storage design planning is simplified with no need to try to figure out which mailboxes databases to place in individual storage groups. Long-term administration is simplified as well.
DAGs make it far less complex to create highly available Exchange architectures that live in a single data center or span data centers across the globe. DAGs support up to 16 copies of your Exchange databases and handle much of the complexity of Clustering Services in the background and, even then, DAGs only use a subset of the full Windows Failover Clustering service, simplifying administration. Further, at install time, you don’t need to worry about whether you’re running a standalone mailbox server or a clustered mailbox server since any mailbox server can be made a member of a DAG at any time.
With Exchange 2010’s improvements, Microsoft has also increased the maximum recommended clustered database size from 200 GB to 2 TB; this means that you can run your operations with fewer databases, which, in turn, means less ongoing administrative effort.
Planning impact: A fully redundant Exchange 2010 infrastructure can be accomplished with as few as two servers, while the equivalent architecture under Exchange 2007 requires four. Redundancy does not need to be planned ahead of time; it can be added at any point.
So long, single-instance storage
Long a staple of the Exchange world, single-instance storage was ideal for the enterprise when storage costs were sky-high. These days, with storage costs so low that the amount of data being racked up multiples on a regular basis, Microsoft has traded storage space for overall storage performance.In Exchange 2007, when a user sent a message with an attachment to 1,000 users, only a single copy of that attachment was stored in the Exchange database; pointers were then used to point individual mailboxes to those shared attachments. With Exchange 2007, Microsoft took the first steps toward the eventual elimination of single-instance storage by not “single-instancing” message bodies. Prior to Exchange 2007, everything — messages and attachments — was single-instanced.
Over the years, the capacity of new hard drives has gone through the roof, whereas overall disk performance has accelerated at a comparative snail’s pace. Exchange 2010’s capacity vs. performance choice falls squarely on the performance side of the equation with significant improvements in overall I/O being the result. Another result is that Exchange 2010 supports a broader array of storage devices, including less expensive SATA disks. However, this also means that each time a user sends out a message with a 10 MB attachment, you can truly multiply that message size by the recipient count as the overall impact to the database size. To help counter this issue, Exchange databases are now compressed, at least to a point; messages headers and bodies are compressed but attachments are not.
Planning impact: Make sure you plan for adequate storage and understand that you now pay for each and every byte or each and every message and attachment. Exchange 2010’s support for SATA disks should help keep costs in line.
Adios, storage groups
With the introduction of Exchange 2010, Microsoft has done away with storage groups. This doesn’t come as a surprise; after all, under a number of high-availability scenarios in Exchange 2007, you could have only one database inside a storage group anyway. Remember that in previous versions of Exchange (including Exchange 2000, Exchange 2003, and Exchange 2007), storage groups were the level at which transaction logs were stored for the individual mailboxes databases stored inside the storage group. With the elimination of storage groups, each database now gets its own transaction log as well. To go along with this change, mailbox databases are now managed at the organization level rather than at the server level, and databases can be mounted on any available mailbox server.Planning impact: Overall storage design planning is simplified with no need to try to figure out which mailboxes databases to place in individual storage groups. Long-term administration is simplified as well.
Sayonara, complex high-availability options! Hello, database availability groups!
Exchange 2007 introduced a variety of high-availability options, from local replication to availability and redundancy options that could span data centers. While these were very welcome additions at the time, Exchange 2010 eliminates them in favor of a new feature called Database Availability Groups (DAGs).DAGs make it far less complex to create highly available Exchange architectures that live in a single data center or span data centers across the globe. DAGs support up to 16 copies of your Exchange databases and handle much of the complexity of Clustering Services in the background and, even then, DAGs only use a subset of the full Windows Failover Clustering service, simplifying administration. Further, at install time, you don’t need to worry about whether you’re running a standalone mailbox server or a clustered mailbox server since any mailbox server can be made a member of a DAG at any time.
With Exchange 2010’s improvements, Microsoft has also increased the maximum recommended clustered database size from 200 GB to 2 TB; this means that you can run your operations with fewer databases, which, in turn, means less ongoing administrative effort.
Planning impact: A fully redundant Exchange 2010 infrastructure can be accomplished with as few as two servers, while the equivalent architecture under Exchange 2007 requires four. Redundancy does not need to be planned ahead of time; it can be added at any point.
Comments