Skip to main content

Database Availability Group (DAG) - Exchange 2010

 Database Availability Group (DAG)

Now that Exchange 2010 has been officially released , I wanted to start with what I believe is one of the best features added to Exchange 2010. There may be some heart break of the removal of a few features from Exchange 2007 however Database Availability Groups (DAG) is a feature that has been ask for over years. To better under what a DAG is let’s recap through Exchange.

Exchange 2007 introduced LCR, CCR, SCC and SCR
LCR (local continuous replication) this was mainly used for small business who wanted to replicate a copy of their Exchange database to another disk on the same server.



SCC (Single copy cluster) was what I would call a traditional Exchange cluster which used shared storage to host the Exchange database.

Basic architecture of an SCC



CCR (cluster continuous replication) was used to replicate Exchange database information between 2 Exchange server allowing for hardware and storage redundancy but was limited to 1 Active node and 1 Passive node.

Basic deployment of CCR




SCR (standby continuous replication) was introduced in Exchange 2007 SP1 to provide the ability to replicate Exchange databases to an disaster recovery location.



How did it use to work?

The concept of a DAG and how it functions I believe is easier learned by someone who hasn’t worked with Exchange clusters previously.

In Ex 200X an Exchange server was installed as either an Active or Passive cluster node at the time setup.exe was run.

Depending on which version of Exchange you installed you had to create an Exchange virtual server (EVS) which was changed to cluster mailbox server (CMS) in Exchange 2007.

When a user connected Outlook the mailbox server name was a clustered resource which moved between any number of nodes on the Exchange cluster. This allowed for no end user configuration changes all the resource moved between physical servers
An Exchange database was associated with the clustered resource and when you open EMC/ESM the only Exchange server name that was shown was the clustered node, let’s call is CMS1. That means database one would always belong to CMS1 even when this moved between physical machines.

Here comes the DAG

So now it’s time to forget everything that I just mentioned previously in this article about Exchange clustering.

What has been removed?


  1. No more EVS/CMS
  2. Database is no longer associated to a Server but is an Org Level resource
  3. There is no longer a requirement to choose Cluster or Non Cluster at installation, an Exchange 2010 server can move in and out of a DAG as needed
  4. The limitation of only hosting the mailbox role on a clustered Exchange server
  5. Storage Groups have been removed from Exchange

Is anything the same?
1. Window Enterprise Edition is still required since a DAG still uses pieces of Windows Failover Clustering
What’s New?

1. Other roles can be install on the mailbox server when it is a member of a DAG
2. A database name must be unique in the Exchange Org
Let’s walk through the installation of Exchange 2010 and then setup our DAG


I am going to pickup where I left off in the following post http://egyeng.com/forums/showthread.php?6038 where we walked through the exchange installation.


1. Open EMC -> Expand Orgnaization componets and select the database availability group tab



2. Right click and select New Database Availability Group




3. We are now ask to fill in 3 pieces of information for our DAG
a. DAG name
b. FileShare witness (fsw) UNC path (can be any machine)
c. phycial location on the server that will host the fsw




You can see I am using my DC in the lab for the fsw machine, note that whatever machine you are using as the fsw needs to have the Exchange Trusted Subsystem group in the local Admins group
4. Click Finish on the completion page


We have now created our first DAG, if we open active directory users and computers we will see a computer objects gets created with the DAG name we supplied




This object is used by Windows clustering
After the wizard completes we can verify in EMC that our DAG was created as well




by itself the DAG does not do anything for us and there are no properties to manage in EMC, however if we use the shell we can see a few additional properties like:


NetworkCompression : InterSubnetOnly
NetworkEncryption : InterSubnetOnly

[PS] C:\>Get-DatabaseAvailabilityGroup | fl


Name : GenieDAG
Servers : {E14-EX1}
FileShareWitnessShare : \\E14-DC1\GENIEFSW
FileShareWitnessDirectory : C:\GENIEFSW
AlternateFileShareWitnessShare :
AlternateFileShareWitnessDirectory :
NetworkCompression : InterSubnetOnly
NetworkEncryption : InterSubnetOnly
DatacenterActivationMode : Off
StoppedMailboxServers : {}
StartedMailboxServers : {}
OperationalServers :
ControllingActiveManager :
ReplicationPort : 0
NetworkNames : {}
AdminDisplayName :
ExchangeVersion : 0.10 (14.0.100.0)
Identity : GenieDAG
WhenChanged : 4/17/2009 7:22:42 PM
WhenCreated : 4/17/2009 7:22:42 PM
OrganizationId :
OriginatingServer : E14-DC1.ExchangeGenie.Local
IsValid : True
Lets add our first node to the DAG
1. in EMC right click our DAG and select manage database availability group


2. On the manage database availability group page click the Add button




3. In the select mailbox server window select the appropriate mailbox server in my case its e14-ex1




4. click Manage




after selecting manage Windows clustering is installed at this time




5. Click finish on the completion page




6. We can now see that E14-ex1 was added to the DAG



If we open our Admin tools we will see the Windows clustering is installed and that E14-ex1 is a member of the cluster




note: by default the DAG is set to use DHCP to assign and address to it, in the current build there is no way to assign an IP to the DAG in gui. This can be done when adding a node to the DAG from EMS.
Let see what it looks like to add the server from EMS
1. Open EMS (use the local shell currently) add-databaseavailabilitygroupserver GenieDag -mailboxserver E14-ex1 -databaseavailabilitygroupIpAddress 192.168.1.60





Let open Windows Failover Clustering and see that the IP is assigned to the cluster.


Another item you will notice that is different from previous versions of Exchange is there are not clustered resources, no disks, not CMS/EVS.
The DAG only users Windows Clustering for hear beat and quorum the new Active Manager is used to manage the DAG failvoer.
We have currently created a DAG with only 1 Exchange server which does not do us any good as DAG nodes can only replicate to another server, so we will need to add another node.

Comments

Popular posts from this blog

Integration with vCloud Director failing after NSXT upgrade to 4.1.2.0 certificate expired

  Issue Clarification: after upgrade from 3.1.3 to 4.1.2.0 observed certificate to be expired related to various internal services.   Issue Verification: after Upgrade from 3.1.3 to 4.1.2.0 observed certificate to be expired related to various internal services.   Root Cause Identification: >>we confirmed the issue to be related to the below KB NSX alarms indicating certificates have expired or are expiring (94898)   Root Cause Justification:   There are two main factors that can contribute to this behaviour: NSX Managers have many certificates for internal services. In version NSX 3.2.1, Cluster Boot Manager (CBM) service certificates were incorrectly given a validity period of 825 days instead of 100 years. This was corrected to 100 years in NSX 3.2.3. However any environment originally installed on NSX 3.2.1 will have the internal CBM Corfu certs expire after 825 regardless of upgrade to the fixed version or not. On NSX-T 3.2.x interna...

Calculate how much data can be transferred in 24 hours based on link speed in data center

  In case you are planning for migration via DIA or IPVPN link and as example you have 200Mb stable speed so you could calculate using the below formula. (( 200Mb /8)x60x60x24) /1024/1024 = 2TB /per day In case you have different speed you could replace the 200Mb by any rate to calculate as example below. (( 5 00Mb /8)x60x60x24) /1024/1024 =  5.15TB  /per day So approximate each 100Mb would allow around 1TB per day.

Device expanded/shrank messages are reported in the VMkernel log for VMFS-5

    Symptoms A VMFS-5 datastore is no longer visible in vSphere 5 datastores view. A VMFS-5 datastore is no longer mounted in the vSphere 5 datastores view. In the  /var/log/vmkernel.log  file, you see an entry similar to: .. cpu1:44722)WARNING: LVM: 2884: [naa.6006048c7bc7febbf4db26ae0c3263cb:1] Device shrank (actual size 18424453 blocks, stored size 18424507 blocks) A VMFS-5 datastore is mounted in the vSphere 5 datastores view, but in the  /var/log/vmkernel.log  file you see an entry similar to: .. cpu0:44828)LVM: 2891: [naa.6006048c7bc7febbf4db26ae0c3263cb:1] Device expanded (actual size 18424506 blocks, stored size 18422953 blocks)   Purpose This article provides steps to correct the VMFS-5 partition table entry using  partedUtil . For more information see  Using the partedUtil command line utility on ESX and ESXi (1036609) .   Cause The device size discrepancy is caused by an incorrect ending sector for the VMFS-5 partition on the ...