Capítulo 3 Arquitectura de Sun Cluster
La arquitectura de Sun Cluster permite el desarrollo, la gestión y la visualización de un grupo de sistemas como un único sistema grande.
Este capítulo se divide en los siguientes apartados:
Entorno de hardware de Sun Cluster
Los componentes siguientes de hardware componen un clúster:
-
Los nodos del clúster con discos locales (sin compartir) proporcionan la principal plataforma de computación del clúster.
-
El almacenamiento multisistema proporciona discos compartidos entre los nodos.
-
Los soportes extraíbles se configuran como dispositivos globales, como cintas y CD-ROM.
-
La interconexión del clúster proporciona un canal para la comunicación intermodal.
-
Las interfaces de red pública permiten que las interfaces de red que utilicen los sistemas de clientes tengan acceso a los servicios de datos del clúster.
La Figura 3–1 ilustra cómo trabajan conjuntamente los componentes del hardware.
Figura 3–1 Componentes del hardware de Sun Cluster
Entorno del software de Sun Cluster
Si desea trabajar como miembro de un clúster, un nodo debe tener el siguiente software instalado:
-
Software Solaris
-
Software de Sun Cluster
-
Aplicación de servicio de datos
-
Gestión de volúmenes (SolarisTM Volume Manager o VERITAS Volume Manager)
Una excepción es una configuración que se suministre con una gestión de volúmenes. Es posible que no necesite un gestor de volúmenes de software.
La Figura 3–2 muestra con precisión cómo los componentes de software trabajan conjuntamente para crear el entorno de Sun Cluster.
Figura 3–2 Arquitectura del software de Sun Cluster
Supervisor de pertenencia al clúster (CMM)
Para asegurarse de que los datos no sufran daños, 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 en respuesta a un fallo.
CMM recibe información sobre conectividad con otros nodos desde la capa de transporte del clúster y 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.
CMM se ejecuta por completo en el núcleo.
Depósito de configuración del clúster (CCR)
CCR confía en CMM para garantizar que el clúster sólo se ejecute cuando se tenga el suficiente quórum. CCR 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.
Sistemas de archivos del clúster
Un sistema de archivos del clúster es un servidor proxy entre:
-
El núcleo de un nodo y el sistema de archivos subyacente
-
El gestor de volúmenes que se ejecute en un nodo con una conexión física con los discos
Los sistemas de archivos del clúster dependen de los dispositivos globales (discos, cintas, CD-ROM), accesibles desde cualquier nodo del clúster, a través del mismo nombre de archivo, (por ejemplo /dev/global/). Ese nodo no necesita una conexión física con el dispositivo de almacenamiento. Se puede utilizar un dispositivo global como dispositivo regular, esto es, se puede crear un sistema de archivos en un dispositivo global mediante newfs o mkfs.
El sistema de archivos del clúster ofrece las prestaciones siguientes:
-
Las ubicaciones de los accesos de archivo son transparentes. Un proceso puede abrir un archivo que se encuentre en cualquier ubicación del sistema. Asimismo, los procesos de todos los nodos pueden usar el mismo nombre de ruta para ubicar un archivo.
Nota –Cuando el sistema de archivos del clúster lee archivos, no actualiza la hora de acceso en éstos.
-
Se utilizan protocolos de coherencia para preservar la semántica de acceso a archivos UNIX aunque varios nodos estén accediendo al archivo al mismo tiempo.
-
Para mover datos de archivos eficientemente se utiliza masivamente la antememoria y el movimiento de E/S en bloque sin copia.
-
El sistema de archivos del clúster ofrece el bloqueo de archivos a través de las interfaces fcntl(2). Las aplicaciones que se ejecuten en varios nodos del clúster pueden sincronizar el acceso a los datos mediante el bloqueo a los archivos de aviso en un archivo del sistema de archivos del clúster. Los bloqueos de archivo se recuperan inmediatamente desde los nodos que abandonan el clúster y las aplicaciones que fallan mientras se mantienen los bloqueos.
-
El acceso continuo a los datos queda asegurado aunque se produzcan fallos. Las aplicaciones no se ven afectadas por fallos si sigue estando operativa una ruta de acceso a los discos. Esta garantía se mantiene para el acceso a discos de bajo nivel y todas las operaciones del sistema de archivos.
-
Los sistemas de archivos del clúster son independientes del sistema de archivos subyacente y del software de gestión de volúmenes. Los sistemas de archivos del clúster convierten en global cualquier sistema de archivos admitido del disco.
Servicios de datos escalables
El objetivo principal de la conexión en red por clúster es ofrecer escalabilidad a los servicios de datos. Esto significa que a medida que aumente la carga ofrecida a un servicio, éste pueda mantener un tiempo de respuesta constante frente a este aumento de carga de trabajo según se vayan añadiendo nodos nuevos al clúster y se ejecuten instancias nuevas de servidores. Un buen ejemplo es un servicio web. Normalmente, un servicio de datos escalable se compone de varias instancias cada una de las cuales se ejecuta en distintos nodos del clúster. Cuando están juntas, estas instancias se comportan como un único servicio de un cliente remoto de ese servicio e implementa la funcionalidad del servicio. Un servicio web escalable con varios daemons httpd que se ejecuten en varios nodos puede hacer que cualquier daemon atienda las peticiones de un cliente. El que sirve la solicitud depende de una norma de equilibrio de cargas. La respuesta al cliente parece provenir del servicio, no del daemon concreto que atendió la petición, preservando así la apariencia de servicio individual.
La figura siguiente muestra la arquitectura de servicio escalable.
Figura 3–3 Arquitectura de servicio de datos escalable
Los nodos que no alojan la interfaz global (nodos delegados) tienen la dirección compartida alojada en sus interfaces de bucle. Los paquetes que se reciben en la interfaz global se distribuyen en otros nodos del clúster, basándose en las normas configurables de equilibrio de cargas. Las normas de equilibrio de cargas posibles se describen a continuación.
Normas de equilibrio de cargas
El equilibrio de cargas mejora el rendimiento del servicio escalable, tanto en tiempo de respuesta como en rendimiento.
Hay dos clases de servicios de datos escalables: puros y adosados. Un servicio puro es aquel donde una instancia puede responder a peticiones de clientes sin restricciones. Un servicio adosado tiene al clúster equilibrando la carga en las solicitudes al nodo. Estas peticiones no se redirigen a otras instancias.
Un servicio puro usa una política de equilibrio de cargas ponderada bajo la cual, predeterminadamente, las peticiones de los clientes se distribuyen de manera uniforme entre las instancias del servidor en el clúster. Por ejemplo, en un clúster de tres nodos donde cada uno tenga el peso de 1, cada nodo atiende a un tercio de las solicitudes de cualquier cliente en nombre de ese servicio. Los pesos se pueden cambiar en cualquier momento mediante la interfaz de la orden scrgadm(1M) o mediante la interfaz de SunPlex Manager.
Un servicio adosado tiene dos tipos: servicio adosado normal y servicio adosado comodín. Ambos permiten que sesiones simultáneas de aplicación a través de varias conexiones TCP compartan el estado de la memoria (estado de la sesión de aplicación).
Los normales permiten a un cliente compartir el estado entre varias conexiones TCP simultáneas. Se considera que el cliente es “adosado” con respecto a la instancia del servidor que recibe en un único puerto. Al cliente se le garantiza que todas sus solicitudes vayan a la misma instancia del servidor, siempre que ésta permanezca activa y accesible y que la política de equilibrio de cargas no cambie mientras el servicio esté en línea.
Los servicios adosados comodín usan números de puerto asignados dinámicamente, pero siguen esperando que las peticiones de clientes vayan al mismo nodo. El cliente está “adosado con comodín” a los puertos con respecto a la misma dirección IP.
Almacenamiento en discos multisistema
El software Sun Cluster consigue de los discos una alta disponibilidad mediante el almacenamiento en discos multisistema, que se pueden conectar a más de un nodo a la vez. El software de gestión de volúmenes se puede utilizar para ordenar estos discos en un almacenamiento compartido controlado por un nodo del clúster. Los discos se configuran después para desplazarse a otro nodo si se produce un fallo. El uso de discos multisistema en sistemas Sun Cluster proporciona muchas ventajas, entre las que se encuentran:
-
Acceso global a los sistemas de archivos
-
Rutas de acceso múltiple a los datos y a los sistemas de archivos
-
Tolerancia a los fallos de un único nodo
Interconexión del clúster
Todos los nodos deben estar conectados por la interconexión del clúster a través de, al menos, dos redes independientes físicamente o rutas de acceso, para evitar que exista un único punto de fallo. Puesto que son necesarias dos interconexiones para conseguir una mayor seguridad, se pueden usar hasta seis para dispersar el tráfico y evitar de este modo los atascos, con lo que se mejora la seguridad y la escalabilidad. La interconexión del Sun Cluster utiliza Fast Ethernet, Gigabit-Ethernet, Sun Fire Link o Scalable Coherent Interface (SCI, IEEE 1596-1992), con lo que se consiguen comunicaciones privadas de alto rendimiento entre clústers.
En los entornos de clústers son esenciales las interconexiones de alta velocidad y baja latencia, así como los protocolos para comunicaciones intermodales. La interconexión SCI en los sistemas Sun Cluster ofrece un rendimiento mejorado en tarjetas estándar de interfaces de red (NIC). Sun Cluster utiliza la interfaz de memoria compartida remota (RSMTM) en la comunicación intermodal en una red Sun Fire Link. RSM es una interfaz de mensajería de Sun altamente eficaz en operaciones de memoria remota.
La interconexión del clúster consta de los siguientes componentes de hardware:
-
Adaptadores: las tarjetas de interfaz de red que residen en cada nodo de clústers. Un adaptador de red con varias interfaces podría convertirse en un único punto de fallo si fallara todo el adaptador.
-
Uniones: los interruptores que se encuentran en el exterior de los nodos del clúster. Las uniones llevan a cabo funciones de transporte y conmutación para permitir conectar más de dos nodos simultáneamente. En un clúster de dos nodos no se necesitan las uniones puesto que los nodos se pueden conectar directamente entre sí mediante cables físicos redundantes que están conectados con adaptadores redundantes en cada nodo. Las configuraciones de más de dos nodos requieren uniones.
-
Cables: las conexiones físicas que se sitúan entre dos adaptadores de red o un adaptador y una unión.
La Figura 3–4 muestra cómo se conectan los tres componentes.
Figura 3–4 Interconexión del clúster
Grupos de ruta múltiple de red IP
Los adaptadores de red pública se organizan en grupos de ruta múltiple IP (grupos de ruta múltiple), cada uno de ellos con uno o más adaptadores de red pública. Cada adaptador de un grupo de ruta múltiple puede estar activo o se pueden configurar interfaces en espera que estén inactivos a menos que ocurra una recuperación de fallos.
Los grupos de ruta múltiple ofrecen la base para la construcción de nombres de sistema lógicos y recursos de dirección compartida. El mismo grupo de ruta múltiple de un nodo puede alojar cualquier número de nombres de sistema lógicos o recursos de dirección compartida. Si desea supervisar la conectividad de redes públicas de nodos del clúster, puede crear rutas múltiples.
Si desea más información sobre sistemas lógicos y recursos de direcciones compartidos, consulte Sun Cluster Data Services Planning and Administration Guide for Solaris OS.
Interfaces de red pública
Los clientes se conectan al clúster a través de interfaces de red pública. Todas las tarjetas adaptadoras de red pueden conectarse a una o más redes públicas, de acuerdo con las interfaces de hardware que la tarjeta tenga. Los nodos pueden configurarse para que incluyan múltiples tarjetas de interfaz de red pública a fin de que varias estén activas y se utilicen en caso de recuperación de fallos como respaldo entre ellas. Si uno de los adaptadores falla, el software de ruta múltiple de red del protocolo de Internet (IP) de Solaris, en Sun Cluster, recibe la instrucción de recuperarse de una interfaz defectuosa en otro adaptador del grupo.
- © 2010, Oracle Corporation and/or its affiliates