Sun Cluster: Guía de conceptos para SO Solaris

Aislamiento de fallos

Un problema fundamental de los clústers es un fallo que provoque en éstos una partición (denominada esquizofrenia). Cuando ocurre, no todos los nodos pueden comunicarse, por lo que algunos podrían intentar formar clústers individuales o subconjuntos que se creerían con permisos de acceso y de propiedad exclusivos respecto a los discos multisistema. En consecuencia, varios nodos intentando escribir en los discos podrían provocar la corrupción de los datos.

El aislamiento de fallos limita el acceso de los nodos a los discos multisistema, evitando que físicamente se pueda acceder a ellos. Cuando un nodo abandona el clúster (falla o se particiona), el aislamiento de fallos se asegura de que el nodo ya no pueda acceder a los discos. Sólo los nodos miembros actuales tendrán acceso a los discos, conservándose así la integridad de los datos.

Los servicios de dispositivos de disco ofrecen prestaciones para servicios que utilizan discos multisistema. Cuando un miembro del clúster que sirve actualmente como primario (propietario) del grupo de dispositivos de disco cae o deja de ser accesible, se elije otro primario, lo que permite que continúe el acceso al grupo de dispositivos de disco con la mínima interrupción. Durante este proceso, el primario antiguo debe renunciar al acceso a los dispositivos antes de que el nuevo primario pueda iniciarse. Sin embargo, cuando un miembro se descuelga del clúster y deja de estar disponible, éste no puede informar al nodo que libere los dispositivos para los que era primario. Por tanto, se necesita un medio para permitir que los miembros supervivientes tomen control y accedan a los dispositivos globales de los miembros fallidos.

El sistema SunPlex usa reservas de disco SCSI para implementar el aislamiento de fallos, gracias a las cuales, los nodos fallidos se “aíslan” de los discos multisistema, evitando que accedan a estos discos.

Las reservas de los discos SCSI-2 admiten un tipo que concede acceso a todos los nodos conectados al disco (cuando no hay ninguna reserva vigente) o restringe el acceso a un nodo individual (el nodo que retiene la reserva).

Cuando un miembro del clúster detecta que otro nodo ya no se está comunicando a través de la interconexión del clúster, inicia un procedimiento de aislamiento de fallos para evitar que el otro nodo acceda a los discos compartidos. Cuando se produce este aislamiento de fallos es normal que el nodo aislado emita un aviso grave con mensajes de “conflicto de reserva” en la consola.

El conflicto de reserva se produce porque después de haberse detectado que el nodo ya no es miembro del clúster, se pone una reserva SCSI en todos los discos que están compartidos entre este nodo y los demás nodos. El nodo podría no advertir que se le está aislando y si intenta acceder a uno de los discos compartidos, detecta la reserva y entra en situación de pánico.

Mecanismo de recuperación rápida para aislamiento de fallos

El mecanismo por el que la estructura del clúster se asegura de que un nodo fallido no pueda rearrancar y empezar a escribir en almacenamiento compartido se denomina recuperación rápida.

Los nodos que son miembros del clúster habilitan permanentemente un ioctl específico, MHIOCENFAILFAST, para los discos a los que tienen acceso, incluidos los de quórum. ioctl es una directiva para el controlador de disco y da a un nodo la posibilidad de entrar en pánico por sí mismo si éste no puede acceder al disco debido a que otro nodo lo está reservando.

ioctl MHIOCENFAILFAST hace que el controlador compruebe el retorno del error de cada lectura y escritura que emite un nodo al disco en el caso del código de error Reservation_Conflict. ioctl emite periódicamente en segundo plano una operación de prueba al disco para comprobar si se produce Reservation_Conflict. Las rutas del flujo de control de segundo y primer plano entran en pánico si se devuelve Reservation_Conflict.

En discos SCSI-2, las reservas no son persistentes, pues no resisten los rearranques de los nodos. En los discos SCSI-3 con reserva de grupo persistente (PGR), la información de reserva se almacena en el disco y permanece en los rearranques de los nodos. El mecanismo de recuperación rápida funciona igual aunque disponga de discos SCSI-2 o SCSI-3.

Si un nodo pierde conectividad con los otros nodos del clúster y no es parte de una partición que pueda conseguir el quórum, otro nodo lo expulsa del clúster. Otro nodo que forme parte de la partición que pueda conseguir el quórum coloca reservas en los discos compartidos y cuando el nodo que no tiene el quórum intenta acceder a éstos recibe un conflicto de reserva y entra en condición de pánico como resultado del mecanismo de recuperación rápida.

Después de la condición de pánico, el nodo podría rearrancar e intentar volverse a unir al clúster o, si éste se compone de sistemas basados en plataformas SPARC, permanecer en el indicador OpenBootTM PROM (OBP). La acción que se toma depende del valor del parámetro auto-boot?. Se puede establecer auto-boot? con eeprom(1M), en el indicador ok de la PROM de OpenBoot en un clúster basado en la plataforma SPARC o con la utilidad SCSI que se puede ejecutar opcionalmente tras un arranque de la BIOS en un clúster basado en la plataforma x86.