por Daniel Seveso

¿Que es DAG?

DAG es un acrónimo en inglés por "Database Availability Group" o grupo de disponibilidad de base de datos, y es el nuevo concepto de alta disponibilidad para bases de datos en Exchange 2010. Una evolución de los anteriores esquemas de disponibilidad the Exchange Virtual Servers en Exchange 2003 y Clustered Mailbox Servers en Exchange 2007.

Evolución

Los mecanismos de alta disponibilidad ofrecidos en versiones de Exchange 2007 y previas, basan su disponibilidad en el servicio de Cluster en varios grados. Completamente para el caso de Exchange 2000/2003 y Exchange 2007 SCC (Single Copy Cluster) y en forma accesoria para Exchange 2007 CCR o SCR (Cluster Continuous Replication y Stand-by Continuous Replication respectivamente), estas últimas introduciendo el concepto de bases de datos replicadas con mecanismos de log shipping.

Los clusters de Exchange 2000/2003 como los de Exchange 2007 SCC, están basados en storage compartido, requiriendo sistemas de disponibilidad de hardware para mantener redundancia en las bases de datos.

CCR y SCR por su parte van un paso más adelante, manteniendo replicas de la base de datos en nodos pasivos o Stand-by, posibilitando soluciones geográficamente dispersas más accesibles y otras funcionalidades disponibles a partir de Exchange 2007 SP1, como retraso de replicación administrativo (LAG) que permite tener una copia Stand-by de la base de datos con un retraso forzado (por ejemplo de un día), evitando la replicación de cualquier problema que ocurra en la base de producción replique inmediatamente a su réplica.

Pese a estas mejoras el equipo de desarrollo de Exchange continuó trabajando en soluciones integradas de alta disponibilidad, especialmente en disponibilidad cross-site.

Alta disponibilidad en Exchange 2010

En Exchange 2010, los conceptos de Single Copy Cluster (SCC) y Local Continuous Replication (LCR) desaparecen por completo, mientras que Cluster Continuous Replication (CCR) y Stand-by Continuous Replication (SCR) combinan su funcionalidad para crear el Database Availability Group (DAG). DAG pasa a ser entonces la base del nuevo concepto de alta disponibilidad en Exchange, donde la unidad de falla es la base de datos y no el servidor.

El siguiente esquema muestra la diversificación de los requerimientos de los clientes MAPI a través del rol de CAS, los tres Mailbox Servers que integran el DAG y como podemos activar las replicas de nuestras bases de datos ya sea por una falla o por mantenimiento.

Por definición, un DAG es un grupo de hasta 16 Mailbox Servers que tienen un conjunto de bases de datos y provee recuperación automática de fallas a nivel de base de datos. El DAG es el límite administrativo para la replicación y los failovers de estas bases de datos. Cualquier servidor en el DAG puede tener una copia de una base de datos de cualquier otro Mailbox Server en el mismo DAG.

Un nuevo componente “Active Manager” se encarga de las actividades de failover y movimientos de las bases de datos entre los servidores de Mailbox en el DAG. El Active Manager reemplaza el modelo de recursos, que veníamos utilizando con Windows Failover Cluster en las versiones anteriores de Exchange. Por lo tanto, Exchange 2010 ya no tiene recursos especializados de Cluster sino que utiliza los servicios de Cluster con una dependencia muy limitada a la IP, el Nombre de red, el Quorum y el registro del Cluster.

El Active Manager tiene dos modos de funcionamiento, Primary Active Manager (PAM) o Stand-by Active Manager (SAM). Ambos modos están activos en funcionamiento normal, pero hay sólo un servidor del DAG que corre PAM y el resto SAM. PAM es el ejecutor, quien reacciona en el momento de falla, y quien determina en un evento de failover, en qué réplica se va a definir la base de datos activa. PAM siempre corre en el nodo que es el actual dueño del quorum. SAM es quien reporta cualquier mal funcionamiento de las bases de datos, sea activa o réplica, o del servicio de Information Store, y ante una falla reporta la misma al PAM solicitando un failover. SAM también responde consultas de estado a otros componentes de Exchange que corren el “Active Manager client”.

Simple caso de falla

Para describir como se comporta Exchange 2010 durante la falla de una base de datos pondré un simple secuencia de sucesos (en realidad la lista de lo que ocurre es más extensa, pero me limitaré a lo más importante y palpable para un administrador):

1) Una base de datos se corrompe debido a un problema en el controlador de disco

2) The Active Manager (PAM o SAM) detecta los errores del servicio Information Store

3) Si el servidor donde está la base en problemas corre un SAM, informa al PAM para que ejecute la decisión del proceso de Failover

4) Si el servidor donde está la base en problemas corre un PAM, este tomará la decisión de qué réplica activar, dependiendo de un conjunto de criterios (ver referencias)

5) Si el servidor donde está corriendo la copia activa de la base de datos está accesible, el PAM desmonta la base de datos y espera que la operación termine. Luego monta la base de datos en el servidor elegido como destino.

6) PAM actualiza la información de estado de la base de datos en el Cluster database (tambien llamado “Persistent Storage”.

7) Luego el active manager tiene información de en qué Mailbox Server se encuentra la base de datos, esta es consumida por los “Active Manager clients” por ejemplo el rol de CAS, que redireccionará las conexiones de los usuarios de esa base de datos al nuevo servidor.

Detalles de Implementación

Algunos detalles interesantes de la implementación de DAG.

Al no tener componentes de Exchange en cluster en el mailbox server, ya no es impedimento instalar roles adicionales en cada servidor. Esto nos permite tener una solución de alta disponibilidad completa con todos los roles, con solo dos nodos.
Las bases de datos en DAG ya no dependen del servidor, sino que de la organización de Exchange.
Cada Mailbox Server solo puede ser miembro de un DAG porque requiere su membresía a un Windows Cluster.
Por la misma razón, los DAGs solo pueden ser instalados en versiones Enterprise de Windows.
La implementación de DAGs puede ser incremental. No es necesario instalar el servicio de Cluster antes de instalar Exchange. Es posible extender la configuración de Exchange de un mailbox server normal a una configuración DAG luego de haber sido instalado.
El concepto de Storage Group desaparece en Exchange 2010, teniendo un set de logs por cada base de datos individual. (esto ya se practicaba de esta forma en Exchange 2007 aunque seguía existiendo el concepto de SG). También se incrementa la cantidad de bases de datos por servidor al doble (100 bases de datos en Exchange 2010)
Es posible ubicar miembros de un DAG en diferentes sitios de AD (esto era una limitante con CCR)
Los failover de base de datos ocurren típicamente en menos de 30 segundos, significativamente más rápido que un failover en Exchange 2003 o 2007.
Mejoras sustanciales en el mecanismo de log shipping, como por ejemplo: uso de TCP en lugar de SMB para la copia de logs, compresión de datos para replicación inter-site, encripción de la replicación y posibilidad de “seeding” desde una copia en lugar de la base activa (esto no era posible en Exchange 2007 CCR).
Permite un “Lag time” o retardo forzado de replicación hasta de 14 días, que es especialmente útil cuando defnimos trabajar sin backups.