Database Availability Group (DAG)
Database Availability Group (DAG) is the new high availability solution in Exchange 2010. None of the clustering technologies in 2007 is valid in 2010.
DAG is a collection of upto 16 mailbox servers with a maximum of 16 copies of each database. It makes the database independent of any server and gives us failover on a mailbox level rather than a hardware or storage group level as in 2007. To illustrate it, if one database gets corrupted or the disk having the files fails, you can quickly mount a copy of the same database in any of the servers which is part of the DAG.
Once first node becomes a part of a DAG, the failover clustering quorum settings will be set to “Node Majority”. Once the second node is added, the quorum setting is automatically changed to “Node and file share majority”. The file share witness is only created once the second server is added to the DAG as the quorum setting is only changed at that time.
Log shipping no longer uses SMB; instead it uses the ESE streaming API for seeding, 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).
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.
DAG Information
When an administrator creates a DAG, it is initially empty, and an object is created in Active Directory that represents the DAG. The directory object is used to store relevant information about the DAG, such as server membership information. When an administrator adds the first server to a DAG, a failover cluster is automatically created for the DAG. DAGs use a subset of Windows Failover Clustering technologies, namely, the cluster heartbeat, cluster networks, and the cluster database (for storing data that changes or can change quickly such as database mount status, replication status, and last mounted location).
- File Share Witness (FSW) is configured for the cluster, but must be server outside the DAG.
- Although a Windows Failover Cluster is created, no cluster resources are created and all DAG administration is managed from Exchange. Failover management is also managed entirely within Exchange.
- Replication of database copies, and failover of those database copies, can only be with servers which are members of the same DAG.
Mailbox Servers
- In Exchange 2007 database server either hosted only active or passive copies of a database. In Exchange 2010, a server within a DAG can hold both Active and passive copies of databases, so the mailbox server needs to service both of these types of databases.
- Executes Store services on active mailbox database copies.
- Executes Replication services on passive mailbox database copies.
- Active definition of health – Is Information Store capable of providing email service against it?
- Passive definition of health – Is Replication Service able to copy logs and play them into the passive copy?
- Each server can host up to 100 database copies.
Because DAGs rely on Windows Failover Clustering, they can only be created on Exchange 2010 Enterprise Edition Mailbox servers that are running Windows Server 2008 Enterprise or Windows Server 2008 Datacenter. In addition, each Mailbox server in the DAG must have at least two network interface cards in order to be supported.
Mailbox Database
A failover or switchover occurs at the database level. Since a failover now only involves a database, rather than an entire server, the failover time has been reduced from around 2 mins to 30 seconds which considerably improves the client experience.
Database names for Exchange 2010 must be unique within the Exchange organization, as these are now Organization-wide objects rather than being tied to a server. Within a DAG a database may have a copy on any server within the DAG.
When a mailbox database has been configured with one or more database copies, the full path for all database copies must be identical on all Mailbox servers that host a copy.
Mailbox Database Copy
Only one copy of a database can be active with a DAG
Replication
Continuous replication has the following basic steps: Database seeding; Log copying; Log inspection; Log replay
Exchange Server 2007 utilized SMB and notifications to get logs. Exchange Server 2010 utilizes TCP sockets and notifications to the source about which logs are required on the target.
Exchange 2010 supports options encryption and compression of the logs. These features are set at the Database Availability Group Level.
After the log files have been inspected, they are placed within the log directory so that they can be replayed in the database copy. Before the Replication service replays the log files, it performs a series of validation tests.
Once these validation checks have been completed, the Replication service will replay the log iteration.
----------------------------------------------------------------------------------------
No comments:
Post a Comment