Grupos de disponibilidad de base de datos
Un grupo de disponibilidad de base de datos (DAG) es el componente base de la alta disponibilidad del servidor de buzones y el marco de resistencia del sitio integrado en Microsoft Exchange Server. Se trata de un grupo de hasta 16 servidores de buzones de correo que aloja un conjunto de bases de datos y proporciona recuperación automática en el nivel de la base de datos de los errores que afectan a los servidores o bases de datos individuales.
Importante
Todos los servidores que haya en un DAG deben ejecutar la misma versión de Exchange. Por ejemplo, no puede combinar servidores de Exchange 2013 y servidores de Exchange 2016 en el mismo DAG.
Un DAG es un límite para la replicación de bases de datos de buzones, los cambios de bases de datos y de servidores, y las conmutaciones por error así como para un componente interno denominado Active Manager. Active Manager, que se ejecuta en todos los servidores de buzones, administra los cambios y las conmutaciones por error en el DAG. Para obtener más información acerca de Active Manager, consulte Active Manager.
Cualquier servidor en un DAG puede hospedar una copia de una base de datos de buzones de correo de cualquier otro servidor en el DAG. Cuando se agrega un servidor a un DAG, funciona con los otros servidores del DAG para proporcionar recuperación automática de errores que afectan a las bases de datos de buzones, como un error de disco, de servidor o de red.
Nota:
Para obtener más información sobre la creación de DAG, la administración de los miembros de los DAG, la configuración de propiedades de los DAG, la creación y supervisión de copias de bases de datos de buzones, y la realización de cambios, consulte Administración de alta disponibilidad y resistencia de sitios.
Ciclo de vida del grupo de disponibilidad de base de datos
Los DAG aprovechan el concepto de implementación incremental, que es la capacidad de implementar la disponibilidad de datos y servicios para todos los servidores de buzones de correo y bases de datos después de instalar Exchange. Después de implementar Exchange Server servidores de buzones de correo, puede crear un DAG, agregar servidores de buzones al DAG y, a continuación, replicar bases de datos de buzones entre los miembros del DAG.
Nota:
Se admite para crear un DAG que contenga una combinación de servidores de buzones físicos y servidores de buzones virtualizados, siempre que los servidores y la solución cumplan los requisitos del sistema de Exchange Server y los requisitos establecidos en Exchange Server virtualización. Como en todas las configuraciones de alta disponibilidad de Exchange, se debe garantizar que el tamaño de todos los servidores de buzones de correo del DAG se haya determinado adecuadamente para poder controlar la carga de trabajo necesaria durante interrupciones programadas y no programadas.
Los DAG se crean con el cmdlet New-DatabaseAvailabilityGroup. Inicialmente se crean como objetos vacíos en Active Directory. Este objeto de directorio se usa para almacenar información relevante acerca del DAG, como la información de suscripción del servidor y algunas configuraciones del DAG. Al agregar el primer servidor a un DAG, se crea automáticamente un clúster de conmutación por error para el DAG. El DAG usa de manera exclusiva este clúster de conmutación por error; dicho clúster debe dedicarse al DAG. El uso del clúster no se permite para ninguna otra finalidad.
Además de crearse un clúster de conmutación por error, se inicia la infraestructura que supervisa los servidores en busca de errores en la red o el servidor. El mecanismo de latidos del clúster de conmutación por error y la base de datos del clúster se usan para administrar la información sobre el DAG que puede cambiar rápidamente (como el estado de montaje de la base de datos, el estado de replicación y la última ubicación de montaje) y para realizar un seguimiento de dicha información.
Cuando se crea, el DAG recibe un nombre único y una o varias direcciones IP estáticas, o bien se configura para que use el Protocolo de configuración dinámica de host (DHCP) o se crea sin un punto de acceso administrativo del clúster. Los DAG sin un punto de acceso administrativo solo se pueden crear en servidores que ejecutan Exchange 2019, Exchange 2016 o Exchange 2013 Service Pack 1 o posterior, con Windows Server 2012 edición R2 Standard o Datacenter. Estas son las características de los DAG sin puntos de acceso administrativo del clúster:
No hay ninguna dirección IP asignada al clúster o al DAG y, por lo tanto, tampoco hay un recurso de dirección IP en el grupo de recursos principal del clúster.
No hay un nombre de red asignado al clúster y, por lo tanto, tampoco un recurso Nombre de red en el grupo de recursos principal del clúster
El nombre del clúster o del DAG no están registrados en DNS y no se puede resolver en la red.
No hay un objeto de nombre clúster (CNO) creado en Active Directory.
El clúster no se puede administrar mediante la herramienta Administración del clúster de conmutación por error. Se debe administrar mediante Windows PowerShell y los cmdlets de PowerShell se deben volver a ejecutar en cada miembro de clúster individual.
Este ejemplo muestra cómo usar el Shell de administración de Exchange para crear un DAG con un punto de acceso administrativo del clúster que tendrá tres servidores. Dos servidores (EX1 y EX2) están en la misma subred (10.0.0.0) y el tercero (EX3) está en otra (192.168.0.0).
New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer EX4 -DatabaseAvailabilityGroupIPAddresses 10.0.0.5,192.168.0.5
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3
Los comandos para crear un DAG sin un punto de acceso administrativo del clúster son muy similares:
New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer EX4 -DatabaseAvailabilityGroupIPAddresses ([System.Net.IPAddress])::None
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3
El clúster para DAG1 se crea al agregar EX1 al DAG. Durante la creación de clústeres, el cmdlet Add-DatabaseAvailabilityGroupServer recupera las direcciones IP configuradas para el DAG e ignora las que no coinciden con ninguna de las subredes halladas en EX1. En el primer ejemplo, el clúster para DAG1 se crea con la dirección IP 10.0.0.5, mientras que 192.168.0.5 no se tiene en cuenta. En el segundo ejemplo de arriba, el valor del parámetro DatabaseAvailabilityGroupIPAddresses indica a la tarea que cree un clúster de conmutación por error para el DAG que no tiene punto de acceso administrativo. Por tanto, el clúster se crea con un recurso de dirección IP o de nombre de red en el grupo de recursos principal del clúster.
A continuación, se agrega EX2 y el cmdlet Add-DatabaseAvailabilityGroupServer recupera de nuevo las direcciones IP configuradas para el DAG. Las direcciones IP del clúster no cambian porque EX2 está en la misma subred que EX1.
A continuación, se agrega EX3 y el cmdlet Add-DatabaseAvailabilityGroupServer recupera de nuevo las direcciones IP configuradas para el DAG. Puesto que en EX3 hay una subred que coincide con 192.168.0.5, la dirección 192.168.0.5 se agrega como recurso de dirección IP al grupo de clústeres. Además, se configura automáticamente una dependencia OR para el recurso Nombre de red de cada recurso de dirección IP. El clúster usará la dirección 192.168.0.5 cuando el grupo de recursos principal del clúster se mueva a EX3.
Para los DAG con puntos de acceso administrativo del clúster, la agrupación en clústeres de conmutación por error de Windows registra las direcciones IP del clúster en el Sistema de nombres de dominio (DNS) cuando el recurso Nombre de red se pone en línea. Además, cuando EX1 se agrega al clúster, se crea un objeto de nombre de clúster (CNO) en Active Directory. El nombre de red, las direcciones IP y el CNO para el clúster no se usan en los roles del DAG. Los administradores y los usuarios finales no necesitan conectarse a la dirección IP ni al nombre del DAG o del clúster, ni usarlos como interfaz. Algunas aplicaciones de terceros se conectan al punto de acceso administrativo del clúster para realizar tareas de administración, como la copia de seguridad o la supervisión. Si no usa ninguna aplicación de terceros que requiera un punto de acceso administrativo de clúster y el DAG ejecuta Exchange 2016 o Exchange 2019 en Windows Server 2012 R2, se recomienda crear un DAG sin un punto de acceso administrativo. Conseguirá que el proceso de configuración del DAG sea más sencillo, ya no necesitará una o varias direcciones IP y reducirá la superficie de ataque del DAG.
Los DAG también se configuran para usar un servidor testigo y un directorio testigo. El sistema configura automáticamente el servidor testigo y el directorio testigo, aunque también los puede configurar manualmente el administrador. En los ejemplos anteriores, EX4 (un servidor que no forma parte del DAG ni lo hará en el futuro) se está configurando manualmente como el servidor testigo del DAG.
De manera predeterminada, un DAG se diseña para que utilice la característica integrada de replicación continua y replique las bases de datos de buzones entre sus servidores. Si usa la replicación de datos de terceros que admite la API de replicación de terceros en Exchange Server, debe crear el DAG en modo de replicación de terceros mediante el cmdlet New-DatabaseAvailabilityGroup con el parámetro ThirdPartyReplication. Una vez habilitado este modo, no se puede deshabilitar.
Una vez creado el DAG, se le pueden agregar servidores de buzones de correo. Cuando se agrega el primer servidor al DAG, se forma un clúster para que el DAG lo utilice. Los DAG hacen uso de la tecnología de clúster de conmutación por error de Windows, como el latido de clúster, las redes de clústeres y la base de datos de clústeres (para almacenar datos que cambian, por ejemplo el estado de base de datos que cambia de activa a pasiva y viceversa, o de montada a desmontada y viceversa). Al irse agregando al DAG cada uno de los siguientes servidores, se une al clúster subyacente, el Exchange ajusta automáticamente el modelo de quórum del clúster y el servidor se agrega al objeto DAG en Active Directory.
Una vez que se han agregado servidores de buzones de correo al DAG, se pueden configurar algunas de las propiedades de este último, por ejemplo si se debe usar el cifrado de red o la compresión de red para la replicación de bases de datos en el DAG. También se pueden configurar las redes de DAG y crear más.
Una vez que se han agregado miembros al DAG y éste se ha configurado, las bases de datos de buzones activas de cada servidor se pueden replicar en los demás miembros del DAG. Después de crear copias de las bases de datos de buzones, se puede supervisar su estado de mantenimiento con varias herramientas de supervisión integradas. Además, puede realizar cambios de base de datos y servidores.
Modelos de quórum de grupos de disponibilidad de base de datos
Debajo de cada DAG hay un clúster de conmutación por error de Windows. Los clústeres de conmutación por error utilizan el concepto de quórum, que emplea un consenso de votantes para garantizar que solamente un subconjunto de miembros del clúster (que podría ser todos los miembros o una mayoría de miembros) funcione a la vez. Quorum no es un concepto nuevo para Exchange Server. Los servidores Buzón de correos de alta disponibilidad de versiones anteriores de Exchange usan también la agrupación en clústeres de conmutación por error y su concepto de quórum. El quórum representa una visión compartida de los miembros y los recursos, y el quórum de término también se utiliza para describir los datos físicos que representan la configuración dentro del clúster que se comparte entre todos los miembros del mismo. A consecuencia de ello, todos los DAG necesitan su clúster de conmutación por error subyacente para tener quórum. Si el clúster pierde quórum, todas las operaciones del DAG terminarán y todas las bases de datos albergadas en el mismo se desmontarán. En este caso, es necesario que intervenga el administrador para corregir el problema de quórum y restaurar las operaciones del DAG.
El quórum es importante para asegurar la coherencia, como mecanismo para resolver empates y como garantía de la capacidad de respuesta de los clústeres:
Garantizar la coherencia: un requisito principal para un clúster de conmutación por error de Windows es que cada uno de los miembros siempre tenga una vista del clúster coherente con los demás miembros. La sección del clúster actúa como repositorio definitivo de toda la información de configuración relativa al clúster. Si la sección del clúster no puede cargarse localmente en un miembro del DAG, el servicio del clúster no se inicia al no poder garantizar que el miembro cumpla el requisito de tener una vista del clúster que sea coherente con los otros miembros.
Actuar como desempate: se usa un recurso de testigo de cuórum en los DAG con un número par de miembros para evitar escenarios de síndrome cerebral dividido y asegurarse de que solo una colección de los miembros del DAG se considera oficial. Cuando el servidor testigo se necesita para quórum, cualquier miembro del DAG que pueda comunicarse con el servidor testigo puede colocar un bloqueo de Bloque de mensajes del servidor en el archivo witness.log del servidor testigo. El miembro del DAG que bloquea el servidor testigo (denominado nodo de bloqueo) retiene un voto adicional por motivos de quórum. Los miembros del DAG que están en contacto con el nodo de bloqueo son mayoría y mantienen el quórum. Cualquier miembro del DAG que no pueda estar en contacto con el nodo de bloqueo forma parte de la minoría y por lo tanto pierde el quórum.
Garantizar la capacidad de respuesta: para garantizar la capacidad de respuesta, el modelo de cuórum se asegura de que, cada vez que se ejecute el clúster, suficientes miembros del sistema distribuido sean operativos y comunicativos, y se pueda garantizar al menos una réplica del estado actual del clúster. No se necesita tiempo adicional para poner en conexión otros miembros ni para determinar si está garantizada un réplica en concreto.
Los DAG con un número par de miembros usan el modo de quórum Mayoría de recursos compartidos de archivos y nodo del clúster, que emplea un servidor testigo externo que ejerce de mecanismo para resolver empates. En este modo de quórum, cada miembro de DAG obtiene un voto. Asimismo, el servidor testigo se usa para proporcionar a un miembro de DAG un voto ponderado (por ejemplo, obtiene dos votos en vez de uno). Los datos del quórum de clúster se almacenan de forma predeterminada en el disco del sistema de cada miembro del DAG y se mantienen coherentes en esos discos. Sin embargo, no se guarda una copia de los datos del quórum en el servidor testigo. Se utiliza un archivo en el servidor testigo para mantener un seguimiento del miembro que tiene la copia de datos más actualizada, pero el servidor testigo no tiene una copia de los datos de quórum del clúster. En este modo, una mayoría de los votantes (los miembros del DAG más el servidor testigo) deben estar operativos y poderse comunicar entre sí para mantener el quórum. Si la mayoría de los votantes no pueden comunicarse entre sí, el clúster subyacente del DAG pierde el quórum y para que el DAG vuelva a estar operativo requerirá una intervención del administrador. Para obtener más información, vea Cambio de centro de datos y Restore-DatabaseAvailabilityGroup.
Los DAG con un número impar de miembros usan un modo de quórum de nodos mayoritarios. En este modo, cada miembro obtiene un voto y el disco del sistema local de cada miembro se usa para almacenar los datos de quórum del clúster. Si la configuración del clúster cambia, ese cambio se refleja en todos los discos. El cambio solamente se considera efectuado y permanente si se realiza en los discos de la mitad de los miembros (redondeado) más uno. Por ejemplo, en un DAG de cinco miembros, el cambio debe efectuarse en dos miembros más uno, o en un total de tres miembros.
El quórum precisa una mayoría de votantes para que puedan comunicarse entre sí. Suponga un DAG con cuatro miembros. Como este DAG tiene un número par de miembros, un servidor testigo externo se emplea para proporcionar a uno de los miembros del clúster un quinto voto que resuelva el empate. Para mantener una mayoría de votantes, y por lo tanto quórum, debe haber al menos tres votantes a fin de poder comunicarse entre sí. Un máximo de dos votantes puede estar sin conexión en cualquier momento sin que se interrumpa el servicio y el acceso a los datos. Si tres votantes o más están sin conexión, el DAG pierde el quórum y el servicio y el acceso a los datos se interrumpirán hasta que se resuelva el problema.