Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

What is the deciding factor when we implement multiple Exchange 2010 Database Availability Groups (DAG's) versus a single DAG?

I'm using HP's Exchange 2010 sizing tool to put a budget together and it's asking me about quantity of DAG's. We're going to hire consultants to design this, but I just need a rough estimate for planning / budgeting purposes.

What is the relation between DAG count to server count?

share|improve this question
    
"What is the relation between DAG count to server count?" Did you read the article I posted in my answer?? –  GregD Sep 9 '10 at 14:15
    
@GregD - Not yet, I'm trying to be a good citizen at serverfault while doing other tasks. I intend to give it my full attention. –  TLDR Sep 9 '10 at 14:17
    
If you can give us an idea of what your environment and requirements are like, that would help a lot. About how many users, and do they use e-mail heavily; how many physical sites, is there site-link redundancy; how many servers can fail before the system goes offline; is "offline" maintenance acceptable; if there are any other major requirements of the system. –  Chris S Sep 9 '10 at 15:19

3 Answers 3

It depends what you need from the DAG. You can have several types of DAG - a "normal" DAG and a "Lagged Copy DAG", which is used more for disaster recovery.

How many replicas you should have is (in my opinion) more of a business decision than an IT one.

A "Normal" DAG is basically a copy of specified mailbox databases. You would have multiple replicas when you want failover to occur transparently to your end users. This allows several Exchange servers do go down (for maintenance or otherwise) and keep your mailbox database online.

A "Lagged Copy DAG" is still a DAG which replicates your mailbox database, but in a slightly different way. You can set a lag period on a lagged DAG so the replica is effectively a copy of the main database at some point in the past (by default 14 days, IIRC). Once a transaction log file is finished (i.e it reaches 1MB and another is created) on your active database copy, it is immediately copied to all lagged replicas but is not replayed immediately. This transaction log will stay on the lagged replica until the lag period expires, at which point it is written to the lagged copy database.

With that information, you should be able to give management an idea of what Exchange can do with regards to high availability/disaster recovery and possibly recommend a solution, but let them ultimately decide.

share|improve this answer

I haven't voted to close this call yet, but I do believe it's borderline since it can't really be "answered" in it's current form.

High availability is subjective and wholly dependent on your circumstances and what you deem is an acceptable level of risk.

You haven't indicated anything about your acceptable level of risk. For example, if you want the smallest form of HA, without site resilience, then you'll need (2)two DAGs. If your WAN is a single point of failure, then you'll want (2)two, four-member DAGs in (2)two different datacenters.

This article on Database Availability Group Design is a pretty good start.

share|improve this answer
1  
WTF is with the downvote? –  GregD Sep 9 '10 at 13:59
    
Well I'll level it off at least, but I completely agree; and you put way more effort into this answer that I would have based on the effort put into the question. –  Chris S Sep 9 '10 at 14:00
    
@ChrisS - I'm new here ... I put more effort into the question w/an edit. –  TLDR Sep 9 '10 at 14:12

Performance and Availability requirements, primarily based on the number of users, how heavily they're using the servers, and how your systems can fail. More usage or points of failure = more DAGs.

share|improve this answer
    
@Downvoter - This is the bulleted list I'm looking for. (although I need more info) I'll even it out +1 –  TLDR Sep 9 '10 at 14:14

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.