test

Sun Cluster para el sistema operativo Solaris: Visión general

Capítulo 2 Conceptos claves de Sun Cluster

Este capítulo explica los conceptos claves relacionados con los componentes de hardware y software del sistema Sun Cluster que es necesario comprender para comenzar a trabajar con los sistemas Sun Cluster.

Este capítulo se divide en los siguientes apartados:

Nodos del clúster

Un nodo del clúster es una máquina que ejecuta los softwares Solaris y Sun Cluster. Éste permite tener de dos a ocho nodos por clúster.

Los nodos del clúster se acoplan generalmente a uno o más discos; aquellos que no lo están usan el sistema de archivos del clúster para acceder a los discos multisistema. Los nodos en configuraciones de bases de datos paralelas comparten acceso simultáneo a algunos de los discos o a todos ellos.

Todos los nodos del clúster reciben información de cuándo un nodo se une al clúster o deja éste, conocen también los recursos que se están ejecutando tanto localmente como en los otros nodos del clúster.

Los nodos del mismo clúster deben tener capacidades de procesamiento, memoria y E/S similares para permitir que la recuperación de fallos se produzca sin que haya una degradación importante en el rendimiento. Debido a la posibilidad de la recuperación de un fallo, cada nodo debe tener capacidad suficiente para cumplir con los acuerdos de los niveles de servicios si un nodo falla.

Interconexión del clúster

La interconexión del clúster es la configuración física de dispositivos que se utiliza para la transferencia de comunicaciones privadas de clústers y comunicaciones de servicios de datos entre los nodos de los clústers.

Las interconexiones redundantes permiten que continúe el funcionamiento en las interconexiones que queden, mientras los administradores de los sistemas aíslan los fallos y restablecen la comunicación. Sun Cluster detecta, repara y reinicia automáticamente la comunicación en una interconexión restablecida.

Si desea más información, consulte Interconexión del clúster.

Pertenencia al clúster

El Supervisor de pertenencia al clúster (CMM) es un conjunto distribuido de agentes que intercambian mensajes en una interconexión de clústers con el fin de terminar las tareas siguientes:

La función principal del CMM es establecer la pertenencia al clúster, lo cual requiere un acuerdo en todo el clúster en el conjunto de nodos que forman parte del clúster en cualquier momento. El CMM detecta cambios importantes en el estado de los clústers en cada nodo, como, por ejemplo, una pérdida de comunicación entre uno o más nodos; confía en el módulo del núcleo de transporte para generar pulsos en el medio de transporte con otros nodos del clúster y, si no detecta un pulso de un nodo en un período concreto, considera que el nodo ha fallado e inicia una reconfiguración del clúster para renegociar la pertenencia a éste.

Para determinar ésta y para asegurar la integridad de los datos, el CMM efectúa las tareas siguientes:

Consulte Integridad de los datos si desea más información sobre cómo se protege el clúster de particionarse en varios clústers independientes.

Depósito de configuración del clúster

El Depósito de configuración del clúster (CCR) es una base de datos privada, distribuida en todo el clúster para almacenar la información que pertenece a la configuración y al estado del clúster. Con el fin de evitar el deterioro de los datos de la configuración, cada nodo debe tener información sobre el estado actual de los recursos de los clústers. El CCR se asegura de que todos los nodos tengan una visión coherente del clúster, para ello se actualiza cuando se produce un error o una recuperación de un fallo o cuando el estado general del clúster cambia.

Las estructuras del CCR contienen los tipos siguientes de información:

Supervisores de errores

El sistema Sun Cluster permite que todos los componentes de la “ruta” entre los usuarios y los datos queden totalmente disponibles, al supervisar las aplicaciones, el sistema de archivos y las interfaces de la red.

Sun Cluster detecta rápidamente un fallo en el nodo y crea un servidor equivalente para los recursos en el nodo que ha fallado. Sun Cluster se asegura de que los recursos que no resulten afectados por el nodo incorrecto estén siempre disponibles durante la recuperación y que los recursos del nodo defectuoso queden disponibles tan pronto como se recuperen.

Supervisión de los servicios de datos

Cada servicio de datos de Sun Cluster proporciona un supervisor de fallos que explora periódicamente el servicio de datos para determinar su buen estado. Un supervisor de errores comprueba que el daemon de la aplicación o los daemons se estén ejecutando y que los clientes reciban servicio. Basándose en la información proporcionada por los análisis, se pueden iniciar acciones predefinidas como el reinicio de los daemons o la activación de la recuperación de un fallo.

Supervisión de las rutas de los discos

Sun Cluster admite la supervisión de las rutas de los discos (DPM, disk-path monitoring) que mejora la fiabilidad general en la recuperación de fallos y en la conmutación, al informar sobre el fallo de una ruta de discos secundaria. Para supervisar las rutas de los discos hay dos métodos disponibles. El primero, usar la orden scdpm que permite supervisar, dejar de supervisar o mostrar el estado de las rutas del disco del clúster. Consulte la página de comando man scdpm(1M) para obtener más información sobre las opciones de la línea de órdenes.

El segundo método es utilizar la interfaz gráfica del usuario (GUI) de SunPlex Manager que proporciona una visión topológica de las rutas de discos supervisadas. La vista se actualiza cada 10 minutos para incluir información sobre el número de pings que han fallado.

Supervisión de ruta múltiple de red IP

Todos los nodos del clúster tienen su propia configuración de Ruta múltiple de red IP, que puede ser distinta de la configuración de otros nodos del clúster. Ruta múltiple de red IP supervisa los siguientes errores en la comunicación a través de la red:

Dispositivos del quórum

Un dispositivo del quórum es un disco compartido por dos nodos o más que aporta votos que se utilizan para establecer un quórum con el fin de que se ejecute el clúster, ya que éste sólo puede funcionar cuando está disponible un quórum de votos. El dispositivo del quórum se usa cuando un clúster se particiona en distintos conjuntos de nodos, para establecer qué conjunto de nodos constituye el nuevo clúster.

Los nodos del clúster y los dispositivos del quórum votan para formar el quórum. De forma predeterminada los nodos del clúster aumentan en uno su recuento de votos del quórum cuando arrancan y se convierten en miembros del clúster. Los nodos pueden tener un recuento de votos de cero si el nodo se está instalando o cuando un administrador lo ha situado en estado de mantenimiento.

Los dispositivos del quórum adquieren votos según el número de conexiones de nodo que tenga el dispositivo. Cuando se configura un dispositivo del quórum, éste adquiere un recuento máximo 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).

Integridad de los datos

El sistema Sun Cluster intenta evitar el deterioro de los datos y asegurar su integridad. Puesto que los nodos de los clústers comparten datos y recursos, un clúster nunca debe dividirse en particiones que estén activas al mismo tiempo. El CMM garantiza que sólo pueda haber un clúster operativo al mismo tiempo.

Pueden surgir dos tipos de problemas derivados de las particiones del disco: esquizofrenia y amnesia. La esquizofrenia se produce cuando la interconexión del clúster entre los nodos se pierde y el clúster se divide en subclústers, cada uno de los cuales cree que es la única partición. Un subclúster que desconoce la existencia de los otros puede provocar conflictos en los recursos compartidos como direcciones de red duplicadas y deterioro de datos.

La amnesia se produce si todos los nodos dejan el clúster en grupos residuales. Un ejemplo es un clúster de dos nodos A y B. Si el nodo A queda inactivo, los datos de la configuración del CCR se actualizan solamente en el nodo B, no en el A. Si el nodo B queda inactivo posteriormente y se rearranca el nodo A, éste se ejecutará con los antiguos contenidos del CCR. Este estado recibe el nombre de amnesia y puede llevar a ejecutar un clúster con información sobre la configuración del estado.

Para evitar la esquizofrenia y la amnesia se debe dar cada nodo un voto y obligar a que haya una mayoría de votos por clúster en funcionamiento. Una partición con la mayoría de votos tiene quórum y se le permite funcionar. Este mecanismo de voto por mayoría funciona bien si en el clúster hay más de dos nodos. En un clúster de dos nodos, la mayoría es dos. Si ese tipo del clúster resulta particionado, un voto externo permite que una partición obtenga el quórum. Este voto externo lo proporciona un dispositivo del quórum. Cualquier disco compartido entre los dos nodos puede ser un dispositivo del quórum.

La Tabla 2–1 describe cómo Sun Cluster utiliza el quórum para evitar la esquizofrenia y la amnesia.

Tabla 2–1 Quórum del clúster y problemas de esquizofrenia y amnesia

Tipo de partición 

Solución del quórum 

Esquizofrenia 

Permite solamente la partición (subclúster) con una mayoría de votos que ejecutar como clúster (sólo puede existir una partición con dicha mayoría). Si el nodo pierde la votación y no reúne el quórum necesario, emite un aviso grave.  

Amnesia  

Garantiza que cuando se arranque un clúster, tenga al menos un nodo que era miembro de la propiedad del clúster más reciente (y por tanto disponga de los datos de configuración más recientes)  

Aislamiento de fallos

Un problema fundamental de los clústers es un fallo que provoque en éllos 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 se “creerían” con permisos de acceso y de propiedad exclusivos respecto a los discos multisistema. Si varios nodos intentan guardar datos en los discos se puede producir un deterioro en 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.

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 discos multisistema, evitando que accedan a estos discos.

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 nodo defectuoso 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.

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

El mecanismo de recuperación rápida emite avisos graves acerca de un nodo defectuoso, pero no evita que éste rearranque. Después del aviso grave, es posible que el nodo rearranque e intente reunificar el clúster.

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. El nodo que no tiene quórum emite después un aviso grave como resultado del mecanismo de recuperación rápida.

Dispositivos

El sistema de archivos global permite que todos los archivos del clúster sean accesibles por igual y que estén visibles para todos los nodos. De similar modo, Sun Cluster consigue que todos los dispositivos de un clúster sean accesibles y visibles en todo el clúster. Esto es, el subsistema de E/S permite el acceso a cualquier dispositivo del clúster, desde cualquier nodo, sin tener en cuenta dónde se acopla físicamente el dispositivo. Este acceso recibe el nombre de acceso global a dispositivos.

Dispositivos globales

Los sistemas Sun Cluster utilizan dispositivos globales con el fin de proporcionar un acceso realmente disponible en todo el clúster a cualquier dispositivo del clúster, desde cualquier nodo. Por lo general, si un nodo falla a la hora de proporcionar acceso a un dispositivo global, Sun Cluster conmuta a otra ruta al dispositivo y vuelve a dirigir el acceso a esa ruta. Esta redirección es fácil con los dispositivos globales, puesto que se utiliza el mismo nombre para el dispositivo, sin tener en cuenta la ruta. El acceso a un dispositivo remoto se lleva a cabo del mismo modo que en un dispositivo local que utilice el mismo nombre. Asimismo, la API que se usa para acceder a un dispositivo global en un clúster es la misma que la que se utiliza para acceder de manera local a un dispositivo.

Los dispositivos globales de Sun Cluster pueden ser discos, CD-ROM y cintas. No obstante, los discos son los únicos dispositivos globales de puerto múltiple que se admiten. Ello significa que los CD-ROM y los dispositivos de cinta actualmente no son dispositivos de alta disponibilidad. Los discos locales de cada servidor tampoco son multipuerto, por lo tanto no son dispositivos de alta disponibilidad.

El clúster asigna ID exclusivas a cada disco, CD-ROM y dispositivo de cinta del clúster, lo que permite el acceso uniforme a todos los dispositivos desde cualquier nodo del clúster.

ID del dispositivo

El software Sun Cluster gestiona dispositivos globales a través de una estructura conocida como el controlador del ID del dispositivo (DID) que se utiliza para asignar automáticamente ID exclusivos a cada dispositivo del clúster, incluidos los discos multisistema, las unidades de cinta y los CD-ROM.

También es una pieza integral de la función de acceso global a los dispositivos del clúster. Asimismo, analiza todos los nodos del clúster y construye una lista de dispositivos exclusivos del disco. Este controlador también asigna a cada dispositivo un número menor y mayor exclusivos, coherentes en todos los nodos del clúster. El acceso a los dispositivos globales se realiza a través del DID exclusivo asignado por el controlador del DID en lugar de los DID tradicionales de Solaris.

De esta manera se asegura que cualquier aplicación que acceda a los discos, como Solaris Volume Manager o Sun Java System Directory Server, utilice una ruta coherente en todo el clúster. Esta coherencia es especialmente importante en los discos multisistema, puesto que los números locales menores y mayores de cada dispositivo pueden variar según el nodo y también pueden cambiar la convención de asignación de nombres del dispositivo Solaris.

Dispositivos locales

El software Sun Cluster gestiona también los dispositivos locales que son accesibles tan solo en un nodo que ejecute un servicio y que tenga una conexión física con el clúster. Es posible que los dispositivos locales tengan un mejor rendimiento que los globales, puesto que aquéllos no tienen que duplicar la información del estado en varios nodos simultáneamente. El fallo en el dominio del dispositivo suprime el acceso a éste a menos que varios nodos puedan compartir este dispositivo.

Grupos de dispositivos de discos

Los grupos de dispositivos de discos permiten a los grupos de discos del gestor de volúmenes convertirse en “globales”, gracias a la compatibilidad de ruta múltiple y de sistema múltiple en los discos subyacentes. Cada nodo del clúster conectado físicamente a los discos multisistema proporciona una ruta de acceso al grupo de dispositivos de disco.

En el sistema Sun Cluster, los discos de sistema múltiple pueden estar bajo el control del software Sun Cluster registrándose como grupos de dispositivos de discos. Este registro proporciona al sistema Sun Cluster información sobre qué nodos tienen una ruta a ciertos grupos de discos del gestor de volúmenes. El software de Sun Cluster crea un grupo de dispositivos básicos de disco para cada dispositivo de disco y de cinta del clúster. Estos grupos de dispositivos del clúster permanencen fuera de línea hasta que se accede a ellos como dispositivos globales montando un sistema de archivos global o accediendo a un archivo básico de bases de datos.

Servicios de datos

Un servicio de datos es la combinación de software y archivos de configuración que permite a una aplicación ejecutarse sin modificaciones en una configuración de Sun Cluster, ya que en esta circunstancia se ejecuta como recurso bajo el control del Gestor del grupo de recursos (RGM). Un servicio de datos permite configurar una aplicación como Sun Java System Web Server o la base de datos de Oracle para ejecutarse en un clúster en lugar de un único servidor.

El software de un servicio de datos proporciona implementaciones de los métodos de gestión de Sun Cluster que efectúan las operaciones siguientes en la aplicación:

Los archivos de configuración de un servicio de datos definen las propiedades del recurso que representa la aplicación en el gestor del grupo de recursos.

El RGM (gestor del grupo de recursos) controla la disposición de la recuperación de fallos y los servicios de datos escalables en el clúster y es responsable del inicio y de la parada de los servicios de datos en los nodos seleccionados del clúster, en respuesta a los cambios en la pertenencia al clúster; permite a las aplicaciones de servicios de datos utilizar la estructura del clúster.

El RGM controla los servicios de datos como recursos. Estas implementaciones las suministra Sun o las crea un desarrollador que utiliza una plantilla de servicios de datos genéricos, la API de la biblioteca de desarrollo de servicios de datos (DSDL API) o la API de la gestión de recursos (RMAPI). El administrador del clúster crea y gestiona los recursos en contenedores que reciben el nombre de grupos de recursos. Las acciones del administrador y del RGM provocan que los recursos y los grupos de recursos estén alternativamente en línea y fuera de línea.

Tipos de recursos

Un tipo de recurso es un conjunto de propiedades que describen una aplicación al clúster y que contiene información sobre cómo se debe iniciar, detener y supervisar la aplicación en los nodos del clúster; incluye, también, las propiedades específicas de la aplicación que es necesario definir para usar ésta en el clúster. Los servicios de datos de Sun Cluster tienen varios tipos de recursos predefinidos. Por ejemplo, Sun Cluster HA para Oracle es el tipo de recurso SUNW.oracle-server y Sun Cluster HA for Apache es SUNW.apache.

Recursos

Un recurso es una instancia de un tipo de recurso que está definido en todo el clúster y que permite que varias instancias de una aplicación se instalen en éste. Cuando se inicializa un recurso, RGM asigna valores a las propiedades específicas de la aplicación y el recurso hereda las propiedades en el tipo de recurso.

Los servicios de datos usan varios tipos de recursos. Las aplicaciones como Apache Web Server o Sun Java System Web Server usan direcciones de red (nombres de sistema lógicos y direcciones compartidas) de las que dependen las aplicaciones. Los recursos de aplicación y red forman una unidad básica que gestiona RGM.

Grupos de recursos

Los recursos gestionados por RGM se colocan en grupos de recursos, de modo que se puedan gestionar como una unidad. Un grupo de recursos es un conjunto de recursos interdependientes o relacionados. Por ejemplo, un recurso derivado de un tipo de recurso SUNW.LogicalHostname es posible que se sitúe en el mismo grupo de recursos que el derivado de un tipo de recurso de base de datos de Oracle. El grupo de recursos migra como unidad si se inicia una recuperación de fallos o un cambio.

Tipos de servicios de datos

Los servicios de datos permiten a las aplicaciones estar altamente disponibles y los servicios escalables ayudan a evitar la interrupción significativa de las aplicaciones después de un único fallo en el clúster.

Cuando se configura un servicio de datos, se debe configurar como:

Servicios de datos a prueba de fallos

La recuperación de fallos es un proceso por el cual el clúster reubica automáticamente una aplicación de un nodo principal con fallos en un nodo designado secundario y redundante. Las aplicaciones a prueba de fallos tienen las características siguientes:

Si el supervisor de fallos detecta un error, intenta reiniciar la instancia del mismo nodo o la de otro nodo (recuperación de fallos), dependiendo de la forma en que se haya configurado el servicio de datos. Los servicios a prueba de fallos usan un grupo de recursos a prueba de fallos: un contenedor para los recursos de instancias de aplicaciones y recursos de la red (nombres de sistemas lógicos). Éstos son direcciones IP que pueden configurarse como activas en un nodo y, posteriormente, configurarse automáticamente como inactivas en el nodo original y activarse en otro nodo.

Es posible que los clientes hayan sufrido una breve interrupción del servicio y es posible que necesiten volver a conectarse después de terminar la recuperación del fallo. Sin embargo, los clientes no parecen estar al tanto del cambio en el servidor físico que proporciona el servicio.

Servicios de datos escalables

El servicio de datos escalables permite a las instancias de la aplicación ejecutarse en varios nodos de manera simultánea y usan dos grupos de recursos. El grupo de recursos escalable contiene los recursos de las aplicaciones y el grupo de recursos a prueba de fallos contiene los recursos de la red (direcciones compartidas), del que depende el servicio escalable. El grupo de recursos escalable puede estar en línea en varios nodos, de forma que se puedan ejecutar varias instancias del servicio simultáneamente. El grupo de recurso a prueba de fallos que aloja la dirección compartida está disponible en un solo nodo cada vez. Todos los nodos que alojan un servicio escalable usan la misma dirección compartida para alojar el servicio.

El clúster recibe las peticiones de servicio a través de una única interfaz de red (la interfaz global). Estas solicitudes se distribuyen a los nodos, basándose en uno de los algoritmos predefinidos especificados por la norma de equilibrado de cargas que el clúster puede usar para equilibrar la carga del servicio entre varios nodos.

Aplicaciones paralelas

Los sistemas Sun Cluster proporcionan un entorno que comparte la ejecución paralela de aplicaciones en todos los nodos del clúster, mediante las bases de datos paralelas. Admisión de Sun Cluster para Parallel Server/Real Application Clusters de Oracle es un conjunto de paquetes que, tras su instalación, permite la ejecución de Oracle Parallel Server/Real Application Clusters en nodos de Sun Cluster. Este servicio de datos también permite que las órdenes de Sun Cluster puedan gestionar Admisión de Sun Cluster para Parallel Server/Real Application Clusters de Oracle.

Una aplicación paralela se instrumentaliza de manera que se pueda ejecutar en un entorno del clúster y la puedan controlar simultáneamente dos o más nodos. En un entorno Oracle Parallel Server/Real Application Clusters, las diversas instancias de Oracle colaboran para proporcionar acceso a la misma base de datos compartida. Los clientes de Oracle pueden usar cualquiera de las instancias para acceder a la base de datos. De este modo, si una o mas instancias fallan, los clientes pueden conectarse con una instancia superviviente y continuar accediendo a la base de datos.