One of the topics I receive a lot of questions about is
Datacenter Activation Coordination Mode, or DAC Mode for short. Here is
an excerpt from Deploying and Managing Exchange Server 2013 High Availability that covers this topic in more detail.
Credit Goes to exchangeserverpro.com.
Datacenter Activation Coordination (DAC) Mode is a property of DAGs that is designed to prevent split brain conditions from occurring by enabling a protocol called Datacenter Activation Coordination Protocol (DACP).
In addition, DAC Mode enables the use of three PowerShell cmdlets for site-resilience:
A split brain condition can occur in a multi-site DAG when one datacenter goes offline entirely. It can also occur in a single-site DAG in some network failure situations. Let’s take a look at an example of a multi-site failure where the benefits of DAC mode become clear.
In this example the Sydney and Melbourne datacenters each host two DAG members, with Sydney also hosting the file share witness server. To keep this example simple a single database exists in the DAG, currently active on a Sydney DAG member.
The Sydney datacenter has a power failure that takes the entire site offline. With two DAG members and the FSW offline in Sydney, and just two DAG members online in Melbourne, quorum can’t be maintained and the database goes offline.
The administrators activate the alternate file share witness in Melbourne to restore quorum, and bring the database online in Melbourne to restore service.
Eventually the datacenter in Sydney has power restored and the Sydney DAG members and file share witness come back online. However, the WAN connection remains offline, preventing the DAG members in each site from communicating with each other.
The two Sydney DAG members and file share witness have enough votes to achieve quorum, so the database is brought online in Sydney.
At this stage the problem should be apparent. Both Sydney and Melbourne have an active copy of the same database because the DAG members in each site were not able to communicate with each other. A split brain condition has occurred.
DAC and DACP prevent this behavior by requiring a DAG member to check with other DAG members before it is allowed to bring database online.
DACP exists as a bit (a 0 or 1) that is stored in memory. When DAC mode is enabled each DAG member starts up with a DACP bit of 0. Until it can communicate with a DAG member that has a DACP bit of 1, or alternatively it can communicate with every other member of the DAG, it will not attempt to activate its database copies even if it can achieve quorum with some of the DAG members.
To demonstrate this let’s go back in the example scenario above to the stage where the Sydney datacenter was coming back online again.
When DAC Mode has been configured in advance the Sydney DAG members start up with a DACP bit of 0 and are unable to communicate with the Melbourne DAG members because the WAN link is still offline.
Therefore they do not bring the database online in Sydney, preventing a split brain condition.
When the WAN connection is restored the Sydney DAG members are able to communicate with the Melbourne DAG members. Their DACP bit is set from 0 to 1 and, because they now realize that the database is already active in Melbourne, their database copies become passive copies.
For more on DAC mode and other features of database availability groups check out the
Credit Goes to exchangeserverpro.com.
Datacenter Activation Coordination (DAC) Mode is a property of DAGs that is designed to prevent split brain conditions from occurring by enabling a protocol called Datacenter Activation Coordination Protocol (DACP).
In addition, DAC Mode enables the use of three PowerShell cmdlets for site-resilience:
- Stop-DatabaseAvailabilityGroup
- Restore-DatabaseAvailabilityGroup
- Start-DatabaseAvailabilityGroup
A split brain condition can occur in a multi-site DAG when one datacenter goes offline entirely. It can also occur in a single-site DAG in some network failure situations. Let’s take a look at an example of a multi-site failure where the benefits of DAC mode become clear.
In this example the Sydney and Melbourne datacenters each host two DAG members, with Sydney also hosting the file share witness server. To keep this example simple a single database exists in the DAG, currently active on a Sydney DAG member.
The Sydney datacenter has a power failure that takes the entire site offline. With two DAG members and the FSW offline in Sydney, and just two DAG members online in Melbourne, quorum can’t be maintained and the database goes offline.
The administrators activate the alternate file share witness in Melbourne to restore quorum, and bring the database online in Melbourne to restore service.
Eventually the datacenter in Sydney has power restored and the Sydney DAG members and file share witness come back online. However, the WAN connection remains offline, preventing the DAG members in each site from communicating with each other.
The two Sydney DAG members and file share witness have enough votes to achieve quorum, so the database is brought online in Sydney.
At this stage the problem should be apparent. Both Sydney and Melbourne have an active copy of the same database because the DAG members in each site were not able to communicate with each other. A split brain condition has occurred.
DAC and DACP prevent this behavior by requiring a DAG member to check with other DAG members before it is allowed to bring database online.
DACP exists as a bit (a 0 or 1) that is stored in memory. When DAC mode is enabled each DAG member starts up with a DACP bit of 0. Until it can communicate with a DAG member that has a DACP bit of 1, or alternatively it can communicate with every other member of the DAG, it will not attempt to activate its database copies even if it can achieve quorum with some of the DAG members.
To demonstrate this let’s go back in the example scenario above to the stage where the Sydney datacenter was coming back online again.
When DAC Mode has been configured in advance the Sydney DAG members start up with a DACP bit of 0 and are unable to communicate with the Melbourne DAG members because the WAN link is still offline.
Therefore they do not bring the database online in Sydney, preventing a split brain condition.
When the WAN connection is restored the Sydney DAG members are able to communicate with the Melbourne DAG members. Their DACP bit is set from 0 to 1 and, because they now realize that the database is already active in Melbourne, their database copies become passive copies.
For more on DAC mode and other features of database availability groups check out the
No comments:
Post a Comment