Kraft & Kennedy, Inc. provides technology and strategic consulting services to law firms, corporate legal departments and financial services firms. We can help you analyze, plan, implement and manage business and technology solutions to optimize your organization's functionality and processes.
This morning, my colleague Joe Hoegler pointed me to a new post on VMware’s Business Critical Applications blog entitled High Availability for Exchange 2010 without DAG. Joe recently achieved his Microsoft Certified Master on Exchange 2010 and has a great deal of experience with Exchange. He and I have worked together on projects where we’ve been successful in virtualizing Exchange 2010 on vSphere. We both read the article and spent some time discussing it and both came to the same conclusions, so we wanted to share some of our collective thoughts.
Every so often, you may encounter issues with DAG name and/or IP address resources going offline in your DAG Failover Cluster with the following (or similar) error code:
Cluster IP address resource ‘Cluster IP Address’ cannot be brought online because the cluster network ‘Cluster Network 2′ is not configured to allow client access. Please use the Failover Cluster Manager snap-in to check the configured properties of the cluster network.
Since all end user client connectivity occurs through the CAS role, this is generally not a user-facing issue but integrated applications that depend on the DAG name for connectivity would fail to connect in this case. The most common example of an application that could potentially be affected is an Exchange-aware backup application.
Continue reading…
If you read Microsoft’s documentation and guidance regarding DAG design, you will note guidance that the greater number of DAG members that you have, the better. This is because, with more DAG members, you can increase your resiliency in the event of member failures.
For example, with two, three-node DAGs, each DAG can sustain only a single member failure and still remain online. Since a three-node DAG requires two voting members for quorum, two simultaneous voting member failures would result in a loss of quorum and the DAG going offline. However, a single, six-node DAG (stretched across sites if desired) can sustain three simultaneous voting member failures before going offline. Since a six-node DAG would require four online voting members, you could have three Mailbox server members online plus your Witness Server and sustain simultaneous failures in the three other Mailbox server members without losing quorum.
Continue reading…