Administración de alta disponibilidad y resistencia de sitios
Se aplica a: Exchange Server 2013
Después de compilar, validar e implementar una solución de alta disponibilidad o resistencia del sitio de Microsoft Exchange Server 2013, la solución pasa de la fase de implementación a la fase operativa del ciclo de vida general de la solución. 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.
Administración del 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 DAG: la creación de un DAG suele ser un procedimiento único realizado 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 DAG: la administración de miembros del DAG es una tarea poco frecuente que normalmente se realiza 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 propiedades de DAG: cada DAG tiene varias propiedades que se pueden configurar según sea necesario. Entre estas propiedades se incluyen:
Servidor testigo y directorio de testigos: el servidor testigo es un servidor fuera del DAG que actúa como votante de cuórum cuando el 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 DAG tendrá una o más direcciones IPv4 y, opcionalmente, 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 del centro de datos: el modo de coordinación de activación del centro de datos es una configuración de propiedad en un DAG diseñada para evitar condiciones de cerebro dividido en el nivel de base de datos, en un escenario en el que se restaura el servicio en un centro de datos principal después de que se haya realizado una conmutación del centro de datos. Para obtener más información acerca del modo de coordinación de activación de centros de datos, consulte Modo de coordinación de activación de centro de datos.
Servidor testigo alternativo y directorio testigo alternativo: el servidor testigo alternativo y el directorio testigo alternativo son valores que puede preconfigurar como parte del proceso de planeación de un cambio de centro de datos. Se refieren al servidor testigo y al directorio testigo que se usarán cuando se realiza un cambio de centro de datos.
Puerto de replicación: de forma predeterminada, todos los DAG usan el puerto TCP 64327 para la replicación continua. Puede modificar el DAG para que use un puerto TCP diferente para la replicación mediante el parámetro ReplicationPort del cmdlet Set-DatabaseAvailabilityGroup .
Detección de redes: puede forzar que el DAG vuelva a detectar redes e interfaces de red. Esta operación se usa cuando se agregan o quitan redes, o cuando se introducen nuevas subredes. La detección de todas las redes dag se puede forzar mediante el parámetro DiscoverNetworks del cmdlet Set-DatabaseAvailabilityGroup .
Compresión de red: de forma predeterminada, los DAG usan la compresión solo entre redes DAG en subredes diferentes. 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 DAG usan el cifrado solo entre redes DAG en subredes diferentes. 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.
Apagar miembros del DAG: la solución de alta disponibilidad de Exchange 2013 se integra con el proceso de apagado de Windows. Si un administrador o una aplicación inician el apagado de un servidor 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 las bases 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 va a apagar experimenten una activación sin pérdida. 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 base de datos. Para obtener instrucciones detalladas sobre cómo configurar DAG y las propiedades de un DAG, consulte Configurar las propiedades del grupo de disponibilidad de 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 Managing database availability groups.
Administración de copias de base de datos de buzones de correo
Las tareas de administración operativa asociadas con las copias de base de datos de buzones incluyen:
Agregar copias de base de datos de buzones: al agregar una copia de una base de datos de buzón de correo, la replicación continua se habilita automáticamente entre la base de datos existente y la copia de la base de datos.
Configuración de propiedades de copia de base de datos de buzón: puede configurar una variedad de propiedades, como la directiva de activación de la base de datos, la cantidad de tiempo, si existe, para el retraso de reproducción y el retraso de truncamiento, y la preferencia de activación para la copia de la base de datos.
Suspender o reanudar una copia de base de datos de buzón de correo: puede suspender una copia de base de datos de buzón de correo como preparación para la propagación o para otras formas 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 buzón: la actualización, también conocida como propagación, es el proceso en el que se agrega una copia de una base de datos de buzón de correo 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.
Activación de una copia de base de datos de buzón de correo: la activación es el proceso de designar una copia pasiva específica como la nueva copia activa de una base de datos de buzón de correo. 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 buzón: puede quitar una copia de base de datos de buzón en cualquier momento. En ocasiones, puede que sea necesario quitar una copia de una base de datos de buzones de correo. Por ejemplo, no puede quitar un servidor de buzones de un DAG hasta que se eliminen del servidor todas las copias de bases de datos de buzones. Además, tiene que quitar todas las copias de una base de datos de buzones de correo antes de cambiar la ruta de una base de datos de buzones.
Para obtener más información sobre cómo agregar una copia de base de datos de buzones, consulte Adición de una copia de base de datos de buzones. Para obtener instrucciones detalladas acerca de cómo configurar copias de bases de datos de buzones, consulte Configuración de las propiedades de una copia de 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 Managing mailbox database copies. Para obtener más información sobre cómo quitar una copia de base de datos de buzones, consulte Eliminación de una copia de base de datos de buzones.
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 2013 incluye una serie de características que se pueden usar para realizar una variedad de tareas de supervisión de estado para los DAG y las copias de base de datos de buzones de correo, entre las que se incluyen:
Registro de eventos de canal Crimson
Además de supervisar el mantenimiento y el estado, también es importante 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 grupos de disponibilidad de base de datos.
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 un cambio de base de datos, consulte Activación de una copia de base de datos de buzones. Los cambios se pueden realizar en los centros 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 en un entorno sin RAID desencadenará un error de la 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.