Clúster de Alta Disponibilidad

Cluster de Alta Disponibilidad

Cluster de Alta Disponibilidad. Para conseguir redundancia y protección contra fallos de un sistema, la primera de las medidas que se suelen tomar es replicar sus componentes hardware más críticos. Por ejemplo en el caso de un servidor se emplean configuraciones de discos en RAID, fuentes de alimentación redundantes, varias interfaces de red en bonding, etc. Y el mismo concepto de redundancia se aplica también para el resto de componentes como la electrónica de red o el sistema eléctrico.

Estas medidas indudablemente aumentan el nivel de disponibilidad de un sistema, pero para conseguir un nivel aun mas alto, se suelen utilizar configuraciones avanzadas de hardware y software como son los clusters de Alta Disponibilidad.

Un Cluster de Alta Disponibilidad es un conjunto de dos o mas servidores, que se caracteriza por compartir el sistema de almacenamiento, y por que están constantemente monitorizándose entre sí. Si se produce un fallo del hardware o de los servicios de alguno de las maquinas que forman el cluster, el software de alta disponibilidad es capaz de rearrancar automáticamente los servicios que han fallado en cualquiera de los otros equipos del cluster. Y cuando el servidor que ha fallado se recupera, los servicios se migran de nuevo a la máquina original.

Esta capacidad de los clusters de restablecer en pocos segundos un servicio, manteniendo la integridad de los datos, permite que en muchos casos los usuarios no tengan por que notar que se ha producido un problema. Cuando una avería de este tipo, en un sistema sin cluster, podría dejarles sin servicio durante horas. La utilización de clusters no solo es beneficiosa para caídas de servicio no programadas, si no que también es útil en paradas de sistema programadas como puede ser un mantenimiento hardware o una actualización software.

Razones para implementar un cluster HA

• Aumentar la disponibilidad
• Mejorar el rendimiento
• Escalabilidad
• Tolerancia a fallos
• Recuperación ante fallos en tiempo aceptable
• Reducir costes
• Consolidar servidores
• Consolidar el almacenamiento

Concepto importante: recurso

Lo primero que vamos a encontrar al trabajar con un cluster de alta disponibilidad es un recurso. Es fundamental comprender el concepto de recurso, porque nos abrirá la puerta a entendernos con lo que hay detrás y con las posibilidades de configuración Un recurso es una interpretación de un servicio (a veces, incluso un conjunto de servicios o demonios) que será puesto en alta disponibilidad. Para cada recurso hay un script que sabe cómo manejar los servicios que corresponden, controlar los estados, parar, arrancar, etc... A priori, un recurso se corresponde con un servicio. Esto quiere decir lo siguiente:

-> Servicio http (apache) -> Recurso http (apache)
-> Servicio sgbd (mysql) -> Recurso sgbd (mysql)
[etc...]

Una vez comprendida e interiorizada esta correspondencia podemos decir que un recurso puede ser algo mucho más completo que un servicio y que tiene características añadidas:

• Movilidad : Un servicio pertenece a una máquina. Un recurso no pertenece a una máquina concreta.
• Integración : Podemos conseguir un grado muy alto de integración entre distintos recursos; relaciones de localización, relaciones de orden de arranque y parada, etc...
• Agrupación : Podríamos decir que un recurso en algunos casos está compuesto de varios servicios, e incluso de otros recursos.

Así que podemos resumir que cuando hablamos de un cluster de alta disponibilidad, nos referimos que se ofrecen recursos y servicios.

Hardware necesario

La cantidad, calidad y capacidad del hardware estará íntegramente relacionada con la dimensión del cluster a construir. Para un firewall, es de suponer que los elementos principales de cada máquina será la RAM y las interfaces de red. Otras características como el disco duro no toman tanta importancia. De manera genérica, para un firewall montado en un cluster necesitaremos las siguientes interfaces de red:

• Interfaz dedicada para la comunicación entre nodos. Recomendable usar más de una; el sistema será más completo mientras más redundancia haya.
• Interfaz dedicada a cada zona. Si estamos construyendo un firewall de tres patas, necesitaremos 3 interfaces dedicadas en cada nodo.
• En caso de bonding entre interfaces, el número se incrementa considerablemente, dado que también habrá que hacer el bonding en cada uno de los nodos del cluster.

Software a utilizar: Pacemaker + Corosync

Pacemaker este proyecto surge en el año 2007, a raíz de la segunda generación de Linux-HA. Los programadores del componente CRM de Linux-HA, deciden extraer el desarrollo y mantenimiento de este en un proyecto separado. Para que el nuevo CRM pueda utilizar como capa de comunicación no solo Heartbeat si no también OpenAIS.

Pacemaker es compatible totalmente con Heartbeat, así como con los scripts de recursos existentes para este, también se ha adaptado el administrador gráfico Linux-HA para que funcione con Pacemaker.

Pacemaker esta disponible en la mayoría de las distribuciones Linux actuales, las cuales lo han adoptado como sucesor de Heartbeat. También es la opción elegida en Suse Linux Enterprise, una de las distribuciones comerciales mas importantes en el sector corporativo.

Corosync Cluster Engine es un proyecto open source bajo la licencia BSD, derivado del proyecto Open-AIS. El objetivo principal del proyecto es desarrollar una solución de cluster completa, certificada por la OSI (Open Source Initiative), con soporte para Linux, Solaris, BSD y MacOSX.

El proyecto se inicia en Julio de 2008, y la primera versión estable Corosync 1.0.0 se lanzó en agosto de 2009. Hasta el momento solo la distribución Fedora lo soporta oficialmente incluyendo los binarios de Corosyn en sus repositorios de paquetes.

Configuraciones de Alta Disponibilidad

Las configuraciones mas comunes en entornos de clusters de alta disponibilidad son la configuración activo/activo y la configuración activo/pasivo.

Configuración Activo/Activo

En una configuración activo/activo, todos los servidores del cluster pueden ejecutar los mismos recursos simultáneamente. Es decir, los servidores poseen los mismos recursos y pueden acceder a estos independientemente de los otros servidores del cluster. Si un nodo del sistema falla y deja de estar disponible, sus recursos siguen estando accesibles a través de los otros servidores del cluster. La ventaja principal de esta configuración es que los servidores en el cluster son mas eficientes ya que pueden trabajar todos a la vez. Sin embargo, cuando uno de los servidores deja de estar accesible, su carga de trabajo pasa a los nodos restantes, lo que produce una degradación del nivel global de servicio ofrecido a los usuarios. En la siguiente figura se muestra como ambos servidores están activos, proporcionando un mismo servicio a los diferentes usuarios. Los clientes acceden al servicio o recursos deforma transparente y no tienen conocimiento de la existencia de varios servidores formando un cluster.

Configuración Activo/Pasivo

Un cluster de alta disponibilidad, en una configuración activo/pasivo, consiste en un servidor que posee los recursos del cluster y otros servidores que son capaces de acceder a esos recursos, pero no los activan hasta que el el propietario de los recursos ya no este disponible. Las ventajas de la configuración activo/pasivo son que no hay degradación de servicio y que los servicios solo se reinician cuando el servidor activo deja de responder. Sin embargo, una desventaja de esta configuración es que los servidores pasivos no proporcionan ningún tipo de recurso mientras están en espera, haciendo que la solución sea menos eficiente que el cluster de tipo activo/activo. Otra desventaja es que los sistemas tardan un tiempo en migrar los recursos (failover) al nodo en espera.

Funcionamiento de un cluster de alta disponibilidad

En un cluster de alta disponibilidad, el software de cluster realiza dos funciones fundamentales. Por un lado intercomunica entre sí todos los nodos, monitorizando continuamente su estado y detectando fallos. Y por otro lado administra los servicios ofrecidos por el cluster, teniendo la capacidad de migrar dichos servicios entre diferentes servidores físicos como respuesta a un fallo.

Fuentes

• Artículo [[http://informatica.gonzalonazareno.org/proyectos 2010-11proyecto_integrado_arturo_borrero_pdf.pdf Proyecto Integrado:

"Firewall en cluster de alta disponibilidad"]]. Disponible en: "http://informatica.gonzalonazareno.org" Consultado el 13 de enero de 2015

• Artículo [Clusters de Alta Disponibilidad (HA)] . Disponible en: "http://www.lintips.com" Consultado el 13 de enero de 2015
• Artículo [Sencillo cluster de alta disponibilidad con Pacemaker y Corosync]. Disponible en: "http://albertomolina.wordpress.com" Consultado el 30 de noviembre de 2014