DRBD (IV de IV)

Llegamos al final de esta serie de artículos sobre DRBD, y para esta última entrada teníamos pendiente ver (muy por encima) la configuración final que se adoptó para llevar a cabo el desarrollo solicitado.

Volvemos a entrar en materia, siguiendo justo donde lo habíamos dejado: Explicar la configuración final.

Bajo las premisas que comentábamos en los artículos anteriores, sobre todo en la tercera parte, se configura pues el clúster, con ambos nodos. La máquina virtual se crea como recurso del clúster y se le asigna un nodo preferido (el nodo que está en la misma planta). De todos modos, si este nodo falla y la máquina se migra (failover), una vez que el nodo principal se restablezca, la máquina no se vuelve a migrar (failback), sino que se queda en el secundario. Esto se hace para evitar mover la máquina 2 veces cuando hay un fallo. Así se migraría en el fallo y, cuando no se esté trabajando, se volvería a migrar a mano para minimizar los daños.

Las particiones de configuraciones replicadas por DRBD y montadas en ambos servidores.

Las particiones de discos duros virtuales, replicadas por DRBD y montadas a la vez en ambos servidores (para esto es necesario el OCFS2, sino no se pueden montar simultáneamente).

Dicha partición presentada al Linux como dispositivo iSCSI con una IP fija.

En la configuración del clúster, además, se fuerzan ciertas reglas como son:

  1. Para montar las particiones DRBD, es necesario que previamente se haya montado el sistema de archivos de Linux y los servicios de red. Si no funciona uno de los dos, no se montan las particiones.
  2. Para crear el dispositivo iSCSI y asignarle la dirección IP, previamente se han tenido que montar las particiones DRBD. Si no se han podido montar, no se crea el recurso iSCSI.
  3. Para arrancar la máquina virtual, previamente se ha tenido que montar las particiones DRBD, el recurso iSCSI y la IP. Si no se han podido montar, no se puede arrancar la máquina virtual.
  4. La máquina virtual, si no está corriendo en ningún nodo, por defecto arranca en el nodo que está en la propia planta. Si ya se ha migrado al secundario por algún fallo, se queda en el secundario y no realiza “failback”.

Respecto a la configuración del DRBD, tenemos:

  1. El método de réplica requiere confirmación. Es decir, un dato no se da por escrito en el segundo nodo, hasta que no está confirmado.
  2. Un dispositivo DRBD por recurso (así se pueden parar o arrancar independientemente uno del otro) y por puerto diferente, para separar tráfico por puertos.
  3. Si un nodo se desconecta, permite la reconexión del nodo y su sincronización automática durante 5 minutos. Si en 5 minutos no ha habido re-sincronización de los discos, se dejan desconectados, para evitar pérdidas de datos. La re-sincronización se realizará manualmente para tener control absoluto sobre la operación. Se hará cuando no se esté trabajando, al igual que el migrar la máquina nuevamente al nodo principal.

Con esta configuración es posible tener un entorno virtualizado de alta disponibilidad y con tolerancia a fallos a un precio muy económico, teniendo además un buen rendimiento.

Espero que os hayan gustado los artículos y que veáis que se pueden realizar cosas muy interesantes con software libre, y que no tienen nada que envidiar a según qué sistemas comerciales. Evidentemente, no estamos hablando de una potencia y características de ESX, pero para según qué instalaciones tendremos más que suficiente.

Como siempre, si alguien tiene algún comentario o quiere ampliar información, estoy a vuestra disposición.

Saludos.

DRBD (III de IV)

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.