3 into 4 can go…

Once you’ve determined the number of Exchange Server 2010 mailbox database copies you’re going to use it makes sense to deploy a complimentary number of mailbox servers in the DAG .  If you decide to go with an odd number of database copies go with an odd number of nodes; if you use an even number of copies aim to deploy an even number of nodes - it’ll make your life easier in the long run.  ..but that could well mean you need to make a decision over ease of management versus cost.  Surely there will be cases where it makes more financial sense to deploy 4 servers to host your 3 copies rather than 6 for example?  …but what are the implications? Well it’s not a problem to get it to work.  It just means you’re likely compelled to introduce a layer of complexity into the solution. To illustrate this I’ll use an example where there are 4 nodes of a single DAG with 3 copies of every mailbox database and to make it simple I’ll be deploying a single database on each disk ( JBOD ), using volume mount points. What’s the problem? On every DAG member you create a directory structure; c:\data\mbxdb01, c:\data\mbxdb02…up to c:\data\mbxdb06 (since you have 6 disks).  You deploy mbxdb01on nodes 1, 2 and 3 since but now on node 4 you have c:\data\mbxdb01 which you can’t use because each database has to have the same path – so c:\data\mbxdb01 can only be used by mbxdb01. Disk01 c:\data\mbxdb01 c:\data\mbxdb01 c:\data\mbxdb01 c:\data\mbxdb01 At first glance you have 2 choices – don’t use the disk (!$@&?!) or change your design to 4 copies (equally unpalatable). One Solution ..but there is a way around this with this particular example and that is to deploy a directory structure which is different on each node. Disk01 c:\data\mbxdb01 c:\data\mbxdb01 c:\data\mbxdb01 c:\data\mbxdb02 Disk02 c:\data\mbxdb03 c:\data\mbxdb02 c:\data\mbxdb02 c:\data\mbxdb03 Disk03 c:\data\mbxdb04 c:\data\mbxdb03 c:\data\mbxdb04 c:\data\mbxdb04 Disk04 c:\data\mbxdb05 c:\data\mbxdb05 c:\data\mbxdb05 c:\data\mbxdb06 Disk05 c:\data\mbxdb07 c:\data\mbxdb06 c:\data\mbxdb06 c:\data\mbxdb07 Disk06 c:\data\mbxdb08 c:\data\mbxdb07 c:\data\mbxdb08 c:\data\mbxdb08 The above design works very nicely I think (..and of course the creation of this directory structure can be scripted using diskpart for example) but it does mean that you need to be careful when you lose a disk for example or when you are rebuilding a failed server (again both scriptable with the right skills).  Or perhaps more importantly when you decide to add a node to the design at some point in the future.  It could mean quite a lot of rejigging and downtime – the worst case might be changing the directory structure across all servers in the DAG.  (…ouch?!) Managing a large DAG is easy? I’m of the opinion that one of the areas of Exchange Server 2010 which needs time and effort to get right is managing large DAG’s with swarms of databases housing multitudes of big mailboxes.  You’re going to have to get good at scripting to make things run smoothly.  Scripts like the Exchange 2010 Database Redundancy Check Script will make or break a big deployment and should prevent a beautiful design descending into chaos.  ..and the more straightforward the design the more straightforward its management will be in most cases. So 3 into 4 can go  …but proceed with caution....(read more)