Database Availability Group (DAG)
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.
•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.
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
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.
Database Availability Group (DAG) When an administrator creates a DAG, it is initially empty, and an
DAG's can also be created on Exchange 2010 Standard Edition. All you need is Enterprise Edition of the OS.
Why? "All you need is Enterprise Edition of the OS"
It's not possible to doit with Windows 2008 Std 64bit?
It needs 64-bit Enterprise OS since it requires clustering components for DAG and also if you need more than 32GB of RAM on a mailbox server.
Thanks Greg, What the Log inspection will do and what are all the Validation tests will be performed before the log replay.