Monday, 21 December 2015

Exchange 2016 Database Availability Group (Part 1)

Introduction


In this post, I’ll demonstrate how to set up a simple Exchange 2016 Database Availability Group with two servers on the same subnet. We’ll go through some background information then set up a DAG and configure our networking. 

To read other parts in this series go to:


Exchange 2016 DAG Basics


An Exchange DAG is the mailbox role high availability. Setting up a DAG therefore only provides high availability for mailbox databases and public folder mailboxes stored in these databases. If you want CAS high availability then you’ll need to use DNS round robin or an external load balancer but we’ll discuss CAS load balancing in another post.

Points to note:

  • Exchange DAGs don’t require shared storage (mailbox databases are stored on the local disks on the server and logs are shipped to other servers)
  • All mailbox servers must be in the same AD domain
  • You create database copies but are limited to 16 copies for each database
  • You can’t create a database copy on a server that already has an active or passive copy of that database
  • The mailbox servers cannot be domain controllers - this is not supported
  • When a DAG is set up, a Windows Failover Cluster is set up. You cannot use this cluster for any other servies – this is not supported.
  • Datacenter activation coordination (DAC) mode prevents a split brain scenario where the same database is active in both datacenters and you then get dirvergence of data where changes are made to both databases but not replicated across. DAC is not enabled by default but should be enabled for all DAGs. We’ll enable this on our DAG.
  • DAGs only provide high availability for the mailbox role (the mailbox databases). It doesn't provide high availability for the client access services (OWA, Outlook, ActiveSync etc). You will need to set up load balancing for the client access services using either DNS round robin or a hardware load balancer. For information on how to configure DNS round robin and the advantages/disadvantages of using this over a hardware load balancer, see here.



Networking requirements



  • Use at least 1Gb connections for the DAG members but 10Gb is preferable
  • You can configure a DAG with a single network which will be used for MAPI and REPLICATION or you can set up two separate networks – one for MAPI and one for REPLICATION. The latter is preferred for performance and high availability although it adds some complexity.
  • If you're using separate MAPI and REPLICATION networks, a MAPI network failure will cause a server failover. If the REPLICATION network fails then the MAPI network will be used for replication even if the RecplicationEnabled property on the network is set to False. Manual fail back to the REPLICATION network will be necessary if it is restored. To fail back, suspend and resume the mailbox database copy. The other option is to restart the Microsoft Exchange Replication service but this causes a brief outage.
  • Each DAG member requires the same number of networks and network adapters
  • Additional REPLICATION networks can be added and you can configure teaming on the REPLICATION network adapters although this does add complexity
  • Each DAG member must only have one MAPI network which needs to have access to other Exchange servers, DNS and AD
  • The MAPI network adapter for each server must be able to communicate with each other server's MAPI network and should be the only network adapter configured with a default gateway
  • The REPLICATION network adapter for each server must be able to communicate with each other server's REPLICATION network
  • The REPLICATION network should be isolated from other REPLICATION networks (if you're using multiple REPLICATION networks) and also isolated from the MAPI network
  • Roundtrip latency must be lower than 500ms however you must also look at the effect of this latency on other services e.g. CAS services
  • Automatic Private IP Addressing (APIPA) for DAG members is not supported



Quorum and witness server requirements


You must always have an odd number of voters in a cluster. If you have an even number of mailbox servers in the DAG, the DAG will use a node and file share majority quorum model where it will use a file share witness which is created on a witness server during the DAG setup. If you have an odd number of mailbox servers in the DAG then the DAG will use the node majoirty quorum model and the file share witness will not be used.

The witness server can be any server in the domain running Server 2003 or later but not a DAG member because you’ll lose two votes if that member goes down and ideally not a domain controller as this means that the Exchange Trusted Subsystem has more permissions than it requires which is not a best practice.

The DAG will create a file share on the witness server and will use this as a voter in case you have an even number of mailbox servers.


Lab environment


As we start the demonstration, I’ll give you a quick run through the servers I have in this lab. I have two Exchange 2016 servers in the litwareinc.com domain which has two domain controllers and a file server as below:

image

All servers are running Server 2012 R2. We’ll set up a DAG using these two Exchange servers.


Set up MAPI and REPLICATION networks


We’ll use the current network (10.2.0.0/16) as the MAPI network. We then need to add an additional network adapter on each Exchange server to be used for the REPLICATION network – it’s a good idea to name the network adapters to avoid confusion.

image

Set up a REPLICATION network on an isolated subnet. It should not be able to route to the MAPI network or other networks. In this case, I’m using 172.16.0.0/16.

The REPLICATION network should not have a default gateway or any DNS servers configured. You should now have networking that looks something like this:

image

Just to confirm, your IPCONFIG output for should look like this (this is for LITEX02):

image

The next step is to disable the network features that are not required. For the MAPI network adapters, we don’t need to change any of the defaults. You should have the below enabled (yes, IPv6 should be enabled!)

image

For the REPLICATION network adapters, disable the below features:

  • Client for Microsoft Networks
  • File and Printer Sharing for Microsoft Networks


Your replication network should now look like this:

image

On the REPLICATION network adapters, ensure that they are configured not to register their addresses in DNS. To do this, double click on the network adapter, double click on Internet Protocol Version 4 (TCP/IPv4):

image

Then click on advanced then the DNS tab and untick “Register this connection’s addresses in DNS” as below then press OK on all windows.

image

That’s it for networking. Next up is the witness server configuration.


Configure the witness server


The witness server shouldn’t be a domain controller or a DAG member. In this case, we’re left with only our file server so we’ll use that. When we create the DAG, Exchange will create a witness directory and share on the witness server. To do this, it requires that the “Exchange Trusted Subsystem” AD group is a local administrator on the witness server. If you’re interested in the membership of the group, it includes all the Exchange servers:

image

Add the “Exchange Trusted Subsystem” group as a local administrator on the witness server:

image

Create an Exchange 2016 Database Availability Group


All the preparation is now done and we’re good to go ahead and create our DAG. We can use either the Exchange Admin Center (EAC) or PowerShell to do this. EAC and PowerShell instructions are below:


Create an Exchange 2016 DAG using the Exchange Admin Center


Log into the Exchange Admin Center using an account that’s a member of the Organization Management AD group or assigned the Organization Management or Database Availability Groups roles in Exchange:

image

Click on Servers then click on Database Availability Groups:

image

Click the + icon to create a new Database Availability Group then assign a name, witness server and witness directory for your DAG. I’m using the settings below:

  • DAG Name: DAG01
  • Witness Server: LITFS01
  • Witness Directory: C:\DAG01-witness


As we’re using Server 2012 R2, we can set up an IP-less DAG. These are recommended and simpler to manage and set up but not supported unless you’re running Server 2012 R2 or later. Note that you cannot manage an IP-lesscluster using the failover cluster management console – you need to use PowerShell. We therefore don’t need to add an IP address as per the screenshot below. Once you’re entered the details, click on Save.

image

We now have a DAG set up:

image

The DAG has no members – it’s just an AD object at the moment. To add a server to the DAG, highlight the DAG in the screenshot above and click on the image icon.

Click on the + icon to add servers:

image

Add the Exchange servers you want to add to the DAG:

image

Then press OK. You’ll be presented with the window below. Click Save.

image

Exchange now prepares the servers and then adds them to the DAG. You’ll notice that the Windows Failover Clustering feature is installed as part of this process:

image

Our DAG is now created:

image

Click close and we can now see that our DAG has both LITEX01 and LITEX02 as members:

image


Create an Exchange 2016 DAG using PowerShell


Hopefully you’re now starting to use PowerShell more. If not, maybe the fact that we can create a DAG in three lines of PowerShell may sway you a bit more.
First, create new DAG with the settings below:


  • DAG Name: DAG01
  • Witness Server: LITFS01
  • Witness Directory: C:\DAG01-witness


New-DatabaseAvailabilityGroup -Name DAG01 -DatabaseAvailabilityGroupIPAddresses ([System.Net.IPAddress]::None) -WitnessServer LITFS01 -WitnessDirectory C:\DAG01-witness

image

Next up, we will add LITEX01 to the DAG:

Add-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer LITEX01

image

Then we’ll add LITEX02 to the DAG:

Add-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer LITEX02

image

Configure DAG networks


We need to set our DAG so we can configure our networks manually as this is not possible by default. We then need to disable replication for our MAPI network.


Configure DAG networks using the EAC


Double click on our newly created DAG and tick the option “Configure database availability group networks manually” as below then click Save:

image

By default, all networks are enabled for REPLICATION. As we have a dedicated REPLICATION network, we need to make a change to the defaults.

If we highlight the DAG, we can confirm that the DAG has identified two networks as we can see the MapiDagNetwork and ReplicationDagNetwork01 and that both have replication enabled on the right hand side pane under DAG Network:

image

To disable replication for the MAPI network, click on Disable Replication under MapiDagNetwork:

image

Press OK when prompted.


Configure DAG networks using PowerShell


Enable manual DAG network configuration:

Set-DatabaseAvailabilityGroup DAG01 -ManualDagNetworkConfiguration:$true

image

Disable replication on the MAPI network:

Set-DatabaseAvailabilityGroupNetwork -Identity DAG01\MapiDagNetwork -ReplicationEnabled:$false

image

Confirm that only the REPLICATION network is configured for replication by running this command:

Get-DatabaseAvailabilityGroupNetwork

image

Enable Datacenter Activation Coordination Mode


As we briefly discussed above, this prevents a split-brain scenario and although not enabled by default, it’s recommended. Unfortunately there’s no option to do this using the EAC so we’ll need to use PowerShell:

Set-DatabaseAvailabilityGroup DAG01 -DatacenterActivationMode DagOnly

image

Confirm the DAG was set up correctly


We’ll go through a few checks to ensure that we have indeed set up our DAG correctly.
Confirm the cluster exists:

Get-Cluster

image

We can see the DAG01 cluster is created.

Confirm that all nodes are up in the cluster:

Get-Cluster | Get-ClusterNode

image

Here we see that both servers are up in the cluster.

Confirm that the DAG was created successfully and that both servers are operational:

Get-DatabaseAvailabilityGroup –Status

image

And there you go. One DAG.


Conclusion


In this post we have gone through the steps you need to go through to set up an Exchange 2016 DAG. In the next post, I’ll demonstrate how to set up mailbox database copies so that our databases are highly available. Click here to go to part 2.

6 comments:

  1. This comment has been removed by the author.

    ReplyDelete
  2. thank for good article, i have on doubt about DAC, if we want to do disaster recovery site without using DAC it is possible or not in exchange 2016. thanks.

    ReplyDelete
  3. thanks. but can you guide with two witness server because when witness server and secondary mailbox is down primary not working.

    ReplyDelete