Exchange 2010 DAG for HA

I'm looking for some advice on implementing an Exchange 2010 DAG (active/passive) using a physical server (mailbox role only) and a virtual server (mailbox role only). My aim is to minimize cost by leveraging my existing VMWare infrastrucure and Microsoft enterprise licensing. I'm really interested to know if anybody has any experience with this type setup and how it is going for them. Ultimately, if this is doable I would like to have a third memeber in the DAG located offsite in my DR site.

Because the concept of the DAG is new to me I'm a little lost on the disk requirements. My assumption is to keep the disks separate between each DAG member so I would have physical disks on the physical sever and would use SAN LUNs for my virtual memeber, is this the correct assumption? It's my understanding that Microsoft no longer uses shared disk for HA regarding Exchange.

Thanks in advance for your help.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

I used to run an active/passive DAG, but it was across 2 virtual server, but in two seperate physical locations.  It worked great!

Your assumption is correct, DAG does not use shared disks. Each DAG member will have its own copy of the mailbox/public folder databases and therefore needs its own storage, preferably identical in size.  There are some more requirements to DAG, eg a Witness server, but Google can help you out there!
Your plan is sound. Each MBX role server gets its own disk, as a full copy of each DB must be created for a DAG member. You can do that with physical, virtual or a mix. Ideally, you will eliminate single points of failure (don't use the same SAN for multiple virtual DAG members), and as long as you have an odd number of members, you may not need an explicit witness server. A DAG with 2+1 members, where the third member is at a DR site, will give you plenty of confidence for high availability, but it will require manual intervention in case of an emergency: the 1 MBX server at the DR site should not switch the DBs to primary when it looses contact with the main site, or you'll end up with split-brain the first time your WAN link has a hiccup.

Don't forget redundant CAS and HT roles in your plan, too: CAS-protected mailboxes don't do you much good if you can't get at them.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
gsmartinManager of ITCommented:
As an interim solution your DAGs can be on the same SAN on separate LUNs and RAID disks within the SAN.  In my case, I have a highly redundant SAN and likeliness of my entire SAN going down is highly unlikely given level of redundancy we have in our SAN (Multiple Controllers, FC HBAs, FC Switches, Disks, etc.).  However, I am still planning to move one of the DAGs out to a new SAN with our future SAN upgrade.  FYI...  According to Microsoft if you configuring a multi server Exchange DAG you don't require RAID or redundancy.  You can technically create a volume set with a group of disks or RAID 0 (no redundancy but better performance). This is not my preference.  I prefer having the redundancy.

I am running a four server collapsed role (CAS, HT, Mailbox, EDGE) split between our two main DataCenters (DC/DR).  One of the servers at our DR site is setup with a LAG copy.  All Exchange servers our virtualized using VMware. Our FSW is located at our primary data center location where the bulk of our user's reside.  Having two servers on the DR side provides us with the ability to automatically failover if our primary site goes down.  

However, my issue with this configuration is with the location of FSW.  The caveat of FSW is the passive DAG servers can't take over database responsibilities if they can't access the FSW.  So there's a consideration to move FSW to third remote site that both DC and DR can access.  Issue here moving the FSW away from where your primary users may be an issue especially if the WAN links go down or if they lose power.  In turn, Exchange will no longer function without FSW.  So I am currently considering using DFSR to see it could be leveraged some how mitigate the issue, but this can also create other scenarios if connectivity goes down between the DC and DR.
oztrodamusAuthor Commented:
Thanks everybody for your help :)

I did not think about the FSW and the possible split-brain scenario with the DR site member. I know in the past Microsoft has recommended the transport server act as the FSW, but Googleing the topic people are using the DC as the FSW server. I actually like that approach better. I can use a virtual DC in both the primary and DR site if I decide to use an alternate FSW per Microsoft document

GSMartin I believe you can put your DAG in DAC mode to address your specific issue.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.