vsolutions

Existen ciertos servicios que tienen que ser garantizados y por ello se designan recursos y medios que permitan obtener un tiempo de inactividad tendente a cero (o sea, una disponibilidad de casi el 100%, ya que la perfección es virtualmente imposible).

Deseamos disponer del servicio en todo momento incluso ante fallos de las comunicaciones o del hardware.

Para ello no hay una única receta y se aplican diversas técnicas que exceden el propósito de este artículo, si bien una útil y que debe ser valorada es la de la construcción de un Cluster HA (high availability cluster).

Un cluster de alta disponibilidad consiste en un mínimo de dos servidores (en adelante: nodos), que ofrecerán de forma conjunta el servicio en cuestión.

Estos servidores se verán como una única entidad (el cluster), que será la que ofrezca el servicio.

El modelo mas básico y sencillo de cluster es el Activo-Pasivo.

En este caso ambos servidores se conectan entre si, para que cada cual monitorice a su compañero, de tal modo que uno realiza el trabajo mientras el segundo queda a la espera, comprobando en todo momento que el nodo activo, realiza el trabajo. Si se da la circunstancia de caida del nodo que realiza el trabajo, el nodo pasivo toma el control y continua realizando el trabajo (pasando de este modo a ser el nodo activo). De cara al cliente/usuario del servicio, solo percibe que el servicio continua ofreciéndose sin tener que ser partícipe del problema o fallo que se ha producido en los equipos que ofrecen el citado servicio.

Normalmente las empresas disponen de redes SAN, que utilizan para ofrecer una o varias LUNs, que permiten que ambos nodos del cluster dispongan de un lugar de datos accesibles por ambos.

Pongamos un ejemplo sencillo:

Supongamos que queremos que nuestro servicio de alta disponibilidad sea un servidor web mediante apache.

El servicio apache, utiliza (como cualquier aplicación), unos archivos de configuración y un lugar donde residen las páginas que servirá a los clientes que conecten a nuestra web.

Si ambos nodos deben poder ofrecer la web, lo mas lógico es que tanto la configuración como las webs estén en uno/varios (olvidemos en este caso la seguridad) contenedores accesibles por ambos nodos.

De este modo cuando uno de los nodos ponga en marcha apache, utilizará la configuración residente en un punto compartido, y por tanto la misma que su compañero. De igual modo las páginas y otros elementos que compongan el site, también podrán ser cargados.

El esquema sería el siguiente:

Ambos nodos del cluster disponen de acceso a almacenamiento compartido

En caso de no disponer de una infraestructura como la mencionada, no todo está perdido. Existen soluciones gratuitas que permiten crear esta base sin costosos elementos como los antes mencionados.

Este es el caso de DRBD, que permite, configurar una partición o disco de DISCO LOCAL de cada nodo de modo que el disco/partición seleccionada para este uso forma parte de una especie de RAID 1 vía ethernet . Dicho de otro modo, cualquier cosa que se escriba en una de las particiones que forman el recurso compartido por drbd, será replicada en la partición/disco residente en el otro nodo y viceversa.

Con este sistema y ante la caída del nodo activo, dispondremos de la información común replicada en el nodo pasivo y por tanto en condiciones de tomar el control. Este sistema tiene 3 posibles modos de réplica (A,B,y C), de los que por seguridad lo mas recomendable es utilizar el C, si bien la configuración del módulo “drbd”, no es objeto actual del artículo, creo importante citar este aspecto ya que una mala elección del modo de réplica puede dar al traste con la información compartida del cluster.

La configuración de DRBD es sencilla y en la web del proyecto hay buena documentación y ejemplos de configuración.

Una vez solventado el mayor problema para montar un cluster HA, sin almacenamiento compartido, sigamos examinando el resto de claves para la realización del cluster.

Los nodos deben estar permanentemente conectados para monitorizarse entre si. Para ello es mas que recomendable utilizar varios medios de modo que la rotura de uno de los enlaces no suponga un problema.

Lo mas económico pasa por la utilización de una tarjeta de red exclusiva para este cometido y ofrecer redudancia de comunicación mediante el puerto serie de los equipos. Partiendo de que la información para la monitorización es poca, la velocidad que ofrece el puerto serie no es ningú problema. Evítese el uso de switches para la unión vía ethernet, siendo la mejor opción un cable cruzado y directo entre las tarjetas de red destinadas a la monitorización. Del mismo modo procederemos entre los puertos serie con el cable apropiado.

Es importante tener e cuenta que el nodo pasivo, en caso de no recibir, señal desde el nodo activo, se pondrá en acción pasando a ser el nodo activo. Aqui surge un problema, ya que podría darse el caso de que el nodo pasivo no reciba el heartbeat del nodo activo por un problema en el propio nodo pasivo (pod´ria averiarse su tarjeta de red y puerto serie por los que transmite el heartbeat…). Si se dá este caso, ambos nodos se pondrían en funcionamiento de forma simultánea con las consecuencias que esto tendría (las mencionaré posteiormente). Para evitar esto, una forma sencilla de averiguar el origen del problema pasa por lo siguiente:

Se pueden configurar los nodos de modo que ante la pérdida de señal por parte del nodo opuesto, el nodo pasivo, compruebe si el problema es suyo por medio de un ping a un elemento externo al cluster que siempre esté encendido (un router, la ip de gestión de un switch o similares). Si el nodo pasivo puede comunicar con el elemento externo al cluster y no con su compañero, el problema probablemente esté en su compañero, mientras que de ser imposible la comunicacion con otros elementos, probablemente el problema sea de él mismo y por tanto NO activase como nodo activo (ya que probablemente el nodo actualmente activo está funcionando correctamente).

La información de monitorización se conoce como heartbeat (latido), consistente en su forma mas básica en la emisión de un ping desde uno de los nodos, que debe ser respondido por el otro integrante del cluster en caso de estár “vivo”.

No es recomendable compartir una tarjeta de red para este y otros usos ya qua la saturación de la misma en un momento dado, podría dar a entender a uno de los nodos del lcuster que el otro no responde por algún fallo. Otras posibilidades pasan por transmitir una frase cifrada que ambos nodos conocen y que aumenta laseguridad del sistema (un atacante con acceso al canal de heartbeat podría hacer pasar un falso ping por el del otro nodo y comprometer todo el sistema).

La siguiente clave consiste en ofertar el servicio vía red mediante la misma IP en todo momento e independientemente del nodo que esté activo en cada instante.

El segundo y vital componente de nuestro cluster será el software heartbeat .

Este software es, en si, el alma del cluster y mediante una fácil configuración consistente en 3 archivos, podemos indicarle:

• IP de servicio (que ip será la que ofrezca el servicio y por tanto ésta se configurará de forma automática en el nodo activo en cada momento. Esta IP no debemos configurarla de forma manual en ninguna tarjeta de red, ya que el software lo hará por nosotros)
• Servicio a clusterizar (en nuestro ejemplo apache)
• Forma de comunicación y heartbeat a utilizar, canales de transmisión (ethernet + pto. serie en el ejemplo)

Con este software instalado y configurado en ambos nodos del cluster solo tendremos que arancarlo como un servicio mas para que automáticamente tengamos el clustern en funcionamiento.

Aspectos a cuidar y tener en cuenta son aquellos que puedar dar al traste con el sistema. De estos quiero hacer especial mención a aquellos que pueden hacer que ambos nodos del cluster se dispongan simultáneamente como nodo activo.

Esto puede ser desastroso, por múltiples factores de los que los mas importantes y fáciles de ver serían:

• Ambos nodos intentarán configurar la misma IP con los conflictos que esto ocasionará
• Ambos nodos querran poder escribir sobre el contenido compartido pudiendo corromperlo

Es por ello que existen elementos hardware que se aseguran de que solamente un nodo esté activo en el mismo instante de tiempo. El problema reside en que nuestro artículo versa sobre clusters para empresas con bajos o casi nulos recursos económicos y por tanto tenemos que sacar de la chistera otro componente de software llamado watchdog.

Watchdog, es un software que se instala en cada nodo y que “automonitoriza” ese nodo.

Si el servicio clusterizado se queda colgado o tiene problemas de servicio, watchdog, reinicia el nodo, haciendo que ya no esté disponible y por tanto el nodo pasivo, puede tomar el control con seguridad. Cuando el nodo activo, vuelve a arrancar, y dependiendo de la configuraión deseada, podrá ser el nuevo nodo pasivo (hasta que su compañero caiga por alguna razón), o volver a notificar al nodo activo que él será el que pase a serlo y requiriendo que su compañero vuelva a hacer las funciones de nodo pasivo.