• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 756
  • Last Modified:

Exchange 2010 Architecture in 3 Data Centers

I am planning for a new Exchange 2010 deployment to replace our legacy Exchange 2003/2007 environments.  This is part of a large merger so we are rebuilding Exchange from the ground up.  With this merger we are going to have 3 production data centers, so we are planning to use this to our advantage with DR planning.  My plans are to put 1 CAS/HUB server and 1 MBX server in data centers A and B and put 1 CAS/HUB and 2 MBX in data center C.  Then put MBX-A and MBX-C1 in a DAG with the witness server in data center B, and put MBX-B and MBX-C2 in a DAG with the witness server in data center A.  The idea behind this is so that if we lose a whole data center the failover will be automatic.  My question is, does this topology make logical sense and will there be a problem with having the witness server completely off site from the DAG it is associated with, does the witness server store data or is it just a broker for the replication process.  Thoughts??  Thank you.
0
cbitsupport
Asked:
cbitsupport
  • 3
  • 2
1 Solution
 
willettmeisterCommented:
Please weigh in on this if I am wrong but I believe since you have 3 data centers you don't need any witness servers.  Witness servers are basically provide an additional "vote" if one of the DC's is unavailable and allows the failover to occur automatically.  This idea a remant of the Majority Node set cluster type days and is necessary on when there are an even number of servers in the environment because with an even number there is a possibililty that there will not be a majority to determine the failover destination if one server fails.  For example you have MBA, MBB, and MBC.  MBA fails.  Both MBB and MBC vote that the failover should occur to them. The witness server woudl provide the tie breaking vote to allow the automatic failover and decide where the failover will occur to.
 
0
 
NavdeepCommented:
Hi,

you can have witness server in failover DC

You can follow the following site resillence documentation on msexchange.org
http://www.msexchange.org/articles_tutorials/exchange-server-2010/management-administration/planning-deploying-testing-exchange-2010-site-resilient-solution-sized-medium-organization-part6.html

Also you can check the following technet notes
http://technet.microsoft.com/en-us/library/dd351172.aspx
0
 
cbitsupportAuthor Commented:
So from my understanding with the witness servers, they are just "votes" not nessesarily file servers so by putting them off site it will work exactly like I want it for DR and not cause performance issues.

Does it make sense of using 2 seperate DAGs for this setup or should I just do one big one that encompasses all 4 MBX servers??
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
NavdeepCommented:
In my opinion, since you have same facility, you can put them in one Diag / or additional Diag depending upon the crypticality  of the mailboxes like general staff and vip. For Witness server it's better to put it in DR site. Just in case if your main site /DR site losses connectivity with FileSharewitness then Node election would be confusing.



0
 
NavdeepCommented:
Hi,

You can give this an article a read regarding placement of fileshare witness. Although it's for exchange 2007 however the concept would remain the same in ex2010 as well

Placement of the File Share Witness (FSW) on a Geographically Dispersed CCR Cluster
http://blogs.technet.com/b/exchange/archive/2007/04/25/3402084.aspx
0
 
cbitsupportAuthor Commented:
Thank you for the help, this answered my question
0

Featured Post

Get your Disaster Recovery as a Service basics

Disaster Recovery as a Service is one go-to solution that revolutionizes DR planning. Implementing DRaaS could be an efficient process, easily accessible to non-DR experts. Learn about monitoring, testing, executing failovers and failbacks to ensure a "healthy" DR environment.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now