DRBD: Replicación de Datos de Alta Disponibilidad

En el mundo de la infraestructura tecnológica, garantizar la disponibilidad continua de los datos es fundamental. Una interrupción puede significar pérdidas significativas. Aquí es donde entran en juego soluciones diseñadas específicamente para mantener los datos accesibles incluso frente a fallos de hardware. Una de estas soluciones, ampliamente reconocida en el ecosistema Linux, es DRBD, que se presenta como una tecnología robusta para la replicación y la alta disponibilidad a nivel de bloque.

DRBD son las siglas de Distributed Replicated Block Device (Dispositivo de Bloque Replicado Distribuido). Su función principal es crear un espejo de dos dispositivos de bloque ubicados en nodos diferentes a través de una red IP. Se comporta, en esencia, como un RAID 1 en red, pero operando a un nivel superior y con características diseñadas para escenarios de alta disponibilidad en clusters Linux. La replicación de datos se realiza en tiempo real, de forma continua, garantizando que ambas copias de los datos permanezcan idénticas o lo más cerca posible de serlo en todo momento.

¿Cómo Funciona DRBD? El Mecanismo Interno

DRBD opera como un módulo del núcleo Linux, posicionándose estratégicamente entre el planificador de I/O (entrada/salida) en la capa inferior y el sistema de archivos en la capa superior. Esto le permite interceptar las operaciones de escritura antes de que lleguen al dispositivo de almacenamiento físico local y replicarlas al nodo remoto.

El funcionamiento típico de DRBD implica dos nodos, configurados con roles de Primario y Secundario para un recurso DRBD específico (que representa el dispositivo de bloque replicado). Cuando una aplicación en el nodo Primario realiza una operación de escritura, esta operación es primero procesada por la capa DRBD en ese nodo. DRBD no solo envía la escritura al dispositivo de bloque local subyacente (como una partición o un volumen LVM), sino que también propaga simultáneamente esa misma operación de escritura al nodo Secundario a través de la red.

En el nodo Secundario, la capa DRBD recibe los datos replicados y los escribe en su dispositivo de bloque local subyacente correspondiente. Este proceso asegura que ambos dispositivos de bloque, en nodos distintos, contengan la misma información.

Las operaciones de lectura, en una configuración estándar, se realizan localmente en el nodo Primario. Esto minimiza la latencia de lectura, ya que no requieren comunicación de red para cada lectura. DRBD permite configuraciones más avanzadas, como el balanceo de lectura, que puede distribuir la carga de lectura entre los nodos, aunque el modo Primario/Secundario es el más común para alta disponibilidad.

La gestión de DRBD se realiza principalmente a través de la herramienta de alto nivel drbdadm, que simplifica la configuración y administración. Para tareas de bajo nivel o ajustes finos, existe la herramienta drbdsetup.

DRBD y la Alta Disponibilidad: Failover y Resincronización

El verdadero poder de DRBD para la alta disponibilidad se manifiesta cuando ocurre un fallo. Si el nodo Primario falla (ya sea por un problema de hardware, sistema operativo o aplicación), un gestor de recursos de cluster (como Pacemaker o Heartbeat, con los que DRBD se integra muy bien) detecta el fallo.

El gestor de cluster inicia entonces un proceso para promover el nodo Secundario al estado de Primario. Una vez que el antiguo nodo Secundario ha asumido el rol Primario, las aplicaciones pueden reiniciarse o migrar a este nodo y continuar operando, accediendo a la copia de los datos que ahora reside en su dispositivo de bloque local. Esta transición puede requerir una verificación adicional de la integridad del sistema de archivos que se encuentra sobre DRBD, ya sea mediante un chequeo del sistema de archivos (fsck) o una reproducción del journal.

Cuando el nodo que falló previamente vuelve a estar en línea, puede ser reincorporado al cluster. DRBD iniciará un proceso de sincronización para poner al día el dispositivo de bloque en este nodo con los cambios que ocurrieron mientras estaba fuera de servicio. El algoritmo de sincronización de DRBD es muy eficiente: solo resincroniza aquellos bloques que fueron modificados durante el tiempo que el nodo estuvo inactivo, en lugar de tener que copiar el dispositivo completo. Esto acelera significativamente el proceso de recuperación y reduce el impacto en el rendimiento durante la resincronización.

DRBD vs. Almacenamiento Compartido Tradicional

Los sistemas de cluster convencionales a menudo dependen de almacenamiento compartido (como SAN o NAS) al que acceden todos los nodos. DRBD ofrece una alternativa con varias ventajas:

Como se ve en la tabla, DRBD reduce la sobrecarga de lectura al mantener las operaciones de lectura locales (en el Primario). También permite configuraciones de alta disponibilidad con menos hardware dedicado y, por lo tanto, potencialmente a menor costo y consumo de energía, utilizando el almacenamiento ya presente en los servidores del cluster. Además, DRBD proporciona alta disponibilidad a nivel del propio almacenamiento, ya que la falla de un nodo no implica la inaccesibilidad de los datos desde el otro nodo operativo.

Una desventaja de DRBD en comparación con un sistema de almacenamiento compartido muy rápido es que las operaciones de escritura en DRBD implican una comunicación de red adicional para replicar los datos al nodo Secundario antes de confirmar la escritura (en modos síncronos), lo que puede añadir una pequeña latencia en comparación con una escritura directa a un dispositivo compartido de muy baja latencia.

DRBD vs. RAID-1

A primera vista, DRBD puede parecer similar a una configuración RAID-1 (mirroring) porque ambos involucran una copia de datos en dos dispositivos de almacenamiento para redundancia. Sin embargo, operan de maneras fundamentalmente diferentes.

En RAID-1, la redundancia es transparente para la aplicación que utiliza el almacenamiento. Solo hay una instancia de la aplicación, y esta no es consciente de que existen múltiples copias de los datos. La capa RAID decide de cuál disco leer y, si un disco falla, simplemente empieza a leer del otro sin que la aplicación se entere del fallo. La aplicación interactúa con un único dispositivo lógico.

En contraste, con DRBD, generalmente hay dos instancias de la aplicación (o del servicio que utiliza el dispositivo DRBD), una en cada nodo. En una configuración Primario/Secundario, la instancia activa (en el nodo Primario) lee y escribe en su copia local. La instancia en el nodo Secundario está inactiva o en modo de solo lectura (si está configurado).

La diferencia clave en caso de fallo es esta: si un dispositivo de almacenamiento subyacente falla en un sistema RAID-1, la capa RAID maneja la situación de forma transparente. Si la *única* instancia de la aplicación falla en un sistema con RAID-1, los datos en los dos discos RAID quedan efectivamente inutilizables por esa aplicación fallida.

Con DRBD, si un dispositivo de almacenamiento (o el nodo completo) falla, la instancia de la aplicación *vinculada a ese nodo* también fallará o dejará de operar con el dispositivo DRBD. Es la *otra* instancia de la aplicación, que reside en el nodo superviviente (el que fue promovido a Primario por el gestor de cluster), la que toma el control y continúa operando con su copia local de los datos. La fortaleza de DRBD reside en la capacidad de que una instancia de aplicación en un nodo distinto tome el relevo rápidamente.

Aspectos Técnicos Adicionales y Flexibilidad

DRBD es notablemente flexible en cuanto a los tipos de dispositivos de bloque subyacentes que puede utilizar. Puede operar sobre:

• Una partición o un disco duro completo.
• Dispositivos creados por software RAID.
• Volúmenes Lógicos (LVM - Logical Volume Manager).
• Sistemas de Gestión de Volumen Empresarial (EVMS - Enterprise Volume Management System).

Es crucial entender que los dispositivos DRBD deben configurarse *antes* de crear sistemas de archivos sobre ellos. Toda operación con los datos de usuario debe realizarse a través del dispositivo lógico /dev/drbdN (donde N es el número menor del dispositivo) y *nunca* directamente sobre el dispositivo de bloque subyacente ('raw device'). DRBD utiliza una porción final del dispositivo subyacente para almacenar metadatos. Acceder o escribir directamente en el dispositivo subyacente puede corromper estos metadatos y causar inconsistencia en los datos replicados.

Por ejemplo, si el dispositivo subyacente tiene un tamaño de 1024 MB, el dispositivo DRBD correspondiente solo tendrá aproximadamente 1023 MB disponibles para los datos del usuario, con una pequeña porción (alrededor de 70 KB) reservada y oculta para los metadatos de DRBD.

Gracias a la integración con udev, DRBD puede crear enlaces simbólicos amigables como /dev/drbd/by-res/RECURSO, que son más fáciles de recordar y usar que los números menores del dispositivo, además de proporcionar una capa de seguridad contra errores al usar el número incorrecto.

DRBD no solo se limita a configuraciones Primario/Secundario. Permite configuraciones de balanceo de carga donde ambos nodos pueden acceder a un recurso DRBD en modo lectura/escritura simultáneamente ('multiple primary'). Sin embargo, este modo requiere el uso de un gestor de bloqueo distribuido (DLM - Distributed Lock Manager) para coordinar el acceso y evitar la corrupción de datos, ya que ambos nodos modifican la misma copia lógica de los datos.

La integración de DRBD va más allá de los gestores de cluster. Se integra con soluciones de virtualización como Xen y puede ser utilizado tanto por debajo como por encima de la pila de LVM en Linux.

Más recientemente, DRBD también se ha integrado y puede ser aprovechado por LINSTOR, un software de gestión de almacenamiento de bloque, para la replicación entre diferentes nodos y para ofrecer dispositivos de almacenamiento a usuarios y aplicaciones de manera más orquestada.

LINBIT, la empresa detrás de DRBD, también ha desarrollado una versión para Windows llamada WinDRBD, llevando las ventajas de la replicación a nivel de bloque a ese sistema operativo.

Consideraciones de Red

Por defecto, DRBD utiliza los puertos TCP 7788 y superiores para la comunicación entre los nodos DRBD. Es esencial asegurarse de que los firewalls en ambos nodos permitan la comunicación a través de estos puertos para que la replicación funcione correctamente.

Un punto importante a tener en cuenta es que el tráfico de datos replicado entre los nodos DRBD *no está cifrado* por defecto. Para garantizar la seguridad de los datos en tránsito, especialmente si los nodos se comunican a través de una red no confiable (como Internet), se recomienda encarecidamente desplegar una solución de Red Privada Virtual (VPN) para la conexión entre los nodos DRBD.

¿DRBD es Gratuito?

La pregunta sobre la disponibilidad y el costo es común. DRBD fue sometido a la comunidad del núcleo Linux y, tras un proceso de revisión, fue incluido en el núcleo Linux oficial a partir de la versión 2.6.33, liberada en diciembre de 2009. Su inclusión en el núcleo Linux implica que el software base es de código abierto y está disponible bajo licencias de software libre, lo que permite su uso, modificación y distribución. LINBIT ofrece paquetes precompilados y firmados, así como documentación y, presumiblemente, soporte comercial, pero el core de DRBD como módulo del núcleo Linux es parte del proyecto de código abierto.

Preguntas Frecuentes sobre DRBD

P: ¿Qué significa DRBD?
R: DRBD significa Distributed Replicated Block Device (Dispositivo de Bloque Replicado Distribuido).

P: ¿Cuál es el propósito principal de DRBD?
R: Su propósito principal es proporcionar alta disponibilidad de datos a nivel de bloque mediante la replicación en tiempo real entre dos servidores, típicamente en un cluster Linux.

P: ¿DRBD cifra los datos replicados por defecto?
R: No, el tráfico de datos entre los nodos no está cifrado por defecto. Se recomienda usar una VPN para asegurar la comunicación.

P: ¿Con qué gestores de cluster se integra DRBD?
R: Se integra comúnmente con Pacemaker y Heartbeat, aunque puede funcionar con otros frameworks de gestión de cluster.

P: ¿Puedo usar DRBD en sistemas operativos Windows?
R: Sí, existe una versión llamada WinDRBD desarrollada por LINBIT para Windows.

P: ¿Es DRBD compatible con LVM?
R: Sí, DRBD puede operar tanto por debajo como por encima de la pila de LVM en Linux.

P: ¿DRBD es parte del núcleo Linux oficial?
R: Sí, DRBD fue incluido en el núcleo Linux oficial a partir de la versión 2.6.33.

P: ¿Qué puertos utiliza DRBD para comunicarse?
R: Por defecto, utiliza los puertos TCP 7788 y superiores.

P: ¿Pueden ambos nodos escribir en el dispositivo DRBD simultáneamente?
R: Sí, en una configuración 'multiple primary', pero esto requiere un gestor de bloqueo distribuido (DLM).

P: ¿Qué ocurre si un nodo DRBD falla?
R: Un gestor de cluster puede detectar el fallo y promover el nodo Secundario a Primario, permitiendo que las operaciones continúen en el nodo superviviente.

P: ¿Cómo se actualiza un nodo después de un fallo?
R: DRBD realiza una sincronización eficiente, copiando solo los bloques que han cambiado desde que el nodo falló.

Conclusión

DRBD es una tecnología fundamental en el ámbito de la alta disponibilidad en entornos Linux. Al proporcionar una solución de replicación síncrona o asíncrona a nivel de bloque, permite a las organizaciones proteger sus datos contra fallos de hardware o sistema operativo, asegurando que las aplicaciones críticas puedan continuar operando con una interrupción mínima. Su integración en el núcleo Linux, su flexibilidad para operar con diversos dispositivos de almacenamiento subyacentes y su compatibilidad con los principales gestores de cluster lo convierten en una opción robusta y eficiente para construir infraestructuras resilientes. Entender su funcionamiento, sus ventajas frente a otras soluciones y sus consideraciones de implementación es clave para desplegar sistemas de alta disponibilidad confiables.

Si quieres conocer otros artículos parecidos a DRBD: Replicación de Datos de Alta Disponibilidad puedes visitar la categoría Bases de datos.