Estructura de alta disponibilidad (HA)

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.

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.

Supervisor de pertenencia al clúster

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.

A diferencia de anteriores versiones del software Sun Cluster, CMM se ejecuta completamente en el núcleo.

Consulte Quórum y dispositivos del quórum para obtener información sobre cómo el clúster se protege de una partición en varios clústers independientes.

Mecanismo de recuperación rápida

Si el CMM detecta un problema grave en un nodo, envía una señal a la estructura del clúster para forzar un apagado (aviso grave) del nodo y borrarlo de la 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 “aislado” 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) el CMM detecta el fallo y el nodo emite un aviso grave. Cuando la finalización de un daemon del clúster hace que un nodo emita un aviso grave, en la consola de éste aparecerá un mensaje parecido a éste.

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 aviso grave, el nodo podría rearrancar e intentar volver a unirse al clúster o, si éste se compone de sistemas basados en plataformas SPARC, permanecer en el indicador PROM (OBP) de OpenBoot^TM. La acción que se toma depende del valor del parámetro auto-boot?. Puede establecer auto-boot? con eeprom(1M), en el indicador ok de la PROM de OpenBoot.

Depósito de configuración del clúster (CCR)

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 y 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.