El sistema SunPlex hace que todos los componentes de la “ruta de acceso” entre usuarios y datos esté muy disponible, incluyendo las interfaces de red, las aplicaciones en sí, el sistema de archivos y los discos multisistema. En general, un componente del clúster está muy disponible si sobrevive a cualquier fallo (de software o hardware) que se produzca en el sistema.
La tabla siguiente muestra los tipos de fallos de componentes de SunPlex (tanto de hardware como de software) y los tipos de recuperación que incorpora la estructura de alta disponibilidad.
Tabla 3–1 Niveles de detección de fallos y recuperación en SunPlex
Componente del clúster fallido |
Recuperación de software |
Recuperación de hardware |
---|---|---|
Servicio de datos |
API HA , estructura HA |
N/D |
Adaptador de red pública |
Ruta múltiple de red IP |
Varias tarjetas adaptadoras de red pública |
Sistema de archivos del clúster |
Réplicas primaria y secundaria |
Discos multisistema |
Disco multisistema duplicado |
Gestión de volúmenes (Gestor de volúmenes de Solaris y VERITAS Volume Manager) |
RAID-5 por hardware (por ejemplo: Sun StorEdgeTM A3x00) |
Dispositivo global |
Réplicas primaria y secundaria |
Varias rutas de acceso al dispositivo, uniones de transporte al clúster |
Red privada |
Software de transporte HA |
Varias redes privadas independientes del hardware |
Nodo |
CMM, controlador de recuperación rápida |
Varios nodos |
La estructura de alta disponibilidad del software de Sun Cluster detecta el fallo en un nodo rápidamente y crea un servidor equivalente nuevo para los recursos de la estructura en uno de los nodos restantes del clúster. En ningún momento se interrumpe completamente la disponibilidad de los recursos de la estructura. Los que no se hayan visto afectados por el nodo que haya fallado están completamente disponibles durante la recuperación. Además, los recursos de la estructura del nodo fallido vuelven a estar disponibles en cuanto se recuperan. Un recurso de la estructura recuperado no tiene que esperar a que todos los demás recursos de la estructura completen su recuperación.
La mayoría de recursos de la estructura de alta disponibilidad se recuperan de manera transparente para las aplicaciones (servicios de datos) usando el recurso. Las semánticas del acceso a los recursos de la estructura se conservan perfectamente entre los fallos de los nodos. Las aplicaciones simplemente no pueden advertir que el servidor del recurso de la estructura se ha trasladado a otro nodo. El fallo de un único nodo es completamente transparente para los programas desde el resto de los nodos que usan archivos, dispositivos y volúmenes de disco conectados a este nodo, siempre que exista una ruta de acceso alternativa de hardware a los discos desde otro nodo. Un ejemplo es el uso de discos multisistema que tengan puertos con varios nodos.
El Supervisor de pertenencia al clúster es un conjunto distribuido de agentes, uno por miembro del clúster, que intercambian mensajes por la interconexión del clúster para:
Forzar una vista de miembros uniforme en todos los nodos (quórum)
Activar la reconfiguración sincronizada en respuesta a cambios en la pertenencia, mediante retrollamadas registradas
Manejar el particionamiento del clúster (esquizofrenia, amnesia)
Asegurar la completa conectividad entre todos los miembros del clúster
A diferencia de anteriores versiones del software Sun Cluster, CMM se ejecuta completamente en el núcleo.
La función principal de CMM es establecer acuerdos a nivel del clúster sobre el conjunto de nodos que participan en éste en todo momento. Esta limitación se denomina pertenencia al clúster.
Para determinar la pertenencia al clúster y, por tanto, asegurar la integridad de los datos, CMM:
Registra los cambios en la pertenencia al clúster, como la incorporación o el cese de un nodo en el clúster
Se asegura que los nodos “defectuosos” abandonen el clúster
Se asegura que los nodos “defectuosos” permanezcan fuera del clúster hasta que éste se repare
Evita que el clúster se particione en subgrupos de nodos
Consulte Quórum y dispositivos del quórum para obtener más información sobre cómo se protege el clúster de particionarse en varios clústers independientes.
Para asegurarse de que los datos permanezcan incorruptos, todos los nodos deben alcanzar un acuerdo uniforme sobre la pertenencia al clúster. Cuando es necesario, CMM coordina una reconfiguración de los servicios del clúster (aplicaciones) en respuesta a un fallo.
CMM recibe información sobre conectividad con otros nodos desde la capa de transporte del clúster. CMM usa la interconexión del clúster para intercambiar información de estado durante la reconfiguración.
Después de detectar un cambio en la composición del clúster, CMM lleva a cabo una configuración sincronizada del clúster en que los recursos de éste podrían redistribuirse de acuerdo con la nueva composición.
Si CMM detecta un problema crítico en un nodo, envía una señal a través de la estructura del clúster para forzar su apagado (pánico) y así retirar su pertenencia al clúster. El mecanismo por el que ello ocurre se denomina recuperación rápida. Éste obliga a un nodo a apagarse de dos formas.
Si un nodo abandona el clúster y después intenta crear uno nuevo sin tener quórum, queda “encerrado” y se le impide acceder a discos compartidos. Consulte Aislamiento de fallos para obtener detalles sobre este uso de la recuperación rápida.
Si uno o más daemons específicos del clúster dejan de existir (clexecd, rpc.pmfd, rgmd o rpc.ed) CMM detecta el fallo y el nodo entra en pánico.
panic[cpu0]/thread=40e60: Failfast: Aborting because "pmfd" died 35 seconds ago. 409b8 cl_runtime:__0FZsc_syslog_msg_log_no_argsPviTCPCcTB+48 (70f900, 30, 70df54, 407acc, 0) %l0-7: 1006c80 000000a 000000a 10093bc 406d3c80 7110340 0000000 4001 fbf0 |
Después de la condición de pánico, el nodo podría rearrancar e intentar volverse a unir al clúster o permanecer en el indicador OpenBootTM PROM (OBP). La acción que se toma depende del valor del parámetro auto-boot? en la OBP.
El depósito de configuración del clúster (CCR) es una base de datos privada compartida a nivel del clúster para almacenar información perteneciente a la configuración y estado del clúster. CCR es una base de datos distribuida. Cada nodo mantiene una copia completa de la base de datos. CCR se asegura de que todos los nodos tengan una vista uniforme de la “extensión” del nodo. Para evitar que se corrompan datos, todos los nodos necesitan conocer el estado actual de los recursos del clúster.
CCR usa un algoritmo de puesta al día de dos fases para las actualizaciones: una actualización se tiene que completar satisfactoriamente en todos los miembros del clúster o de lo contrario se anula. CCR usa la interconexión del clúster para aplicar las actualizaciones distribuidas.
CCR se compone de archivos de texto que nunca se deben editar manualmente, ya que cada archivo contiene un registro de suma de control para asegurar la coherencia entre los nodos. La actualización manual de los archivos de CCR provocaría que un nodo o todo el clúster dejaran de funcionar.
CCR confía en CMM para garantizar que el clúster sólo se ejecute cuando se tenga el suficiente quórum. CCR es responsable de verificar la uniformidad de los datos entre el clúster, efectuando recuperaciones según sea necesario y facilitando actualizaciones a los datos.