Quórum y dispositivos del 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.
Para obtener una introducción acerca del quórum y CMM, consulte Pertenencia al clúster de Sun Cluster para el sistema operativo Solaris: Visión general.
De las particiones de clústeres surgen dos tipos de problemas:
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 existente porque los nodos de una partición no pueden comunicarse con el nodo de la 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 da cuando se inicia el clúster en un nodo que no estaba en la última partición del clúster que estuvo en funcionamiento.
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 del 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 del quórum aportan votos basados en el número de votos que están conectados al dispositivo. Cuando se configura un dispositivo del quórum, el software Sun Cluster asigna al dispositivo del quórum un recuento de votos de N-1, donde N es el número de votos conectados al dispositivo del quórum. Por ejemplo, un dispositivo del 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.
Los dispositivos del quórum se configuran durante la instalación del clúster o posteriormente utilizando los procedimientos descritos en el Capítulo 5, Administración del quórum de Sun Cluster: Guía de administración del sistema para el SO Solaris.
Acerca del aislamiento de fallos
Un problema fundamental de los clústers es un fallo que provoque en éstos una partición (denominada esquizofrenia). Cuando esto ocurre, no todos los nodos pueden comunicarse, por lo que algunos podrían intentar formar clústers individuales o subconjuntos que “creerían” que tienen permisos de acceso y de propiedad exclusivos respecto a los dispositivos multisistema. Cuando varios nodos intentan escribir en los discos, los datos se pueden dañar.
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 de recuperación de fallos para servicios que utilizan dispositivos multisistema. Cuando falla o no se puede localizar un miembro del clúster que actualmente funciona como el principal (propietario) del grupo de dispositivos de disco, se elige un nuevo miembro principal. El nuevo miembro principal habilita el acceso al grupo de dispositivos de disco para que se pueda continuar funcionando con la menor interrupción posible. Durante este proceso, el antiguo miembro principal debe perder sus derechos de acceso en favor de los dispositivos antes de que se pueda iniciar el nuevo miembro principal. 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 Sun Cluster 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 disco SCSI-2 admiten una forma de reservas que garantizan el acceso a todos los nodos adjuntos al disco (cuando no hay ninguna reserva). De lo contrario, el acceso se restringe a un solo nodo (el que tiene 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. En este proceso, el nodo excluido emite avisos graves y aparece un mensaje de “conflicto de reserva” en la consola.
El descubrimiento de que el nodo ya no es un miembro del clúster desencadena una reserva SCSI en todos los discos que están compartidos entre este nodo y los demás. El nodo aislado puede que no sea “consciente” de que está siendo aislado y, si intenta acceder a uno de los discos compartidos, detecta la reserva y emite avisos graves.
Mecanismo de recuperación rápida para aislamiento de fallos
El mecanismo mediante el cual la estructura del clúster se asegura de que un nodo que ha fallado no pueda reiniciarse ni comenzar a escribir en un almacenamiento compartido se llama 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. Este ioctl es una directiva para el controlador del disco. El ioctl proporciona al nodo la capacidad de enviar mensajes graves en caso de que no pueda acceder al disco porque éste esté reservado por algún otro nodo.
El MHIOCENFAILFAST ioctl provoca que el controlador marque el error devuelto desde cada lectura y escritura que el nodo emita para el disco con el código de error Reservation_Conflict. En segundo plano y de forma periódica, el ioctl emite operaciones de prueba para el disco para comprobar el código de error Reservation_Conflict. Las rutas de flujo de control en segundo y en primer plano emiten mensajes graves 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 lo mismo, independientemente de que se tengan 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 forma parte de la partición que puede conseguir reservas de plazas del quórum en los discos compartidos. Cuando el nodo que no tiene quórum intenta acceder a los discos compartidos, recibe un conflicto de reserva y emite mensajes graves 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?. Puede definir auto-boot? con eeprom(1M), en el indicador OpenBoot PROM ok de un clúster basado en SPARC. Si lo desea, también puede configurar este parámetro con la utilidad SCSI, que puede ejecutar opcionalmente después de que arranque la BIOS en un clúster basado en x86.
Acerca de las configuraciones del 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 del quórum se conectan a uno de 1 a través de N nodos y el nodo N+1, el clúster sobrevive al fallo de cualquiera de ellos 1 mediante N nodos o cualquiera de los N/2 nodos. Esta disponibilidad asume que el dispositivo de quórum está funcionando correctamente.
-
En una configuración de N- nodos donde un único dispositivo del quórum se conecta a todos los nodos, el clúster puede sobrevivir al fallo de cualquiera de los N-1 nodos. 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 ver los tipos de configuraciones del quórum que se deben evitar, consulte Configuraciones de quórum malas . Para ver los tipos de configuraciones del quórum recomendadas, consulte Configuraciones de quórum recomendadas .
Cumplimiento de los requisitos de dispositivos de quórum
Debe cumplir los siguientes requisitos. Si hace caso omiso de estos requisitos, la disponibilidad del clúster puede verse comprometida.
-
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 con varios sistemas 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 la Figura 3–2.
Para ver los tipos de configuraciones del quórum que se deben evitar, consulte Configuraciones de quórum malas . Para ver tipos de configuraciones del quórum recomendadas, consulte Configuraciones de quórum recomendadas .
Mejores prácticas relacionadas con los dispositivos del 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 necesita configurar otro dispositivo del quórum porque su configuración es ó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 entornos concretos, puede que desee 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 describe en Configuraciones de quórum atípicas , el clúster está menos disponible: 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, fallará el clúster entero.
Consulte Configuraciones de quórum atípicas para conocer las excepciones a estas 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 del quórum agiliza 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 ver los tipos de configuraciones del quórum que se deben evitar, consulte Configuraciones de quórum malas . Para ver tipos de configuraciones del quórum recomendadas, consulte Configuraciones de quórum recomendadas .
Configuraciones de quórum recomendadas
Esta sección contiene ejemplos de configuraciones recomendadas del quórum. Para ver los tipos de configuraciones del 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. Estos dos votos pueden proceder 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
Puede configurar un clúster con más de dos nodos sin dispositivo del quórum. No obstante, si lo hace así, no podrá iniciar el clúster sin una mayoría de nodos en el clúster.
Configuraciones de quórum atípicas
En la Figura 3–3 se da por hecho que se están ejecutando aplicaciones con un papel fundamental (una base de datos de Oracle, por ejemplo) en el nodo A y en el 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 información acerca de las mejores prácticas relacionadas con esta excepción, consulte Mejores prácticas relacionadas con los dispositivos del quórum .
Figura 3–3 Configuración atípica
Configuraciones de quórum malas
Esta sección contiene ejemplos de configuraciones que se deben evitar. Para ver tipos de configuraciones del quórum recomendadas, consulte Configuraciones de quórum recomendadas .
- © 2010, Oracle Corporation and/or its affiliates