Administración de grupos de disponibilidad de base de datos

  • Artículo

 

Se aplica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Última modificación del tema: 2016-11-28

Un grupo de disponibilidad de base de datos (DAG) es un conjunto de hasta 16 servidores de buzones de correo de Microsoft Exchange Server 2010 que ofrece recuperación automática en el nivel de base de datos ante un error de base de datos, servidor o red. Los DAG usan replicación continua y un subconjunto de tecnologías de clústeres de conmutación por error de Windows para ofrecer alta disponibilidad y resistencia en los sitios. Los servidores de buzones de un DAG se supervisan mutuamente para detectar errores. Cuando se agrega un servidor de buzones de correo a un DAG, éste trabaja con los demás servidores del DAG para ofrecer recuperación automática de base de datos a partir de errores de base de datos.

Al crear un DAG (que inicialmente está vacío), se crea un objeto de directorio en Active Directory que representa a dicho DAG. El objeto de directorio se usa para almacenar información relevante acerca del DAG, como la información de suscripción del servidor. Al agregar el primer servidor a un DAG, se crea automáticamente 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.

Contenido

Cómo crear grupos de disponibilidad de base de datos

Membresía de DAG

Configuración de las propiedades del DAG

Redes de DAG

Configuración de los miembros DAG

Realización del mantenimiento en los miembros DAG

Apagar los miembros de DAG

Instalación de paquetes acumulativos de actualizaciones en los miembros de DAG

Cómo crear grupos de disponibilidad de base de datos

Se puede crear un DAG con el Asistente para nuevos grupos de disponibilidad de base de datos en la Consola de administración de Exchange (EMC) o mediante la ejecución del cmdlet New-DatabaseAvailabilityGroup en el Shell de administración de Exchange. Cuando cree un DAG, proporcione un nombre para el DAG y establezca una configuración adicional para el servidor y el directorio testigo. Además, se asignan al DAG una o más direcciones IP, ya sea usando direcciones IP estáticas o permitiendo que se asignen direcciones IP de forma automática al DAG mediante el Protocolo de configuración dinámica de host (DHCP). Puede asignar direcciones IP de forma manual al DAG mediante el parámetro DatabaseAvailabilityGroupIpAddresses. Si omite este parámetro, el DAG intenta obtener una dirección IP usando el servidor DHCP en la red.

Para obtener instrucciones detalladas acerca de cómo crear un grupo de disponibilidad de base de datos, consulte Crear un grupo de disponibilidad de la base de datos.

Al crear un DAG, en Active Directory se crean un objeto vacío que representa al DAG con el nombre especificado y una clase de objeto msExchMDBAvailabilityGroup.

Los DAG utilizan un subconjunto de tecnologías de clústeres 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 o pueden cambiar rápidamente, por ejemplo, el estado de la base de datos que cambia de activa a pasiva, y viceversa, o de montada a desmontada, y viceversa). Dado que los DAG dependen del clúster de conmutación por error de Windows, solo pueden crearse en los servidores de buzones de correo de Exchange 2010 que ejecutan el sistema operativo Windows Server 2008 Enterprise o Windows Server 2008 R2 Enterprise.

Nota

El error en el clúster creado y utilizado por el DAG debe ser dedicado a DAG. El clúster no se puede usar para ninguna otra solución de alta disponibilidad ni para cualquier otro fin. Por ejemplo, el error en el clúster no se puede usar para organizar por clústeres otras aplicaciones o servicios. No es compatible el uso de un error en el clúster subyacente de DAG para fines que no son el DAG.

Servidor testigo de DAG y directorio testigo

Al crear un DAG, se debe especificar un nombre que no supere los 15 caracteres y que sea único dentro del bosque de Active Directory. Además, cada DAG se configura con un servidor testigo y un directorio testigo. El servidor testigo y su directorio se usan sólo para fines de quórum cuando la cantidad de miembros del DAG es par. No es necesario crear un directorio testigo por adelantado. Exchange crea automáticamente y protege el directorio en el servidor testigo. El directorio no debe usarse para ningún fin que no sea para el servidor testigo del DAG.

Los requisitos para el servidor testigo son los siguientes:

  • El servidor testigo no puede ser miembro del DAG.

  • El servidor testigo debe estar en el mismo bosque de Active Directory que el DAG.

  • El servidor testigo debe ejecutarse en Windows Server 2003 o una versión posterior.

  • Un servidor simple puede servir de testigo para varios DAG. Sin embargo, cada DAG requiere su propio directorio testigo.

Se recomienda usar un servidor de transporte de concentradores de Exchange 2010 en el sitio de Active Directory que contiene el DAG. Esto permite que un administrador de Exchange controle el directorio y el servidor testigo. Independientemente de qué servidor se use como servidor testigo, si Windows Firewall se habilita en el servidor testigo deseado, debe habilitar la excepción de Windows Firewall para Compartir impresoras y archivos.

Importante

Si el servidor testigo especificado no es un servidor de Exchange 2010, debe agregar el grupo de seguridad universal (USG) del subsistema de confianza de Exchange al grupo de administradores locales en el servidor testigo antes de crear el DAG. Estos permisos de seguridad son necesarios para asegurar que Exchange pueda crear un directorio y compartirlo en el servidor testigo, según sea preciso.

Ni el servidor testigo ni el directorio testigo necesitan ser tolerantes a errores ni usar ningún tipo de redundancia o alta disponibilidad. No es necesario usar un servidor de archivos en clúster para el servidor testigo, ni emplear ninguna otra forma de resistencia para el servidor testigo. Existen varias razones para ello. Con DAG más grandes (por ejemplo, de seis miembros o más) deben producirse varios errores antes de que sea necesario un servidor testigo. Debido a que un DAG de seis miembros puede tolerar hasta dos errores de votante sin perder quórum, se tendrían que producir errores en tres votantes antes de que se necesite un servidor testigo para mantener el quórum. Además, si se produce un error que afecta el servidor testigo actual (por ejemplo, se pierde el servidor testigo debido a un error de hardware), se puede usar el cmdlet Set-DatabaseAvailabilityGroup para configurar un servidor testigo y un directorio testigo nuevos (en caso de tener quórum).

Nota

También se puede usar el cmdlet Set-DatabaseAvailabilityGroup para configurar el servidor testigo y el directorio testigo en la ubicación original si el servidor testigo perdió su almacenamiento o si alguien cambió el directorio testigo o los permisos de los recursos compartidos.

En un entorno en el que un DAG se amplía en varios centros de datos (y sitios de Active Directory) y se configura para resistencia de sitios, se recomienda usar un servidor testigo en el centro de datos principal (el centro de datos que contiene la mayor cantidad de usuarios). Si todos los centros de datos tienen una cantidad similar de usuarios, el centro de datos elegido para hospedar el servidor testigo se considera el centro de datos principal desde el punto de vista de la solución. Si el servidor testigo se encuentra en el centro de datos que tiene la mayor cantidad de clientes, la mayoría de los clientes conservará el acceso después de un error.

Si el centro de datos se encuentra lejos de las grandes cantidades de usuarios, es posible que eso afecte su decisión. Por lo tanto, es posible que deba determinar si existe el requisito de que el centro de datos principal permanezca en buen estado y activo en caso de que se pierda la conexión de red de área extensa (WAN) en los otros dos centros de datos. En ese caso, el servidor testigo también debe encontrarse en el centro de datos principal.

A pesar de que se admite el uso de un servidor testigo en un tercer centro de datos, no se recomienda ese escenario. Desde el punto de vista de Exchange, esta configuración no proporciona una mayor disponibilidad. Es importante examinar los factores críticos de la ruta de acceso si usa un servidor testigo en un tercer centro de datos. Por ejemplo, si falla la conexión WAN entre el centro de datos principal y el segundo y el tercer centro, la solución del centro de datos principal no estará disponible.

Especificación de un servidor testigo y un directorio testigo durante la creación de los DAG

Al crear un DAG, debe proporcionar un nombre para el DAG. Además, puede especificar un servidor testigo y un directorio testigo. Si especifica un servidor testigo, se recomienda usar un servidor de transporte de concentradores, ya que permite a un administrador de Exchange conocer la disponibilidad del servidor testigo.

Al crear un DAG, estarán disponibles las siguientes combinaciones de opciones y comportamientos:

  • Puede solamente especificar un nombre para el DAG y dejar en blanco los campos Servidor testigo y Directorio testigo. En este caso, el asistente busca un servidor de transporte de concentradores que no tiene instalado el rol de servidor Buzón de correo y crea automáticamente el directorio predeterminado (%SystemDrive%:\DAGFileShareWitnesses\<DAGFQDN>) y el recurso compartido predeterminado (<DAGFQDN>) en dicho servidor. Además, usa el servidor de transporte de concentradores como servidor testigo. Por ejemplo. piense en un servidor testigo denominado EXMBX3 en cuya unidad C se ha instalado el sistema operativo. Un DAG denominado DAG1 en un dominio denominado contoso.com usaría el directorio testigo predeterminado C:\DAGFileShareWitnesses\DAG1.contoso.com, que se compartiría como \\EXMBX3\DAG1.contoso.com.

  • Puede especificar un nombre para el DAG, el servidor testigo que desea usar y el directorio que va a crear y compartir en el servidor testigo.

  • Puede especificar un nombre para el DAG y el servidor testigo que desea usar, y dejar en blanco el campo Directorio testigo. En este caso, el asistente creará el directorio predeterminado en el servidor testigo especificado.

  • Puede especificar un nombre para el DAG, dejar en blanco el campo Servidor testigo y especificar el directorio que va a crear y compartir en el servidor testigo. En este caso, el asistente busca un servidor de transporte de concentradores que no tiene instalado el rol de servidor de buzón de correo y crea automáticamente el DAG especificado en dicho servidor, comparte el directorio y usa ese servidor de transporte de concentradores como servidor testigo.

Cuando se forma un DAG, éste inicialmente usará el modelo de quórum Mayoría de nodo. Cuando se agrega el segundo servidor de buzones de correo al DAG, el quórum cambia automáticamente a un modelo de quórum Mayoría de recurso compartido de archivos y nodo. Al producirse este cambio, el DAG comienza a usar el servidor testigo para mantener el cuórum. Si el directorio testigo no existe, Exchange, de forma automática, lo creará, lo compartirá y proporcionará permisos de control total para la cuenta del equipo del objeto de nombre de clústeres (CNO) para el DAG.

Nota

No se admite el uso de un recurso compartido de archivos que forme parte de un espacio de nombres del Sistema de archivos distribuido (DFS).

Si Firewall de Windows está habilitado en el servidor testigo antes de crear el DAG, es posible que bloquee la creación. Exchange usa Instrumental de administración de Windows (WMI) para crear el directorio y el recurso compartido de archivos en el servidor testigo. Si Firewall de Windows está habilitado en el servidor testigo y no hay excepciones de firewall configuradas para WMI, el cmdlet New-DatabaseAvailabilityGroup se cierra con un error. Si especifica un servidor testigo y no especifica un directorio testigo, obtiene el siguiente mensaje de error.

La tarea no pudo crear el directorio testigo predeterminado en el servidor <Nombre del servidor>. Especifique un directorio testigo manualmente.

Si especifica un servidor testigo y un directorio testigo, obtiene el siguiente mensaje de advertencia.

No se puede obtener acceso a los recursos compartidos de archivos en el servidor testigo 'nombre de servidor'. Es posible que el grupo de disponibilidad de base de datos sea más vulnerable a errores hasta que se corrija este problema. Puede usar el cmdlet Set DatabaseAvailabilityGroup para intentar la operación de nuevo. Error: No se ha encontrado la ruta de acceso de la red.

Si Firewall de Windows está habilitado en el servidor testigo después de crear el DAG pero antes de agregar los servidores, es posible que bloquee las acciones de agregar o quitar miembros del DAG. Si Firewall de Windows está habilitado en el servidor testigo y no hay excepciones de firewall configuradas para WMI, el cmdlet Add-DatabaseAvailabilityGroupServer muestra el siguiente mensaje de advertencia.

No se pudo crear el directorio testigo de recurso compartido de archivos 'C:\DAGFileShareWitnesses\DAG_FQDN' en el servidor testigo nombre de servidor. Es posible que el grupo de disponibilidad de base de datos sea más vulnerable a errores hasta que se corrija este problema. Puede usar el cmdlet Set DatabaseAvailabilityGroup para intentar la operación de nuevo. Error: Se produjo la excepción WMI en el servidor nombre de servidor: el servidor RPC no está disponible. (Excepción de HRESULT: 0x800706BA)

Para solucionar el error y las advertencias precedentes, realice una de las siguientes acciones:

  • Cree manualmente el directorio testigo y el recurso compartido en el servidor testigo, y asigne el CNO para el control completo de DAG para el directorio y el recurso compartido.

  • Habilite la excepción de WMI en Firewall de Windows.

  • Deshabilite Firewall de Windows.

Volver al principio

Membresía de DAG

Después de crear un DAG, es posible agregarle o quitarle servidores mediante el Asistente para administrar grupos de disponibilidad de bases de datos en la EMC, o mediante los cmdlets Add-DatabaseAvailabilityGroupServer o Remove-DatabaseAvailabilityGroupServer en el Shell. Para obtener instrucciones detalladas sobre cómo administrar la pertenencia a un DAG, consulte Administrar pertenencia al grupo de disponibilidad de la base de datos.

Nota

Cada servidor de buzones de correo que pertenezca a un DAG también es un nodo en el clúster subyacente usado por el DAG. Como consecuencia, en cualquier momento, un servidor de buzones de correo puede pertenecer a un solo DAG.

Si el servidor de buzones de correo que se agrega al DAG no tiene instalado un componente de clúster de conmutación por error, el método usado para agregar el servidor (por ejemplo, el cmdlet Add-DatabaseAvailabilityGroupServer o el Asistente para administrar grupos de disponibilidad de base de datos) instala la característica de clúster de conmutación por error.

Cuando se agrega el primer servidor de buzones de correo a un DAG, ocurre lo siguiente:

  • Se instala el componente de clúster de conmutación por error de Windows, si aún no se había instalado.

  • Se crea un clúster de conmutación por error usando el nombre del DAG. Este error en el clúster es usado exclusivamente por el DAG, y el clúster debe estar dedicado al DAG. No se admite el uso del clúster para cualquier otro fin.

  • Un CNO se crea en el contenedor de equipos predeterminado.

  • El nombre y la dirección IP del DAG se registran como Host (A) en Sistema de nombres de dominio (DNS).

  • El servidor se agrega al objeto del DAG en Active Directory.

  • La base de datos del clúster se actualiza con información sobre las bases de datos montadas en el servidor agregado.

En un entorno grande o de varios sitios, en especial en los que el DAG se extiende a varios sitios de Active Directory, debe esperar hasta que se complete la replicación de Active Directory en el objeto DAG que contiene el primer miembro del DAG. Si este objeto de Active Directory no se replica en todo el entorno, el agregado del segundo servidor puede ocasionar la creación de un clúster nuevo (y un CNO nuevo) en el DAG. Esto sucede porque el objeto DAG parece estar vacío desde la perspectiva del segundo miembro que se agrega y, por lo tanto, producirá que el cmdlet Add-DatabaseAvailabilityGroupServer cree un clúster y un CNO para el DAG, a pesar de que estos objetos ya existen. Para comprobar que el objeto DAG que contiene el primer servidor DAG se haya replicado, use el cmdlet Get-DatabaseAvailabilityGroup en el segundo servidor que se agrega a fin de comprobar si el primer servidor que se agregó figura como miembro del DAG.

Cuando se agrega el segundo servidor y los servidores siguientes a un DAG, ocurre lo siguiente:

  • El servidor se une al clúster de conmutación por error de Windows del DAG.

  • El modelo de quórum se ajusta automáticamente:

    • El modelo de quórum Mayoría de nodos se usa para los DAG que tienen una cantidad impar de miembros.

    • El modelo de quórum Mayoría de recurso compartido de archivos y nodo se usa para los DAG que tienen una cantidad par de miembros.

  • De ser necesario, Exchange crea automáticamente el directorio testigo y el recurso compartido.

  • El servidor se agrega al objeto del DAG en Active Directory.

  • La base de datos del clúster se actualiza con información acerca de las bases de datos montadas.

Nota

El cambio de modelo de quórum debe producirse automáticamente. Sin embargo, si el modelo de quórum no cambia automáticamente al modelo adecuado, puede ejecutar el cmdlet Set-DatabaseAvailabilityGroup solo con el parámetro Identity para corregir la configuración de quórum del DAG.

Preconfiguración del objeto de nombre de clúster para un grupo de disponibilidad de base de datos

El CNO es una cuenta de equipo que se crea en Active Directory y se asocia con el recurso Nombre del clúster. El recurso Nombre del clúster está asociado al CNO, que es un objeto habilitado para Kerberos que actúa como la identidad del clúster y proporciona el contexto de seguridad del clúster. En Exchange 2007, esta cuenta de equipo habilitada para Kerberos se creó en el dominio mediante el contexto de seguridad del usuario que realiza las tareas. Para hacerlo, es necesario que la cuenta del usuario disponga de los permisos para crear y habilitar cuentas de equipo en el dominio o que la cuenta de equipo se preconfigure y aprovisione correctamente.

La formación del clúster subyacente del DAG y del CNO de ese clúster se realiza cuando se agrega el primer miembro al DAG. PowerShell se comunica con el servicio de replicación de Microsoft Exchange en el servidor de buzones de correo que se agrega cuando se agrega el primer servidor al DAG. El servicio de replicación de Microsoft Exchange instala la característica de clúster de conmutación por error (si aún no está instalada) y comienza el proceso de creación del clúster. El servicio de replicación de Microsoft Exchange se ejecuta bajo el contexto de seguridad LOCAL SYSTEM y es en este contexto de seguridad donde se realiza la creación del clúster.

Advertencia

Si sus miembros de DAG se ejecutan en Windows Server 2012, debe ensayar previamente el CNO antes de agregar el primer serviros al DAG.

Se puede preconfigurar y aprovisionar el CNO en entornos en los que la creación de la cuenta de equipo está restringida o en los que las cuentas de equipo se crean en un contenedor distinto del contenedor de equipos predeterminado. Se crea una cuenta de equipo para el CNO, se la deshabilita y, a continuación, hay dos alternativas:

  • Asignar el control total de la cuenta de equipo a la cuenta de equipo del primer servidor del buzón de correo que se agrega al DAG.

  • Asignar el control total sobre la cuenta de equipo al grupo de seguridad universal del subsistema de confianza de Exchange.

La asignación del control total sobre la cuenta de equipo a la cuenta de equipo del primer servidor de buzón de correo que agrega al DAG garantiza que el contexto de seguridad LOCAL SYSTEM podrá administrar la cuenta de equipo preconfigurada. Como alternativa, se puede usar la asignación de control total sobre la cuenta de equipo al grupo de seguridad del subsistema de confianza de Exchange porque el grupo del subsistema de confianza de Exchange contiene las cuentas de equipo de todos los servidores de Exchange del dominio.

Para obtener instrucciones detalladas acerca de cómo preconfigurar y aprovisionar el CNO para un DAG, consulte Ensayo del objeto de nombre de clúster para un grupo de disponibilidad de base de datos.

Eliminación de servidores de un DAG

Se pueden quitar servidores de buzones de correo de un DAG mediante el Asistente para administrar grupos de disponibilidad de base de datos en la EMC o el cmdlet Remove-DatabaseAvailabilityGroupServer en el Shell. Antes de que sea posible quitar el servidor de buzones de correo de un DAG, se deben quitar del servidor todas las bases de datos de buzones de correo replicadas. Si intenta quitar de un DAG un servidor de buzones de correo con bases de datos de buzones de correo replicadas, se produce un error en la tarea.

Existen escenarios en los que, antes de realizar determinadas operaciones, se debe quitar un servidor de buzones de correo de un DAG. Entre estos escenarios se incluyen lo siguientes:

  • Ejecución de una operación de recuperación de servidores   Si un servidor de buzones de correo que es miembro de un grupo de disponibilidad de base de datos se pierde o presenta algún error y debe ser reemplazado porque no es posible recuperarlo, puede ejecutar una operación de recuperación del servidor mediante el conmutador Setup /m:RecoverServer. Sin embargo, antes de realizar la operación de recuperación, primero, deberá quitar el servidor del DAG mediante el cmdlet Remove-DatabaseAvailabilityGroupServer con el parámetro ConfigurationOnly.

  • Eliminación de la disponibilidad de base de datos   Existen situaciones en las que se debe quitar el DAG (por ejemplo, al deshabilitar el modo de replicación de terceros). Si necesita eliminar un DAG, primero, deberá quitar todos los servidores del DAG. Si intenta quitar un DAG que contiene uno o más miembros, se produce un error en la tarea.

Volver al principio

Configuración de las propiedades del DAG

Una vez que los servidores se han agregado al DAG, puede usar la EMC o el Shell para configurar las propiedades de un DAG, incluidos el servidor testigo y el directorio testigo que usa el DAG, y las direcciones IP asignadas al DAG.

Las propiedades configurables incluyen las siguientes:

  • Servidor testigo   El nombre del servidor en el que desea hospedar el recurso compartido de archivos para el recurso compartido de archivos testigo. Se recomienda que especifique un servidor de transporte de concentradores fuera del DAG como servidor testigo. Esto permite que el sistema configure, proteja y use los recursos compartidos automáticamente, según sea necesario.

  • Directorio testigo   El nombre de un directorio que se usará para almacenar datos del testigo del recurso compartido de archivos. El sistema creará automáticamente este directorio en el servidor testigo especificado.

  • Direcciones IP del grupo de disponibilidad de base de datos   Una o más direcciones IP asignadas al DAG. Estas direcciones se pueden configurar mediante direcciones IP estáticas asignadas en forma manual o se pueden asignar al DAG en forma automática mediante un servidor DHCP de la organización.

El Shell le permite configurar propiedades del DAG que no están disponibles en la EMC, como direcciones IP del DAG, opciones de cifrado y compresión de redes, detección de redes, el puerto TCP usado para la replicación y opciones alternativas para el servidor testigo y el directorio testigo. Además, le permite habilitar el modo de coordinación de la activación del centro de datos.

Para obtener instrucciones detalladas sobre cómo configurar las propiedades de un DAG, consulte Configurar las propiedades del grupo de disponibilidad de la base de datos.

Cifrado de red de DAG

Los DAG admiten el uso de cifrado mediante el aprovechamiento de las capacidades de cifrado del sistema operativo de Windows Server. Los DAG utilizan la autenticación Kerberos entre servidores de Exchange. Las API EncryptMessage y DecryptMessage del proveedor de compatibilidad para seguridad (SSP) Microsoft Kerberos manejan el cifrado del tráfico de red del DAG. El SSP de Microsoft Kerberos admite varios algoritmos de cifrado. (Para conocer la lista completa, consulte la sección 3.1.5.2, "Tipos de cifrado" de Extensiones del protocolo Kerberos). El protocolo de enlace de la autenticación de Kerberos selecciona el protocolo de cifrado más alto de la lista: en general, el Estándar de cifrado avanzado (AES) de 256 bits, posiblemente con un HMAC (código de autenticación de mensajes basado en hash) SHA para mantener la integridad de los datos. Para obtener información detallada, consulte HMAC.

El cifrado de red es una propiedad del DAG, y no una red del DAG. Puede configurar el cifrado de red del DAG mediante el uso del cmdlet Set-DatabaseAvailabilityGroup en el Shell. En la siguiente tabla, se muestran las opciones disponibles de cifrado de las comunicaciones de red del DAG.

Opciones de cifrado de las comunicaciones de red del DAG

Opción Descripción

Deshabilitado

No se usa cifrado de red.

Habilitado

El cifrado de red se usa en todas las redes del DAG para replicación y propagación.

InterSubnetOnly

El cifrado de red se usa en las redes del DAG al replicar en diferentes subredes. Esta es la configuración predeterminada.

SeedOnly

El cifrado de red se usa en todas las redes del DAG solo para la propagación.

Compresión de red de DAG

Los DAG admiten compresión integrada. Cuando se habilita la compresión, la comunicación de redes del DAG usa XPRESS, que es la implementación del algoritmo LZ77 por parte de Microsoft. Para obtener información detallada, consulte Una explicación del algoritmo desinflar y la sección 3.1.7.2, "Algoritmo de compresión" de Especificación del protocolo de formato. Se trata del mismo tipo de compresión usado en muchos protocolos de Microsoft, en especial, la compresión RPC de MAPI entre Microsoft Outlook y Exchange.

Como sucede con el cifrado de red, la compresión de red es una propiedad del DAG, y no una red del DAG. Para configurar la compresión de red del DAG debe usar el cmdlet Set-DatabaseAvailabilityGroup en el Shell. En la siguiente tabla, se muestran las opciones disponibles de compresión de las comunicaciones de red del DAG.

Opciones de compresión de las comunicaciones de red del DAG

Configuración Descripción

Deshabilitado

No se usa compresión de red.

Habilitado

La compresión de red se usa en todas las redes del DAG para replicación y propagación.

InterSubnetOnly

La compresión de red se usa en las redes del DAG al replicar en diferentes subredes. Esta es la configuración predeterminada.

SeedOnly

La compresión de red se usa en todas las redes del DAG solo para la propagación.

Volver al principio

Redes de DAG

Una red del DAG es un conjunto de una o más subredes usadas para el tráfico de replicación o el tráfico MAPI. Cada DAG contiene un máximo de una red MAPI y cero más redes de replicación. En una configuración del adaptador de red simple, la red se usa para el tráfico de replicación y MAPI. A pesar de que se admite un único adaptador de red y una ruta de acceso, se recomienda que cada DAG tenga como mínimo dos redes del DAG. En una configuración de dos redes, una red se dedica generalmente al tráfico de replicación y la otra se usa principalmente para el tráfico MAPI. También puede agregar adaptadores de red a cada miembro DAG y configurar redes DAG adicionales como redes de replicación.

Nota

Cuando se usan varias redes de replicación, no hay forma de especificar una orden de precedencia para el uso de las redes. Exchange selecciona aleatoriamente una red de replicación del grupo de redes de replicación para usarla en el trasvase de registros.

Puede usar el Asistente para la nueva red del grupo de disponibilidad de base de datos de la EMC o el cmdlet New-DatabaseAvailabilityGroupNetwork del Shell para crear una red del DAG. Para obtener instrucciones detalladas acerca de cómo crear una red de grupo de disponibilidad de base de datos, consulte Crear una red de grupo de disponibilidad de la base de datos.

Puede usar el cuadro de diálogo Propiedades de la red del DAG de la EMC o el cmdlet Set-DatabaseAvailabilityGroupNetwork del Shell para configurar las propiedades de red del DAG. Para obtener instrucciones detalladas sobre cómo configurar las propiedades de una red de DAG, consulte Configurar las propiedades de la red del grupo de disponibilidad de la base de datos. Cada red del DAG tiene parámetros obligatorios y opcionales para configurar:

  • Nombre de red   Nombre exclusivo para la red del DAG de 128 caracteres como máximo.

  • Descripción de red   Descripción opcional de la red del DAG de 256 caracteres como máximo.

  • Subredes de red   Una o más subredes a las que se obtiene acceso mediante un formato de dirección IP o máscara de bits (por ejemplo, 192.168.1.0/24 para subredes del protocolo de Internet versión 4 IPv4; 2001:DB8:0:C000::/64 para subredes del protocolo de Internet 6 IPv6).

  • Habilitar replicación   En la EMC, seleccione la casilla que permite dedicar la red del DAG al tráfico de replicación y bloquee el tráfico MAPI. Desactive la casilla para impedir que la replicación use la red del DAG y para habilitar el tráfico MAPI. En el Shell, use el parámetro ReplicationEnabled del cmdlet Set-DatabaseAvailabilityGroupNetwork para habilitar y deshabilitar la replicación.

Nota

La deshabilitación de la replicación en la red MAPI no garantiza que el sistema no usará esa red MAPI para replicación. Cuando todas las redes configuradas para replicación se encuentran sin conexión, presentan errores o no se encuentran disponibles y solo existe una red MAPI (que no está configurada como habilitada para la replicación) el sistema usa esa red MAPI para la replicación.

Las redes DAG iniciales (por ejemplo, DAGNetwork01 y DAGNetwork02) creadas por el sistema se basan en las subredes enumeradas por el servicio de clúster. Cada miembro DAG debe tener la misma cantidad de adaptadores de redes y cada adaptador de red debe tener una dirección IPv4 (y opcionalmente, también una dirección IPv6) en una subred única. Varios miembros de DAG pueden tener direcciones IPv4 en la misma subred, pero cada adaptador de red y par de dirección de IP en un miembro DAG específico deben estar en una subred única. Además, solamente el adaptador usado para la red MAPI se debe configurar con la puerta de enlace predeterminada. Las redes de replicación no se deben configurar con una puerta de enlace predeterminada.

Por ejemplo, considere DAG1, un DAG de dos miembros donde cada miembro tiene dos adaptadores de red (uno dedicado para la red MAPI y el otro para la red de replicación). Las configuraciones de dirección IP de ejemplo se muestran en la siguiente tabla.

Configuraciones del adaptador de red de ejemplo

Adaptador de red del servidor Dirección IP/máscara de subred Puerta de enlace predeterminada

EX1-MAPI

192.168.1.15/24

192.168.1.1

Replicación de EX1

10.0.0.15/24

No aplicable

EX2-MAPI

192.168.1.16

192.168.1.1

Replicación de EX2

10.0.0.16

No aplicable

En la siguiente configuración, hay dos subredes configuradas en el DAG: 192.168.1.0 y 10.0.0.0. Cuando se agregan EX1 y EX2 al DAG, se enumerarán dos subredes y se crearán dos redes de DAG: DAGNetwork01 (192.168.1.0) y DAGNetwork02 (10.0.0.0). Estas redes se configurarán como se muestra en la siguiente tabla.

Configuraciones de red DAG enumeradas para un DAG de subred simple

Nombre Subredes Interfaces Acceso a MAPI habilitado Replicación habilitada

DAGNetwork01

192.168.1.0/24

EX1 (192.168.1.15)

EX2 (192.168.1.16)

True

True

DAGNetwork02

10.0.0.0/24

EX1 (10.0.0.15)

EX2 (10.0.0.16)

False

True

Para completar la configuración de DAGNetwork02 como la red de replicación dedicada, deshabilite la replicación para DAGNetwork01 ejecutando el siguiente comando.

Set-DatabaseAvailabilityGroupNetwork -Identity DAG1\DAGNetwork01 -ReplicationEnabled:$false

Tras deshabilitar la replicación para DAGNetwork01, el servicio de replicación de Microsoft Exchange utiliza DAGNetwork02 para la replicación continua. Si DAGNetwork02 experimenta una error, el servicio de replicación de Microsoft Exchange vuelve a usar DAGNetwork01 para la replicación continua. Esto lo hace intencionalmente el sistema para mantener la disponibilidad alta.

Implementaciones de varias subredes y redes de DAG

En el ejemplo anterior, aunque hay dos redes diferentes usadas por el DAG (192.168.1.0 y 10.0.0.0), el DAG se considera un DAG de subred simple ya que cada miembro utiliza la misma subred para formar la red MAPI. Cuando los miembros de DAG usan diferentes subredes para la red MAPI, el DAG es referido como un DAG de subredes múltiples. En un DAG de subredes múltiples, la configuración adicional de las redes DAG se deben realizar para asociar las subredes adecuadas con cada red DAG.

Por ejemplo, considere DAG2, un DAG de dos miembros donde cada miembro tiene dos adaptadores de red (uno dedicado para la red MAPI y otro para una red de replicación) y cada miembro de DAG está ubicado en un sitio de Active Directory separado, con su red MAPI en una subred diferente. Las configuraciones de dirección IP de ejemplo se muestran en la siguiente tabla.

Configuraciones del adaptador de red del ejemplo para un DAG en una subred múltiple

Adaptador de red del servidor Dirección IP/máscara de subred Puerta de enlace predeterminada

EX1-MAPI

192.168.0.15/24

192.168.0.1

Replicación de EX1

10.0.0.15/24

No aplicable

EX2-MAPI

192.168.1.15

192.168.1.1

Replicación de EX2

10.0.1.15

No aplicable

En la siguiente configuración, hay cuatro subredes configuradas en el DAG: 192.168.0.0, 192.168.1.0, 10.0.0.0, y 10.0.1.0. Cuando se agreguen EX1 y EX2 al DAG, se enumerarán cuatro subredes y se crearán dos redes de DAG: DAGNetwork01 (192.168.0.0), DAGNetwork02 (10.0.0.0), DAGNetwork03 (192.168.1.0), y DAGNetwork04 (10.0.1.0). Estas redes se configurarán como se muestra en la siguiente tabla.

Configuraciones de red DAG enumeradas para un DAG de subred múltiple

Nombre Subredes Interfaces Acceso a MAPI habilitado Replicación habilitada

DAGNetwork01

192.168.0.0/24

EX1 (192.168.0.15)

True

True

DAGNetwork02

10.0.0.0/24

EX1 (10.0.0.15)

False

True

DAGNetwork03

192.168.1.0/24

EX2 (192.168.1.15)

True

True

DAGNetwork04

10.0.1.0/24

EX2 (10.0.1.15)

False

True

Para completar la configuración necesaria, DAGNetwork03 y DAGNetwork04 se deben contraer en DAGNetwork01 y DAGNetwork02, respectivamente. Esto incluye agregar la subred asociada actualmente con DAGNetwork03 para DAGNetwork01, y agregar la subred asociada actualmente con DAGNetwork04 para DAGNetwork02. Esto quitará las asociaciones de la subred desde DAGNetwork03 y DAGNetwork04, dejándolas como redes de DAG vacías que se pueden quitar. Para contraer las subredes en dos redes de DAG y deshabilitar la replicación en la red MAPI, ejecute los siguientes comandos.

Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork01 -Subnets 192.168.0.0,192.168.1.0 -ReplicationEnabled:$false
Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork02 -Subnets 10.0.0.0,10.0.1.0
Remove-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork03
Remove-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork04

Redes del DAG y redes iSCSI

De forma predeterminada, los DAG encuentran todas las redes detectadas y configuradas para ser usadas según su clúster subyacente. Esto incluye todas las redes Internet SCSI (iSCSI) que se usan como resultado del uso del almacenamiento iSCSI para uno o más miembros del DAG. Se recomienda que el almacenamiento iSCSI use redes y adaptadores de red dedicados. Estas redes no deben ser administradas por el DAG ni por su clúster, ni deben usarse como redes del DAG (MAPI o replicación). En lugar de ello, estas redes deben ser manualmente deshabilitadas para que el DAG no las use, de modo que puedan dedicarse al tráfico de almacenamiento iSCSI. Para deshabilitar la detección de las redes iSCSI y su uso como redes de DAG, configure el DAG para que omita cualquier red iSCSI actualmente detectada usando el cmdlet Set-DatabaseAvailabilityGroupNetwork, como se muestra en el ejemplo siguiente:

Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork02 -ReplicationEnabled:$false -IgnoreNetwork:$true

Este comando también deshabilitará el uso de la red por parte del clúster. Si bien las redes iSCSI continuarán apareciendo como redes de DAG, no se usarán para tráfico de replicación o MAPI después de la ejecución del comando anterior.

Volver al principio

Configuración de los miembros DAG

Los servidores del buzón de correo que son los miembros de un DAG tienen propiedades específicas para alta disponibilidad que se pueden configurar como se describe en las siguientes secciones:

  • Marcación automática de montaje de base de datos

  • Directiva de activación automática de la copia de la base de datos

  • Bases de datos activas máximas

Marcación automática de montaje de base de datos

El parámetro AutoDatabaseMountDial especifica el montaje de la base de datos automático después de la falla de la base de datos. Puede usar el cmdlet Set-MailboxServer para configurar el parámetro AutoDatabaseMountDial con cualquiera de los siguientes valores:

  • BestAvailability   Si especifica este valor, la base de datos monta automáticamente tras un error si la longitud de la cola de copia es inferior o igual a 12. La longitud de la cola de copia es el número de registros reconocidos por la copia pasiva que debe replicarse. Si la longitud de la cola de copia es superior a 12, las bases de datos no se montan automáticamente. Cuando la longitud de la cola de copia es inferior o igual a doce, Exchange intentará replicar los registros restantes en la copia pasiva y montará la base de datos.

  • GoodAvailability   Si especifica este valor, las bases de datos se montarán de forma automática inmediatamente tras un error si la longitud de la cola de copia es inferior o igual a 6. La longitud de la cola de copia es el número de registros que la copia pasiva reconoce que deben replicarse. Si la longitud de la cola de copia es superior a seis, la base de datos no se monta automáticamente. Cuando la longitud de la cola de copia es inferior o igual a 6, Exchange intentará replicar los registros restantes en la copia pasiva y montará la base de datos.

  • Lossless   Si especifica este valor, la base de datos no se montará automáticamente hasta que todos los registros de la copia activa se hayan copiado en la copia pasiva. Esta configuración también causa el algoritmo de selección de copia del administrador activo para ordenar candidatos posibles para la activación basada en el valor de preferencia de activación de la copia de la base de datos y no en la longitud de la cola de la copia.

El valor predeterminado es GoodAvailability. Si especifica entre BestAvailability o GoodAvailability, y ninguno de los registros de la copia activa se pueden copiar en la copia pasiva, es posible que pierda parte de los datos del buzón. No obstante, la característica de la recuperación de elementos eliminados de transporte (habilitada de manera predeterminada) contribuye a proteger contra la pérdida de datos, al volver a enviar los mensajes en la cola del contenedor de transporte.

Además de los valores anteriores, también puede configurar el parámetro AutoDatabaseMountDial con un valor personalizado usando ADSI Edit o Ldp.exe para modificar directamente el atributo en Active Directory. El parámetro AutoDatabaseMountDial es presentado por el atributo msExchDataLossForAutoDatabaseMount del objeto del servidor del buzón de correo. El valor numérico completo de este atributo representa el número máximo de archivos de registro de transacción que desea perder para montar una base de datos sin intervención por parte del usuario. Si configura el parámetro AutoDatabaseMountDial con un valor personalizado mayor a 12, le recomendamos que también aumente el tamaño del volcado de archivos de transporte para permitir mayor protección contra una cantidad mayor de registros perdidos.

Ejemplo: Configuración del marcado automático de montaje de base de datos

El siguiente ejemplo configura un servidor de buzón de correo con una configuración AutoDatabaseMountDial de GoodAvailability.

Set-MailboxServer -Identity EX1 -AutoDatabaseMountDial GoodAvailability

Directiva de activación automática de la copia de la base de datos

El parámetro DatabaseCopyAutoActivationPolicy especifica el tipo de activación automática disponible para copias de bases de datos de buzones en los servidores de buzón seleccionados. Puede usar el cmdlet Set-MailboxServer para configurar el parámetro DatabaseCopyAutoActivationPolicy con cualquiera de los siguientes valores:

  • Blocked   Si especifica este valor, las bases de datos no pueden ser activadas automáticamente en los servidores de buzón seleccionados.

  • IntrasiteOnly   Si especifica este valor, la copia de la base de datos puede activarse en servidores en el mismo sitio de Active Directory. Esto impide activación o errores entre sitios. Esta propiedad es para ingresar copias de bases de datos del buzón (por ejemplo: una copia pasiva se transforma en una copia activa). Las bases de datos no pueden activarse en este servidor de buzones para copias de bases de datos que están activas en otro sitio de Active Directory.

  • Unrestricted   Si especifica este valor, no existen restricciones especiales de activación para copias de bases de datos de buzón de los servidores de buzón seleccionados.

Ejemplo: Configuración de la directiva de activación automática de la copia de la base de datos

El siguiente ejemplo configura un servidor de buzón de correo con una configuración DatabaseCopyAutoActivationPolicy de Blocked.

Set-MailboxServer -Identity EX1 -DatabaseCopyAutoActivationPolicy Blocked

Bases de datos activas máximas

El parámetro MaximumActiveDatabases (también usado con el cmdlet Set-MailboxServer) especifica el número de bases de datos que se puede montar en este servidor de buzón. Puede configurar los servidores del buzón de correo para cumplir con los requisitos de implementación al asegurar que un servidor de correo de voz individual no se sobrecargue.

El parámetro MaximumActiveDatabases está configurado con un valor numérico de número entero. Cuando se alcanza el número máximo, las copias de la base de datos en el servidor no se activarán si se produce un error o cambio. Si las copias ya están activas en un servidor, este no permite montar bases de datos.

Ejemplo: Configuración de las bases de datos activas máximas

El siguiente ejemplo configura un servidor de buzón de correo para que admita un máximo de 20 bases de datos activas.

Set-MailboxServer -Identity EX1 -MaximumActiveDatabases 20

Volver al principio

Realización del mantenimiento en los miembros DAG

Antes de realizar cualquier tipo de mantenimiento de software o hardware en un miembro de DAG, primero debe quitar el miembro de DAG del servicio usando la secuencia StartDagServerMaintenance.ps1. Esta secuencia saca a todas las bases de datos activas del servidor y bloquea a las bases de datos activas para que se muevan a ese servidor. La secuencia también asegura que toda la funcionalidad de compatibilidad de DAG crítico que pueda haber en el servidor (por ejemplo, el rol del administrador activo primario (PAM)) se mueva a otro servidor y se bloquee para que no vuelva al servidor. Concretamente, la secuencia StartDagServerMaintenance.ps1 realiza las siguientes tareas:

  • Ejecuta Suspend-MailboxDatabaseCopy con el parámetro ActivationOnly para suspender cada copia de base de datos alojada en el miembro del DAG para la activación.

  • Pausa el nodo en el clúster, el cual evita que el noto sea o se convierta en PAM.

  • Establece el valor del parámetro DatabaseCopyAutoActivationPolicy en el miembro DAG para Blocked.

  • Mueve todas las bases de datos activas alojadas actualmente en el miembro de DAG a otros miembros de DAG.

  • Si el miembro de DAG posee actualmente el grupo de clúster predeterminado, la secuencia mueve el grupo de clúster predeterminado (y por lo tanto el rol PAM) a otro miembro DAG.

Si cualquier de las anteriores tareas falla, se deshacen todas las operaciones excepto los movimientos correctos de la base de datos.

Tras completar el mantenimiento y cuando el miembro de DAG esté listo para volver al servicio, puede usar la secuencia StopDagServerMaintenance.ps1 para sacar al miembro de DAG fuera del modo de mantenimiento y volverlo a poner en la producción. Concretamente, la secuencia StopDagServerMaintenance.ps1 realiza las siguientes tareas:

  • Ejecuta el cdmlet Resume-MailboxDatabaseCopy para copia de la base de datos alojada en el miembro de DAG.

  • Reanuda el nodo en el clúster, el cual habilita la funcionalidad del clúster completo para el miembro de DAG.

  • Establece el valor del parámetro DatabaseCopyAutoActivationPolicy en el miembro DAG para Unrestricted.

Ambas secuencias aceptan el parámetro -ServerName (el cual puede ser el nombre del host o el nombre de dominio completo (FQDN) de un miembro de DAG) y el parámetro -WhatIf. Ambas secuencias se pueden ejecutar de forma local o remota. El servidor en el cual se ejecutan las secuencias debe tener instalada la herramienta Administración del clúster de conmutación por error (RSAT-Clustering) de Windows.

Volver al principio

Apagar los miembros de DAG

La solución de alta disponibilidad de Exchange 2010 está integrada con el proceso de apagado de Windows. Si un administrador o una aplicación inician el apagado de un servidor de Windows en un DAG con una base de datos montada que se replica en uno o más miembros del DAG, el sistema intentará activar otra copia de la base de datos montada antes de permitir que se complete el proceso de apagado.

Sin embargo, este nuevo comportamiento no garantiza que todas las bases de datos del servidor que se apaguen experimenten una activación lossless. Por lo tanto, el procedimiento recomendado es realizar una conmutación de servidor antes de apagar un servidor miembro de un grupo de disponibilidad de base de datos. Para obtener instrucciones detalladas acerca de cómo realizar un cambio de servidor, consulte Realizar un cambio de servidor.

Volver al principio

Instalación de paquetes acumulativos de actualizaciones en los miembros de DAG

La instalación de paquetes acumulativos de actualizaciones de Microsoft Exchange Server 2010 en un servidor que es miembro de un grupo de disponibilidad de base de datos (DAG) es un proceso relativamente directo. Al instalar un paquete acumulativo de revisiones en un servidor que es miembro de un DAG, se detienen varios servicios durante la instalación, incluidos todos los servicios de Exchange y el servicio de clúster. El proceso general para aplicar paquetes acumulativos de revisiones a un DAG es el siguiente:

  1. Use la secuencia StartDagServerMaintenance.ps1 para poner al miembro de DAG en el modo de mantenimiento.

  2. Instale el paquete acumulativo de revisiones.

  3. Use la secuencia StopDagServerMaintenance.ps1 para sacar al miembro de DAG del modo de mantenimiento y volver a ponerlo en la producción.

  4. Use la secuencia RedistributeActiveDatabases.ps1 para volver a equilibrar las copias de la base de datos en el DAG.

Puede descargar el paquete acumulativo de actualizaciones más reciente de Exchange 2010 en el Centro de descarga de Microsoft. Para obtener instrucciones detalladas sobre cómo instalar un paquete acumulativo de actualizaciones en un miembro de un DAG, consulte Instalación de paquetes acumulativos de actualizaciones en miembros de grupos de disponibilidad de base de datos.

Volver al principio

 © 2010 Microsoft Corporation. Reservados todos los derechos.