This is a common discussion, who should be in charge of High Availability (HA), the host virtualization operating system or the application? If you ask an electrician how to fix something, they’ll tell you to rewire it. If you ask a carpenter what is wrong, they will say rebuild it. If you ask a virtualization engineer, they will say let the host be in charge of HA. If you ask an Exchange engineer, we’ll recommend letting the Exchange application be in charge. It is this last point that should win in the decision process. It is our application; we want to be in charge.
Don’t forget, once you are in a DAG, it is like having RAID (Redundant Array of Independent Disks) level at the application level. In the computer world, we have been using RAID at the disk level for years; why not accept the fact that Exchange DAG is a RAID configuration of the databases? Please, let Exchange be in charge of itself.
One common issue is that DAG DB’s want a very quick heartbeat to decide if a server has a database failure. We use the built in Active Manager process to create a fabric of communication between all Exchange servers (2010 and above). It is this replication engine that understands what DB is mounted, where it is mounted, and what CAS layer activity is available to send to the active DB where the users’ mailbox is currently available. Since we are managing the availability, don’t let others get in the way.
But Mike, we can just increase the DAG timeout. Yah, we recommend never changing that setting.
But Mike, I’ve spent lots of money in my virtualization environment. Again that’s fine, we’ll fully support you. But the timeout values for those products is usually longer than the heartbeat for Active Manager. You have more than one of each Exchange Server role for redundancy, just leave them pinned to a physical host and let Exchange handle the failover.
So there you go, just let Exchange be in charge of any HA failovers. Thank you.