Informática

DRBD (III de IV)

10 julio, 2012

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.

Puedes compartir este artículo en:

    Deja un comentario

    Información básica acerca de cómo protegemos tus datos conforme al Reglamento General de Protección de Datos (Reglamento UE 2016/679) y en la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales

    De conformidad con lo establecido en el Reglamento General de Protección de Datos, te informamos de:

    - Quien es el responsable del tratamiento: SEAS, Estudios Superiores Abiertos S.A.U con NIF A-50973098, dirección en C/ Violeta Parra nº 9 – 50015 Zaragoza y teléfono 976.700.660.

    - Cuál es el fin del tratamiento: Gestión y control de los comentarios del blog de SEAS. 

    - En que basamos la legitimación: En tu consentimiento.

    - La comunicación de los datos: No se comunicarán tus datos a terceros.

    - Los criterios de conservación de los datos: Se conservarán mientras exista interés mutuo para mantener el fin del tratamiento o por obligación legal. Cuando dejen de ser necesarios, procederemos a su destrucción.

    - Los derechos que te asisten: (i) Derecho de acceso, rectificación, portabilidad y supresión de sus datos y a la limitación u oposición al tratamiento, (ii) derecho a retirar el consentimiento en cualquier momento y (iii) derecho a presentar una reclamación ante la autoridad de control (AEPD).

    - Los datos de contacto para ejercer tus derechos: SEAS, Estudios Superiores Abiertos S.A.U. C/ Violeta Parra nº 9 –
    50015 Zaragoza (España) o través de correo electrónico a lopd@estudiosabiertos.com

    - También puedes ponerte en contacto con nuestro Delegado de Protección de Datos en dpd@estudiosabiertos.com

    Información adicional: Puedes consultar la información adicional y detallada sobre nuestra política de privacidad