Administrar grupos de disponibilidad de base de datos

Se aplica a: Exchange Server 2010

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

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 proporciona recuperación automática de nivel de base de datos desde una base de datos, un servidor o un error de red. Los DAG usan replicación continua y un subconjunto de tecnologías de clúster de conmutación por error de Windows para proporcionar disponibilidad continua de buzones de correo. Los servidores de buzones de correo de un DAG se monitorean entre sí en busca de 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

Creación de grupos de disponibilidad de base de datos

Pertenencia a un grupo de disponibilidad de base de datos

Configuración de las propiedades del grupo de disponibilidad de base de datos

Redes de grupos de disponibilidad de base de datos

Cancelación de miembros del grupo de disponibilidad de base de datos

Instalación de paquetes acumulativos de actualizaciones para miembros del grupo de disponibilidad de bases de datos

Creación de 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 DatabaseAvailablityGroupIpAddresses. Si omite este parámetro, el DAG intentará 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 usan un subconjunto de tecnologías 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 o que pueden cambiar rápidamente, como los cambios de estado de las bases de datos de activo a pasivo, o viceversa, o de montado a desmontado, o viceversa). Dado que los DAG se basan en los clústeres de conmutación por error de Windows, solo es posible crearlos en servidores de buzones de correo de Exchange 2010 que ejecutan el sistema operativo Windows Server 2008 Enterprise o Windows Server 2008 R2 Enterprise.

Directorio testigo y servidor testigo del grupo de disponibilidad de base de datos

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 solo para fines de quórum cuando la cantidad de miembros del DAG es par. No es necesario crear un directorio testigo por adelantado. Exchange creará automáticamente y protegerá 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 ejecutar Windows Server 2008 R2, Windows Server 2008, Windows Server 2003 R2 o Windows Server 2003.
• Un único servidor puede actuar como testigo para varios DAG; no obstante, 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.

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 servidor sin perder quórum, se tendrían que producir errores en tres miembros 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).

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 considerará 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 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 buscará un servidor de transporte de concentradores que no tenga instalado el rol de servidor Buzón de correo y creará automáticamente el directorio predeterminado (%SystemDrive%:\DAGFileShareWitnesses\<DAGFQDN>) y el recurso compartido predeterminado (<DAGFQDN>) en dicho servidor. Además, usará 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 crea 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 buscará un servidor de transporte de concentradores que no tenga instalado el rol de servidor Buzón de correo y creará automáticamente el DAG especificado en dicho servidor, compartirá el directorio y usará ese servidor de transporte de concentradores como servidor testigo.

Cuando se forma un DAG, éste inicialmente usa 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 quó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 red de clústeres (CNO) para el DAG.

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 cerrará con un error. Si especifica un servidor testigo y no especifica un directorio testigo, obtendrá el siguiente error:

Si especifica un servidor testigo y un directorio testigo, obtendrá la siguiente advertencia:

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 mostrará la siguiente advertencia:

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

• Cree previamente el directorio testigo y el recurso compartido en el servidor testigo
• Habilite la excepción de WMI en Firewall de Windows
• Deshabilite Firewall de Windows

Volver al principio

Pertenencia a un grupo de disponibilidad de base de datos

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-DatabaseAvailbilityGroupServer o Remove-DatabaseAvailbilityGroupServer 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.

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) instalará 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.
• Se crea un objeto de red de clústeres (CNO) en el contenedor de equipos predeterminado.
• El nombre y la dirección IP del DAG se registran como Host (A) en 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 parecerá 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 nuevos 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.

Preconfiguración del objeto de la red 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.

Como se indicó anteriormente, 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.

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 sobre la cuenta de equipo a la cuenta de equipo del primer buzón de correo que 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 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 Ensayar el objeto de red de clúster para un grupo de disponibilidad de base de datos.

Eliminación de servidores de un grupo de disponibilidad de base de datos

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-DatabaseAvailbilityGroupServer 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 producirá un error en la tarea.

Existen ciertos 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 producirá un error en la tarea.

Volver al principio

Configuración de las propiedades del grupo de disponibilidad de base de datos

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 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 del grupo de disponibilidad de base de datos, consulte Configurar las propiedades del grupo de disponibilidad de la base de datos.

Cifrado de red de grupos de disponibilidad de base de datos

Los DAG admiten el uso de cifrado mediante el aprovechamiento de las capacidades de cifrado del sistema operativo de Windows Server. Los DAG usan la autenticación Kerberos entre servidores de Exchange. Los API EncryptMessage/DecryptMessage del proveedor de compatibilidad para seguridad (SSP) de Microsoft Kerberos manejan el cifrado del tráfico de red del DAG. El SSP de Microsoft Kerberos admite varios algoritmos de cifrado. (Para ver la lista completa, consulte la sección de referencia 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

Compresión de red de grupos de disponibilidad de base de datos

Los DAG también 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 Algoritmo LZ77 y la sección de referencia 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

Volver al principio

Redes de grupos de disponibilidad de base de datos

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. 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. 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. Puede crear redes adicionales en un DAG y configurarlas como redes de replicación para redundancia.

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 sobre cómo crear una red del DAG, 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 del 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 IPv4; 2001:DB8:0:C000::/64 para subredes 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.

Redes del DAG y redes iSCSI

De forma predeterminada, los DAG encontrarán 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 tarjetas de interfaz de red dedicadas. 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, deben ser manualmente deshabilitadas para que el DAG no las use, de modo que puedan dedicarse al tráfico de almacenamiento iSCSI. Se deben realizar dos pasos para deshabilitar la detección de redes iSCSI y su uso como redes del DAG:

1. Configure el DAG para que omita las redes iSCSI detectadas actualmente mediante el cmdlet Set-DatabaseAvailabilityGroupNetwork, como se muestra en el ejemplo.

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

2. Deshabilite la red para que el clúster no la use mediante la ejecución del siguiente comando desde un símbolo del sistema con privilegios elevados o desde la ventana PowerShell. (Ejecute Cluster network para mostrar los nombres de las redes del clúster).

   Cluster network ClusterNetworkName /prop Role=0
   

Después de deshabilitar todas las redes iSCSI para que el DAG y su clúster no las usen, puede forzar de forma opcional la detección de redes mediante la ejecución del cmdlet Set-DatabaseAvailabilityGroup con el parámetro DiscoverNetworks. Si alguna red iSCSI continúa apareciendo como red del DAG, quite todas las subredes de la red y, a continuación, elimine la red del DAG.

Volver al principio

Cancelación de miembros del grupo de disponibilidad de base de datos

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 sin pérdida de información. 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 una conmutación de servidor, consulte Realizar un cambio de servidor.

Volver al principio

Instalación de paquetes acumulativos de revisiones en miembros de grupos de disponibilidad de base de datos

La instalación de paquetes acumulativos de revisiones 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 detendrán varios servicios durante la instalación, incluidos todos los servicios de Exchange y el servicio de clúster de Windows. El proceso general para aplicar paquetes acumulativos de revisiones a un DAG es el siguiente:

• Realice un cambio de servidores para que todas las bases de datos del servidor sean copias pasivas.
• Suspenda la activación de las bases de datos en el servidor que se está actualizando.
• Instale el paquete acumulativo de revisiones.
• Reanude la activación de las bases de datos en el servidor actualizado.
• Realice cambios de bases de datos según sea necesario.

Puede descargar el paquete acumulativo de revisiones más reciente para Exchange 2010 en el Centro de descarga de Microsoft. Para obtener instrucciones detalladas sobre cómo instalar un paquete acumulativo de revisiones 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