Why a Company Should Deploy Exchange Database Availability Groups.
Microsoft has offered high availability solutions for Exchange for a number of years. That said, the solutions were complicated – they created a complex environment and were costly to implement. Further they didn’t offer a lot of protection against a serious failure within the mailbox stores.
Microsoft made significant improvements with Exchange 2007 when they introduced four methodologies for Exchange high availability but still did not fully address the complexity in architecture or in management of an Exchange cluster.
Finally, Microsoft introduced Exchange 2010 and with Exchange 2010 came the ability to create Database Availability Groups (DAG). DAG provides a solid clustering solution that provides a level of assurance that has long been needed for companies and eliminates a lot of the complexity of creating a highly available Exchange architecture.
So what makes DAG so compelling compared to previous high availability Exchange solutions?
First, a DAG has a very limited dependency on Windows Failover Clustering. A DAG only uses the cluster database, heartbeat, and file share witness functionality from Windows Failover Clustering. With previous versions of Exchange, Exchange was an application that was operated by Windows Clustering. With Exchange 2010, there has been a paradigm shift and Windows Failover Clustering is now only a resource to Exchange. This will translate to lower costs of deployment and lower administration costs for most companies.
Deployment with Database Availability Groups is easier and can be deployed incrementally. As mentioned, DAGs still require Windows Failover Clustering therefore Windows 2008 SP2 or R2 Enterprise is required. Beyond installing Exchange on an Enterprise edition of Windows, a company can implement a Database Availability Group incrementally during the lifecycle of the Exchange server. Therefore a company does not need to deploy a cluster prior to installing Exchange as in previous versions. For most companies this will mean less costs to implement and less pain to implement as a company grows or needs change.
Database Availability Groups can also exist with other Exchange roles. With previous versions of Exchange, if clustering was involved the mailbox store role had to be separated from the other Exchange roles. This means a high availability solution will require less hardware which means less cost to implement.
Management is performed fully through the Exchange management tools. With older versions of Exchange, you were required to use cluster management tools as well as Exchange management tools to administer the environment. With Exchange 2010, this is no longer the case. A company can manage DAGs completely using the Exchange management tools. This will translate to a smaller administration foot print for companies.
These four reasons hopefully show that implementing Exchange Database availability groups will cost less to implement, will cost less to administer, and will provide flexibility to an organization while providing an extremely high level of “peace of mind”. These four reasons are only a few of the reasons why Database Availability Groups make sense for most companies to implement. As with all IT projects, we recommend reviewing the business needs pertaining to high availability of your messaging environment and evaluating whether Database Availability Groups would meet those needs. If your company needs assistance with evaluating those business needs or if you would like additional reasons why DAGs are so compelling, PEI would be more than happy to assist.
-Jacob Eker, PEI
