Compartir a través de


Administración de la alta disponibilidad y la resistencia de sitios

 

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

Última modificación del tema: 2010-05-06

Tras construir, validar e implementar una solución de alta disponibilidad y resistencia de sitios de Microsoft Exchange Server 2010, la solución pasa de la fase de implementación a la fase operativa dentro del ciclo de vida general de la misma. La fase operativa consta de varias tareas, todas ellas relacionadas con una de las áreas siguientes: grupos de disponibilidad de base de datos (DAG), copias de bases de datos de buzones, supervisión proactiva de rendimiento y administración de conmutación y conmutación por error.

La administración de una solución de alta disponibilidad y resistencia de sitios de Exchange 2010 se realiza de un modo distinto que en versiones anteriores de Exchange. Se han aplicado varios cambios en la arquitectura y el diseño de Exchange 2010 que eliminan la necesidad de realizar tareas que eran necesarias en versiones anteriores de Exchange, y que proporcionan mayor granularidad y control de la solución. Por ejemplo:

  • Exchange 2010 no usa el concepto de servidor de buzones en clúster (conocido como Exchange Virtual Server en Exchange Server 2003 y versiones anteriores). Por lo tanto, Exchange ya no es una aplicación en clúster y las identidades del servidor de Exchange ya no se mueven entre servidores en clúster.

  • Exchange 2010 no usa el concepto de grupos de almacenamiento. Por lo tanto, las bases de datos dejan de estar asociadas a los servidores y se administran de forma global, tampoco comparten secuencias de registros, y la replicación continua (incluidas las conmutaciones y conmutación por error) operan en la base de datos.

  • Exchange 2010 no usa los conceptos de redes públicas y privadas. Estos conceptos se han sustituido por los de redes MAPI y redes de replicación. Cada grupo de disponibilidad de base de datos debe contener una red MAPI y una o más redes de replicación.

Contenido

Administración de grupo de disponibilidad de base de datos

Administración de copias de bases de datos de buzones

Supervisión proactiva

Cambios y conmutaciones por error

Administración de grupo de disponibilidad de base de datos

Las tareas de administración operativa asociadas a los grupos de disponibilidad de base de datos incluyen:

  • Creación de uno o más grupos de disponibilidad de base de datos   La creación de un grupo de disponibilidad de base de datos suele ser un procedimiento que se realiza una vez durante la fase de implementación del ciclo de vida de la solución. Sin embargo, durante la fase operativa puede haber muchos motivos para crear grupos de disponibilidad de base de datos (DAG). Por ejemplo:

    • El DAG está configurado para el modo de replicación de otros fabricantes y desea volver a usar la replicación continua. No se puede cambiar un DAG para la replicación continua; es necesario crear un grupo nuevo.

    • Tiene servidores en varios dominios. Todos los miembros de un DAG deben ser también miembros del mismo dominio.

  • Administración de la pertenencia a un grupo de disponibilidad de base de datos   Administrar miembros de un grupo de disponibilidad de base de datos (DAG) es una tarea que se realiza en raras ocasiones durante la fase de implementación del ciclo de vida de la solución. Sin embargo, debido a la flexibilidad que aporta la implementación incremental, también se puede administrar la pertenencia a grupos de disponibilidad de base de datos a lo largo del ciclo de vida de la solución.

  • Configuración de las propiedades de un grupo de disponibilidad de base de datos   Cada grupo de disponibilidad de base de datos (DAG) dispone de varias propiedades que pueden configurarse según sea necesario. Entre estas propiedades se incluyen:

    • Servidor testigo y directorio testigo   El servidor testigo es un servidor externo al grupo de disponibilidad de base de datos (DAG) que actúa como votante de quórum cuando un DAG contiene un número par de miembros. El directorio testigo es un directorio creado y compartido en el servidor testigo que usa el sistema para mantener un quórum.

    • Direcciones IP   Cada grupo de disponibilidad de base de datos dispone de una o más direcciones IPv4 y, opcionalmente, de una o más direcciones IPv6. Las direcciones IP asignadas al DAG las usa el clúster subyacente del DAG. El número de direcciones IPv4 asignadas al DAG es igual al número de subredes que componen la red MAPI que usa el DAG. Puede configurar el DAG para que use direcciones IP estáticas, o bien obtener direcciones de forma automática mediante el Protocolo de configuración dinámica de host (DHCP).

    • Modo de coordinación de activación de bases de datos   El modo de coordinación de activación de bases de datos es una propiedad del DAG que está diseñada para grupos de disponibilidad con tres o más miembros implementados en varios sitios. El modo de coordinación de activación de bases de datos se usa para controlar las condiciones que de otro modo provocarían un síndrome de cerebro dividido en el DAG, como sería un error de sitio. Para obtener más información acerca del modo de coordinación de activación de bases de datos, consulte Descripción del modo de coordinación de activación de centros de datos.

    • Servidor testigo alternativo y directorio testigo alternativo   El servidor testigo alternativo y el directorio testigo alternativo son valores que se pueden preconfigurar como parte del proceso de planeación de los grupos de disponibilidad de base de datos configurados para la resistencia a sitios.

    • Puerto de replicación   De forma predeterminada, todos los grupos de disponibilidad de base de datos usan el puerto TCP 64327 para la replicación continua. Puede modificar el grupo de disponibilidad de base de datos para que use otro puerto TCP para la replicación mediante el parámetro ReplicationPort del cmdlet Set-DatabaseAvailabilityGroup.

    • Detección de redes   Puede forzar a un grupo de disponibilidad para que detecte redes e interfaces de red. Esta operación se usa cuando se agregan o quitan redes, o bien se cambian subredes de DAG. Se puede forzar que se vuelvan a detectar las redes de DAG mediante el parámetro DiscoverNetworks del cmdlet Set-DatabaseAvailabilityGroup.

    • Compresión de red   De forma predeterminada, los grupos de disponibilidad de base de datos usan compresión solamente entre redes DAG de diferentes subredes. Puede habilitar la compresión de todas las redes DAG o solo para operaciones de propagación, o bien puede deshabilitar la compresión de todas las redes DAG.

    • Cifrado de red   De forma predeterminada, los grupos de disponibilidad de base de datos usan cifrado solamente entre redes DAG de diferentes subredes. Puede habilitar el cifrado de todas las redes DAG o solo para operaciones de propagación, o bien puede deshabilitar el cifrado de todas las redes DAG.

  • Administración de redes DAG   Aunque se admite el uso de una única tarjeta de interfaz de red (NIC), recomendamos que cada miembro de un grupo de disponibilidad de base de datos disponga de al menos dos NIC. Una NIC se usa para la red MAPI y la otra para la red de replicación. El resto de tarjetas NIC se pueden agregar para crear más redes de replicación, para usarlas en redes de copia de seguridad dedicadas, o para usarlas en el sistema como almacenamiento SCSI en Internet. La administración de redes DAG implica la designación de una red como la red MAPI o como red de replicación, así como la configuración de subredes.

  • Apagado de miembros de grupos de disponibilidad de base de datos   La solución de alta disponibilidad de Exchange 2010 está integrada en el proceso de apagado de Windows. Si un administrador o una aplicación procede a apagar un servidor de Windows en un grupo de disponibilidad de base de datos con una base de datos montada que se ha replicado en uno o más miembros de DAG, el sistema intentará activar otra copia de las bases de datos montadas 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 van a apagar vayan a experimentar una activación sin pérdidas. Por lo tanto, es mejor 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 crear un grupo de disponibilidad de base de datos, consulte Crear un grupo de disponibilidad de la base de datos. Para obtener instrucciones detalladas acerca de cómo configurar grupos de disponibilidad de base de datos y sus propiedades, consulte Configurar las propiedades del grupo de disponibilidad de la base de datos. Para obtener más información acerca de cada una de las tareas anteriores, y sobre la administración de grupos de disponibilidad de base de datos en general, consulte Administración de grupos de disponibilidad de base de datos.

Volver al principio

Administración de copias de bases de datos de buzones

Las tareas de administración operativa asociadas con las copias de base de datos de buzones incluyen:

  • Agregar copias de bases de datos de buzones   Cuando agrega una copia a la base de datos de buzones, se habilita automáticamente la replicación continua entre la base de datos existente y la copia de la base de datos.

  • Configurar las propiedades de la copia de base de datos de buzones   Puede configurar diferentes propiedades como, por ejemplo, la directiva de activación de base de datos, el periodo de retardo de reproducción y truncamiento (si lo hubiera) y la preferencia de activación para la copia de base de datos.

  • Suspender o reanudar una copia de base de datos de buzones   Puede suspender una copia de base de datos de buzones que se esté preparando para la propagación, o para otro tipo de tarea de mantenimiento. También puede suspender una copia de base de datos de buzones solo para activación. Esta configuración evita que el sistema active automáticamente la copia como resultado de un error, pero permite que el sistema mantenga actualizada la copia de la base de datos con respecto al envío y la reproducción de registros.

  • Actualizar una copia de base de datos de buzones   La actualización, también denominada propagación, es el proceso en el que se agrega una base de datos de buzones a otro servidor de buzones. Se convierte en la base de datos de línea de base para la copia. Tras la propagación inicial de la línea de base de la copia de base de datos, no será necesario volver a propagar la base de datos, salvo raras excepciones.

  • Activar una copia de base de datos de buzones   La activación de una copia de base de datos de buzones consiste en designar una determinada copia pasiva como la nueva copia activa de una base de datos de buzones. Se hace referencia a este proceso como conmutación. Para obtener más información, consulte "Conmutaciones y conmutaciones por error" más adelante en este tema.

  • Quitar una copia de base de datos de buzones   Puede quitar una copia de base de datos de buzones en cualquier momento. En ocasiones, puede ser necesario quitar una copia de una base de datos de buzones. Por ejemplo, no puede quitar un servidor de buzones de un grupo de disponibilidad de base de datos hasta que todas las copias de bases de datos de buzones se hayan eliminado del servidor. Además, debe quitar todas las copias de una base de datos de buzones antes de cambiar la ruta de una base de datos de buzones.

Para obtener instrucciones detalladas acerca de cómo agregar una copia de base de datos de buzones, consulte Agregar una copia de la base de datos de buzones. Para obtener instrucciones detalladas acerca de cómo configurar copias de bases de datos de buzones, consulte Configurar las propiedades de la copia de la base de datos de buzones. Para obtener más información acerca de cada una de las tareas anteriores, y sobre la administración de copias de bases de datos de buzones en general, consulte Administrar copias de base de datos de buzones. Para obtener instrucciones detalladas acerca de cómo quitar una copia de base de datos de buzones, consulte Quitar una copia de base de datos de buzones.

Volver al principio

Supervisión proactiva

Asegurarse de que los servidores funcionan de forma confiable y que las copias de base de datos están en buen estado son los objetivos clave para las operaciones diarias de mensajería. Exchange 2010 incluye una serie de características que se pueden usar para realizar diferentes tareas de supervisión de mantenimiento en grupos de disponibilidad de base de datos y copias de bases de datos de buzones, incluidas las siguientes:

Además de supervisar el mantenimiento y el estado, es fundamental supervisar las situaciones que pueden poner en peligro la disponibilidad. Por ejemplo, se recomienda que supervise la redundancia de las bases de datos replicadas. Esto es fundamental para evitar situaciones en las que solamente dispone de una copia de una base de datos. Este escenario debe tratarse con la máxima prioridad y resolverse lo antes posible.

Para obtener información detallada acerca de cómo supervisar el estado y el mantenimiento de grupos de disponibilidad de base de datos y copias de bases de datos de buzones, consulte Supervisión de la alta disponibilidad y la resistencia de sitios.

Volver al principio

Cambios y conmutaciones por error

Una conmutación es un proceso manual en el que un administrador activa una o más copias de una base de datos de buzones. Estas conmutaciones, que se pueden producir en la base de datos o en el servidor, suelen realizarse como parte de la preparación de actividades de mantenimiento. La administración de las conmutaciones implica realizar conmutaciones en bases de datos y servidores, según sea necesario. Por ejemplo, si necesita realizar el mantenimiento en un servidor de buzones de un grupo de disponibilidad de base de datos, primero haría una conmutación de servidor para que el servidor no hospede ninguna copia de base de datos activa. Para obtener instrucciones detalladas acerca de cómo realizar una conmutación de base de datos, consulte Activar una copia de la base de datos de buzones. Para obtener instrucciones detalladas acerca de cómo realizar una conmutación de servidor, consulte Realizar un cambio de servidor. Los cambios se pueden realizar en los centros de datos. Para obtener más información acerca de las conmutaciones de centros de datos, consulte Cambios en el centro de datos.

Una conmutación por error es la activación automática por parte del sistema de una o más copias de base de datos en respuesta a un error. Por ejemplo, la pérdida de una unidad de disco desencadenará un fallo de base de datos. La pérdida de la red MAPI o una conmutación por error de energía desencadenarán una conmutación por error de servidor.

Para obtener más información acerca de las conmutaciones y conmutaciones por error, consulte Cambios y conmutaciones por error.

Volver al principio

 © 2010 Microsoft Corporation. Reservados todos los derechos.