Este tema abarca diversos tipos de errores del controlador del grid que necesitan la intervención manual del administrador del grid para restaurar el funcionamiento del controlador del grid.
Nota: Se recomienda encarecidamente leer la referencia de alta disponibilidad de CA AppLogic® para que se familiarice con las capacidades de alta disponibilidad de CA AppLogic®, especialmente de todo lo relacionado con la alta disponibilidad del controlador del grid y los tipos de errores que pueden ocurrir.
CA AppLogic® se recupera automáticamente de dos tipos de errores del controlador del grid:
En determinados escenarios de error, el controlador del grid puede ser inaccesible y CA AppLogic® no podrá recuperarlo automáticamente. A continuación se resumen estos casos, de acuerdo con lo observado por el usuario:
Un administrador puede ver la información del estado de la GUI de recuperación que se mantiene mediante CA AppLogic®. Esta información se almacena en un archivo que se encuentra en dom0, en el servidor del controlador (en el que se va a iniciar el controlador del grid). Consulte el último tema al final de este documento para conocer la ubicación y el formato del archivo de estado de la GUI de recuperación.
A continuación, se muestra una lista de motivos por los que es posible que el controlador del grid no se reinicie por sí solo:
Para restaurar el funcionamiento del controlador del grid, realice los pasos siguientes:
Aparecerá la página Grids. El estado del grid puede ser en ejecución, detenido, erróneo, con errores en ejecución (el grid crea errores pero deja los servidores en funcionamiento), requiere su atención y necesita reiniciar.
Se abre el cuadro de diálogo Parámetros del grid.
primary=srvaddr
El valor de srvaddr es el ID del servidor (srvNN) o la dirección del servidor que se convertirá en el nuevo controlador. Las direcciones deben ser accesibles en la LAN de la red troncal. Si se especifica un nombre, debe resolver a una dirección que sea accesible en la red troncal.
Cuando esta configuración se utiliza en un grid en funcionamiento (con un controlador en ejecución), el controlador se apaga inmediatamente y se reinicia en el nuevo host. Esto no debería afectar a las aplicaciones del grid, pero puede interrumpir el acceso de la GUI al controlador del grid y retrasar o interrumpir los comandos de gestión de aplicaciones que estén en curso.
También se recomienda que, con el servidor primario, haya dos servidores secundarios como mínimo en el grid. Si el grid no tiene ningún servidor secundario o los servidores secundarios están no operativos y no se pueden restaurar, realice los pasos siguientes para configurar al menos dos servidores secundarios para el grid. Si no hay suficientes servidores disponibles, se recomienda agregar más servidores al grid para alta disponibilidad del controlador del grid.
secondary=srvaddr,srvaddr,...
Los valores de srvaddr son los ID de los servidores o las direcciones de los servidores a los que se permite asumir el rol del host del controlador en caso de error del host del controlador primario. Esta configuración se puede utilizar para limitar o cambiar la asignación automática de hosts del controlador secundario. Se pueden especificar hasta siete hosts secundarios. Esta configuración se puede especificar sola o conjuntamente con el valor primary= para volver a asignar el host secundario y mover el controlador a un nuevo host primario simultáneamente. El valor secondary= no tiene ningún efecto en un grid desactivado. Para volver a asignar los hosts del controlador secundario, en primer lugar recupere el grid mediante el uso del parámetro de grid primary=srvaddr.
Si cualquiera de las sugerencias anteriores no restauran el controlador del grid, se tratará de un problema grave y requerirá intervención manual para resolverlo; póngase en contacto con el Soporte técnico de CA inmediatamente. Recopile la información siguiente para el Soporte técnico de CA:
Un administrador puede ver la información del estado de la GUI de recuperación que se mantiene mediante CA AppLogic®. Esta información se almacena en un archivo que se encuentra en dom0, en el servidor del controlador (el servidor en el que se va a iniciar el controlador del grid). El archivo se denomina /usr/local/recovery/gui/chroot/data/status y contiene el estado actual de la recuperación del controlador del grid. La información almacenada en este archivo es la que utiliza la GUI de recuperación del controlador para mostrar el progreso/estado. Este archivo utiliza el formato siguiente, codificado en JSON (a continuación se utilizan datos de ejemplo):
{
"grid_name" : "my-grid-name",
"grid_version" : "2.7.6",
"role" : "Recovery controller 2",
"status" : "Recovery in progress (master recovery controller is srv2)",
"recovery_start_time" : "15:14:41 PDT (Mar 21, 2009)",
"recovery_eta" : "15:23:54 PDT",
"recovery_remaining_time" : 278,
"current_time" : "15:19:12 PDT",
"stage" : 0,
"stage_remaining_time" : 79,
"failure_reason" : "srv1 down (no response for 30 sec on either network)",
"known_servers" : "srv1:down,srv2:up",
"stages" : [
"Waiting for quorum (at least 3 of the N servers to connect)",
"Waiting for server with controller volumes to become available",
"Waiting for remaining controller volume streams",
"Verifying both networks are present",
"Sharing controller volumes",
"Mounting controller volumes",
"Starting grid controller",
"Grid controller started"
],
"msgs" : [
{
"time" : "15:15:23 PDT",
"severity" : "alert",
"text" : "My alert message"
},
{
"time" : "15:16:00 PDT",
"severity" : "info",
"text" : "My info message"
}
]
}
Algunas notas sobre los campos anteriores:
Cuando la recuperación del controlador del grid no está en curso, sólo se proporcionan algunos campos en el archivo de estado:
{
"grid_name" : "my-grid-name",
"grid_version" : "2.7.6",
"role" : "Recovery controller 2",
"status" : "Okay",
"known_servers" : "srv2:up,srv1:up"
}
|
Copyright © 2013 CA.
Todos los derechos reservados.
|
|