{"id":2365,"date":"2026-04-24T01:10:05","date_gmt":"2026-04-24T01:10:05","guid":{"rendered":"https:\/\/dsantana.uas.edu.mx\/?p=2365"},"modified":"2026-04-24T19:18:47","modified_gmt":"2026-04-24T19:18:47","slug":"implementacion-de-un-cluster-de-alta-disponibilidad-con-replicacion-de-datos-en-tiempo-real","status":"publish","type":"post","link":"https:\/\/dsantana.uas.edu.mx\/index.php\/2026\/04\/24\/implementacion-de-un-cluster-de-alta-disponibilidad-con-replicacion-de-datos-en-tiempo-real\/","title":{"rendered":"Implementaci\u00f3n de un Cl\u00faster de Alta Disponibilidad con Replicaci\u00f3n de Datos en Tiempo Real"},"content":{"rendered":"\n<figure class=\"wp-block-image size-full\"><img fetchpriority=\"high\" decoding=\"async\" width=\"1024\" height=\"1024\" src=\"https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/Implementacion-de-un-Cluster-de-Alta-Disponibilidad-con-Replicacion-de-Datos-en-Tiempo-Real.png\" alt=\"\" class=\"wp-image-2366\" srcset=\"https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/Implementacion-de-un-Cluster-de-Alta-Disponibilidad-con-Replicacion-de-Datos-en-Tiempo-Real.png 1024w, https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/Implementacion-de-un-Cluster-de-Alta-Disponibilidad-con-Replicacion-de-Datos-en-Tiempo-Real-300x300.png 300w, https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/Implementacion-de-un-Cluster-de-Alta-Disponibilidad-con-Replicacion-de-Datos-en-Tiempo-Real-150x150.png 150w, https:\/\/dsantana.uas.edu.mx\/wp-content\/uploads\/2026\/04\/Implementacion-de-un-Cluster-de-Alta-Disponibilidad-con-Replicacion-de-Datos-en-Tiempo-Real-768x768.png 768w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p><\/p>\n\n\n\n<h1 class=\"wp-block-heading\">DRBD (Dispositivo de Bloque Replicado Distribuido): Arquitectura y Funcionamiento T\u00e9cnico<\/h1>\n\n\n\n<p><strong>DRBD<\/strong> (<em>Distributed Replicated Block Device<\/em>) es una soluci\u00f3n de almacenamiento replicado basada en software, de tipo <em>shared-nothing<\/em>, que refleja el contenido de dispositivos de bloque (discos duros, particiones, vol\u00famenes l\u00f3gicos, etc.) entre hosts. Funciona como un <strong>RAID-1 por red<\/strong>: replica datos <strong>en tiempo real<\/strong> de forma continua mientras las aplicaciones los modifican, de manera <strong>transparente<\/strong> (las aplicaciones no necesitan saber que los datos est\u00e1n en m\u00faltiples hosts), y de forma <strong>s\u00edncrona o as\u00edncrona<\/strong> seg\u00fan la configuraci\u00f3n elegida. Es una tecnolog\u00eda ampliamente utilizada para implementar <strong>alta disponibilidad (HA)<\/strong> en Linux: si un servidor falla, el otro posee una r\u00e9plica actualizada de los datos para continuar operando. DRBD es software de c\u00f3digo abierto, disponible en la plataforma Linux.<\/p>\n\n\n\n<p><em>Dado que la imagen de referencia mencionada no est\u00e1 disponible para su an\u00e1lisis directo, la siguiente explicaci\u00f3n describe la arquitectura t\u00edpica que aparece en diagramas est\u00e1ndares de DRBD, explicitando las suposiciones realizadas.<\/em><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Arquitectura por Capas de DRBD (Pila de I\/O Linux)<\/h2>\n\n\n\n<p><strong>DRBD es un m\u00f3dulo del kernel de Linux que se ubica entre el planificador de I\/O (capa inferior) y el sistema de archivos (capa superior)<\/strong>. Espec\u00edficamente, constituye un controlador para un <strong>dispositivo de bloque virtual<\/strong>, posicion\u00e1ndose cerca de la parte inferior de la pila de I\/O del sistema. La gu\u00eda oficial de DRBD 9 hace referencia a esta disposici\u00f3n en su \u00abFigura 1: Posici\u00f3n de DRBD dentro de la pila de I\/O de Linux\u00bb. <a href=\"https:\/\/www.linuxparty.es\/75-hardware\/10502-como-configurar-drbd-para-replicar-el-almacenamiento-en-dos-servidores-centos-7-y-8.html\">[linuxparty.es]<\/a><a href=\"https:\/\/linbit.com\/drbd-user-guide\/drbd-guide-9_0-en\/\">[linbit.com]<\/a><\/p>\n\n\n\n<p>La pila, de arriba hacia abajo, se organiza as\u00ed:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Aplicaciones del usuario<\/strong> (base de datos, servidor web, etc.) \u2014 generan operaciones de lectura\/escritura sobre archivos.<\/li>\n\n\n\n<li><strong>Sistema de archivos<\/strong> (EXT4, XFS, etc.) \u2014 traduce operaciones de archivo a operaciones de bloque sobre el dispositivo montado.<\/li>\n\n\n\n<li><strong>DRBD (dispositivo virtual <code>\/dev\/drbdX<\/code>)<\/strong> \u2014 intercepta cada operaci\u00f3n de bloque y la replica al nodo remoto antes de (o simult\u00e1neamente a) pasarla al dispositivo local subyacente. El dispositivo DRBD tiene un <strong>n\u00famero mayor (<em>major number<\/em>) de 147<\/strong> y n\u00fameros menores a partir de 0. <code>udev<\/code> crea adem\u00e1s enlaces simb\u00f3licos por nombre de recurso para facilitar la administraci\u00f3n.<\/li>\n\n\n\n<li><strong>Dispositivo de bloque local<\/strong> (partici\u00f3n, disco completo, RAID por software, LVM o EVMS) \u2014 el almacenamiento f\u00edsico subyacente donde DRBD persiste los datos.<\/li>\n\n\n\n<li><strong>Red TCP\/IP<\/strong> \u2014 canal de comunicaci\u00f3n con el nodo remoto (puertos <strong>TCP 7788<\/strong> en adelante, por defecto) a trav\u00e9s de una interfaz de red, idealmente <strong>dedicada<\/strong> para DRBD.<\/li>\n<\/ol>\n\n\n\n<p>DRBD es, por definici\u00f3n y por mandato de la arquitectura del kernel de Linux, <strong>agn\u00f3stico de las capas superiores<\/strong>. No puede agregar m\u00e1gicamente funcionalidades que las capas superiores no posean; por ejemplo, <strong>no puede auto-detectar corrupci\u00f3n del sistema de archivos ni agregar capacidad de cl\u00faster activo-activo<\/strong> a sistemas de archivos como ext3 o XFS que no la soportan nativamente.<\/p>\n\n\n\n<p><strong>Metadatos de DRBD:<\/strong> DRBD almacena metadatos internos en cada nodo. Cuando se usa la opci\u00f3n <code>meta-disk internal<\/code> (lo m\u00e1s habitual), estos metadatos se reservan en la parte final del dispositivo de bloque subyacente. Por ejemplo, si el dispositivo crudo tiene <strong>1024 MB<\/strong>, el dispositivo DRBD dispondr\u00e1 de solo <strong>1023 MB<\/strong> para datos del usuario, con aproximadamente <strong>70 KB<\/strong> reservados para metadatos. <strong>Es fundamental que toda manipulaci\u00f3n de datos se haga sobre <code>\/dev\/drbdX<\/code><\/strong> y no sobre el dispositivo crudo, ya que acceder al dispositivo directamente <strong>causar\u00e1 inconsistencias<\/strong>.<\/p>\n\n\n\n<p><strong>Herramientas de administraci\u00f3n en espacio de usuario:<\/strong> DRBD incluye tres herramientas que se comunican con el m\u00f3dulo del kernel para configurar y administrar los recursos, de mayor a menor nivel:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><th>Herramienta<\/th><th>Nivel<\/th><th>Funci\u00f3n<\/th><\/tr><tr><th><strong><code>drbdadm<\/code><\/strong><\/th><td>Alto<\/td><td>Herramienta principal. Obtiene par\u00e1metros de <code>\/etc\/drbd.conf<\/code> y act\u00faa como <em>front-end<\/em> para <code>drbdsetup<\/code> y <code>drbdmeta<\/code>. Soporta modo <em>dry-run<\/em> con la opci\u00f3n <code>-d<\/code>.<\/td><\/tr><tr><th><strong><code>drbdsetup<\/code><\/strong><\/th><td>Bajo<\/td><td>Configura directamente el m\u00f3dulo DRBD cargado en el kernel. Todos los par\u00e1metros se pasan por l\u00ednea de comandos. Rara vez se usa directamente.<\/td><\/tr><tr><th><strong><code>drbdmeta<\/code><\/strong><\/th><td>Bajo<\/td><td>Permite crear, volcar, restaurar y modificar estructuras de metadatos DRBD. Tambi\u00e9n de uso infrecuente para la mayor\u00eda de los usuarios.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">2. Topolog\u00eda T\u00edpica: Dos Nodos con Replicaci\u00f3n por Red<\/h2>\n\n\n\n<p>Los despliegues est\u00e1ndares de DRBD constan de <strong>dos servidores<\/strong> (Nodo A y Nodo B) conectados por red. Un diagrama de referencia t\u00edpico (como la \u00abIlustraci\u00f3n t\u00e9cnica y educativa\u00bb presente en los materiales de clase) muestra un cl\u00faster activo\/pasivo en Linux con dos servidores: el <strong>Nodo A (activo)<\/strong> ejecutando Apache con una <strong>IP virtual (VIP)<\/strong> visible a los clientes, y el <strong>Nodo B (pasivo)<\/strong> en espera. Ambos nodos aparecen conectados por enlaces que representan <strong>Pacemaker, Corosync y DRBD<\/strong>, mostrando replicaci\u00f3n en tiempo real del directorio <code>\/var\/www\/html<\/code>. El diagrama ilustra adem\u00e1s un evento de <strong>failover<\/strong> donde la IP virtual y el servicio Apache se mueven autom\u00e1ticamente del Nodo A al Nodo B cuando el Nodo A falla.<\/p>\n\n\n\n<p>En esta disposici\u00f3n <em>shared-nothing<\/em>:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>El <strong>Nodo A (Primary)<\/strong> monta el volumen DRBD con un sistema de archivos convencional (p.ej., EXT4) y aloja el servicio activo.<\/li>\n\n\n\n<li>El <strong>Nodo B (Secondary)<\/strong> mantiene una copia espejo del volumen pero <strong>no lo monta<\/strong> mientras sea secundario; los datos est\u00e1n replicados a nivel de bloque pero no son accesibles como archivos hasta una eventual promoci\u00f3n.<\/li>\n\n\n\n<li>La replicaci\u00f3n se realiza de forma continua a trav\u00e9s de una <strong>interfaz de red dedicada<\/strong> para DRBD.<\/li>\n<\/ul>\n\n\n\n<p><strong>Tr\u00e1fico de red no cifrado:<\/strong> La documentaci\u00f3n oficial de SUSE advierte que el tr\u00e1fico de datos entre espejos DRBD <strong>no est\u00e1 cifrado<\/strong>. Para un intercambio seguro de datos, se recomienda implementar una <strong>VPN<\/strong> sobre la conexi\u00f3n de replicaci\u00f3n.<\/p>\n\n\n\n<p>DRBD permite usar <strong>cualquier dispositivo de bloque soportado por Linux<\/strong> como almacenamiento subyacente: partici\u00f3n o disco duro completo, RAID por software, LVM o EVMS.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Flujo de I\/O: Escrituras y Lecturas<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Flujo de escritura (modo single-primary)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Aplicaci\u00f3n escribe:<\/strong> La aplicaci\u00f3n emite una escritura sobre el dispositivo montado (<code>\/dev\/drbdX<\/code>) en el nodo Primary.<\/li>\n\n\n\n<li><strong>DRBD intercepta y replica:<\/strong> Las escrituras al nodo primario se transfieren al dispositivo de bloque de nivel inferior <strong>y simult\u00e1neamente se propagan<\/strong> al nodo secundario. El secundario transfiere a su vez los datos a su propio dispositivo de bloque de nivel inferior.<\/li>\n\n\n\n<li><strong>Confirmaci\u00f3n (<em>acknowledge<\/em>):<\/strong> El momento de la confirmaci\u00f3n a la aplicaci\u00f3n depende del <strong>protocolo de replicaci\u00f3n<\/strong> configurado (A, B o C), como se detalla en la siguiente secci\u00f3n.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Flujo de lectura<\/h3>\n\n\n\n<p><strong>Toda la I\/O de lectura se ejecuta localmente<\/strong> en el nodo primario, accediendo directamente al disco local sin a\u00f1adir latencia de red, a menos que se configure <strong>balanceo de lectura<\/strong> (<em>read-balancing<\/em>), una opci\u00f3n avanzada donde el primario podr\u00eda leer tambi\u00e9n desde el secundario v\u00eda red para distribuir carga. Esta opci\u00f3n no es habitual en configuraciones est\u00e1ndar. El nodo secundario no atiende lecturas porque no tiene aplicaciones activas ni un sistema de archivos montado.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Flujo en modo dual-primary<\/h3>\n\n\n\n<p>En configuraci\u00f3n activo-activo, <strong>ambos nodos<\/strong> pueden originar escrituras; cada escritura local en un nodo se replica al otro. Las lecturas son atendidas localmente por cada nodo para sus propias aplicaciones. Un sistema de archivos de disco compartido (GFS2, OCFS2) junto con un <strong>gestor de bloqueos distribuido<\/strong> coordina la coherencia de acceso concurrente. Este modo de operaci\u00f3n requiere latencias de red muy bajas y coordinaci\u00f3n precisa.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">4. Modos de Replicaci\u00f3n: Protocolo A, B y C<\/h2>\n\n\n\n<p>DRBD soporta <strong>tres protocolos de replicaci\u00f3n<\/strong> que representan tres grados distintos de sincron\u00eda. La elecci\u00f3n influye en dos factores del despliegue: <strong>protecci\u00f3n<\/strong> (de datos ante fallo) y <strong>latencia<\/strong> (percibida por la aplicaci\u00f3n). El <strong>rendimiento<\/strong> (<em>throughput<\/em>), por el contrario, es en gran medida independiente del protocolo seleccionado.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Protocolo A \u2014 Replicaci\u00f3n as\u00edncrona<\/h3>\n\n\n\n<p>Las operaciones de escritura locales en el nodo primario se consideran completadas tan pronto como la escritura en disco local ha terminado <strong>y el paquete de replicaci\u00f3n ha sido colocado en el <em>buffer<\/em> TCP de env\u00edo local<\/strong>. En caso de un failover forzado, <strong>puede ocurrir p\u00e9rdida de datos<\/strong>: los datos en el nodo en espera son consistentes despu\u00e9s del failover, pero las actualizaciones m\u00e1s recientes realizadas antes del failover podr\u00edan perderse. El Protocolo A se usa con mayor frecuencia en <strong>escenarios de replicaci\u00f3n a larga distancia<\/strong>. <\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Protocolo B \u2014 Replicaci\u00f3n semis\u00edncrona (\u00abs\u00edncrono de memoria\u00bb)<\/h3>\n\n\n\n<p>Tambi\u00e9n conocido como <strong>protocolo s\u00edncrono de memoria<\/strong> (<em>memory-synchronous<\/em>). En este modo, la escritura se confirma una vez que el disco local ha terminado <strong>y<\/strong> el nodo remoto ha acusado recibo de los datos (los ha recibido en su capa de red\/memoria). No espera la persistencia en disco del secundario. Esto reduce la ventana de posible p\u00e9rdida respecto al Protocolo A: si solo el Primario falla, el Secundario ya tiene los datos recibidos; sin embargo, si ambos nodos fallan simult\u00e1neamente antes de que el Secundario persista a disco, los datos podr\u00edan perderse.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Protocolo C \u2014 Replicaci\u00f3n s\u00edncrona (completamente)<\/h3>\n\n\n\n<p>Es <strong>con diferencia, el protocolo de replicaci\u00f3n m\u00e1s utilizado<\/strong> en configuraciones DRBD. La escritura se confirma solo despu\u00e9s de que <strong>ambos nodos<\/strong> hayan persistido los datos en disco. Garantiza la m\u00e1xima consistencia: ante un failover, <strong>ninguna actualizaci\u00f3n se pierde<\/strong> porque el secundario ya escribi\u00f3 todos los bloques confirmados. El costo es mayor latencia por escritura (incluye el retardo de red + I\/O remoto). En redes LAN r\u00e1pidas, este impacto es aceptable.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Tabla comparativa: Protocolo A vs B vs C<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><th><strong>Aspecto<\/strong><\/th><th><strong>Protocolo A (As\u00edncrono)<\/strong><\/th><th><strong>Protocolo B (Semis\u00edncrono)<\/strong><\/th><th><strong>Protocolo C (S\u00edncrono)<\/strong><\/th><\/tr><tr><th><strong>Confirmaci\u00f3n de escritura<\/strong><\/th><td>Tras disco local + paquete en <em>buffer<\/em> TCP<\/td><td>Tras disco local + recepci\u00f3n en memoria remota<\/td><td>Tras disco local + disco remoto<\/td><\/tr><tr><th><strong>Latencia percibida<\/strong><\/th><td>M\u00ednima (similar a disco local solo)<\/td><td>Moderada (a\u00f1ade latencia de red, sin I\/O remoto)<\/td><td>Mayor (red + I\/O remoto por cada escritura)<\/td><\/tr><tr><th><strong>Protecci\u00f3n ante fallo del Primary<\/strong><\/th><td>Posible p\u00e9rdida de actualizaciones recientes<\/td><td>Datos normalmente seguros (en RAM remota); riesgo si ambos nodos fallan<\/td><td><strong>Cero p\u00e9rdida de datos<\/strong> en failover<\/td><\/tr><tr><th><strong>Throughput<\/strong><\/th><td>Independiente del protocolo<\/td><td>Independiente del protocolo<\/td><td>Independiente del protocolo<\/td><\/tr><tr><th><strong>Uso t\u00edpico<\/strong><\/th><td>R\u00e9plica a larga distancia<\/td><td>Escenarios intermedios, sitios cercanos<\/td><td><strong>Configuraci\u00f3n m\u00e1s com\u00fan<\/strong> en cl\u00fasteres HA locales<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">5. Roles, Estados y Monitorizaci\u00f3n<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Roles: Primary y Secondary<\/h3>\n\n\n\n<p>Cada recurso DRBD tiene en cada momento un rol asignado en cada nodo. En modo <strong>single-primary<\/strong>, el recurso est\u00e1 en Primary <strong>en un solo miembro del cl\u00faster a la vez<\/strong>, garantizando que solo un nodo manipule los datos en cada momento. El Secundario recibe los bloques replicados pero t\u00edpicamente no monta el sistema de archivos.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Estados observados en la pr\u00e1ctica<\/h3>\n\n\n\n<p>El estado de un recurso DRBD se reporta mediante <code>cat \/proc\/drbd<\/code> (DRBD 8.4) o <code>drbdadm status<\/code> (DRBD 9, que ofrece una vista m\u00e1s legible)\u3011. Un estado saludable se ve as\u00ed:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>cs:Connected  ro:Primary\/Secondary  ds:UpToDate\/UpToDate\n<\/code><\/pre>\n\n\n\n<p>Esto indica que ambos nodos est\u00e1n <strong>conectados<\/strong>, hay un <strong>nodo activo (Primary) y uno pasivo (Secondary)<\/strong>, y los <strong>bloques de datos est\u00e1n id\u00e9nticos<\/strong> (completamente sincronizados)\u30105000\u2020L7-L10\u3011.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Principales estados de conexi\u00f3n (cs), rol (ro) y disco (ds)<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><th><strong>Categor\u00eda<\/strong><\/th><th><strong>Estado<\/strong><\/th><th><strong>Significado<\/strong><\/th><\/tr><tr><th><strong>Conexi\u00f3n (cs)<\/strong><\/th><td><code>Connected<\/code><\/td><td>Comunicaci\u00f3n activa, replicaci\u00f3n operativa en tiempo real\u30105000\u2020L8-L9\u3011<\/td><\/tr><tr><td><\/td><td><code>StandAlone<\/code> \/ <code>Disconnected<\/code><\/td><td>Sin conexi\u00f3n al par (fallo de red, split-brain detectado, etc.)\u301014\u2020L11-L14\u3011<\/td><\/tr><tr><td><\/td><td><code>SyncSource<\/code><\/td><td>Este nodo est\u00e1 enviando bloques durante una sincronizaci\u00f3n activa\u30105000\u2020L13\u3011<\/td><\/tr><tr><td><\/td><td><code>SyncTarget<\/code><\/td><td>Este nodo est\u00e1 recibiendo bloques durante una sincronizaci\u00f3n activa<\/td><\/tr><tr><th><strong>Rol (ro)<\/strong><\/th><td><code>Primary\/Secondary<\/code><\/td><td>Primer valor = rol local, segundo = rol del par\u30105000\u2020L8-L9\u3011<\/td><\/tr><tr><td><\/td><td><code>Primary\/Primary<\/code><\/td><td>Ambos nodos en modo dual-primary (requiere FS compartido)<\/td><\/tr><tr><th><strong>Disco (ds)<\/strong><\/th><td><code>UpToDate\/UpToDate<\/code><\/td><td>Ambos discos completamente sincronizados (estado ideal)\u30105000\u2020L9-L10\u3011<\/td><\/tr><tr><td><\/td><td><code>UpToDate\/Inconsistent<\/code><\/td><td>El primario est\u00e1 actualizado; el secundario a\u00fan no tiene todos los datos\u30105000\u2020L13-L14\u3011<\/td><\/tr><tr><td><\/td><td><code>Diskless<\/code><\/td><td>No hay dispositivo de bloque local asignado al controlador DRBD (p.ej., el disco fall\u00f3)\u30103\u2020L16\u3011<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Sincronizaci\u00f3n en progreso<\/h3>\n\n\n\n<p>Cuando DRBD sincroniza datos por primera vez o tras una desconexi\u00f3n, el estado muestra informaci\u00f3n de progreso. Ejemplo de salida:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>cs:SyncSource  ro:Primary\/Secondary  ds:UpToDate\/Inconsistent\nsync'ed: 45.7% (46624\/102400)  finish: 0:01:12  speed: 12,000 K\/sec\n<\/code><\/pre>\n\n\n\n<p>El porcentaje indica el avance de la copia de bloques hasta que ambos discos queden en estado <code>UpToDate<\/code>\u30105000\u2020L13-L15\u3011\u30105000\u2020L57-L61\u3011. Al terminar, la conexi\u00f3n vuelve a <code>Connected<\/code> normal.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">6. Sincronizaci\u00f3n Inicial, Re-Sincronizaci\u00f3n y Recuperaci\u00f3n<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Sincronizaci\u00f3n inicial<\/h3>\n\n\n\n<p>Al configurar un recurso DRBD por primera vez, se debe designar un nodo como fuente de la sincronizaci\u00f3n inicial. Si un nodo ya contiene datos valiosos, se lo promueve a <strong>Primario inicial<\/strong> (por ejemplo con <code>drbdadm primary --force<\/code>) y DRBD copia <strong>todos los bloques<\/strong> al otro nodo hasta que ambos queden <em>UpToDate<\/em>\u301018\u2020L1-L2\u3011.<\/p>\n\n\n\n<p>Si ambos nodos parten de discos <strong>nuevos e inicializados<\/strong> (sin datos valiosos), es posible <strong>omitir la sincronizaci\u00f3n inicial completa<\/strong> para ahorrar tiempo, usando un procedimiento especial que marca ambos nodos como sincronizados sin copiar bloques\u30102\u2020L6-L7\u3011.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Re-sincronizaci\u00f3n tras desconexi\u00f3n<\/h3>\n\n\n\n<p>Si la comunicaci\u00f3n se pierde temporalmente o un nodo se reinicia, al reconectar DRBD <strong>sincroniza solo los bloques que fueron modificados durante la ca\u00edda<\/strong>, no el dispositivo en su totalidad. Esto hace que la recuperaci\u00f3n sea eficiente incluso para vol\u00famenes grandes: un bitmap interno rastrea qu\u00e9 regiones cambiaron mientras los nodos estuvieron desconectados. DRBD elige autom\u00e1ticamente un nodo como <code>SyncSource<\/code> (normalmente el que estuvo activo) y el otro como <code>SyncTarget<\/code>, y el estado <code>UpToDate\/Inconsistent<\/code> se muestra hasta completar el diferencial\u30105000\u2020L11-L15\u3011.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Recuperaci\u00f3n de split-brain<\/h3>\n\n\n\n<p>Cuando un nodo v\u00edctima de split-brain se re-sincroniza con el nodo \u00abganador\u00bb, <strong>no se realiza una sincronizaci\u00f3n completa del dispositivo<\/strong>. En su lugar, las <strong>modificaciones locales del nodo v\u00edctima se revierten<\/strong>, y las modificaciones realizadas en el nodo sobreviviente se propagan hacia el nodo v\u00edctima. Una vez completada la re-sincronizaci\u00f3n, el split-brain se considera resuelto y los nodos forman nuevamente un sistema de almacenamiento replicado totalmente consistente\u301014\u2020L3-L5\u3011.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">7. <em>Split-Brain<\/em>: Detecci\u00f3n, Prevenci\u00f3n y Resoluci\u00f3n<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">\u00bfQu\u00e9 es el <em>split-brain<\/em>?<\/h3>\n\n\n\n<p>Es una situaci\u00f3n donde, debido a una <strong>falla temporal de todos los enlaces de red<\/strong> entre nodos del cl\u00faster, y posiblemente por intervenci\u00f3n de software de gesti\u00f3n o error humano, <strong>ambos nodos cambian al rol Primary estando desconectados<\/strong>. Es un estado potencialmente da\u00f1ino, pues implica que se pudieron realizar modificaciones en cualquiera de los nodos sin haberlas replicado al otro\u301014\u2020L1\u3011.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Detecci\u00f3n<\/h3>\n\n\n\n<p>DRBD detecta el split-brain <strong>al momento en que la conectividad se restablece<\/strong> y los nodos intercambian el handshake inicial del protocolo DRBD. Si DRBD detecta que ambos nodos son (o fueron) Primary mientras estaban desconectados, <strong>corta inmediatamente la conexi\u00f3n de replicaci\u00f3n<\/strong>. Los mensajes del log del sistema indicar\u00e1n \u00abSplit-Brain detected\u00bb\u301014\u2020L11-L14\u3011.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prevenci\u00f3n: Fencing, STONITH y Qu\u00f3rum<\/h3>\n\n\n\n<p>La estrategia m\u00e1s efectiva es <strong>evitar el split-brain<\/strong> mediante:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Fencing\/STONITH:<\/strong> Configurar un recurso <em>Shoot The Other Node In The Head<\/em> en Pacemaker para que, si un nodo queda aislado, el cl\u00faster env\u00ede un comando para <strong>apagarlo o reiniciarlo<\/strong> autom\u00e1ticamente, asegurando que solo quede uno activo escribiendo en DRBD.<\/li>\n\n\n\n<li><strong>Qu\u00f3rum:<\/strong> DRBD 9 incorpora una funcionalidad de quorum que puede usarse como alternativa al fencing en cl\u00fasteres Pacemaker, evitando el escenario de \u00absplit-brain\u00bb al requerir mayor\u00eda de nodos para permitir la promoci\u00f3n a Primary.<\/li>\n\n\n\n<li><strong>Redundancia de comunicaci\u00f3n:<\/strong> M\u00faltiples enlaces de red entre nodos (heartbeat dedicado + red de replicaci\u00f3n) reducen la probabilidad de aislamiento total.<\/li>\n<\/ul>\n\n\n\n<p>La documentaci\u00f3n oficial advierte que configurar DRBD para resolver autom\u00e1ticamente divergencias de datos causadas por split-brain es configurar para <strong>potencial p\u00e9rdida autom\u00e1tica de datos<\/strong>, y recomienda considerar las implicaciones antes de habilitarlo. Lo preferible es invertir en pol\u00edticas de fencing, configuraci\u00f3n de qu\u00f3rum, integraci\u00f3n con gestor de cl\u00faster y enlaces de comunicaci\u00f3n redundantes para <strong>evitar<\/strong> la divergencia de datos\u301014\u2020L7-L9\u3011.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Resoluci\u00f3n: Pol\u00edticas <code>after-sb<\/code><\/h3>\n\n\n\n<p>Si pese a todo ocurre un split-brain, DRBD ofrece opciones configurables de resoluci\u00f3n autom\u00e1tica (pol\u00edticas <code>after-sb-0pri<\/code>, <code>after-sb-1pri<\/code>, <code>after-sb-2pri<\/code>):<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong><code>discard-zero-changes<\/code>:<\/strong> Descarta los cambios del nodo que no realiz\u00f3 ninguna modificaci\u00f3n (si aplica)\u301014\u2020L19\u3011.<\/li>\n\n\n\n<li><strong><code>discard-secondary<\/code>:<\/strong> Descarta siempre los cambios del nodo actualmente en rol Secundario cuando se detecta el split-brain\u301014\u2020L9-L10\u3011.<\/li>\n\n\n\n<li><strong><code>discard-younger-primary<\/code> \/ <code>discard-older-primary<\/code>:<\/strong> Descarta las modificaciones del nodo que fue promovido a Primary m\u00e1s recientemente o m\u00e1s antiguamente, respectivamente\u301014\u2020L21-L23\u3011.<\/li>\n\n\n\n<li><strong><code>disconnect<\/code>:<\/strong> Simplemente corta la conexi\u00f3n y contin\u00faa en modo desconectado, dejando la resoluci\u00f3n al administrador\u301014\u2020L9-L10\u3011.<\/li>\n<\/ul>\n\n\n\n<p><strong>Todas estas pol\u00edticas conllevan potencial p\u00e9rdida de datos<\/strong>, ya que una de las copias divergentes ser\u00e1 revertida. En entornos donde <strong>no es aceptable descartar datos autom\u00e1ticamente<\/strong> (p.ej., bases de datos financieras), se recomienda no habilitar recuperaci\u00f3n autom\u00e1tica y requerir <strong>intervenci\u00f3n manual<\/strong> en todo evento de split-brain\u301014\u2020L21-L25\u3011.<\/p>\n\n\n\n<p>Un ejemplo de configuraci\u00f3n de pol\u00edticas para un recurso con sistema de archivos GFS u OCFS2 en modo dual-primary:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>resource &lt;nombre&gt; {\n  handlers {\n    split-brain \"\/usr\/lib\/drbd\/notify-split-brain.sh root\"\n  }\n  net {\n    after-sb-0pri discard-zero-changes;\n    after-sb-1pri discard-secondary;\n    after-sb-2pri disconnect;\n  }\n}\n<\/code><\/pre>\n\n\n\n<p>\u301014\u2020L19\u3011<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Split-brain y dual-primary<\/h3>\n\n\n\n<p>En modo dual-primary, dado que ambos recursos est\u00e1n <strong>siempre<\/strong> como primarios, <strong>cualquier interrupci\u00f3n en la red entre nodos resultar\u00e1 en un split-brain<\/strong>. En DRBD 9.0.x, el modo Dual-Primary est\u00e1 limitado a exactamente <strong>dos Primarios<\/strong> y su uso previsto es la <strong>migraci\u00f3n en vivo<\/strong> de m\u00e1quinas virtuales\u301023\u2020L15-L16\u3011. Para habilitar este modo de forma permanente, se configura la opci\u00f3n <code>allow-two-primaries<\/code> a <code>yes<\/code> en la secci\u00f3n <code>net<\/code> del archivo de configuraci\u00f3n del recurso\u301023\u2020L15-L16\u3011.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">8. Integraci\u00f3n con Pacemaker, Corosync y Orden de Recursos<\/h2>\n\n\n\n<p>DRBD proporciona la replicaci\u00f3n de datos, pero <strong>no gestiona la conmutaci\u00f3n de servicios ni la supervisi\u00f3n de nodos<\/strong>. En un entorno de alta disponibilidad real, se integra con <strong>Pacemaker<\/strong> (gestor de recursos de cl\u00faster) usando <strong>Corosync<\/strong> como capa de comunicaci\u00f3n. La gu\u00eda oficial de DRBD 9 cubre expl\u00edcitamente la integraci\u00f3n con Pacemaker, adem\u00e1s de configuraciones avanzadas con LVM, GFS, OCFS2 y el software DRBD Reactor desarrollado por LINBIT como alternativa m\u00e1s sencilla de configurar y desplegar\u30101\u2020L21\u3011.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Arquitectura de recursos en Pacemaker<\/h3>\n\n\n\n<p>Seg\u00fan los materiales de configuraci\u00f3n para alta disponibilidad con DRBD y Pacemaker, el <strong>orden correcto<\/strong> de arranque de recursos siempre debe ser:<\/p>\n\n\n\n<p><strong>DRBD \u2192 Filesystem \u2192 Apache \u2192 IP Virtual<\/strong><\/p>\n\n\n\n<p>Pacemaker se encarga de orquestar todo este flujo\u30105000\u2020L82-L83\u3011.<\/p>\n\n\n\n<p>Los pasos clave de configuraci\u00f3n incluyen:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Recurso DRBD en Pacemaker:<\/strong> Controla qui\u00e9n es Primary y qui\u00e9n es Secondary. Ejemplo: <code>pcs resource create drbd-webdata ocf:linbit:drbd drbd_resource=webdata op monitor interval=30s<\/code>\u30105000\u2020L89-L91\u3011.<\/li>\n\n\n\n<li><strong>Recurso Filesystem:<\/strong> Monta <code>\/dev\/drbd0<\/code> en el directorio de datos solo en el nodo activo. Ejemplo: <code>pcs resource create fs-webdata ocf:heartbeat:Filesystem device=\"\/dev\/drbd0\" directory=\"\/var\/www\/html\" fstype=\"ext4\"<\/code>\u30105000\u2020L93-L95\u3011.<\/li>\n\n\n\n<li><strong>Restricci\u00f3n de orden (<em>order constraint<\/em>):<\/strong> Primero DRBD debe estar promovido, luego se monta el filesystem: <code>pcs constraint order promote drbd-webdata then start fs-webdata<\/code>\u30105000\u2020L97-L98\u3011.<\/li>\n\n\n\n<li><strong>Restricci\u00f3n de colocaci\u00f3n (<em>colocation constraint<\/em>):<\/strong> Evita que se monte en un nodo Secondary: <code>pcs constraint colocation add fs-webdata with drbd-webdata INFINITY<\/code>\u30105000\u2020L100-L101\u3011.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Flujo de failover autom\u00e1tico<\/h3>\n\n\n\n<p>En condiciones normales, todos los recursos corren en el Nodo A. Si Pacemaker detecta que el Nodo A falla (no responde al heartbeat de Corosync o un recurso falla), autom\u00e1ticamente:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Promueve el Nodo B a <strong>Primary de DRBD<\/strong>.<\/li>\n\n\n\n<li><strong>Monta<\/strong> el sistema de archivos en el Nodo B.<\/li>\n\n\n\n<li><strong>Arranca<\/strong> la aplicaci\u00f3n (Apache, etc.) en el Nodo B.<\/li>\n\n\n\n<li><strong>Mueve<\/strong> la IP virtual al Nodo B.<\/li>\n<\/ol>\n\n\n\n<p>Todo ello respetando el orden secuencial definido\u30105000\u2020L78-L83\u3011. Si STONITH est\u00e1 configurado, antes de promocionar al Nodo B se env\u00eda una se\u00f1al para <strong>apagar el Nodo A<\/strong> y asegurar que no pueda retomar la actividad con datos obsoletos.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Precondiciones cr\u00edticas para el failover<\/h3>\n\n\n\n<p>Para que el failover funcione correctamente, se deben cumplir estas precondiciones\u30105000\u2020L85-L88\u3011:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>\u2705 DRBD ya est\u00e1 sincronizado \u2192 <code>UpToDate\/UpToDate<\/code><\/li>\n\n\n\n<li>\u2705 El directorio de datos (<code>\/var\/www\/html<\/code>) <strong>no est\u00e1 montado manualmente<\/strong><\/li>\n\n\n\n<li>\u2705 El servicio (Apache) est\u00e1 detenido (lo controla Pacemaker)<\/li>\n\n\n\n<li>\u2705 El cl\u00faster PCS ya est\u00e1 creado y activo<\/li>\n<\/ul>\n\n\n\n<p>Verificaci\u00f3n mediante: <code>pcs status<\/code> y <code>drbdadm status<\/code>\u30105000\u2020L87-L88\u3011.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">9. Tabla Comparativa: Single-Primary vs Dual-Primary<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><th><strong>Aspecto<\/strong><\/th><th><strong>Single-Primary (Activo\/Pasivo)<\/strong><\/th><th><strong>Dual-Primary (Activo\/Activo)<\/strong><\/th><\/tr><tr><th><strong>Nodos con acceso R\/W<\/strong><\/th><td>Solo uno a la vez\u30104\u2020L13\u3011<\/td><td>Ambos simult\u00e1neamente\u301023\u2020L15-L16\u3011<\/td><\/tr><tr><th><strong>Sistema de archivos requerido<\/strong><\/th><td>Convencional (EXT4, XFS, etc.)\u30101\u2020L45\u3011<\/td><td>Distribuido de disco compartido (GFS2, OCFS2) con gestor de bloqueos<\/td><\/tr><tr><th><strong>Riesgo de split-brain<\/strong><\/th><td>Menor (solo si el gestor de cl\u00faster falla en la coordinaci\u00f3n)<\/td><td><strong>Toda interrupci\u00f3n de red resulta en split-brain<\/strong>\u301023\u2020L15-L16\u3011<\/td><\/tr><tr><th><strong>Complejidad<\/strong><\/th><td>Menor; configuraci\u00f3n est\u00e1ndar m\u00e1s com\u00fan<\/td><td>Mayor; requiere lock manager y FS especial<\/td><\/tr><tr><th><strong>Caso de uso t\u00edpico<\/strong><\/th><td>HA para bases de datos, servidores web, NFS<\/td><td>Migraci\u00f3n en vivo de VMs, balanceo de carga con escritura concurrente<\/td><\/tr><tr><th><strong>Limitaci\u00f3n en DRBD 9.0.x<\/strong><\/th><td>Sin limitaci\u00f3n especial<\/td><td>Limitado a exactamente <strong>2 Primarios<\/strong>\u301023\u2020L15-L16\u3011<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">10. Apilamiento (Stacking) y Replicaci\u00f3n de Tres V\u00edas<\/h2>\n\n\n\n<p>Para escenarios de <strong>backup y recuperaci\u00f3n ante desastres<\/strong>, DRBD soporta <strong>replicaci\u00f3n de tres v\u00edas<\/strong> mediante la t\u00e9cnica de <em>stacking<\/em>: se agrega otro recurso DRBD <strong>apilado sobre<\/strong> el recurso existente que contiene los datos de producci\u00f3n. El recurso apilado se replica usando <strong>replicaci\u00f3n as\u00edncrona (Protocolo A)<\/strong>, mientras que los datos de producci\u00f3n t\u00edpicamente usan <strong>replicaci\u00f3n s\u00edncrona (Protocolo C)<\/strong>\u301023\u2020L25\u3011. Esto permite tener, por ejemplo, dos nodos locales con replicaci\u00f3n s\u00edncrona (m\u00e1xima protecci\u00f3n) y un tercer nodo remoto recibiendo una copia as\u00edncrona para disaster recovery.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">11. Casos de Uso y Limitaciones Arquitect\u00f3nicas<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Casos de uso t\u00edpicos<\/h3>\n\n\n\n<p>DRBD opera dentro de la capa de bloques del kernel de Linux, por lo que es <strong>agn\u00f3stico de la carga de trabajo<\/strong>. Puede servir como base de\u30101\u2020L43-L45\u3011:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Servidores de archivos y web:<\/strong> Replicar vol\u00famenes de datos (como <code>\/var\/www\/html<\/code>) para lograr failover sin p\u00e9rdida de datos. Tambi\u00e9n vol\u00famenes NFS en modo activo-pasivo.<\/li>\n\n\n\n<li><strong>Bases de datos relacionales:<\/strong> MySQL\/MariaDB, PostgreSQL u otras bases montadas sobre DRBD en un nodo primario. En un failover, el secundario asume con la base de datos consistente (tras <em>journal replay<\/em> si el primario cay\u00f3 de forma no limpia).<\/li>\n\n\n\n<li><strong>Entornos de virtualizaci\u00f3n:<\/strong> DRBD sirve de almacenamiento compartido para hipervisores (KVM, Xen) sin necesidad de SAN. Permite migraci\u00f3n en vivo en dual-primary o failover en single-primary.<\/li>\n\n\n\n<li><strong>Almacenamiento general HA:<\/strong> Cualquier aplicaci\u00f3n que requiera acceso directo a un dispositivo de bloque.<\/li>\n\n\n\n<li><strong>LINSTOR:<\/strong> Desde 2018, DRBD puede tambi\u00e9n aprovecharse en el software de gesti\u00f3n de almacenamiento de bloques LINSTOR para replicaci\u00f3n entre nodos y provisi\u00f3n de dispositivos de bloque a usuarios y aplicaciones.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Verificaci\u00f3n pr\u00e1ctica de la replicaci\u00f3n (contexto docente)<\/h3>\n\n\n\n<p>Una forma did\u00e1ctica de comprobar la sincronizaci\u00f3n es crear un archivo en el nodo activo (Primary): <code>echo \"Hola DRBD\" &gt; \/var\/www\/html\/prueba.txt<\/code>. Aunque el archivo <strong>no es visible<\/strong> en el nodo Secondary (porque no tiene montado el sistema de archivos), los datos <strong>ya se encuentran replicados a nivel de bloque<\/strong>. Al realizar un failover manual y montar DRBD en el nodo pasivo, el archivo creado aparece inmediatamente, confirmando que la replicaci\u00f3n fue exitosa\u30105000\u2020L20-L26\u3011. <strong>DRBD replica bloques de disco, no archivos<\/strong>\u30105000\u2020L26-L27\u3011.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Limitaciones y consideraciones<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Duplicaci\u00f3n de hardware:<\/strong> DRBD requiere almacenamiento de tama\u00f1o similar en cada nodo. No ahorra espacio; a cambio brinda redundancia contra la falla de un servidor completo. <strong>No protege contra errores l\u00f3gicos<\/strong>: si una aplicaci\u00f3n borra datos en el primario, esa eliminaci\u00f3n se replica inmediatamente. Se complementa con <strong>copias de seguridad<\/strong> tradicionales.<\/li>\n\n\n\n<li><strong>Impacto en latencia de escritura:<\/strong> Aunque las lecturas son locales, las <strong>escrituras<\/strong> incluyen la sobrecarga de replicaci\u00f3n por red. En Protocolo C, la latencia de cada escritura incluye el retardo de red m\u00e1s el I\/O del segundo nodo. En una LAN r\u00e1pida el impacto es aceptable, pero en enlaces lentos puede ser significativo. El Protocolo A reduce este impacto a costa de menor seguridad de datos.<\/li>\n\n\n\n<li><strong>No sustituye a un <em>Cluster Filesystem<\/em>:<\/strong> En modo single-primary, intentar montar un sistema de archivos convencional (EXT4, XFS) en <strong>ambos nodos simult\u00e1neamente corromper\u00eda los datos<\/strong>, ya que estos FS no est\u00e1n dise\u00f1ados para acceso concurrente multi-nodo. Para escritura paralela se <strong>requiere<\/strong> GFS2, OCFS2 u otro FS distribuido. DRBD no puede agregar capacidad activo-activo a sistemas de archivos que no la poseen nativamente\u30101\u2020L45\u3011.<\/li>\n\n\n\n<li><strong>Escalabilidad limitada en configuraci\u00f3n cl\u00e1sica:<\/strong> DRBD est\u00e1 pensado principalmente para <strong>2 nodos<\/strong>. La versi\u00f3n 9 ampli\u00f3 soporte a m\u00faltiples secundarios, pero para topolog\u00edas m\u00e1s complejas de almacenamiento replicado a gran escala se consideran alternativas como Ceph o GlusterFS. DRBD destaca cuando 2 nodos bastan para HA y se desea aprovechar sistemas de archivos tradicionales con la simplicidad de un RAID-1 en red.<\/li>\n\n\n\n<li><strong>Enlaces de red confiables:<\/strong> Dado que DRBD <strong>no cifra ni comprime<\/strong> datos en tr\u00e1nsito por defecto\u30107\u2020L30-L32\u3011, se asume una red local segura o el uso de VPN si el medio es inseguro. La estabilidad de la latencia de red tambi\u00e9n es importante; variaciones grandes afectan el rendimiento perceptiblemente, especialmente en Protocolo C.<\/li>\n\n\n\n<li><strong>Reserva de metadatos:<\/strong> Cuando se usa <code>meta-disk internal<\/code>, DRBD consume una peque\u00f1a porci\u00f3n del dispositivo para sus metadatos (~70 KB en un dispositivo de 1024 MB)\u30107\u2020L65\u3011, reduciendo ligeramente el espacio disponible para datos de usuario.\u30105000\u2020L16-L18<\/li>\n<\/ul>\n\n\n\n<p><strong>Practicas<\/strong>:<\/p>\n\n\n\n<p><a href=\"https:\/\/dsantana.uas.edu.mx\/index.php\/2026\/04\/24\/practica-cluster-de-alta-disponibilidad-en-debian-13\/\">Pr\u00e1ctica: Cl\u00faster de Alta Disponibilidad en Debian 13<\/a><\/p>\n\n\n\n<p><a href=\"https:\/\/dsantana.uas.edu.mx\/index.php\/2026\/04\/24\/practica-integracion-de-apache2-en-el-cluster-de-alta-disponibilidad-pacemaker-corosync\/\">Practica: Integraci\u00f3n de Apache2 en el Cl\u00faster de Alta Disponibilidad (Pacemaker + Corosync)<\/a><\/p>\n\n\n\n<p><a href=\"https:\/\/dsantana.uas.edu.mx\/index.php\/2026\/04\/24\/practica-drbd-en-debian-13-4-replicacion-de-volumen-paso-a-paso\/\">Pr\u00e1ctica: DRBD en Debian 13.4: Replicaci\u00f3n de Volumen Paso a Paso<\/a><\/p>\n\n\n\n<p><a href=\"https:\/\/dsantana.uas.edu.mx\/index.php\/2026\/04\/24\/mysql-en-debian-13-4-cluster-de-alta-disponibilidad-con-drbd-y-replicacion-nativa\/\">MySQL en Debian 13.4 \u2014 Cl\u00faster de Alta Disponibilidad con DRBD y Replicaci\u00f3n Nativa<br><\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>DRBD (Dispositivo de Bloque Replicado Distribuido): Arquitectura y Funcionamiento T\u00e9cnico DRBD (Distributed Replicated Block Device) es una soluci\u00f3n de almacenamiento replicado basada en software, de tipo shared-nothing, que refleja el contenido de dispositivos de bloque (discos duros, particiones, vol\u00famenes l\u00f3gicos, etc.) entre hosts. Funciona como un RAID-1 por red: replica datos en tiempo real de forma continua mientras las aplicaciones los modifican, de manera transparente (las aplicaciones no necesitan saber que los datos est\u00e1n en m\u00faltiples hosts), y de forma s\u00edncrona o as\u00edncrona seg\u00fan la configuraci\u00f3n elegida. Es una tecnolog\u00eda ampliamente utilizada para implementar alta disponibilidad (HA) en Linux: si un servidor falla, el otro posee una r\u00e9plica actualizada de los datos para continuar operando. DRBD es software de c\u00f3digo abierto, disponible en la plataforma Linux. Dado que la imagen de referencia mencionada no est\u00e1 disponible para su an\u00e1lisis directo, la siguiente explicaci\u00f3n describe la arquitectura t\u00edpica que aparece en diagramas est\u00e1ndares de DRBD, explicitando las suposiciones realizadas. 1. Arquitectura por Capas de DRBD (Pila de I\/O Linux) DRBD es un m\u00f3dulo del kernel de Linux que se ubica entre el planificador de I\/O (capa inferior) y el sistema de archivos (capa superior). Espec\u00edficamente, constituye un controlador para un dispositivo de bloque virtual, posicion\u00e1ndose cerca de la parte inferior de la pila de I\/O del sistema. La gu\u00eda oficial de DRBD 9 hace referencia a esta disposici\u00f3n en su \u00abFigura 1: Posici\u00f3n de DRBD dentro de la pila de I\/O de Linux\u00bb. [linuxparty.es][linbit.com] La pila, de arriba hacia abajo, se organiza as\u00ed: DRBD es, por definici\u00f3n y por mandato de la arquitectura del kernel de Linux, agn\u00f3stico de las capas superiores. No puede agregar m\u00e1gicamente funcionalidades que las capas superiores no posean; por ejemplo, no puede auto-detectar corrupci\u00f3n del sistema de archivos ni agregar capacidad de cl\u00faster activo-activo a sistemas de archivos como ext3 o XFS que no la soportan nativamente. Metadatos de DRBD: DRBD almacena metadatos internos en cada nodo. Cuando se usa la opci\u00f3n meta-disk internal (lo m\u00e1s habitual), estos metadatos se reservan en la parte final del dispositivo de bloque subyacente. Por ejemplo, si el dispositivo crudo tiene 1024 MB, el dispositivo DRBD dispondr\u00e1 de solo 1023 MB para datos del usuario, con aproximadamente 70 KB reservados para metadatos. Es fundamental que toda manipulaci\u00f3n de datos se haga sobre \/dev\/drbdX y no sobre el dispositivo crudo, ya que acceder al dispositivo directamente causar\u00e1 inconsistencias. Herramientas de administraci\u00f3n en espacio de usuario: DRBD incluye tres herramientas que se comunican con el m\u00f3dulo del kernel para configurar y administrar los recursos, de mayor a menor nivel: Herramienta Nivel Funci\u00f3n drbdadm Alto Herramienta principal. Obtiene par\u00e1metros de \/etc\/drbd.conf y act\u00faa como front-end para drbdsetup y drbdmeta. Soporta modo dry-run con la opci\u00f3n -d. drbdsetup Bajo Configura directamente el m\u00f3dulo DRBD cargado en el kernel. Todos los par\u00e1metros se pasan por l\u00ednea de comandos. Rara vez se usa directamente. drbdmeta Bajo Permite crear, volcar, restaurar y modificar estructuras de metadatos DRBD. Tambi\u00e9n de uso infrecuente para la mayor\u00eda de los usuarios. 2. Topolog\u00eda T\u00edpica: Dos Nodos con Replicaci\u00f3n por Red Los despliegues est\u00e1ndares de DRBD constan de dos servidores (Nodo A y Nodo B) conectados por red. Un diagrama de referencia t\u00edpico (como la \u00abIlustraci\u00f3n t\u00e9cnica y educativa\u00bb presente en los materiales de clase) muestra un cl\u00faster activo\/pasivo en Linux con dos servidores: el Nodo A (activo) ejecutando Apache con una IP virtual (VIP) visible a los clientes, y el Nodo B (pasivo) en espera. Ambos nodos aparecen conectados por enlaces que representan Pacemaker, Corosync y DRBD, mostrando replicaci\u00f3n en tiempo real del directorio \/var\/www\/html. El diagrama ilustra adem\u00e1s un evento de failover donde la IP virtual y el servicio Apache se mueven autom\u00e1ticamente del Nodo A al Nodo B cuando el Nodo A falla. En esta disposici\u00f3n shared-nothing: Tr\u00e1fico de red no cifrado: La documentaci\u00f3n oficial de SUSE advierte que el tr\u00e1fico de datos entre espejos DRBD no est\u00e1 cifrado. Para un intercambio seguro de datos, se recomienda implementar una VPN sobre la conexi\u00f3n de replicaci\u00f3n. DRBD permite usar cualquier dispositivo de bloque soportado por Linux como almacenamiento subyacente: partici\u00f3n o disco duro completo, RAID por software, LVM o EVMS. 3. Flujo de I\/O: Escrituras y Lecturas Flujo de escritura (modo single-primary) Flujo de lectura Toda la I\/O de lectura se ejecuta localmente en el nodo primario, accediendo directamente al disco local sin a\u00f1adir latencia de red, a menos que se configure balanceo de lectura (read-balancing), una opci\u00f3n avanzada donde el primario podr\u00eda leer tambi\u00e9n desde el secundario v\u00eda red para distribuir carga. Esta opci\u00f3n no es habitual en configuraciones est\u00e1ndar. El nodo secundario no atiende lecturas porque no tiene aplicaciones activas ni un sistema de archivos montado. Flujo en modo dual-primary En configuraci\u00f3n activo-activo, ambos nodos pueden originar escrituras; cada escritura local en un nodo se replica al otro. Las lecturas son atendidas localmente por cada nodo para sus propias aplicaciones. Un sistema de archivos de disco compartido (GFS2, OCFS2) junto con un gestor de bloqueos distribuido coordina la coherencia de acceso concurrente. Este modo de operaci\u00f3n requiere latencias de red muy bajas y coordinaci\u00f3n precisa. 4. Modos de Replicaci\u00f3n: Protocolo A, B y C DRBD soporta tres protocolos de replicaci\u00f3n que representan tres grados distintos de sincron\u00eda. La elecci\u00f3n influye en dos factores del despliegue: protecci\u00f3n (de datos ante fallo) y latencia (percibida por la aplicaci\u00f3n). El rendimiento (throughput), por el contrario, es en gran medida independiente del protocolo seleccionado. Protocolo A \u2014 Replicaci\u00f3n as\u00edncrona Las operaciones de escritura locales en el nodo primario se consideran completadas tan pronto como la escritura en disco local ha terminado y el paquete de replicaci\u00f3n ha sido colocado en el buffer TCP de env\u00edo local. En caso de un failover forzado, puede ocurrir p\u00e9rdida de datos: los datos en el nodo en espera son consistentes despu\u00e9s del failover, pero las actualizaciones m\u00e1s recientes realizadas antes del failover podr\u00edan perderse. El Protocolo A se usa con mayor frecuencia en escenarios de replicaci\u00f3n a larga distancia. Protocolo B \u2014 Replicaci\u00f3n semis\u00edncrona (\u00abs\u00edncrono<\/p>\n","protected":false},"author":1,"featured_media":2366,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[134,16,5,12,1,10,6],"tags":[],"class_list":["post-2365","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-clusters","category-debian","category-docencia","category-linux","category-sin-categoria","category-sistemas-operativos","category-talleres"],"_links":{"self":[{"href":"https:\/\/dsantana.uas.edu.mx\/index.php\/wp-json\/wp\/v2\/posts\/2365","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dsantana.uas.edu.mx\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dsantana.uas.edu.mx\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dsantana.uas.edu.mx\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dsantana.uas.edu.mx\/index.php\/wp-json\/wp\/v2\/comments?post=2365"}],"version-history":[{"count":5,"href":"https:\/\/dsantana.uas.edu.mx\/index.php\/wp-json\/wp\/v2\/posts\/2365\/revisions"}],"predecessor-version":[{"id":2408,"href":"https:\/\/dsantana.uas.edu.mx\/index.php\/wp-json\/wp\/v2\/posts\/2365\/revisions\/2408"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/dsantana.uas.edu.mx\/index.php\/wp-json\/wp\/v2\/media\/2366"}],"wp:attachment":[{"href":"https:\/\/dsantana.uas.edu.mx\/index.php\/wp-json\/wp\/v2\/media?parent=2365"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dsantana.uas.edu.mx\/index.php\/wp-json\/wp\/v2\/categories?post=2365"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dsantana.uas.edu.mx\/index.php\/wp-json\/wp\/v2\/tags?post=2365"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}