Cortes programados y no programados

Se aplica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Última modificación del tema: 2007-10-29

Las interrupciones programadas y no programadas son dos formas de interrupciones en un entorno de replicación continua en clúster (CCR). Las interrupciones programadas las inicia el administrador explícitamente para recuperar un error o para realizar una operación de mantenimiento. Las interrupciones no programadas son eventos inesperados que hacen que los datos, los servicios o ambos no estén disponibles. La replicación continua en clúster está diseñada para controlar las interrupciones programadas y las no programadas.

Interrupciones programadas

La CCR permite programar una interrupción de sistema prolongada de un nodo específico sin necesidad de interrumpir por un tiempo prolongado el servidor de buzones de correo en clúster. La funcionalidad de cortes programados de CCR garantiza que todos los datos de registro del nodo activo se copian correctamente en el nodo pasivo. Como consecuencia, las interrupciones programadas son siempre sin pérdida de datos, aunque la replicación se produzca de forma asincrónica. Los errores, y la conmutación por errores resultante, pueden hacer que datos de registro muy recientes no estén disponibles en el nodo pasivo en el momento de entrar en línea.

En un entorno de CCR, los nodos sólo se pueden desconectar de uno en uno. Si se desconecta más de uno, se producirá una interrupción en el servicio. En cualquier momento determinado, se pueden desconectar tanto el nodo pasivo en el clúster de conmutación por error como el equipo que hospeda el recurso compartido de archivos para el quórum de conjunto de nodos mayoritario (MNS) con el testigo de recurso compartido de archivos, con el fin de llevar a cabo la revisión, actualización y reparaciones del software o hardware. Se recomienda no bajar nunca un nodo sin comprobar primero si está activo o si hospeda recursos. Puede determinar si hospeda recursos con el Administrador de clústeres. Si desea comprobar el estado del nodo, ejecute el cmdlet Get-ClusteredMailboxServerStatus en el Shell de administración de Exchange. Para obtener más información acerca de la visualización del estado de un CMS, consulte Cómo ver el estado de un servidor de buzón en clústeres.

Tareas administrativas

Las interrupciones programadas las inicia el administrador explícitamente para recuperar un error o para realizar una operación de mantenimiento. Una interrupción programada permite al sistema mover el CMS del nodo activo al pasivo (de manera que el nodo pasivo se convierte en el nuevo nodo activo), y montar las bases de datos y los grupos de almacenamiento replicados. Una vez montadas, las bases de datos se convierten en una fuente de todas las actualizaciones subsiguientes para cualquier otra replicación. Las dos copias intercambian las funciones de replicación, cuya copia produce los cambios en la base de datos, a la vez que los recibe y aplica.

Como la CCR usa replicación asincrónica, la transición del CMS activo de un nodo en el clúster a otro nodo en el clúster requiere coordinación ente el clúster y el soporte de replicación. La replicación continua en clúster implementa esta coordinación. El administrador inicia una interrupción programada con el cmdlet Move-ClusteredMailboxServer del Shell de administración de Exchange.

El cmdlet Move-ClusteredMailboxServer comprueba que el nodo pasivo tenga una copia válida y en buen estado. Además, comprueba que la copia sea relativamente actual. Si la copia no es muy actual, la interrupción se podría mantener mientras se completa la replicación. Si estas comprobaciones son correctas, se iniciará la transición. Si no hay ningún error durante la operación de movimiento, la tarea finaliza cuando el CMS ejecuta el nodo seleccionado y todas las bases de datos se montan. Se pueden producir errores durante este proceso que pueden impedir la transición o afectar al montaje automático de todas las bases de datos. Si eso ocurre, se produce el comportamiento de la interrupción no programada.

Bajo algunas condiciones, las interrupciones programadas se usan para recuperar servidores dañados parcialmente. Un ejemplo es un servidor con una base de datos o archivos de registro dañados. En este caso, la lógica de enviar registros a través del sistema de replicación bloquea el cmdlet Move-ClusteredMailboxServer. El administrador tiene una opción simple para administrar este escenario. El administrador desmonta las bases de datos problemáticas y aplica el comando Move-ClusteredMailboxServer con una opción que intenta copiar los archivos asociados con las bases de datos desmontadas, pero que no tiene problemas en el traslado si todos los registros no se pueden copiar. El resultado es que la recuperación, incluso la de un grupo de almacenamiento dañado, se consigue fácilmente con el cmdlet Move-ClusteredMailboxServer.

El cmdlet Move-ClusteredMailboxServer permite que un administrador registre la razón para iniciar el traslado. Esta razón se coloca en el registro de eventos. El comando también obliga a que el administrador especifique el nodo que debe hospedar el CMS. De este modo, se evita que los administradores muevan erróneamente el CMS cuando esté hospedado correctamente.

La interfaz de administración línea de comandos Cluster.exe y la interfaz gráfica de usuario de administrador de clústeres (GUI) incluyen la capacidad de mover un CMS. El uso de estos métodos desencadena la lógica de vaciado de replicación. Sin embardo, es recomendable que no use estos métodos por las siguientes razones:

• Estos métodos no validan el estado de la copia pasiva. Por eso, su uso puede provocar una interrupción extendida mientras el nodo realiza las operaciones para que la base de datos se pueda montar.

• Estos métodos también pueden dejar a la base de datos indefinidamente sin conexión, porque la replicación se ha interrumpido.

Restablecimiento de la actividad de replicación tras una interrupción programada

El proceso para restablecer un entorno de CCR tras el corte programado de un nodo activo consiste en reiniciar el nodo. La replicación se inicia automáticamente con el inicio del sistema. Hay dos casos que se deben tener en consideración:

• La interrupción programada se ha completado correctamente, sin errores durante la transición asociada con la interrupción programada, y todas las bases de datos se han conectado automáticamente. En este caso, el administrador ha realizado la interrupción programada de forma que se garantice que ambos nodos tengan grupos de almacenamiento y bases de datos coherentes. El resultado es que el nodo puede aparecer inmediatamente y continuar con la replicación. Se puede actualizar la copia mediante la reproducción de los archivos de registro. No se requiere ninguna acción en especial.

• La interrupción programada sólo se ha completado correctamente en parte o algunas bases de datos estaban dañadas antes de la misma. En este caso, la interrupción programada no ha podido asegurar que todos los registros de origen estén disponibles para el destino antes de que se montaran sus bases de datos. Esto suele ocurrir como resultado de un error, bien antes de la interrupción programada, o después, durante la operación de la misma. Por tanto, las bases de datos de origen y de destino no son coherentes. En algunos casos, la replicación continua asociada puede recuperar automáticamente algunas incoherencias. Si es así, la replicación empezará y procesará todos los registros disponibles. Si la replicación no puede recuperarse automáticamente, marcará la copia como interrumpida y generará un evento indicando el problema. En caso de que el almacenamiento sea viable, la acción de recuperación primaria se reenviará a al copia. Para obtener más información acerca del procedimiento para corregir estos problemas, consulte Cómo incializar una copia de replicación continua de clústeres.

Interrupciones no programadas

Las interrupciones no programadas ocurren como una respuesta automática del sistema a algunos tipos de errores. La replicación continua en clúster se centra en la recuperación automática donde hay un alto grado de confianza que la en disponibilidad mejorará y en que la mayoría de entornos desearían la recuperación automática.

Una interrupción no programada permite que el sistema active el servidor de buzones en un nodo pasivo, haciéndolo activo, y montar las bases de datos replicadas y los grupos de almacenamiento. Una vez montadas, las bases de datos se convierten en una fuente de todas las actualizaciones subsiguientes para cualquier otra replicación. Las dos copias intercambian las funciones de replicación, cuya copia produce los cambios en la base de datos, a la vez que los recibe y aplica.

Como la CCR usa una replicación asincrónica, una interrupción no programada significa que se producirá pérdida de datos. Como mínimo, en los registros que el servidor activo esté escribiendo no se podrán recuperar las actividades. CCR corrige este problema proporcionando control administrativo del comportamiento de la conmutación por error y una característica para ayudar a reclamar el grueso de los datos que probablemente resultarían afectados.

Cuando se produce una conmutación por error, CCR siempre activa el servidor de correo en el nodo pasivo restante. Los controles del sistema se asocian con las bases de datos montadas en el nodo activo en este momento. La CCR proporciona controles administrativos para dictar si las bases de datos están montadas. La posición predeterminada es Máxima disponibilidad. En esta posición, el sistema montará automáticamente todas las bases de datos que estén sincronizadas con la base de datos de producción activa anterior. Máxima disponibilidad permite más variaciones en la incoherencia entre las dos copias. Buena disponibilidad conectaría una base de datos si durante el tiempo que se tardó en generar un registro nuevo se replica el último registro generado. Lossless garantiza que la copia no entrará en línea a no ser que se pueda confirmar que no se perderán datos. Si se usa Lossless, no se producirá una recuperación automática cuando el servidor original vuelva a estar operativo y los datos de registro están disponibles y no se dañan.

Si una o más bases de datos están en una condición en la que el ajuste no las monta automáticamente, el administrador puede decidir explícitamente montar la copia con su contenido disponible. El administrador debe comprobar el estado de la copia y emitir dos comandos. El primer comando informa al motor de replicación de que esta copia se debería convertir en una fuente de replicación (fuente de cambios), es decir, la copia se debería poder montar. El segundo comando monta la base de datos.

Para obtener más información acerca de la recuperación de daños o errores con replicación continua en clúster activada, consulteAdministración de la replicación continua agrupada.

Controles administrativos

Se proporcionan controles administrativos para controlar el comportamiento en caso de interrupción no programada. La CCR proporciona un atributo para servidores de buzones que puede usar para controlar el comportamiento de recuperación de las interrupciones no programadas. El atributo, AutoDatabaseMountDial, tiene tres valores posibles: Lossless, Buena disponibilidad y Máxima disponibilidad.

• Lossless   Lossless significa que no se ha perdido ningún registro. Cuando el atributo se define en Lossless, en la mayoría de circunstancias el sistema espera al nodo que ha dado error para volver a estar en línea antes de que se monten las bases de datos. Incluso el sistema con errores debe volver con todos los registros accesibles y no dañados. Después del error, el nodo pasivo pasa a activo y el servicio de Almacén de información de Microsoft Exchange entra en línea. A continuación, comprueba si las bases de datos se pueden montar sin pérdida de datos. Si se puede, las bases de datos se montan. Si no, el sistema intenta copiar los registros periódicamente. Si el servidor vuelve con sus registros intactos, este intento finalmente se realizará correctamente, y la base de datos se montará. Si el servidor vuelve sin sus registros intactos, los registros restantes no estarán disponibles, y las bases de datos afectadas no se montarán.

  Nota

  En cualquier momento después de haber concluido la conmutación por error, un administrador puede interceder y decidir montar usando las bases de datos y los registros disponibles en el nodo pasivo anterior. Esta tarea se realiza con un simple proceso de dos pasos. Probablemente la decisión del administrador de interceder se basa en un análisis de la cantidad de tiempo necesaria para hacer que el servidor original sea operativo. La coherencia de la replicación entre los dos nodos en el momento del error y la urgencia de que el cliente tenga acceso a su servidor son factores que forman parte de este análisis.

• Buena disponibilidad   Buena disponibilidad significa que se han perdido tres registros. Buena disponibilidad proporciona una recuperación totalmente automática cuando la replicación funciona normalmente y se registra a medida que se generan los registros.

• Máxima disponibilidad   Máxima disponibilidad significa que se han perdido seis registros. Esta es la configuración predeterminada. Máxima disponibilidad funciona de forma similar a Buena disponibilidad, pero permite la recuperación automática cuando la replicación experimenta una latencia ligeramente superior. De ese modo, el nuevo nodo activo podría estar algo retrasado con respecto al antiguo nodo activo después de la conmutación por error, lo que incrementaría la probabilidad de que se dieran divergencias en la base de datos y requeriría un reinicio total para corregirlo.

Para obtener más información acerca del comportamiento de la administración de la recuperación, consulte Cómo ajustar la configuración de la conmutación por error y el montaje para la replicación continua de clústeres.