Quórum y dispositivos de quórum
Esta sección se divide en los siguientes apartados:
Nota –
Para obtener una lista de los dispositivos específicos que Sun Cluster admite como dispositivos de quórum, póngase en contacto con el proveedor de servicios Sun.
Debido a que los nodos del clúster comparten datos y recursos, un clúster nunca se debe dividir en particiones separadas que estén activas a la vez porque varias particiones activas pueden provocar que se dañen los datos. Cluster Membership Monitor (CMM) y el algoritmo de quórum garantizan que como mucho una instancia del mismo clúster está operativa cada vez, incluso si se particiona la interconexión del clúster.
Si desea obtener más información acerca de CMM, consulte “Cluster Membership” en Sun Cluster Overview for Solaris OS
Pueden surgir dos tipos de problemas derivados de las particiones del disco:
La esquizofrenia se produce cuando se pierde la interconexión del clúster entre nodos y el clúster se particiona en clústeres secundarios. Cada partición cree que es la única partición porque los nodos en una partición no se pueden comunicar con los nodos en otra partición.
La amnesia se produce cuando el clúster se reinicia después de un apagado teniendo datos de configuración del clúster más antiguos que los del momento del apagado. Este problema se puede producir cuando inicia el clúster en un nodo que no se encuentra en la partición que estaba funcionando la última vez.
Sun Cluster evita la esquizofrenia y amnesia:
-
Asignando un voto a cada nodo
-
Controlando la mayoría de los votos de un clúster operativo
Una partición con la mayoría de votos tiene quórum y se le permite funcionar. Este mecanismo de votos de la mayoría evita la esquizofrenia y amnesia cuando hay más de dos nodos configurados en un clúster. Sin embargo, el recuento de los votos de los nodos por sí solo no es suficiente cuando hay más de dos nodos configurados en un clúster. En un clúster de dos nodos, la mayoría es dos. Si dicho clúster de dos nodos se particiona, es necesario un voto externo para que cualquiera de las particiones obtenga quórum. Este voto externo lo proporciona un dispositivo del quórum
Acerca de los recuentos de votos de quórum
Use la opción -q del comando scstat para determinar la siguiente información:
-
Votos totales configurados
-
Votos presentes actuales
-
Votos necesarios para quórum
Para obtener más información acerca de este comando, consulte scstat(1M).
Los nodos y los dispositivos de quórum aportan votos al clúster para formar quórum.
Un nodo aporta votos en función del estado del nodo:
-
Un nodo tiene un recuento de votos de uno cuando arranca y es miembro del clúster.
-
Un nodo tiene un recuento de voto de cero cuando el nodo se está instalando.
-
Un nodo tiene un recuento de voto de cero cuando un administrador de sistema pone el nodo en estado de mantenimiento.
Los dispositivos de quórum aportan votos basándose en el número de votos conectados al dispositivo. Cuando configura un dispositivo de quórum, Sun Cluster asigna al dispositivo de quórum un recuento de votos de N-1 donde N es el número de votos conectados al dispositivo de quórum. Por ejemplo, un dispositivo de quórum conectado a dos nodos con recuentos distintos de cero, tiene un recuento del quórum igual a uno (dos menos uno).
Un dispositivo de quórum aporta votos si se cumple una de las siguientes condiciones:
-
Al menos uno de los nodos a los que está conectado actualmente el dispositivo de quórum es miembro del clúster.
-
Al menos uno de los nodos a los que el dispositivo de quórum está conectado está arrancando y dicho nodo era miembro de la última partición de clúster propietaria del dispositivo de quórum.
Puede configurar los dispositivos de quórum durante la instalación del clúster o posteriormente utilizando los procedimientos que se describen en “Administering Quorum” en Sun Cluster System Administration Guide for Solaris OS.
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 dispositivos 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 dispositivos 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 dispositivos 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 entre en pánico 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 entre 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 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 OpenBootTM. 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.
Acerca de las configuraciones de quórum
La siguiente lista contiene hechos acerca de las configuraciones de quórum:
-
Los dispositivos de quórum pueden contener datos de usuario.
-
En una configuración N+1 donde N dispositivos de quórum están conectados a uno de los nodos de 1 a N y al nodo N+1, el clúster sobrevive a la desactivación de los nodos 1 a N o cualquiera de los nodos N/ 2. Esta disponibilidad asume que el dispositivo de quórum está funcionando correctamente.
-
En una configuración de N nodos en la que un único dispositivo de quórum se conecta a todos los nodos, el clúster puede sobrevivir a la desconexión de cualquiera de los nodos N- 1. Esta disponibilidad asume que el dispositivo de quórum está funcionando correctamente.
-
En una configuración de N nodos donde un único dispositivo de quórum se conecta a todos los nodos, el clúster puede sobrevivir al fallo del dispositivo de quórum si todos los nodos del clúster están disponibles.
Para obtener ejemplos de configuraciones de quórum que se deben evitar, consulte Configuraciones de quórum malas . Para obtener ejemplos de configuraciones de quórum recomendadas, consulte Configuraciones de quórum recomendadas .
Cumplimiento de los requisitos de dispositivos de quórum
Debe cumplir los siguientes requisitos. En caso contrario, puede poner en peligro la disponibilidad del clúster.
-
Asegúrese de que Sun Cluster admite el dispositivo específico como dispositivo de quórum.
Nota –Para obtener una lista de los dispositivos específicos que Sun Cluster admite como dispositivos de quórum, póngase en contacto con el proveedor de servicios Sun.
Sun Cluster admite dos tipos de dispositivos de quórum:
-
Discos compartidos multisistema que admiten reservas SCSI-3 PGR
-
Discos compartidos de doble sistema que admiten reservas SCSI-2
-
-
En una configuración de dos nodos, debe configurar al menos un dispositivo de quórum para asegurar que un único nodo puede continuar si el otro nodo falla. Consulte Figura 3–2.
Para obtener ejemplos de configuraciones de quórum que se deben evitar, consulte Configuraciones de quórum malas . Para obtener ejemplos de configuraciones de quórum recomendadas, consulte Configuraciones de quórum recomendadas .
Cumplimiento de las mejores prácticas recomendadas de dispositivos de quórum
Use la siguiente información para evaluar la mejor configuración de quórum para su topología:
-
¿Tiene un dispositivo capaz de estar conectado a todos los nodos del clúster?
-
En caso afirmativo, configure dicho dispositivo como el dispositivo de quórum. No es necesario configurar otro dispositivo de quórum porque la configuración es la configuración óptima.
Precaución – Si ignora este requisito y añade otro dispositivo de quórum, el dispositivo de quórum adicional reduce la disponibilidad del clúster.
-
En caso contrario, configure el dispositivo(s) de doble puerto.
-
-
Asegúrese de que el número de votos aportados por los dispositivos de quórum es menor que el número de votos total aportados por los nodos. En caso contrario los nodos no pueden formar un clúster si todos los discos no están disponibles—, incluso si todos los nodos están funcionando.
Nota –En ocasiones, en entornos particulares, puede ser preferible reducir la disponibilidad general del clúster para satisfacer sus necesidades. En estas situaciones, puede ignorar estas recomendaciones. Sin embargo, no cumplir estas recomendaciones reduce la disponibilidad general. Por ejemplo, en la configuración que se define en Configuraciones de quórum atípicas el clúster tiene una menor disponibilidad: los votos del quórum superan los votos del nodo. El clúster tiene la propiedad de que si se pierde el acceso al almacenamiento compartido entre los Nodos A y B, todo el clúster fallará.
Consulte Configuraciones de quórum atípicas para conocer las excepciones a estas recomendaciones de mejores prácticas.
-
Especifique un dispositivo de quórum entre cada par de nodos que compartan el acceso al dispositivo de almacenamiento. Esta configuración de quórum acelera el proceso de aislamiento de fallos. Consulte Quórum en configuraciones de más de dos nodos.
-
En general, si la adición de un dispositivo de quórum iguala el número total de votos del clúster, la disponibilidad del clúster disminuye.
-
Los dispositivos de quórum ralentizan ligeramente las reconfiguraciones después de que se una un nodo nuevo o se desactive uno antiguo. Por tanto, no agregue más dispositivos de quórum de los necesarios.
Para obtener ejemplos de configuraciones de quórum que se deben evitar, consulte Configuraciones de quórum malas . Para obtener ejemplos de configuraciones de quórum recomendadas, consulte Configuraciones de quórum recomendadas .
Configuraciones de quórum recomendadas
Para obtener ejemplos de configuraciones de quórum que se deben evitar, consulte Configuraciones de quórum malas .
Quórum en configuraciones de dos nodos
Son necesarios dos votos de quórum para que se forme un clúster de dos nodos. que pueden provenir de los dos nodos del clúster o de un nodo y un dispositivo del quórum.
Figura 3–2 Configuración de dos nodos
Quórum en configuraciones de más de dos nodos
Es válido configurar un clúster de más de dos nodos sin dispositivo de quórum. Sin embargo, si realiza esta operación, no podrá iniciar el clúster sin una mayoría de nodos en el clúster.
Configuraciones de quórum atípicas
Figura 3–3 asume que se están ejecutando aplicaciones de misión crítica (una base de datos de Oracle por ejemplo) en el Nodo A y Nodo B. Si el Nodo A y el Nodo B no están disponibles y no se puede acceder a los datos compartidos, es posible que prefiera que todo el clúster se apague. En caso contrario, esta configuración no es óptima porque no proporciona una alta disponibilidad.
Para obtener más información sobre las prácticas más recomendadas para esta excepción, consulte Cumplimiento de las mejores prácticas recomendadas de dispositivos de quórum.
Figura 3–3 Configuración atípica
Configuraciones de quórum malas
Para obtener ejemplos de configuraciones de quórum recomendadas, consulte Configuraciones de quórum recomendadas .
- © 2010, Oracle Corporation and/or its affiliates