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

Recreating a missing VMFS datastore partition in VMware vSphere 5.x and 6.x

    Symptoms A datastore has become inaccessible. A VMFS partition table is missing.   Purpose The partition table is required only during a rescan. This means that the datastore may become inaccessible on a host during a rescan if the VMFS partition was deleted after the last rescan. The partition table is physically located on the LUN, so all vSphere hosts that have access to this LUN can see the change has taken place. However, only the hosts that do a rescan will be affected.   This article provides information on: Determining whether this is the same problem Resolving the problem   Cause This issue occurs because the VMFS partition can be deleted by deleting the datastore from the vSphere Client. This is prevented by the software, if the datastore is in use. It can also happen if a physical server has access to the LUN on the SAN and does an install, for example.   Resolution To resolve this issue: Run the  partedUtil  command on the host with the issues and verify if your output

ما هى ال FSMO Roles

  بأختصار ال FSMO Roles هى اختصار ل Flexible Single Operation Master و هى عباره عن 5 Roles فى ال Active Directory و هما بينقسموا لقسمين A - Forest Roles 1- Schema Master Role و هى ال Role اللى بتتحكم فى ال schema و بيكون فى Schema Master Role واحد فى ال Forest بيكون موجود على Domain Controller و بيتم التحكم فيها من خلال ال Active Directory Schema Snap in in MMC بس بعد ما يتعمل Schema Register بواسطه الامر التالى من ال Cmd regsvr32 schmmgmt.dll 2-Domin Naming Master و هى ال Role المسئوله عن تسميه ال Domains و بتتأكد ان مفيش 2 Domain ليهم نفس الاسم فى ال Forest و بيتم التحكم فيها من خلال ال Active Directory Domains & Trusts B- Domain Roles 1-PDC Emulator و هى ال Role اللى بتتحكم فى ال Password change فى ال domain و بتتحكم فى ال time synchronization و هى تعتبر المكان الافتراضى لل GPO's و هى تعتبر Domain Role مش زى الاتنين الاولانيين و بيتم التحكم فيها من خلال ال Active directory Users & Computers عن طريق عمل كليك يمين على اسم الدومين و نختار operations master فى تاب ال PDC Emu

Unlock the VMware VM vmdk file

  Unlock the VMware VM vmdk file Kill -9 PID Sometimes a file or set of files in a VMFS become locked and any attempts to edit them or delete will give a device or resource busy error, even though the vm associated with the files is not running. If the vm is running then you would need to stop the vm to manipulate the files. If you know that the vm is stopped then you need to find the ESX server that has the files locked and then stop the process that is locking the file(s). 1. Logon to the ESX host where the VM was last known to be running. 2.  vmkfstools -D /vmfs/volumes/path/to/file  to dump information on the file into /var/log/vmkernel 3.  less /var/log/vmkernel  and scroll to the bottom, you will see output like below: a. Nov 29 15:49:17 vm22 vmkernel: 2:00:15:18.435 cpu6:1038)FS3: 130: <START vmware-16.log> b. Nov 29 15:49:17 vm22 vmkernel: 2:00:15:18.435 cpu6:1038)Lock [type 10c00001 offset 30439424 v 21, hb offset 4154368 c. Nov 29 15:49:17 vm22 vmkernel: gen 664