DRBD (II de IV)

Tal y como os comentaba en la primera entrega de esta serie de artículos sobre DRBD, en esta segunda entrada os explicaré un poquito la configuración más básica que hace falta para ponerlo en funcionamiento, así como los principales modos de funcionamiento que nos puede ofrecer.

Tal y como comentaba anteriormente, la configuración se puede realizar actualmente desde entorno gráfico, aunque para los más puristas y que quieran tener el control absoluto sobre todas las configuraciones posibles, la opción será sin duda mediante un archivo de texto con la configuración deseada. Aquí os presento el ejemplo más básico de dicho archivo y qué datos mínimos nos harán falta (en este ejemplo se van a replicar 2 volúmenes, para ver que la configuración es igual de sencilla sin importar el número de dispositivos a replicar).

Tabla

Como podemos observar, hemos creado un “recurso” llamado “r0”. Dentro de dicho recurso nos creamos los “volúmenes” a replicar con sus datos, así como las direcciones IP y puertos por los cuales se realizará la replicación. Podíamos haber creado los volúmenes como recursos independientes. La ventaja de hacerlo de esta segunda manera, es que podemos detener la sincronización del recurso “r0” y seguir realizando la réplica del recurso “r1” por ejemplo, mientras que si los configuramos como en el ejemplo, si detenemos el recurso “r0” se detendrá la réplica de ambos volúmenes. Esta configuración queda a elección del administrador del sistema, pudiendo hacerse como mejor le convenga. Como ya he comentado, podría tener todos los “recursos” que necesitase en el mismo archivo de configuración, aunque luego podría detener o iniciar los que quisiese.

En “device” especificamos el nombre que daremos al nuevo dispositivo, y podemos llamarlo como mejor nos parezca para luego identificarlo correctamente. Esto quiere decir que si lo llamamos “drbd1” como en el ejemplo, nos aparecerá una nueva entrada en el directorio “dev” con ese nombre y, a partir de ese momento, para acceder a dicha partición ya no accederemos mediante /dev/sda7, sino mediante /dev/drbd1 (esto es a todos los efectos, es decir, cualquier aplicación de nuestro sistema que tuviese que acceder a sda7, ya no lo podrá hacer, siendo esta partición accesible mediante el nuevo nombre drbd1). La partición sigue siendo accesible por cualquier software igual que si fuese la partición original.

Mediante el parámetro “disk”, especificamos la partición, disco, LVM… “real” que queramos replicar mediante el nombre “drbd1”.

En “metadisk” especificamos dónde estarán los metadatos almacenados y, casi siempre, serán “internal” tal y como he comentado antes.

Sólo nos queda especificar en ambos nodos (“bob” y “alice” para nuestro ejemplo) mediante qué IP (ya que puede y debe tener más de una tarjeta de red) y puerto se realizará la sincronización. Para el puerto, también podemos utilizar cualquiera, siempre y cuando no esté utilizado previamente por otra aplicación. Hay que tener en cuenta, que si separamos los volúmenes en recursos distintos, podemos utilizar un puerto para cada uno también, separando así los tráficos de réplica por puertos distintos.

Como podemos observar, los nodos se identifican mediante nombre, no mediante IP, por lo que es importante previamente haberse asegurado de que esto es posible (acceder por nombre desde un nodo al otro), ya sea añadiendo la entrada al archivo “hosts” o mediante DNS.

Simplemente con esta sencilla configuración y levantando el servicio de DRBD, ya tendríamos los discos replicándose en tiempo real. Podríamos tener una aplicación que guardase la información en el disco del nodo “bob” y automáticamente serían replicados por red al nodo “alice”. En cualquier momento que el nodo “bob” fallase, tendríamos disponibles los datos en el otro nodo (“alice”).

A parte de estas configuraciones básicas, hay muchas más que por ahora no entraré a comentar, como por ejemplo el “modo de funcionamiento”. El nodo principal manda el dato al secundario y lo da por escrito sin confirmación, o si queremos más seguridad podemos hacer que no se dé el dato por escrito hasta que no haya confirmación por el nodo secundario, haciendo el entorno mucho más seguro.

Evidentemente, ésta configuración es muy básica y sencilla. Pero para conocer la herramienta es suficiente. Una vez que sepamos manejarlo, podemos “complicarla” todo lo que queramos y necesitemos.

Por ejemplo, los nodos suelen funcionar en un entorno “Activo/Pasivo”, es decir, uno de los nodos es el que está accesible por las aplicaciones y “montado” en “lectura/escritura”, mientras el otro nodo está en modo “pasivo” y no accesible. En el momento que el primario cae, el secundario lo “promovemos” a “activo” y ya lo tendríamos accesible en modo “lectura/escritura”. Esta “promoción” habría que realizarla a mano, con el consiguiente riesgo de perder tiempo y datos mientras se realiza.

Para evitar esta situación, se podría configurar un entorno “Activo/Pasivo” gestionado mediante clúster, así si el nodo principal cae, automáticamente el clúster se encarga de promover el nodo “Pasivo” a “Activo”, minimizando el riesgo de perder información así como el tiempo en tenerlo operativo, ya que sería instantáneo. Si queremos rizar más el rizo, podemos plantear un entorno “Activo/Activo”, en el cuál ambos discos estuviesen montados a la vez como “lectura/escritura” y que automáticamente al caer uno de los nodos, el secundario fuese accesible directamente.

Estas configuraciones ya no son tan triviales, y requieren de algo más de configuración para llevarlas a cabo, como por ejemplo crear el disco drbd como dispositivo ISCSI y asignarle una IP. Tanto el dispositivo ISCSI y la IP se pueden configurar como recursos de un clúster y, si un nodo cae, automáticamente la IP y el acceso ISCSI pasarían al segundo nodo, proporcionando un entorno de alta disponibilidad y tolerancia a fallos. Tal y como comento, estas configuraciones ya no son tan sencillas ya que, por ejemplo, para tener ambas particiones accesibles al mismo tiempo en “lectura/escritura” habría que formatearlas en un sistema de archivos que lo soporte, como por ejemplo ocfs2 (Oracle cluster file system, versión 2).

Además, si la conexión entre nodos cae y tenemos configurado el entorno en “Activo/Activo”, podríamos tener una aplicación que corriese en ambos nodos simultáneamente que diese por desaparecido al otro nodo, accediendo cada aplicación a su disco pensando que el otro nodo ya no está accesible, teniendo así una situación de “Split-brain” (datos distintos en los discos), llegando a resultar peligroso para la integridad de los datos.

De todos modos DRBD está preparado para estas situaciones, y tiene “reglas” que podemos configurar para auto-resolver este tipo de situación, como por ejemplo descartar automáticamente los datos más antiguos, que siempre un nodo se considere el que contiene los datos buenos y sobreescriba los datos del otro nodo… Aunque sin duda alguna, si llegamos a esta situación, la mejor opción es no hacer una reconexión automática y realizarla a mano, así nos aseguraremos de que descartamos los datos que realmente haya que descartar.

Como punto final comentar que, evidentemente, DRBD está preparado perfectamente para auto-reconectar si uno de los nodos se apagase, se reiniciase o perdiese la conexión de red, replicando los datos pendientes automáticamente en cuanto el fallo se restableciese (para entornos “Activo/Pasivo”. Para entornos “Activo/Activo” habría que contemplar las reglas mencionadas anteriormente).

Creo que como introducción a la herramienta, es suficiente. De todos modos en las siguientes entradas os presentaré una configuración real que está en producción ahora mismo y que seguro que os hará comprender mucho mejor las posibilidades que nos brinda esta magnífica herramienta.

Por supuesto, si alguien está interesado en ampliar conocimientos sobre DRBD, estoy disponible para cualquier duda que tengáis.

Saludos y hasta la siguiente entrada.

DRBD (I de IV)

Dado que mis especialidades son las redes y la seguridad informática, en estas entradas os voy a hablar sobre una herramienta que utiliza “la red” para “darnos seguridad”, y así desarrollar una solución que aúna ambas disciplinas.

Dada la longitud de la entrada, he decidido separarla en cuatro partes. Las dos primeras dedicadas a la explicación de la herramienta en sí, y la tercera y cuarta entrega para contaros como puede ser utilizada mediante un ejemplo real en un entorno de producción. No es una herramienta muy novedosa, pero si es una herramienta bastante desconocida, aunque una vez que se conoce, difícilmente se olvida…

La herramienta en cuestión se llama DRBD (www.drbd.org).

Tal y como podemos leer en su página oficial, DRBD (Distributed Replicated Block Device)consiste en crear un RAID-1, pero teniendo los discos “distribuidos” a través de la red. Esto, evidentemente, nos va a dar mucho “juego” y nos va a permitir crear soluciones redundantes en tiempo real, perfectas para utilizar por ejemplo, como dispositivos para clústeres y alta disponibilidad (HA, high availability).

Imagen

En principio, esta herramienta nos puede interesar y llamar la atención. Para todos aquellos que estéis pensando en probarla, sólo tiene una “pega”, y es que por el momento sólo funciona en entornos Linux. Esta es otra buena ocasión para plantearnos el comenzar a utilizar dichos entornos y aprender todas las ventajas que nos pueden aportar para entornos de producción que requieran minimizar errores basados en el sistema operativo, seguridad de los equipos y facilidad de administración (aunque parezca mentira, con las herramientas adecuadas, puede resultar muy fácil la administración de estos entornos. Por ejemplo, Suse Linux en su versión Enterprise, ya trae herramientas gráficas integradas en el propio sistema para la gestión del clúster y la creación de dispositivos DRBD que se puedan utilizar integrados en el propio clúster).

Comencemos pues con la parte un poco más técnica de la herramienta.

En principio, se puede utilizar casi cualquier tipo de dispositivo de almacenamiento para DRBD.

Por ejemplo pueden ser:

• Una partición del disco duro (o una unidad física completa).
• Un dispositivo RAID basado en software.
• Un volume lógico LVM o cualquier otro dispositivo de bloques que sea accesible por el mapeador de discos de Linux.
• Cualquier otro dispositivo de bloques que nuestro sistema reconozca (por ejemplo un disco USB).

Como podemos comprobar, esto nos da una flexibilidad increíble, ya que podremos crear un RAID 1 sobre red entre un disco o partición de nuestro propio equipo y un disco externo USB remoto conectado a otro equipo (aunque esté en una localización remota y distante), sin olvidar en ningún momento que se realiza en tiempo real. Es decir, los datos que escribo sobre uno de los discos, automáticamente serán replicados por red sobre el segundo disco.

Además, podemos replicar tantos dispositivos como queramos, es decir, no se sincroniza únicamente un único disco, sino que podemos sincronizar todos los que queramos simultáneamente, sincronizando por ejemplo uno que contenga las bases de datos, otro que contenga configuraciones de máquinas virtuales para realizar “failover” mediante Xen, etc.

Hace tiempo, la instalación y configuración, no eran triviales, ya que había que compilar los fuentes de la aplicación a mano, buscar las dependencias necesarias y realizar configuraciones mediante “prueba y error” hasta dar con la configuración idónea que funcionase en nuestro entorno. Además, la configuración de los dispositivos que íbamos a utilizar para nuestra réplica, se configuraban mediante un archivo de texto de configuración, el cuál había que realizar a mano y conocer previamente las instrucciones necesarias para ponerlo en funcionamiento. Tal y como he comentado antes, esto es historia, ya que viendo las funcionalidades que nos aporta, los desarrolladores de Novell lo han integrado directamente en su sistema operativo Enterprise accesible mediante un DVD que se puede descargar e incorporar a la instalación del propio sistema operativo, dejando las herramientas necesarias para su configuración y funcionamiento perfectamente integradas en la administración del sistema de Suse (Yast2), permitiendo su gestión y configuración mediante una herramienta gráfica muy fácil de utilizar. Se puede utilizar en otros entornos Linux que no sean de Novell, pero yo os comento esta opción ya que como digo, ya está testeada, desarrollada y adaptada por ellos mismos para funcionar correctamente sobre su sistema, evitando así problemas de compatibilidades, dependencias y demás. Para comenzar, es la mejor opción.

La manera de funcionar es muy simple.

Lo primero que hay que tener claro es que, ya que vamos a estar replicando datos en tiempo real y continuamente, necesitamos una tarjeta de red dedicada en exclusiva para este trabajo. Para entornos de pruebas, se puede utilizar la misma tarjeta de red mediante la que accedemos al equipo y la que utiliza para navegar, pero para entornos de producción, se debería utilizar un dispositivo específico sólo para esta tarea. Además hay que tener en cuenta el volumen de datos a replicar, ya que no es lo mismo utilizar este sistema para replicar ciertos archivos que sólo se modifican una vez al día que utilizarlo por ejemplo para almacenar dentro de él las bases de datos de nuestra empresa, ya que estarán continuamente actualizando los datos, eliminando y creando registros, etc, pudiendo llegar a generar grandes cantidades de datos a replicar y por consiguiente un alto tráfico de red.

Después deberemos elegir los dispositivos que queremos utilizar. Deberán ser del mismo tamaño (para que no haya problemas a la hora de replicar datos de un dispositivo de mayor tamaño sobre otro menor). Una vez escogidos los dispositivos, se formatean y se dejan listos para configurarlos sobre DRBD. Es importante formatearlos, para que no haya problemas a la hora de configurarlos y crear los “metadatos” necesarios para el funcionamiento. Además, si no lo hacemos nosotros, cuando creemos dichos “metadatos”, perderemos todo el contenido igualmente.

Sólo nos queda realizar dos pasos más para tener la herramienta operativa.

Una es crear los propios “metadatos” en los discos que queramos replicar (es una información que se queda almacenada en las propias particiones que contiene información sobre la estructura, configuración… necesaria para el funcionamiento de la herramienta). Los metadatos pueden ser creados dentro de la propia unidad a replicar o incluso en un disco distinto, pero la recomendación es siempre “internos”, ya que son datos necesarios para el correcto funcionamiento del dispositivo y si se perdiese la configuración, perderíamos los datos almacenados.

Y para finalizar, la configuración en sí de los discos a replicar (dispositivo físico, direcciones IP de los nodos involucrados en la réplica, método de réplica…).

Dicha configuración, la dejo para la siguiente entrada del blog, ya que requiere una explicación un poquito más extensa y, además, os hablaré de los modos de funcionamiento que puede tener (“Activo/Pasivo”, “Activo/Activo”, confirmación de escritura del nodo secundario…).

Espero haber llamado vuestra atención sobre esta herramienta y que estéis interesados en seguir leyendo la siguiente entrada.

Saludos.