Scott Schnoll and his posse delivered a great session on availability technology in Exchange 2010 at INTERACT yesterday. We’ve been using this technology for a while now at 3Sharp, and it really is very, very cool.
So, the really big availability news in Exchange 2010 is the introduction of a new construct, the database availability group (DAG). The DAG is a collection of up to 16 servers, each of which can contain a replica of a mailbox database. For example, I could put MDB1, MDB2, and MDB3 on server1, MDB2 and MDB4 on server2, MDB1 and MDB3 on server 3, and so on.
Mailbox databases are now the target object for failover– instead of having an entire mailbox server failover using Windows clustering, the mailbox database itself fails over to another server within the same DAG. For example, MDB1 can move from server1 to server3, either automatically or manually.
Essentially, this is a mechanism for replicating mailbox databases between servers, something that the Exchange admin community has been asking for for years! Some highlights:
- Log shipping no longer uses SMB; instead it uses the ESE streaming API for seeding [ed: hat tip Scott Schnoll for the correction], which is considerably more efficient, and raw TCP sockets for replication. In Exchange 2007, there was one SMB session for all databases on a server. In Exchange 2010, there’s one TCP socket per database, so scalability and parallelization are greatly improved.
- This provides HA for systems that are built on top of DAS; in fact, it’s optimized for DAS. You can use dedicated storage per node; replication means that you can use JBODs without even using RAID.
- DAGs can span AD sites, subnets, and so on (although all servers in the DAG must be in the same AD domain). You can control and throttle DAG replication at the network level or using the DAG controls for log lag.
- The setup experience is completely different than SCC. To enable a DAG, you create a DAG and then add database replicas to it. You don’t have to manually create any of the failover mechanisms, install any Windows prerequisites, or any of the stuff you’d have to do with single-copy clusters (SCC).
The advent of the DAG means that some legacy features are disappearing. First, there are no storage groups in Exchange 2010– each database has its own associated set of logs. Second, SCC is dead (e.g. no longer supported). Personally, I won’t miss it.
Interesting question posed by Josh Maher: do you still need backups? We debated this hotly at the MVP Summit. Microsoft’s position is that some organizations may choose to do fewer backups once they deploy DAGs because their databases are already distributed across multiple servers in multiple sites. Of course, this distribution doesn’t protect you against logical errors in the database, which to me weakens the argument that you don’t need backups. Microsoft itself doesn’t do backups internally any longer. They don’t have business requirements to recover long-term archived mail.
Public folders: no changes, except that you can no longer use continuous replication for public folders. You can put a PF database on a server that’s in a DAG, but you can’t put the PF database itself into the DAG. Because Exchange 2007 limited you to having a single PF database per CCR-protected storage group, this isn’t actually a loss.
More to come on this topic– heaven knows there will be a lot of interesting stuff to explore as people start experimenting with DAGs in their lab. As for us, we’re about to expand our Redmond DAG by adding a server in Toledo to give us site resiliency too– should be fun!
UPDATE 15 Apr 1405 PDT: Ewan Dalton has more on the new features here.