Estructura de alta disponibilidad

El sistema Sun Cluster hace que todos los componentes de la “ruta de acceso” entre los usuarios y los datos estén muy disponibles, incluidos elementos como las interfaces de red, las aplicaciones en sí, el sistema de archivos y los dispositivos 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 siguiente tabla muestra los tipos de fallos de los componentes de Sun Cluster (tanto de hardware como de software) y los tipos de recuperaciones que se integran en la estructura de alta disponibilidad.

La estructura de alta disponibilidad del software de Sun Cluster detecta rápidamente cualquier fallo en los nodos y crea un nuevo servidor equivalente para los recursos de la estructura en otro nodo del clúster. En ningún momento se interrumpe completamente la disponibilidad de los recursos de la estructura. Los recursos de la estructura que no se han visto afectados por el fallo del nodo siguen estando 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) que utilizan el recurso. Las semánticas del acceso a los recursos de la estructura se conservan perfectamente entre los fallos de los nodos. Las aplicaciones no pueden detectar que el servidor del recurso de la estructura se ha movido a otro nodo. El error de un único nodo es completamente transparente para los programas de los nodos restantes que utilicen los archivos, los dispositivos y los volúmenes de discos adjuntos a este nodo. Esta transparencia es posible si hay una ruta de hardware alternativa a los discos desde otro nodo. Un ejemplo es el uso de dispositivos multisistema que tengan puertos con varios nodos.

Cluster Membership Monitor

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.

Tras detectar un cambio en la pertenencia del clúster, CMM efectúa una configuración sincronizada de éste en la cual es posible que los recursos del clúster se redistribuyan, basándose en la nueva pertenencia del clúster.

A diferencia de las versiones de software anteriores de Sun Cluster, CMM se ejecuta por completo en el núcleo.

Consulte Acerca del aislamiento de fallos para obtener más información acerca de cómo se protege el clúster para impedir su división en numerosos clústeres separados.

Mecanismo de recuperación rápida

Si CMM detecta un problema grave en un nodo, lo notifica a la estructura del clúster para forzar el cierre (avisos graves) del nodo y hacer que deje de pertenecer al clúster. El mecanismo por el que esto se produce se llama recuperación rápida. Este mecanismo hace que un nodo se cierre 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 Acerca del aislamiento de fallos para obtener información acerca de este uso del mecanismo de recuperación rápida.

• Si uno o varios de los daemons específicos del clúster sufre un fallo (clexecd, rpc.pmfd, rgmd o rpc.ed), CMM detecta el fallo y el nodo emite avisos graves.

Cuando el fallo del daemon de un clúster provoca que un nodo envíe avisos graves, se muestra un mensaje similar al siguiente en la consola para dicho nodo.

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 del aviso grave, es posible que el nodo rearranque e intente reunificar el clúster. Si el clúster está compuesto por sistemas basados en SPARC, puede que el nodo permanezca en el indicador OpenBoot^TM PROM (OBP). La siguiente acción del nodo dependerá del valor del parámetro auto-boot?. Puede configurar auto-boot? con eeprom(1M), en el indicador OpenBoot PROM ok .

Cluster Configuration Repository (CCR)

CCR usa un algoritmo de puesta al día de dos fases para las actualizaciones: Una actualización debe completarse satisfactoriamente en todos los miembros del clúster, de lo contrario, la actualización se deshace. 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.