Siguiendo con DRBD (ver entradas anteriores al respecto), en esta ocasión os voy a presentar un entorno real en el cual está aplicada esta herramienta.
En esta entrada os presentaré el escenario inicial así como la solución planteada. Dejaré para una última entrada del blog la configuración final que se adoptó y las condiciones que se fuerzan en la configuración del clúster para el correcto funcionamiento de dicha solución.
Vamos pues “al lío”.
El entorno inicial era el siguiente:
Se dispone de un servidor Windows 2003 Server que gestiona un matadero industrial. Dicho servidor realiza conexiones contra un autómata programable que gestiona la cadena del matadero y, a su vez, el servidor es accedido por unas aplicaciones de monitorización y gestión del entorno de producción.
Dicho servidor se considera crítico, ya que el pleno funcionamiento de la instalación depende de la disponibilidad del mismo. Por consiguiente se planteó la posibilidad de crear un entorno de alta disponibilidad y tolerancia a fallos para el citado servidor, pero con un coste muy reducido. Debido al “impedimento económico”, se planteó la posibilidad de utilizar software libre para los sistemas operativos así como para la virtualización (hypervisor de Xen en lugar de ESX VMWare, por ejemplo) y DRBD para sustituir el almacenamiento compartido necesario para este tipo de configuraciones (DRBD en lugar de cabina de discos fibre-channel en este caso).
La solución planteada fue la siguiente:
Tener dos servidores, uno en la propia instalación a gestionar y el otro en un edificio contiguo, con el servidor en cuestión virtualizado mediante el hypervisor de Xen. Los archivos de configuración de la máquina virtualizada se guardarán en una partición replicada mediante DRBD y los discos virtuales de dicha máquina virtual, en otra partición también replicada mediante DRBD. Esta última partición se presenta al sistema operativo mediante iSCSI y una IP fija, haciendo la gestión sumamente fácil mediante recursos de clúster. Ambas particiones están configuradas en modo “Activo/Activo” y sistema de archivo OCFS2 (Oracle Cluster File System, versión 2). La máquina virtual también se creará como recurso de clúster, estando activa en cada momento en uno de los dos servidores, y permitiendo la migración en caso de fallo automáticamente.
Los puntos importantes de esta configuración, son los siguientes:
1.- Al tener los archivos de configuración de la máquina virtual replicados mediante DRBD, en cuanto se realice un cambio en dicha configuración en el servidor que en ese momento tenga la máquina activa, dicho cambio se replicará automáticamente e instantáneamente al otro nodo del clúster, así si la máquina cambia de servidor, seguirá teniendo sus archivos de configuración actualizados.
2.- Al tener el disco virtual de la máquina en otra partición replicada mediante DRBD, todos los datos que se están guardando en cada momento, se replican automáticamente al otro nodo, teniendo siempre los datos redundantes en tiempo real (no sólo los datos, sino el disco duro completo de la máquina virtual: sistema operativo, software instalado, actualizaciones…) Cualquier cambio realizado en el sistema virtualizado, será retransmitido en el instante al otro disco en el otro nodo.
3.- La partición donde se almacena el disco duro virtual, es presentada a sistema Linux mediante iSCSI y una IP fija asignada, configurados ambos como recursos del clúster. En el momento de fallo del nodo donde esté la máquina, tanto la máquina, como la IP y el dispositivo iSCSI se migran al nodo que sigue “vivo”, permitiendo que siga funcionando con un período mínimo de paro. Existe dicho período de paro ya que la máquina no está corriendo simultáneamente en ambos nodos, como ocurriría con ESX, sino que está arrancada en uno y, al fallar, es arrancada en el segundo nodo. Se pierde por tanto el tiempo necesario para arrancar de nuevo la máquina, pero teniendo en cuenta que en un entorno virtualizado de estas características hablamos de unos 30-35 segundos, no es una pérdida de tiempo importante y es perfectamente asumible.
4.- Al reiniciar la máquina en el segundo nodo tras el fallo, sigue teniendo accesible el disco duro mediante iSCSI y la IP que hemos migrado junto con la máquina.
5.- La réplica DRBD se hace mediante una tarjeta de red dedicada, de 1Gb de velocidad. Además la conexión entre los dos edificios se realiza mediante fibra óptica, teniendo un par reservado sólo para esta misión.
6.- Los “pulsos” del clúster (“heartbeat”) son redundantes utilizando la tarjeta de red de DRBD y la tarjeta de red de conexión de la máquina, teniendo 2 caminos redundantes para asegurar que no hay “falsos positivos” en la detección del otro nodo.
7.- Además el clúster está configurado con un recurso STONITH (“Shoot The Other Node In The Head”), lo que quiere decir que ambos nodos se están vigilando el uno al otro constantemente. Si un nodo no detecta al otro, se fuerza un reinicio del nodo que no contesta. Así se evita por ejemplo que un nodo se quede “colgado” y deje de funcionar. Se forzaría un reinicio y así se reconectaría al clúster y los dispositivos DRBD, volviendo a sincronizarse y volviendo a estar operativo al 100%.
Hasta aquí esta tercera entrega. Quedará una última en la cual comento (aunque no sea con demasiada profundidad) como se configuró el clúster y las condiciones que se tienen que forzar en dicho clúster para que los recursos se inicien y funcionen correctamente.
Sin más, hasta la siguiente entrada, saludos.
SEAS es el centro de formación online del Grupo San Valero, especializado en el ámbito técnico, industrial y de empresa. Visita www.seas.es para consultar nuestra oferta formativa de cursos y másteres. Formación profesional para el empleo de calidad y accesible para todos.
