Contexto: Esta práctica configura DRBD (Distributed Replicated Block Device) en dos nodos (denominados nodo-a y nodo-b) con Debian 13.4, para replicar un volumen de datos entre ambos en tiempo real. Cada nodo cuenta con una partición adicional (p.ej. /dev/sdb1) de tamaño idéntico destinada a DRBD. El objetivo es lograr un «RAID-1 de red»: cualquier cambio en el nodo Primario se replicará al Secundario de forma continua, manteniendo ambas copias sincronizadas. DRBD es un módulo del kernel de Linux que se ubica entre el planificador de I/O (parte inferior) y el sistema de archivos (parte superior), actuando como controlador de un dispositivo de bloque virtual. Esto significa que las aplicaciones leen y escriben datos sin saber que, en la capa de bloques, esos datos están siendo duplicados por red en otro servidor — la replicación es transparente para ellas.
A continuación se explica cada paso en detalle, indicando qué se hace, por qué se hace y qué ocurre internamente en la pila de I/O de Linux (aplicación → sistema de archivos → dispositivo DRBD → disco → red), junto con verificaciones, advertencias y errores comunes.
Paso 1: Instalación de DRBD en ambos nodos
Qué se hace: Se instala el paquete de utilidades de DRBD en los dos servidores. En Debian, el paquete se denomina drbd-utils y contiene las herramientas de espacio de usuario (drbdadm, drbdsetup, drbdmeta) necesarias para configurar y manejar DRBD. En Debian, la porción de módulo de DRBD se distribuye con los kernels de Debian, por lo que instalar drbd-utils generalmente es suficiente sin compilar nada adicional. El comando es:
sudo apt update && sudo apt install -y drbd-utilsEsto se ejecuta en nodo-a y nodo-b. La opción -y auto-confirma la instalación. Se instalan las herramientas de administración que se comunican con el módulo del kernel para configurar y administrar los recursos DRBD.
Por qué se hace: DRBD tiene dos componentes: un módulo en el kernel (el driver de bloque replicado, con número mayor de dispositivo 147) y herramientas en user-space para su administración. Sin instalar drbd-utils, no tendríamos los comandos necesarios para crear metadatos, levantar recursos ni monitorear el estado de la replicación.
Internamente (capa afectada): Aquí solo añadimos software; aún no cambia nada en la pila de I/O. Tras la instalación, el módulo kernel estará disponible para cargarse al usarlo más adelante, y las herramientas de administración quedarán listas.
Verificación:
- Ejecutar
drbdadm --versionpara confirmar que la herramienta está disponible. - Verificar que el módulo se pueda cargar:
modinfo drbddebe mostrar información del módulo. - Comprobar el estado del servicio:
systemctl status drbd.
Errores comunes:
| Problema | Síntoma | Solución |
|---|---|---|
| Repositorios o red | apt falla al descargar paquetes | Verificar conexión a internet y que /etc/apt/sources.list tenga repositorios válidos |
| Permisos insuficientes | Error de permisos al instalar | Ejecutar como root o con sudo |
| Módulo kernel ausente (entorno virtual) | modprobe drbd falla con «Module not found» | En kernels virtuales, instalar linux-modules-extra-$(uname -r) |
| Versiones distintas entre nodos | Error de protocolo al conectar nodos | Asegurar que ambos nodos tengan la misma versión de drbd-utils |
Paso 2: Preparación del disco o partición en cada nodo
Qué se hace: Se designa un dispositivo de bloque dedicado en cada servidor para la replicación. En producción se suele usar un disco entero; en laboratorio, una partición (p.ej. /dev/sdb1). Es fundamental que esta partición: (a) tenga el mismo tamaño en ambos nodos, y (b)no esté montada ni en /etc/fstab. La verificación se realiza con:
lsblk -fEste comando lista los dispositivos de bloque. Debe confirmarse que /dev/sdb1 existe en ambos nodos, que no tenga punto de montaje asignado y que su tamaño sea idéntico.
Por qué se hace: DRBD replica bloques de datos crudos. Necesitamos almacenamiento dedicado que DRBD controlará exclusivamente. Ambas particiones deben ser de tamaño idéntico para que la réplica funcione correctamente. DRBD soporta cualquier dispositivo de bloque soportado por Linux: partición o disco duro completo, RAID por software, LVM o EVMS.
Internamente (capa afectada): Solo preparamos la capa de almacenamiento físico (el nivel más bajo de la pila I/O). No hemos configurado DRBD ni hay tráfico de red aún.
Verificación:
- Confirmar que la partición no esté en
/etc/fstabpara que no se monte en reinicios. - Ejecutar
mount | grep sdb1→ no debe mostrar nada. - Verificar tamaños:
lsblk -b /dev/sdb1en cada nodo → deben coincidir.
Errores comunes:
| Problema | Síntoma | Solución |
|---|---|---|
| Partición montada | drbdadm create-md falla al bloquear dispositivo | Desmontar con umount y verificar que ningún proceso la use (lsof /dev/sdb1) |
| Tamaño inconsistente | DRBD ajusta al menor, dejando espacio desperdiciado | Reparticionar al mismo tamaño antes de continuar |
| Confundir disco y partición | Apuntar a /dev/sdb cuando debe ser /dev/sdb1 | Verificar con lsblk y usar exactamente la ruta que aparece en la configuración |
| Datos previos en la partición | Advertencia de destrucción de datos al inicializar | Si los datos no son necesarios, confirmar; si lo son, respaldarlos primero |
Paso 3: Configuración básica del recurso DRBD (/etc/drbd.d/web.res)
Qué se hace: Se crea un archivo de configuración que define el recurso DRBD (el nombre lógico de la pareja de discos replicados). El archivo /etc/drbd.d/web.res debe ser idéntico en ambos nodosy contiene:
resource webdata {
protocol C;
on nodo-a {
device /dev/drbd0;
disk /dev/sdb1;
address 192.168.1.10:7789;
meta-disk internal;
}
on nodo-b {
device /dev/drbd0;
disk /dev/sdb1;
address 192.168.1.11:7789;
meta-disk internal;
}
}Explicación línea por línea
resource webdata { ... }— Nombre lógico del recurso. Se usará en todos los comandos posteriores (drbdadm up webdata, etc.). El archivo de configuración suele llevar el nombre del recurso (web.res) por claridad.protocol C;— Selecciona la replicación síncrona completa: la escritura se confirma a la aplicación solo después de que ambos nodos hayan persistido los datos en disco. De los tres protocolos disponibles (A, B, C), el Protocolo C ofrece la máxima protección ante pérdida de datos: si el Primario falla, el Secundario tiene garantizadamente toda la información. El costo es mayor latencia de escritura (incluye retardo de red + I/O remoto del secundario), pero en una LAN local este impacto es aceptable. ¿Por qué Protocolo C en el laboratorio? Porque estamos en red local de baja latencia, el rendimiento (throughput) es en gran medida independiente del protocolo elegido, y queremos demostrar la máxima garantía de consistencia que DRBD ofrece.
Comparativa rápida de protocolos:
| Protocolo | Tipo | Confirmación de escritura | Riesgo ante fallo del Primary |
|---|---|---|---|
| A (Asíncrono) | Tras disco local + paquete en buffer TCP | Posible pérdida de las actualizaciones más recientes | |
| B (Semisíncrono) | Tras disco local + recepción en memoria remota | Datos normalmente seguros; riesgo si ambos nodos fallan simultáneamente | |
| C (Síncrono) ✅ | Tras disco local + disco remoto | Cero pérdida de datos |
- Bloques
on nodo-a { ... }yon nodo-b { ... }— Definen las propiedades de cada extremo. El nombre dentro deon <nombre>debe coincidir exactamente con el nombre de host del nodo (resultado deuname -nohostname). Si no coincide, DRBD no sabrá qué configuración aplicar en cada máquina.device /dev/drbd0;— Nombre del dispositivo virtual que DRBD creará. DRBD asigna el número mayor 147 a sus dispositivos de bloque. Este/dev/drbd0será el que montemos y usemos como si fuera un disco local.disk /dev/sdb1;— Ruta del dispositivo físico de respaldo (la partición preparada en el Paso 2). DRBD actuará como capa intermedia entre este disco y el sistema de archivos.address <IP:puerto>;— Dirección IP y puerto TCP para la comunicación de replicación. Por defecto, DRBD utiliza los puertos TCP 7788 en adelante. En esta configuración elegimos el puerto 7789, que es igualmente válido. Ambos extremos deben usar el mismo puerto para un recurso dado. Es recomendable usar una red dedicada para el tráfico de replicación por volumen y seguridad, ya que el tráfico entre espejos DRBD no está cifrado por defecto; para un intercambio seguro se recomienda una VPN.meta-disk internal;— Indica que los metadatos de DRBD (bitmaps de sincronización, identificadores de generación, etc.) se almacenarán dentro de la misma partición de datos, reservando un pequeño espacio al final de/dev/sdb1. Ejemplo: si el dispositivo crudo tiene 1024 MB, el dispositivo DRBD dispondrá de solo 1023 MB para datos, con aproximadamente 70 KB reservados para metadatos.
Por qué se hace: Esta configuración define cómo se conectará y comportará el recurso replicado: qué disco local usar, a qué compañero conectarse por red, con qué garantías de sincronización y dónde guardar los metadatos internos.
Internamente (capa afectada): Solo se modifica la capa de configuración (espacio de usuario). Todavía no se han creado dispositivos ni comunicaciones de red. Estamos preparando la «hoja de ruta» que DRBD seguirá.
Verificación:
- Tras copiar el archivo a ambos nodos, ejecutar
drbdadm dump allpara verificar que DRBD interpreta la configuración sin errores de sintaxis. - Confirmar que los nombres de host coinciden: ejecutar
uname -nen cada nodo y verificar que corresponda con la secciónon <nombre>. - Verificar conectividad de red:
ping 192.168.1.11desde nodo-a (y viceversa). - Verificar que el puerto 7789/tcp no esté bloqueado por firewall (
iptables -Lonft list ruleset).
Errores comunes / Advertencias:
| Problema | Síntoma | Solución |
|---|---|---|
Error de sintaxis en .res | drbdadm indica número de línea con error | Revisar corchetes, puntos y coma, y ortografía |
| Nombre de host incorrecto | «No valid configuration found for this host» | uname -n debe coincidir con la sección on <nombre> en el archivo |
| Archivo no copiado al segundo nodo | Segundo nodo queda en StandAlone, no reconoce recurso | Copiar con scp el archivo .res al otro nodo |
| Puerto bloqueado por firewall | Los nodos no conectan (cs:Timeout) | Abrir el puerto TCP configurado en ambos nodos |
Paso 4: Inicializar el recurso DRBD en ambos nodos (metadatos y arranque)
Se ejecutan dos comandos en cada nodo: primero se crean los metadatos, luego se activa el recurso.
Comando 4.1 — Crear metadatos: drbdadm create-md webdata
Este comando inicializa el área de metadatos de DRBD en el dispositivo de respaldo (/dev/sdb1). Al ejecutarlo, si la partición contiene datos previos, DRBD mostrará una advertencia y pedirá confirmación explícita (debe escribirse la palabra completa yes):
About to create a new drbd meta data block on /dev/sdb1.
==> This might destroy existing data! <==
Do you want to proceed? [need to type 'yes' to confirm] yes
Creating meta data...
initialising activity log
NOT initialized bitmap
New drbd meta data block successfully created.create-md escribe estructuras de control al final de la partición: un bitmap de seguimiento de bloques modificados, un activity log para la consistencia de escrituras y campos como el UUID del conjunto de datos. Solo se ejecuta una vez, antes del primer uso del recurso.
Comando 4.2 — Activar recurso: drbdadm up webdata
Este comando adjunta el dispositivo de bloque real al driver DRBD y levanta el dispositivo virtual/dev/drbd0 en cada nodo. Efectúa internamente la carga de la configuración del recurso, el attach del disco y el intento de conexión al nodo par.
Por qué se hace: Sin los metadatos, DRBD no podría rastrear qué bloques han sido modificados para la replicación diferencial. Sin drbdadm up, el dispositivo virtual no existe y los nodos no se comunican. Este paso pone en marcha el motor de DRBD.
Internamente (capas afectadas):
- create-md: actúa sobre la capa de disco físico, escribiendo la sección de metadatos.
- up: involucra la capa de red (DRBD inicia la comunicación TCP entre los nodos en el puerto 7789) y la creación del dispositivo de bloque virtual
/dev/drbd0en la capa de bloques local.
Estado esperado tras
drbdadm upen ambos nodos: Al no haber definido aún un Primario, ambos nodos quedan como Secondary/Secondary con discos Inconsistent/Inconsistent. Esta salida es normal y esperada en una configuración nueva:0: cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent CEsto indica: nodos conectados (cs:Connected), ambos en rol Secundario (ninguno es Primario), y discos inconsistentes (DRBD no sabe cuál tiene datos válidos porque falta la sincronización inicial).
En DRBD 9 con drbdadm status, la salida equivalente tiene un formato más legible:
webdata role:Secondary
disk:Inconsistent
nodo-b role:Secondary
disk:InconsistentVerificación:
- Dispositivo virtual creado:
ls -l /dev/drbd*→ debe existir/dev/drbd0. lsblk→ debe listar un dispositivodrbd0de tamaño ligeramente inferior al desdb1.- Conexión de red:
cat /proc/drbdodrbdadm status→cs:Connected. - Ambos en Secondary con Inconsistent → correcto, se resolverá en el siguiente paso.
Errores comunes:
| Problema | Síntoma | Solución |
|---|---|---|
No confirmar yes en create-md | Comando se aborta sin cambios | Relanzar y escribir la palabra completa yes (no «y», no Enter solo) |
Solo un nodo ejecutó up | Estado WFConnection (esperando al par) | Ejecutar drbdadm up webdata también en el otro nodo |
| Módulo no cargado | Error «can’t open device» | Ejecutar modprobe drbd manualmente antes de drbdadm up |
| Firewall bloquea puerto | cs:Timeout o Connecting persistente | Verificar y abrir el puerto TCP 7789 en ambos nodos |
| Dispositivo inexistente | Error al adjuntar disco | Verificar que la ruta /dev/sdb1 es correcta con lsblk |
Paso 5: Forzar un nodo Primario (sincronización inicial)
Qué se hace: Designamos a nodo-a como Primario para arrancar la replicación inicial. En nodo-a se ejecuta:
drbdadm — –overwrite-data-of-peer primary webdata
La construcción con doble guion -- indica a drbdadm que pase la opción --overwrite-data-of-peer al comando subyacente drbdsetup. Esta opción le dice a DRBD: «Promociona este nodo a Primary, considerando que mis datos son la copia buena y sobreescribiendo la del peer». Se debe ejecutar una sola vez, solo en el nodo elegido como fuente, y solo durante la configuración inicial del recurso.
Por qué se hace: DRBD necesita saber qué lado tiene los datos «correctos» para comenzar a replicar. La guía oficial de LINBIT advierte: «Si se realiza la sincronización inicial en la dirección equivocada, se perderán esos datos. Proceda con precaución». En una configuración nueva con discos vacíos, la elección es arbitraria; pero en producción, si un nodo ya tuviera datos valiosos, se debe elegir ese como Primario inicial.
Sin esta orden, ningún nodo se dejará promover a Primario: DRBD rechaza el cambio con el error «State change failed: (-2) Need access to UpToDate data», protegiéndonos contra la promoción de un nodo sin datos válidos.
Internamente (capas afectadas):
- Nodo-a pasa a estado Primary con acceso de lectura/escritura a
/dev/drbd0. Nodo-b permanece Secondary (solo lectura, sin exponer/dev/drbd0al sistema de archivos). - DRBD inicia la sincronización completa: nodo-a se convierte en
SyncSourcey nodo-b enSyncTarget. Nodo-a envía todos los bloques de datos de su partición vía red al nodo-b, que los almacena en su propio/dev/sdb1. - Hasta completarse, el estado de los discos es UpToDate/Inconsistent (Primario actualizado, Secundario aún incompleto). Al finalizar (100%), ambos quedarán UpToDate/UpToDate.
Dato importante: Según la documentación oficial de LINBIT, «su dispositivo DRBD está totalmente operativo incluso antes de que la sincronización inicial haya terminado (aunque con rendimiento ligeramente reducido). Si se partió de discos vacíos, ya es posible crear un sistema de archivos en el dispositivo». No obstante, para esta práctica de laboratorio es recomendable esperar al 100% para confirmar que todo funciona antes de continuar.
Verificación: Observar el progreso de la sincronización con cualquiera de estos métodos:
cat /proc/drbd— muestra el porcentaje de avance y velocidad. Ejemplo típico durante la sincronización:
0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C
[>....................] sync'ed: 0.4% (1048508/1048508)K
finish: 0:43:41 speed: 0 (0) K/secwatch -n1 cat /proc/drbd— refresca el estado cada segundo para ver el progreso en tiempo real. PresionarCtrl+Cpara detener la observación.
drbdadm status webdata— formato DRBD 9 más legible.
El estado final esperado al completar la sincronización:
0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C
Donde UpToDate/UpToDate confirma que ambos nodos tienen datos idénticos y el recurso está totalmente operativo.
Errores comunes / Advertencias:
| Problema | Síntoma | Solución |
|---|---|---|
| Omitir este paso | No se puede formatear ni montar: «Need access to UpToDate data» | Ejecutar el comando de promoción con --overwrite-data-of-peer |
| Parámetros mal escritos | Error de sintaxis o rechazo | Verificar exactamente: -- --overwrite-data-of-peer (doble guion, espacio, doble guion + opción) |
| Ejecutar en ambos nodos | Split-brain: dos primarios divergentes → DRBD corta la conexión | Nunca ejecutar la promoción forzada en más de un nodo. Si ocurrió, se requiere resolución manual de split-brain |
| Sincronización muy lenta | Progreso bajo (K/sec) | Verificar velocidad de red entre nodos; considerar configurar syncer { rate <velocidad>; } en el archivo de recursos |
Paso 6: Crear el sistema de archivos en el dispositivo DRBD (nodo Primario)
Qué se hace: Con el recurso sincronizado (UpToDate/UpToDate) y en rol Primary en nodo-a, se formatea /dev/drbd0 con ext4:
sudo mkfs.ext4 /dev/drbd0
Este comando se ejecuta solo en el nodo Primario (nodo-a), una única vez. Crea las estructuras del sistema de archivos ext4 (superbloque, tabla de inodos, mapas de bits, etc.) sobre el dispositivo de bloque replicado.
Por qué se hace: Necesitamos un sistema de archivos para almacenar ficheros de forma estructurada. Ext4 es una elección estándar en Linux. DRBD presenta /dev/drbd0 como un disco convencional al sistema, por lo que mkfs.ext4 funciona igual que sobre cualquier disco local. En configuraciones single-primary como la nuestra, se usan sistemas de archivos convencionales (ext4, XFS). Un sistema de archivos de clúster (GFS2, OCFS2) solo se necesitaría en configuraciones dual-primary, ya que DRBD no puede agregar capacidad activo-activo a sistemas de archivos que no la poseen nativamente.
Internamente (capas afectadas): El comando actúa a nivel de capa de sistema de archivos sobre el dispositivo de bloque virtual DRBD. Los cambios producidos por mkfs son interceptados por DRBD en nodo-a, que los replica por red a nodo-b en tiempo real. Al finalizar, ambos discos físicos contienen una copia idéntica del sistema de archivos ext4 recién creado, aunque nodo-b no puede acceder a esos datos todavía (permanece en rol Secondary).
Verificación:
mkfs.ext4produce una salida indicando que las estructuras de ext4 fueron creadas (cantidad de bloques, inodos, etc.).- Confirmar:
blkid /dev/drbd0en nodo-a → debe mostrarTYPE="ext4"con un UUID asignado. file -s /dev/drbd0en nodo-a → debe indicar «Linux rev 1.0 ext4 filesystem».
Errores comunes / Advertencias:
| Problema | Síntoma | Solución |
|---|---|---|
| Ejecutar en nodo Secundario | Error de permisos o dispositivo ocupado | Ejecutar solo en el nodo que está en rol Primary |
Formatear /dev/sdb1 en vez de /dev/drbd0 | ⚠️ Crítico: datos escritos fuera de DRBD, nodo-b no recibe nada → inconsistencia permanente | Toda operación debe hacerse sobre /dev/drbdX, nunca sobre el dispositivo crudo, ya que DRBD usa la última parte del dispositivo crudo para metadatos y el acceso directo causará datos inconsistentes |
| Formatear en ambos nodos | Innecesario y peligroso → se necesitaría re-promover al otro nodo, rompiendo la sincronía | Formatear solo una vez, en el Primary. El Secondary ya tiene la réplica a nivel de bloque |
| Usar un FS de clúster (GFS2/OCFS2) sin dual-primary | Error o comportamiento inesperado | En modo single-primary, usar ext4 o XFS es lo correcto |
Paso 7: Montar el sistema de archivos replicado solo en el nodo Primario activo
Qué se hace: En nodo-a (Primary) se monta el nuevo sistema de archivos ext4 en el directorio de destino:
sudo mount /dev/drbd0 /var/www/html
Tras esto, el directorio /var/www/html en nodo-a queda respaldado por el dispositivo DRBD replicado. En nodo-b no se monta nada: su DRBD sigue en modo Secondary.
Por qué se hace: Montar el dispositivo permite que las aplicaciones (p.ej. un servidor Apache) utilicen el sistema de archivos replicado. Solo el Primario monta el sistema de archivos en configuraciones activo/pasivo, ya que un dispositivo DRBD en rol Secondaryprohíbe completamente el acceso, tanto de lectura como de escritura. La razón de prohibir incluso la lectura es la necesidad de mantener la coherencia de caché, que sería imposible si un recurso secundario fuera accesible de cualquier forma.
Internamente (capas afectadas): Montar implica que la capa de sistema de archivos (ext4) entra en juego sobre el dispositivo de bloque DRBD en nodo-a. Las escrituras realizadas por las aplicaciones producen operaciones de I/O sobre /dev/drbd0. DRBD en nodo-a intercepta cada escritura y la envía por la red a nodo-b (que la persiste en su disco local), manteniendo la sincronización en tiempo real. Las lecturas se atienden localmente desde el disco de nodo-a, sin latencia de red adicional.
Verificación:
mount | grep drbd0odf -hen nodo-a → debe mostrar/dev/drbd0montado en/var/www/htmlcon el tamaño y espacio disponible correspondientes.- Crear un archivo de prueba para confirmar la replicación: Shellecho «Hola DRBD» > /var/www/html/prueba.txt
Mostrar más líneas Aunque el archivo no será visible en nodo-b (porque no tiene montado el sistema de archivos), los datos ya se encuentran replicados a nivel de bloque. Para comprobarlo, se realizaría un cambio de roles manual (fuera del alcance de esta práctica) y se verificaría que el archivo aparece al montar en el otro nodo. - Estado de DRBD tras montar y escribir:
cat /proc/drbd→ debe seguir mostrandoConnected, Primary/Secondary, UpToDate/UpToDate.
Errores comunes / Advertencias:
| Problema | Síntoma | Solución |
|---|---|---|
| ⚠️ Montar en AMBOS nodos con ext4 | Corrupción de datos garantizada: ext4 no soporta acceso concurrente multi-nodo | Jamás montar el FS en el nodo Secondary con un FS convencional |
| Intentar montar en nodo Secondary | Error de permisos / dispositivo inaccesible | Montar solo en el nodo en rol Primary |
| Directorio destino no existe | Error «mount point does not exist» | Crear el directorio previamente: mkdir -p /var/www/html |
| Montar manualmente y luego usar Pacemaker | Conflicto entre el montaje manual y el gestor de clúster | Si se planea usar Pacemaker (siguiente fase), no montar manualmente — Pacemaker se encargará de controlar montaje/desmontaje |
Tabla resumen: Comando → Función → Verificación → Error frecuente
| Paso | Comando | Qué hace | Verificación | Error frecuente |
|---|---|---|---|---|
| 1 | apt install -y drbd-utils | Instala herramientas de administración DRBD | drbdadm --version | Módulo kernel ausente en entorno virtual |
| 2 | lsblk -f | Identifica y verifica la partición libre | Sin punto de montaje, tamaño idéntico en ambos nodos | Partición montada o tamaño distinto |
| 3 | nano /etc/drbd.d/web.res | Define el recurso, protocolo, nodos, IPs y metadatos | drbdadm dump all sin errores | Nombre de host no coincide con uname -n |
| 4a | drbdadm create-md webdata | Inicializa metadatos DRBD en el disco | Mensaje «successfully created» | No escribir yes completo al confirmar |
| 4b | drbdadm up webdata | Levanta /dev/drbd0 y conecta con el par | cat /proc/drbd → cs:Connected | Ejecutar solo en un nodo → WFConnection |
| 5 | drbdadm -- --overwrite-data-of-peer primary webdata | Promociona a Primary e inicia sincronización inicial | UpToDate/UpToDate tras completar | Error «Need access to UpToDate data» si se omite la opción |
| 6 | mkfs.ext4 /dev/drbd0 | Crea sistema de archivos ext4 sobre el volumen replicado | blkid /dev/drbd0 → TYPE="ext4" | Formatear /dev/sdb1 en vez de /dev/drbd0 |
| 7 | mount /dev/drbd0 /var/www/html | Monta el FS replicado en el directorio de datos | df -h muestra /dev/drbd0 montado | Intentar montar en el nodo Secondary |
Nota sobre la arquitectura por capas y el flujo completo
Para recapitular cómo la pila de I/O de Linux opera tras completar todos los pasos, la guía oficial de LINBIT describe la posición de DRBD mediante su «Figure 1: DRBD’s position within the Linux I/O stack»:
Aplicación (Apache, MySQL, etc.)
↓ lectura/escritura de archivos
Sistema de archivos (ext4)
↓ operaciones de bloque
DRBD (/dev/drbd0) ←——→ Red TCP/IP (puerto 7789) ←——→ DRBD remoto (/dev/drbd0)
↓ ↓
Disco físico (/dev/sdb1) Disco físico (/dev/sdb1)
[nodo-a: Primary] [nodo-b: Secondary]
- Escritura: La aplicación escribe → ext4 traduce a operación de bloque → DRBD intercepta, escribe en disco local y simultáneamente envía por red al secundario → con Protocolo C, la escritura se confirma solo cuando ambos discos han persistido los datos.
- Lectura: Se atiende localmente desde el disco de nodo-a, sin latencia de red.
- Failover: Si nodo-a falla, un gestor de clúster (Pacemaker, que se configurará en una práctica posterior) promueve a nodo-b a Primary, monta el FS y arranca los servicios. DRBD provee la replicación de datos, pero no gestiona la conmutación de servicios ni la supervisión de nodos — eso corresponde al gestor de clúster.
¿Por qué aún no usamos Pacemaker?
En esta práctica se configuró DRBD de forma manual (promoción manual del Primary, montaje manual). En un entorno de producción real, esto es insuficiente: si nodo-a falla, nadie promoverá automáticamente a nodo-b. Para eso se integra DRBD con Pacemaker (gestor de recursos de clúster) usando Corosync (capa de comunicación). Pacemaker automatiza:
- Monitorear la salud de los nodos.
- Promover el Secondary a Primary si el Primary falla.
- Montar el sistema de archivos.
- Arrancar el servicio (Apache, etc.).
- Mover la IP virtual al nuevo nodo activo.
La configuración de Pacemaker/Corosync con DRBD será objeto de la siguiente práctica. La documentación oficial de LINBIT cubre explícitamente esta integración, incluyendo configuraciones avanzadas con LVM, GFS, OCFS2 y el software DRBD Reactor como alternativa más sencilla de configurar. Primero se debe dominar la base (DRBD manual) para entender qué hace Pacemaker «por debajo del capó».
Puntos clave para el estudiante
⚠️ NUNCA montar en ambos nodos con ext4
Un dispositivo DRBD en rol Secondary prohíbe completamente el acceso (ni lectura ni escritura) para mantener la coherencia de caché. Montar un FS convencional en ambos nodos simultáneamente causaría corrupción de datos inmediata.
⚠️ NUNCA operar sobre el disco crudo
Todas las operaciones (formatear, montar, leer, escribir) deben hacerse sobre /dev/drbd0, nunca sobre /dev/sdb1. DRBD usa la última parte del dispositivo crudo para metadatos; acceder directamente al disco subyacente causará datos inconsistentes.
🔑 DRBD replica bloques, no archivos
DRBD opera en la capa de bloques del kernel, debajo del sistema de archivos. No «sabe» qué archivos contiene el volumen — replica cada bloque modificado de forma transparente. Esto lo hace agnóstico de la carga de trabajo: sirve igual para bases de datos, servidores web o máquinas virtuales.
📊 Protocolo C = máxima seguridad
En Protocolo C, cada escritura se confirma a la aplicación solo después de que ambos nodos hayan persistido los datos en disco. Esto garantiza cero pérdida de datos ante failover, a cambio de mayor latencia por escritura (retardo de red + I/O del segundo nodo).