Descripción general de gestión de errores
La función de gestión de fallos de Oracle Solaris incluye los siguientes componentes:
-
Una arquitectura para crear módulos gestores de errores flexibles
-
Telemetría de errores estructurada
-
Software de diagnóstico automatizado
-
Agentes de respuesta
-
Mensajería estructurada
Muchas partes de la pila de software participan en la gestión de fallos, incluidos la CPU, la memoria y los subsistemas de E/S, Oracle Solaris ZFS y muchos controladores de dispositivos.
FMA puede proporcionar ayuda para tanto fallos como defectos:
-
Fallos: Un componente con fallos es un componente que antes funcionaba correctamente pero ya no lo hace.
-
Defectos: Un componente defectuoso es un componente que nunca funcionó correctamente.
El hardware puede tener fallos y defectos. La mayoría de los problemas de software son defectos o son causados por problemas de configuración. Los servicios del sistema y la gestión de fallos, con frecuencia, interactúan. Por ejemplo, un problema de hardware puede provocar que los servicios se detengan o se reinicien. Un error en un servicio SMF puede hacer que FMA indique un defecto.
La pila de gestión de fallos incluye detectores de errores, un motor de diagnóstico y agentes de respuesta.
- Detectores de errores
-
Los detectores de errores detectan errores del sistema y realizan cualquier acción necesaria inmediata. Los detectores de errores proporcionan informes de errores bien definidos, o informes de errores, a un motor de diagnóstico.
- Motor de diagnóstico
-
El motor de diagnóstico interpreta los informes de errores y determina si hay un fallo o defecto en el sistema. Una vez realizada dicha determinación, el motor de diagnóstico emite una lista de sospechosos que describe el recurso o conjunto de recursos que pueden ser la causa del problema. El recurso puede tener una unidad reemplazable en campo (FRU), una etiqueta o una unidad de reconfiguración automática de sistema (ASRU) asociadas. Una ASRU se puede eliminar inmediatamente del servicio para mitigar el problema hasta que se reemplace la FRU.
Cuando la lista de sospechosos incluye múltiples sospechosos (por ejemplo, si el motor de diagnóstico no puede aislar un único sospechoso), a cada sospechoso se le asigna una probabilidad de ser el sospechoso clave. La suma de las probabilidades en esta lista da como resultado el 100 por ciento. Los agentes de respuesta interpretan las listas de sospechosos.
- Agentes de respuesta
-
Los agentes de respuesta intentan realizar acciones en función de la lista de sospechosos. Las respuestas incluyen mensajes de registro, desconexión de cadenas de CPU, eliminación de páginas de memoria o eliminación de dispositivos de E/S.
Los detectores de errores, los motores de diagnóstico y los agentes de respuesta están conectados por un daemon del gestor de fallos, fmd, que actúa como un multiplexor entre los diversos componentes, como se muestra en la siguiente figura.
Figura 1-1 Componentes de la arquitectura de gestión de fallos
El ciclo de vida de un problema gestionado por el gestor de fallos puede incluir las siguientes etapas:
- Diagnóstico
-
El gestor de fallos ha diagnosticado un nuevo problema. El diagnóstico incluye una lista de uno o más sospechosos. Es posible que se haya aislado a un sospechoso automáticamente para evitar que se produzcan más errores. El problema se identifica mediante un UUID en la carga útil del evento, y los eventos posteriores que describen el ciclo de vida de la resolución de este problema hacen referencia al mismo UUID.
- Actualización
-
Uno o varios de los recursos sospechosos de un diagnóstico de problemas se ha reparado, reemplazado o liberado, o se ha producido un nuevo fallo en el recurso. La lista de sospechosos aún contiene al menos un recurso con fallos. Es posible que se haya realizado una reparación mediante la ejecución de un comando fmadm o que el sistema haya detectado una reparación para una pieza, por ejemplo, la modificación de un número de serie. El comando fmadm se describe en el Chapter 3, Reparación de fallos.
- Reparación
-
Todos los recursos sospechosos de un diagnóstico de problemas se han reparado, resuelto o liberado. Es posible que algunos de los recursos o todos ellos aún continúen aislados.
- Resolución
-
Todos los recursos sospechosos de un diagnóstico de problemas se han reparado, resuelto o liberado, y ya no están aislados. Por ejemplo, una CPU que era sospechosa y que se había desconectado ha vuelto a estar en línea. La desconexión y la conexión de recursos suelen ser automáticas.
El daemon del gestor de fallos es un servicio de la utilidad de gestión de servicios (SMF). El servicio svc:/system/fmd se activa de manera predeterminada. Consulte Gestión de los servicios del sistema en Oracle Solaris 11.2 para obtener más información sobre los servicios SMF. Consulte la página del comando man fmd(1M) para obtener más información sobre el daemon del gestor de fallos.
El comando fmadm config muestra el nombre, la descripción y el estado de cada módulo en el gestor de fallos. Estos módulos diagnostican y reparan problemas en el sistema. El comando fmstat proporciona información adicional sobre estos módulos, como se muestra en Estadísticas de fallos.