Descripción de grupos de disponibilidad de base de datos

Última modificación del tema: 2010-01-13

Un grupo de disponibilidad de base de datos (DAG) es el componente básico del marco de alta disponibilidad y resistencia de sitio que ofrece Microsoft Exchange Server 2010. Se trata de un grupo de hasta 16 servidores de buzones de correo que hospeda 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 lo servidores o bases de datos individuales.

Un DAG es un límite para la replicación de bases de datos de buzones, las conmutaciones por error y los cambios de bases de datos y de servidores, así como para un componente interno denominado Active Manager. Active Manager es un componente de Exchange 2010 que administra cambios y conmutaciones por error, y se ejecuta en cualquiera de los servidores de un DAG. Para obtener más información acerca de Active Manager, consulte Descripción de 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 otros servidores en el DAG para proporcionar recuperación automática de errores que afectan a las bases de datos de buzones de correo, como un error de disco o de servidor.

Contenido

Ciclo de vida de un grupo de disponibilidad de base de datos

Uso de un grupo de disponibilidad de base de datos para obtener alta disponibilidad

Uso de un grupo de disponibilidad de base de datos para obtener resistencia de sitio

Ciclo de vida de un grupo de disponibilidad de base de datos

Los DAG utilizan una característica de Exchange 2010 denominada implementación incremental, que es la capacidad de implementar la disponibilidad de servicios y datos en todos los servidores y bases de datos de buzones una vez que se ha instalado Exchange. Tras la implementación de Exchange 2010, se puede crear un DAG, agregarle servidores de buzones de correo y, a continuación, replicar las bases de datos de buzones entre los miembros del DAG.

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. Cuando un administrador agrega el primer servidor a un DAG, automáticamente se crea un clúster de conmutación por error para el DAG. Además, 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.

Mientras 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). Puede especificar una única dirección IP o una lista de direcciones IP separadas por comas, utilizando el parámetro DatabaseAvailabilityGroupIPAddresses.

Imagine que un DAG va a tener tres servidores: dos de ellos, EX1 y EX2, están en la misma subred (10.0.0.0) y el tercero, EX3, está en otra (192.168.0.0). El administrador ejecuta los comandos siguientes:

New-DatabaseAvailabilityGroup -Name DAG1 -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

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 este 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.

A continuación, se agrega EX2. Una vez más, el cmdlet Add-DatabaseAvailabilityGroupServer recupera 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. Una vez más, el cmdlet Add-DatabaseAvailabilityGroupServer recupera 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 utilizará la dirección 192.168.0.5 cuando el grupo de clústeres se mueva a EX3.

La agrupación en clústeres de conmutación por error de Windows registra la dirección 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, se crea un objeto de la red de clústeres (CNO) en Active Directory. El sistema usa sólo a nivel interno el nombre, las direcciones IP y el CNO para el clúster a fin de proteger el DAG y permitir la comunicación interna. Los administradores y los usuarios finales no necesitan conectarse a la dirección IP ni al nombre del DAG, ni usarlos como interfaz.

Además de recibir un nombre y una o varias direcciones IP, el DAG se configura también para que utilice un servidor testigo y un directorio testigo. El sistema especifica automáticamente el servidor testigo y el directorio testigo, aunque también los puede especificar manualmente el administrador.

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 utiliza una replicación de datos de terceros que admite la API de replicación de terceros de Exchange 2010, deberá crear el DAG en el 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 un uso limitado de la tecnología de clústeres de conmutación por error de Windows, concretamente el latido de clúster, las redes de clústeres y la base de datos de clústeres (para almacenar datos que cambian o pueden cambiar rápidamente, como 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 (y el sistema ajusta automáticamente, según sea necesario, 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 e incluso crear más, si es necesario.

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 según sea necesario.

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 la alta disponibilidad y la resistencia de sitios.

Volver al principio

Uso de un grupo de disponibilidad de base de datos para obtener alta disponibilidad

Consulte el ejemplo, en el que se usa un DAG con cinco miembros, para obtener información sobre cómo los DAG pueden proporcionar alta disponibilidad para las bases de datos de buzones. Este DAG se muestra en la siguiente figura.

Grupo de disponibilidad de base de datos

En la figura anterior, las bases de datos verdes son copias de bases de datos de buzones activas y las azules son copias de bases de datos de buzones pasivas. En este ejemplo, las copias de bases de datos no se reflejan en cada uno de los servidores, si no que se distribuyen por varios servidores. De esta forma se garantiza que no hay dos servidores en un DAG con el mismo conjunto de copias de bases de datos y, de esta forma, se proporciona al DAG una mayor resistencia ante errores, incluidos los que tienen lugar mientras otros componentes están inactivos por razones de mantenimiento.

Observe la siguiente situación, en la que se usa el ejemplo de DAG anterior, y que muestra la resistencia ante varios errores de bases de datos y servidores.

Inicialmente, el estado de todas las bases de datos y servidores es correcto. Un administrador tiene que instalar actualizaciones del sistema operativo en EX2. Realiza un cambio de servidor, lo que activa la copia de DB4 en otro servidor de buzones de correo. Un cambio de servidor es una tarea que los administradores realizan para mover todas las copias de bases de datos de buzones activas desde el servidor actual a uno o varios servidores de buzones de correo del DAG, como preparación ante el apagón programado del servidor actual. El administrador puede realizar un cambio de servidor con rapidez si ejecuta el comando siguiente en el Shell de administración de Exchange.

Move-ActiveMailboxDatabase -Server EX2

En este ejemplo, solo hay una base de datos de buzones activa en EX2 (DB4), por lo que solo se mueve una copia de base de datos de buzones activa. Mediante la omisión del parámetro ActivateOnServer en el comando anterior, el administrador decide que sea el sistema el que seleccione la mejor copia activa, y el sistema selecciona la copia que está en EX5, como se muestra en la figura siguiente.

Grupo de disponibilidad de base de datos con un servidor sin conexión por razones de mantenimiento

Mientras el administrador realiza el mantenimiento en EX2, EX3 queda sin conexión como consecuencia de un grave error de hardware. Antes de quedar sin conexión, EX3 hospedaba la copia activa de DB2. Para recuperarse del error, el sistema activa automáticamente la copia de DB2 hospedada en EX1 en menos de 30 segundos. Se muestra en la siguiente figura.

Grupo de disponibilidad de base de datos con un servidor sin conexión por razones de mantenimiento y un servidor con error

Una vez que ha finalizado el mantenimiento programado de EX2, el administrador vuelve a ponerlo en línea. En el momento en que EX2 está conectado, los demás miembros del DAG reciben una notificación al respecto, y las copias de DB1, DB4 y DB5 hospedadas en EX2 se vuelven a sincronizar automáticamente con la copia activa de cada base de datos. Se muestra en la siguiente figura.

Grupo de disponibilidad de base de datos con un servidor restaurado que vuelve a sincronizar sus copias de bases de datos

Una vez que se sustituye el componente de hardware dañado en EX3, éste se vuelve a poner en línea. Al igual que en el caso de EX2, una vez que EX3 está conectado, los demás miembros del DAG reciben una notificación al respecto, y las copias de DB2, DB3 y DB4 hospedadas en EX3 se vuelven a sincronizar automáticamente con la copia activa de cada base de datos. Se muestra en la siguiente figura.

Grupo de disponibilidad de base de datos con un servidor reparado que vuelve a sincronizar sus copias de bases de datos

Volver al principio

Uso de un grupo de disponibilidad de base de datos para obtener resistencia de sitio

Además de proporcionar alta disponibilidad en un centro de datos, un DAG se puede ampliar a otros centros de datos en una configuración que proporcione resistencia de sitio para uno o varios centros de datos. En las figuras del ejemplo anterior, el DAG está ubicado en un único centro de datos y un único sitio de Active Directory. Se puede utilizar la implementación incremental para ampliar este DAG a otro centro de datos (y otro sitio de Active Directory) mediante la implementación de un servidor de buzones de correo y los recursos auxiliares necesarios (es decir, uno o varios servidores de Active Directory y uno o varios servidores Transporte de concentradores y Acceso de clientes) y, a continuación, la agregación de servidores de buzones de correo al DAG, como se ilustra a continuación.

Grupo de disponibilidad de base de datos extendido en dos sitios de Active Directory

En este ejemplo, una copia pasiva de cada base de datos activa del centro de datos de Redmond se configura en EX6 en el centro de datos de Dublín.

Volver al principio