Si bien a partir del Service Pack 1 de Exchange Server tenemos la posibilidad de contingencia de Datacenter con SCR, muchas veces no se cuenta con la infraestructura necesaria para poder instalar el servicio de esa manera.

Para esos escenarios, podemos optar por una configuración de cluster CCR distribuído, o geográficamente disperso. Esto quiere decir, instalar un cluster CCR con el nodo activo en un datacenter, y el pasivo en otro (recordemos que CCR sólo permite clusters de dos nodos Activo / Pasivo).

Como pre requisitos:

• Si el cluster CCR es montado sobre Windows Server 2003, es necesario contar con la misma subred para todos los nodos.
• El punto anterio no es necesario si el cluster está montado sobre Windows 2008.
• Ambas subredes deben pertenecer al mismo Sitio de Active Directory.

Antes de comenzar el tema en profundidad, cabe destacar que CCR es un cluster del tipo ‘Majority Node Set’ (MNS), esto quiere decir que al momento de hacer failover al otro nodo, requiere de una mayoría para tomar esa decisión. Es decir, requiere que esté vivo un nodo del clúster y el File Share Witness (FSW).

Dentro del CCR disperso, existen varios escenarios. A continuación, examinaremos cuáles son las posibilidades y las contras de cada uno de ellos.

Escenario 1: Nodo activo y File Share Witness en el mismo Datacenter

Figura 1: Escenario de CCR con el Nodo Activo en el mismo Datacenter que el FSW

Este escenario es la instalación que, quizás, se viene a la mente al momento de configurar una solución de alta disponibilidad de CCR.

• Ante la caída del nodo activo, el pasivo perderá contacto con éste y buscará el FSW para contar con la mayoría. Al encontrarlo, podrá hacer un failover exitoso.
• Podremos hacer un failover manual.
• El problema existe cuando el datacenter primario sufre una catástrofe. En ese caso, tanto el nodo pasivo como el FSW no estarán disponibles, con lo que no habrá un failover automático, ya que no hay mayoría.
• Podremos hacer un failover manual, con algunos cambios de configuración pero tenemos que asegurarnos que el nodo activo no vuelva a la vida, ya que sino caeremos en un escenario de split brain syndrome.
• Para evitar caer en un split brain syndrome, podemos deshabilitar el File Share Witness en el HUB1, para que el primer nodo no lo encuentre y no se active, o simplemente configurar los servicios de cluster para un inicio manual.

Escenario 2: Cruzar el nodo activo con el File Share Witness

Figura 2: Escenario de CCR con el Nodo Activo en el Datacenter distinto al FSW

Este escenario habilita algunos casos de failover automático, pero caer en el split brain syndrome es aún más fácil.

• En caso de catástrofe del Datacenter Secundario, existiría un failover automático al nodo pasivo. Pero es muy fácil caer en un split brain syndrome cuando el Datacenter caído vuelva a la vida.
• En caso de corte en la conectividad, el nodo pasivo automáticamente se convertiría en activo, y el que anteriormente era activo seguirá siendo activo. Caso típico de split brain syndrome.

Escenario 3: Pero entonces… ¿Cómo evitamos el Split Brain Syndrome? File Share Witness en un tercer Datacenter

Figura 2: Escenario de CCR con el FSW en un tercer Datacenter

Este es el escenario ideal. En este escenario tenemos:

• Failover automático en caso de problemas en el nodo activo.
• Failover automático en caso de pérdida del Datacenter completo.
• Failover automático en caso de pérdida de conectividad.
• Se reduce al mínimo la posibilidad de caer en un split brain syndrome.

Pablo D. Vernocchi
Microsoft Exchange MVP
MCSE + M / MCSE + Sec
https://mvp.support.microsoft.com/profile/Pablo