With the release of Exchange 2007, you could still rely on concepts that were old hat from previous versions of Exchange such as storage groups. You understood, perhaps, that a storage group was a way of bringing together databases (Mailbox and Public Folder) and that transaction logs for those databases would all be written, in sequential order, for multiple databases within a storage group. However, with Exchange 2007's high-availability options, you were constantly told that you can only have one database per storage group if you want these to work. That made sense because the Exchange 2007's approach to high availability uses continuous replication, which mean your transaction logs are shipped over to and replayed at the new location (the new disk, server, or site, depending on if you are using Local Continuous Replication, Cluster Continuous Replication, or Standby Continuous Replication). That basically sums up volumes' worth of Storage Groups, Databases and HA in Exchange 2007. Still with me?
In Exchange 2010, storage groups are gone! Now, you might be thinking, that makes sense. Even in Exchange 2007, it seemed the emphasis shifted from the storage group structure to the database side. You could have 50 storage groups and 50 databases (in the Enterprise Edition), which just seems like an extra step for no reason other than to allow folks the versatility of putting multiple databases into a storage group. Ultimately though this would complicate recovery for administrator's because all of the databases in the storage group share a common log stream.
[ Read J. Peter Bruzzese's guide to Exchange 2010 enhancements. | See the InfoWorld Test Center's first look at Exchange 2010. ]
In Exchange 2010, there's another related change to note: the location for the databases to be managed. Under the Exchange 2007 Exchange Management Console, you would look at the navigation pane through the Exchange hierarchy for servers, then locate the individual server, followed by the storage groups and databases. However, in Exchange 2010 a change has been made in how Databases are viewed in Active Directory. Now they are peer objects with Server objects. What this mens is that, like servers, databases are now global objects and, as a result, the location for database management is now performed under the Mailbox node of the Organization Configuration node (as opposed to under the Server Configuration node like you may be used to).
In addition to changing the organizational structure for databases, Exchange 2010 has improved the physical types of storage you can use with solid performance returns. For example, Exchange 2010 supports SATA disk drives and RAID-less configurations. You can go with a SAN, DAS (direct-attached storage), or JBOD (just a bunch of disks) storage and get reliable, decent performance. (Note: Microsoft only recommends JBOD for very specific configurations, for example, an HA configuration where at least three mailbox database copies are used.) Microsoft claims that Exchange 2010 has half the disk IO compared to Exchange 2007; if true, this means you can use lower-performance disks than before and still get enterprise-class results.
But let me drop the next informational bomb on all of you folks who did your best to learn the high-availability options for Exchange 2007: Local Continuous Replication (LCR), Cluster Continuous Replication (CCR), and Standby Continuous Replication (SCR) are all gone in Exchange 2010. Well, in the case of CCR and SCR they aren't quite gone, but they've morphed into something new. Elements from CCR and SCR have been combined into the new HA framework.
To start with, Single Copy Clusters, which was a carry-over from legacy Exchange clustering using shared storage arrays, are gone. The three remaining high-availability methods (LCR, CCR, and SCR) had been used to provide disk, server, and site resiliency, respectively. Of those three, LCR (which allowed you to make a database copy on the same server in Exchange 2007, is eliminated) In Exchange 2010, they have become part of something called Database Availability Groups (DAGs).
DAGs provide automatic recovery by using small portions of Windows Failover Clustering and a new internal component of Exchange 2010 called Active Manager.using continuous replication. That's a real change from Exchange 2007, whose only automatic recovery capabilities were those using failover clustering services. LCR and SCR did not, so you manually had to provide the swap over to the passive data in those cases. CCR used failover clustering and was automatic.
So how is it going to work with Exchange 2010? DAGs still use some features of Windows clustering for the heartbeat and quorum, so the new Active Manager can manage a failover in case one of the DAG nodes crashes. There is also database level failover (and switchover). It's not just for server crashes but any failures that affect an active database can be dealt with (within 30 seconds) by Active Manager. You still need the Enterprise Edition (or Datacenter Edition) of Windows Server for some of those clustering features to work, but you don't have to stress out about setting up the cluster before you install the Mailbox role. (For those of you who have configured CCR, you know what I mean about setting up the server, getting the cluster in place, and then doing the installation of the Active Mailbox role.) Instead, when you add the first MBX server to the DAG WFC is automagically added behind the scenes.
With a DAG you can have up to 16 copies of a database (how is that for resilience?) and install other server roles on a server that is a member of a DAG. In contrast, with CCR, you had to isolate your active and passive MBX servers from other server roles. Speaking of resilience, DAG members can be located on different subnets and in different Active Directory sites, although this doesn't differentiate what could be done with CCR because you can have CCR on Windows 2008 that can be on different subnets and SCR allowed you to replicate to a separate AD site.
Let's recap: Storage groups, single-copy clusters, SCR, CCR, and LCR are all gone. What remains are databases that become the main focus beyond storage groups; continuous replication with asynchronous log shipping through DAGs to provide for disk, server, and site (or datacenter) resiliency; and cheaper storage solutions like JBOD to help you reduce cost, improve mailbox sizes, and increase performance.
Stay tuned for more!