Revisión: 3/12/2018
En la primer parte de esta serie de artículos vimos conceptos básicos sobre DAG (Database Availability Group) en Exchange 2010 / 2013 / 2016.
En esta entrada vamos a profundizar en algunos de estos conceptos e introducir otros críticos para comprender como funciona un DAG de Exchange incluyendo:
- Replicación de base de datos
- Activación de bases
- Switchover y Failover
- Dependencias en el servicio de cluster
- Quorum
- Redes dentro de un DAG
1. Replicación de bases dentro de un DAG
Dentro de un DAG podemos tener bases de datos activas (a la que se conectan los clientes) y pasivas (réplicas) en otros servidores. Estas réplicas son actualizadas mediante replicación asincrónica de logs continua, de forma predeterminada utilizando TCP en el puerto 64327.
Esta replicación se puede dar de 2 formas; modo archivo (file mode) o modo bloque (block mode).
Inicialmente la replicación se da mediante modo archivo, si las bases de datos están actualizadas se pasa a modo bloque. En modo archivo Exchange espera a cerrar el log activo antes de replicar a una copia pasiva mientras que en modo bloque se replica directamente desde el buffer de log en memoria (ESE log buffer).
2. Activación de bases en DAG
Para coordinar el manejo de base de datos, cual debe ser activa, pasiva, etc, el DAG utiliza un componente que forma parte del servicio de replicación de Exchange (MSExchangeRepl.exe): Active Manager.
En un servidor miembro de un DAG, Active Manager puede operar con el rol de PAM (Primary Active Manager) o de SAM (Standby Active Manager), en cualquiera de los casos el componente monitorea la salud de las bases y llegado el caso contacta al PAM para que tome una acción (ej. un failover). Adicionalmente el Active Manager es consultado por otros componentes de la infraestructura con la finalidad de obtener información sobre donde se encuentra la base del usuario que se conecta y eventualmente hacer de proxy hacia el servidor que se encuentre con la base activa.
El servidor que actúa con el rol de PAM es el que tiene el default cluster resource group. En caso de que el servidor con el rol de PAM falle, otro servidor miembro del DAG sería “promovido” de SAM a PAM de forma automática.
En general, no es necesario interactuar directamente con este componente.
3. Switchover y Failover
Para que una base de datos pase de activa a pasiva se tiene que realizar un switchover (acción iniciada por parte de un administrador) o mediante un failover, este último caso producto de una falla en el sistema como por ejemplo rotura de uno de los discos de una base, apagado incorrecto de uno de los servidores, etc.
Frente a un escenario de falla de una base con múltiples copias, Active Manager corre un proceso que en Exchange 2010 se llamaba BCS (Best Copy Selection) y a partir de Exchange 2013 y en Exchange 2016 BCSS (Best Copy and server selection). En cualquier caso el objetivo es similar, tener en cuenta una serie de condiciones y en base a esto priorizar en orden las réplicas candidatas a ser activas.
Dentro de las condiciones a chequear encontramos por ejemplo cola de logs por replicar (Copy queue length), cola de aplicación de logs (Replay Queue Length), estado del índice de las bases y preferencia de activación. Una vez seleccionada una réplica, Active Manager corre un proceso denominado ACLL (Attempt Copy Last Logs) que intenta copiar logs que puedan faltar por replicar desde el origen (la base que falló).
Independientemente de logs que puedan faltar por replicar, bloqueos de activación administrativos sobre las bases, etc, si el DAG no tiene Quorum, las bases serán desmontadas y no podrán ser activadas hasta que no se obtenga la mayoría de votos.
4. Recursos de cluster en DAG
Si bien no se utilizan recursos de cluster específicos a Exchange, el DAG tiene dependencias sobre el servicio de cluster como por ejemplo para monitorear el estado de los servidores mediante heartbeats y para mantener quorum. Esto no quiere decir que el servicio de cluster pueda interferir directamente con la activación de bases sino que este le proporciona a Exchange información necesaria para que posteriormente Active Manager evalúe si se requiere tomar acción o no.
Adicionalmente, de forma predeterminada cuando se crea un DAG se agregan ciertos recursos de cluster como nombre de red (network name), dirección IP y testigo para quorum (FSW: File Share Witness). Este es el modelo tradicional de DAG y podríamos denominarlo como DAG con punto de acceso administrativo al cluster (CAAP).
A partir de Exchange 2013 SP1 sobre Windows 2012 R2 es posible crear un DAG sin un punto de acceso administrativo al cluster. Esto es recomendable en caso de que no haya ninguna incompatibilidad con aplicaciones de terceros. Este modelo también tiene dependencias sobre el servicio de cluster pero no requiere recursos como nombre y dirección IP.
5. Modelos de quorum
La configuración de quorum determina la cantidad de fallas que puede soportar un cluster antes de detener la operativa. Para esto se utiliza un sistema de votos y dependiendo la cantidad de nodos (par o impar) el modelo de quorum a utilizar.
DAG con cantidad par de nodos
Un DAG con una cantidad par de nodos utiliza un modelo denominado Node and File Share Majority. En este modo se utiliza un testigo (File Share Witness) para desempatar en caso de que sea necesario. Para mantener quorum se debe tener la mitad + 1 de los votos, el servidor que tiene el lock al testigo tiene un voto adicional (weighted vote).
DAG con cantidad impar de nodos
Un DAG con cantidad impar de nodos utiliza el modelo Node Majority. En este caso no es necesario utilizar el testigo para desempatar porque no se puede dar la situación donde la mitad de los nodos estén operativos y la otra mitad no. Supongamos el caso de un DAG con 3 nodos, si se cae 1 nodo se mantiene quorum porque mantiene la mayoría, si se caen 2 se pierde el quorum.
El hecho de que el cluster requiera mantener quorum para continuar con la operativa previene que por ejemplo por un problema de red una base quede activa en más de un servidor a la vez.
Supongamos el caso donde tenemos 2 nodos en un sitio y 2 en otro, si se cae el enlace entre ambos sitios, donde queda la base activa? en este caso como es una cantidad par de nodos va a quedar donde se encuentre el FSW (File Share Witness), ya que ese sitio tendría 3 votos versus los 2 que habrían en el otro sitio. En general cuando tenemos múltiples sitios entra en juego el modo DAC (Datacenter Activation Coordination mode) diseñado para prevenir una situación denominada split brain syndrome pero esto lo vamos a ver en un artículo posterior.
6. Redes dentro de un DAG
Una red dentro de un DAG es una colección de subredes que Exchange utiliza para tráfico de replicación o MAPI (red de clientes podríamos decir).
La comunicación de red entre los miembros de un DAG soporta compresión y encriptación de forma builtin. En ambos casos esto viene habilitado de forma predeterminada cuando los nodos están en subredes diferentes, para compresión se utiliza XPRESS (implementación de microsoft del algoritmo LZ77) y en caso de encriptación SSP (Kerberos Security Support Provider). Esta configuración puede ser modificada a través del shell.
Próximos pasos…
En la parte 3 vamos a ver cómo instalar y configurar un DAG en Exchange 2013 /2016.
Por más información teórica y práctica ver el siguiente recurso para miembros VIP del sitio (videos de entrenamiento):
Hola buen día.
Tenemos un diseño de 5 Servidores: 2 CAS y 3 MBx con Exchange2013. me indica el personal que instalo el sistema que al crear una DAG, en automático Exchange da de alta y configura el servicio de Cluster: esto es cierto? siempre que se cree una DAG se deberá tener el Servicio de Cluster iniciado?
sucede que al replicar los 5 servidores a mi DRP, todo levanta perfecto excepto el servicio de cluster :(
Hola Oscar,
El DAG tiene dependencias en el servicio de cluster. Cuando agregas un servidor a un DAG se instalan automáticamente las características de failover clustering. Si el nodo esta operativo vas a encontrar iniciado el servicio de cluster (entre otras cosas).
En principio, la recomendación a nivel de Exchange es utilizar las características nativas de replicación. Esto lo podes usar para tener alta disponibilidad y contingencia.
El mecanismo que estas usando para DR no es recomendado para Exchange y dependiendo del detalle de como se haga si esta soportado o no.
Te recomiendo evaluar el caso de Exchange por separado. Respecto al tema de que no te inicie el servicio de cluster, quizás puedas complementar el procedimiento actual con algunos pasos manuales, de cualquier modo esta no sería la recomendación.