Los escenarios de alta disponibilidad incorporan todas las funcionalidades y flujos de trabajo del escenario de replicación, pero agregan tres elementos nuevos importantes: la verificación de ejecución previa, el control del servidor master y de la aplicación que se ejecuta en él y el propio proceso de conmutación.
Durante una conmutación pueden surgir varios problemas, ya sea con los permisos, con la configuración de la aplicación o incluso con la configuración del propio escenario de alta disponibilidad. Por este motivo, cuando se crea e inicia un escenario de alta disponibilidad, Arcserve RHA realiza una lista muy amplia de comprobaciones. Estas comprobaciones están diseñadas para garantizar que no haya ningún problema conocido que pueda provocar un error durante la conmutación. Cuando se encuentra un problema en la verificación de ejecución previa, se muestran los errores y advertencias, y se le solicita que los resuelva antes de ejecutar el escenario de alta disponibilidad.
Una vez iniciado el escenario, el servidor réplica comprueba el servidor master regularmente, cada 30 segundos de forma predeterminada. Hay tres tipos de comprobaciones de control: una solicitud de ping que se envía al servidor master para poder verificar que éste es accesible y está activo; una comprobación de base de datos que verifica que se están ejecutando los servicios adecuados y que los datos están en buen estado; y una comprobación definida por el usuario que se puede adaptar para controlar aplicaciones concretas.
Si se produce un error en alguna parte de este conjunto, toda la comprobación se considera como fallida. Si todas las comprobaciones dan error durante un período de tiempo de espera de inactividad configurado (el valor predeterminado es 5 minutos), se considera que el servidor master está inactivo. En función de la configuración del escenario de alta disponibilidad, Arcserve RHA le enviará una alerta o iniciará una conmutación automáticamente.
En un escenario de alta disponibilidad inicial, el servidor master es el equipo activo y el réplica es el equipo en espera. El equipo en espera comprueba continuamente el estado del activo, para saber si éste está activo y decidir si debe asumir el papel principal.
Una conmutación se puede desencadenar automáticamente o pulsando un botón. La primera vez que se produce una conmutación, el réplica que estaba en espera pasa a ser el equipo activo y el servidor master revierte al modo en espera (suponiendo que siga operativo). Cuando el servidor master (ahora 'en espera') está preparado, se puede iniciar un proceso de conmutación regresiva automática o manualmente. Después de la conmutación regresiva, el servidor master se vuelve a activar y el réplica vuelve a su rol de control y en espera.
Nota: Después de una desconexión, al intentarse conectar, un nodo (sea master o réplica) intenta determinar su rol. Si los dos nodos se establecen como master, al volverse a conectar el master activo más nuevo continuará actuando como master, mientras que el más antiguo se convertirá en el réplica en espera.
Importante: después de la conmutación, el servicio "Server" en el servidor en espera, utilizado para la compatibilidad con archivos, la impresión y el uso compartido de la canalización con nombre, se vuelve inaccesible durante diez minutos una vez termina la conmutación. Consulte la opción, HASharesAccessTimeout en el archivo ws_rep.cfg.
|
Copyright © 2014 Arcserve.
Todos los derechos reservados.
|
|