Instale y configure DRDB para la replicación del sistema de archivos de red en Debian 8

Hablemos de la replicación del sistema de archivos de red.

La replicación del sistema de archivos de red se usa a menudo hoy en muchos escenarios:

• Replicación de un sistema de archivos por razones de seguridad:si un nodo falla, el otro nodo es accesible.
• Para replicar un sistema de archivos en la sede de otra empresa, para que cada empleado tenga acceso a sus datos localmente y no a través de una red pública. Pero si va a la otra sede, tiene todos sus datos y nuevamente puede acceder localmente.

Como puede imaginar, este tipo de sistema se usa a menudo para crear sistemas de archivos para entornos de clúster.

Hemos optado por implementar la solución con DRDB. Su objetivo principal es (como otros sistemas como este) Alta Disponibilidad y Recuperación de Desastres para sistemas de archivos.

Implementamos la solución con Debian 8, pero debería funcionar también en Ubuntu.

Requisitos

Antes de comenzar, estos son los requisitos previos:

• Al menos 2 servidores Debian.
• Debian se instala como una instalación mínima (no es necesario en absoluto si sabe lo que está haciendo en los sistemas de producción) guía recomendada https://www.howtoforge.com/tutorial/debian-8-jessie-minimal-server/
• Al menos 2 discos Linux en cada servidor:/dev/sda para la instalación de Linux, /dev/sdb para la instalación de DRDB.

¡¡¡ATENCIÓN!!!:Durante la instalación, todos los datos en el disco /dev/sdb serán destruidos, así que no trabaje en un disco con datos dentro.

Instalación de DRBD

En nuestro ejemplo, usaré dos nodos, que son:

• 192.168.152.100 mysql1.local.vm
• 192.168.152.110 mysql2.local.vm

En todos los nodos, modifique el archivo /etc/hosts de la siguiente manera:

127.0.0.1 localhost
192.168.152.100 mysql1.local.vm mysql1
192.168.152.110 mysql2.local.vm mysql2

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Luego ejecute los siguientes comandos para instalar DRDB:

apt-get update
apt-get -y upgrade
apt-get install drbd-utils

Configuración primaria/secundaria:recuperación ante desastres

El archivo de configuración principal es /etc/drbd.conf, que tiene el siguiente aspecto:

include "drbd.d/global_common.conf";
include "drbd.d/*.res";

Por convención, /etc/drbd.d/global_common.conf contiene las secciones globales y comunes de la configuración de DRBD, mientras que .res los archivos contienen un recurso en cada sección.

En nuestro ejemplo, hacemos una configuración mínima que replica los datos en los dos nodos. En cada nodo haga la siguiente modificación:

Comenzaremos a editar el archivo /etc/drbd.d/global_common.conf modify the default line from

global {
usage-count yes;
# minor-count dialog-refresh disable-ip-verification
}
...
net {
protocol C;
# protocol timeout max-epoch-size max-buffers unplug-watermark
# connect-int ping-int sndbuf-size rcvbuf-size ko-count
# allow-two-primaries cram-hmac-alg shared-secret after-sb-0pri
# after-sb-1pri after-sb-2pri always-asbp rr-conflict
# ping-timeout data-integrity-alg tcp-cork on-congestion
# congestion-fill congestion-extents csums-alg verify-alg
# use-rle
}
...

Ahora crearemos el archivo de configuración /etc/drbd.d/r0.res para nuestro recurso. Cree el archivo en todos los nodos y agregue esto dentro:

resource r0 {
  on mysql1.local.vm {
    device    /dev/drbd1;
    disk      /dev/sdb;
    address   192.168.152.100:7789;
    meta-disk internal;
  }
  on mysql2.local.vm {
    device    /dev/drbd1;
    disk      /dev/sdb;
    address   192.168.152.110:7789;
    meta-disk internal;
  }
}

Lo que hemos hecho hasta ahora es lo siguiente:

• Usted "opta" por ser incluido en las estadísticas de uso de DRBD con  el parámetro de recuento de uso.
• Los recursos están configurados para usar la replicación totalmente síncrona con el protocolo Cunless explícitamente especificado de otra manera.
• Nuestro clúster consta de dos nodos: mysql1 y mysql2.
• Tenemos un recurso llamado arbitrariamente r0 que usa /dev/sdb como dispositivo de nivel inferior y está configurado con metadatos internos.
• El recurso utiliza el puerto TCP 7789 para sus conexiones de red y se vincula a las direcciones IP 192.168.152.100 y 192.168.152.110 respectivamente.

En todos los nodos, inicialice los metadatos con el siguiente comando:

drbdadm create-md r0

Deberías ver algo como esto:

--== Thank you for participating in the global usage survey ==--
The server's response is:

you are the 2963th user to install this version
initializing activity log
NOT initializing bitmap
Writing meta data...
New drbd meta data block successfully created.
success

A continuación, habilitamos el recurso e inicializamos la primera ejecución de replicación, solo en el primer nodo, debería comenzar a replicarse:

drbdadm up r0
drbdadm primary --force r0

Para verificar si todo funciona bien, puede verificar el archivo /proc/drbd en ambos nodos y debería ver algo como esto:

Mysql1

[email protected]:# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
srcversion: 1A9F77B1CA5FF92235C2213
1: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r-----
ns:54624 nr:0 dw:0 dr:55536 al:0 bm:3 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:5188060
[>....................] sync'ed: 1.1% (5064/5116)Mfinish: 0:17:21 speed: 4,964 (4,964) K/sec

Mysql2 

[email protected]:# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
srcversion: 1A9F77B1CA5FF92235C2213
1: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r-----
ns:0 nr:17496 dw:17496 dr:0 al:0 bm:1 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:5225188
[>....................] sync'ed: 0.4% (5100/5116)Mfinish: 0:29:41 speed: 2,916 (2,916) want: 5,160 K/sec

Durante la fase de compilación, puede notar UpToDate/Inconsistent , es correcto porque esta es la primera sincronización de datos.

Después de sincronizar el sistema de archivos, esta cubierta cambia a UpToDate/UpToDate como en el siguiente registro:

[email protected]:/home/sysop# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
srcversion: 1A9F77B1CA5FF92235C2213
1: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
ns:5242684 nr:0 dw:0 dr:5243596 al:0 bm:320 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Ahora tenemos un nuevo dispositivo de bloque, llamado /dev/drbd1 que podemos formatear con nuestro tipo de sistema de archivos preferido. Por ejemplo, si queremos formatearlo en ext4 y montarlo en /var/www simplemente podemos hacer: 

[email protected]:/home/sysop# mkfs.ext4 /dev/drbd1
mke2fs 1.42.12 (29-Aug-2014)
Creazione del file system con 1310671 4k blocchi e 327680 inode
Etichetta del file system=ab3e18c9-e8cb-42c8-977a-ab79bdb18aea
Backup del superblocco salvati nei blocchi:
32768, 98304, 163840, 229376, 294912, 819200, 884736
Allocating group tables: fatto
Scrittura delle tavole degli inode: fatto
Creating journal (32768 blocks): fatto
Scrittura delle informazioni dei super-blocchi e dell'accounting del file system: fatto

Entonces podemos montar nuestro sistema de archivos:

mkdir /var/www
mount /dev/drbd1 /var/www

El directorio /var/www ahora está montado a través del sistema drbd.

En este escenario, con una configuración Primaria/Secundaria, hemos implementado un sistema de recuperación ante desastres.

En este caso, si intenta montar el sistema de archivos en el segundo nodo, obtendrá un error:

[email protected]:~# mount /dev/drbd1 /var/www/
mount: /dev/drbd1 is write-protected, mounting read-only
mount: mount /dev/drbd1 on /var/www failed: Tipo di supporto errato

Esto es normal y esperado debido a nuestra configuración.

Ahora podemos simular una falla en mysql1, así que apáguelo con el comando poweroff.

En mysql2 podemos ver lo que sucede:

Oct 5 13:52:14 mysql2 kernel: [13458.629215] drbd r0: PingAck did not arrive in time.
Oct 5 13:52:14 mysql2 kernel: [13458.629587] drbd r0: peer( Primary -> Unknown ) conn( Connected -> NetworkFailure ) pdsk( UpToDate -> DUnknown )
Oct 5 13:52:14 mysql2 kernel: [13458.629919] drbd r0: asender terminated
Oct 5 13:52:14 mysql2 kernel: [13458.629921] drbd r0: Terminating drbd_a_r0
Oct 5 13:52:14 mysql2 kernel: [13458.630028] drbd r0: Connection closed
Oct 5 13:52:14 mysql2 kernel: [13458.630035] drbd r0: conn( NetworkFailure -> Unconnected )
Oct 5 13:52:14 mysql2 kernel: [13458.630035] drbd r0: receiver terminated
Oct 5 13:52:14 mysql2 kernel: [13458.630036] drbd r0: Restarting receiver thread
Oct 5 13:52:14 mysql2 kernel: [13458.630037] drbd r0: receiver (re)started
Oct 5 13:52:14 mysql2 kernel: [13458.630041] drbd r0: conn( Unconnected -> WFConnection )

El nodo mysql2 detecta que mysql1 está muerto, y si marcamos /proc/drbd:

[email protected]:~# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
srcversion: 1A9F77B1CA5FF92235C2213
1: cs:WFConnection ro:Secondary/Unknown ds:UpToDate/DUnknown C r-----
ns:0 nr:5457236 dw:5457236 dr:0 al:0 bm:320 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

podemos ver el estado cambiado de Secundario/principal a Secundario/desconocido. Así que ahora hacemos el truco, promoviendo mysql2 como principal. En mysql2 simplemente ejecute:

drbdadm primary r0

revisemos de nuevo /proc/drbd y veamos la magia...

[email protected]:~# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
srcversion: 1A9F77B1CA5FF92235C2213
1: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown C r-----
ns:0 nr:5457236 dw:5457236 dr:912 al:0 bm:320 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Como puede ver, nuestro nodo ahora es principal y se puede montar regularmente.

[email protected]:~# mount /dev/drbd1 /var/www/
[email protected]:~# df -h
File system Dim. Usati Dispon. Uso% Montato su
/dev/sda1 9,3G 1,4G 7,5G 16% /
udev 10M 0 10M 0% /dev
tmpfs 97M 4,6M 92M 5% /run
tmpfs 241M 0 241M 0% /dev/shm
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 241M 0 241M 0% /sys/fs/cgroup
/dev/drbd1 4,8G 10M 4,6G 1% /var/www

Ahora asumimos que queremos retomar mysql1 nuevamente, si comenzamos ahora llegaremos a dividir el cerebro, de hecho, puede verificar el registro y ver estos errores:

Oct 5 14:26:04 mysql1 kernel: [ 7.760588] drbd r0: conn( StandAlone -> Unconnected )
Oct 5 14:26:04 mysql1 kernel: [ 7.760599] drbd r0: Starting receiver thread (from drbd_w_r0 [458])
Oct 5 14:26:04 mysql1 drbdadm[435]: adjust net: r0
Oct 5 14:26:04 mysql1 drbdadm[435]: ]
Oct 5 14:26:04 mysql1 kernel: [ 7.769318] drbd r0: receiver (re)started
Oct 5 14:26:04 mysql1 kernel: [ 7.769327] drbd r0: conn( Unconnected -> WFConnection )
Oct 5 14:26:04 mysql1 /etc/init.d/mysql[485]: MySQL PID not found, pid_file detected/guessed: /var/run/mysqld/mysqld.pid
Oct 5 14:26:04 mysql1 acpid: starting up with netlink and the input layer
Oct 5 14:26:04 mysql1 acpid: 1 rule loaded
Oct 5 14:26:04 mysql1 acpid: waiting for events: event logging is off
Oct 5 14:26:05 mysql1 kernel: [ 8.270578] drbd r0: Handshake successful: Agreed network protocol version 101
Oct 5 14:26:05 mysql1 kernel: [ 8.270581] drbd r0: Agreed to support TRIM on protocol level
Oct 5 14:26:05 mysql1 kernel: [ 8.270770] drbd r0: conn( WFConnection -> WFReportParams )
Oct 5 14:26:05 mysql1 kernel: [ 8.270771] drbd r0: Starting asender thread (from drbd_r_r0 [461])
Oct 5 14:26:05 mysql1 kernel: [ 8.272594] block drbd1: drbd_sync_handshake:
Oct 5 14:26:05 mysql1 kernel: [ 8.272597] block drbd1: self 242B364F4A5B9C68:525CC995A3CFBA2B:44A1DE193A6C6701:0000000000000004 bits:64463 flags:0
Oct 5 14:26:05 mysql1 kernel: [ 8.272598] block drbd1: peer 6903F6042F95F5FF:525CC995A3CFBA2A:44A1DE193A6C6700:0000000000000004 bits:4 flags:0
Oct 5 14:26:05 mysql1 kernel: [ 8.272599] block drbd1: uuid_compare()=100 by rule 90
Oct 5 14:26:05 mysql1 kernel: [ 8.272601] block drbd1: helper command: /sbin/drbdadm initial-split-brain minor-1
Oct 5 14:26:05 mysql1 kernel: [ 8.272692] drbd r0: meta connection shut down by peer.
Oct 5 14:26:05 mysql1 kernel: [ 8.272720] drbd r0: conn( WFReportParams -> NetworkFailure )
Oct 5 14:26:05 mysql1 kernel: [ 8.272722] drbd r0: asender terminated
Oct 5 14:26:05 mysql1 kernel: [ 8.272722] drbd r0: Terminating drbd_a_r0
Oct 5 14:26:05 mysql1 kernel: [ 8.279158] block drbd1: helper command: /sbin/drbdadm initial-split-brain minor-1 exit code 0 (0x0)
Oct 5 14:26:05 mysql1 kernel: [ 8.279173] block drbd1: Split-Brain detected but unresolved, dropping connection!
Oct 5 14:26:05 mysql1 kernel: [ 8.279197] block drbd1: helper command: /sbin/drbdadm split-brain minor-1
Oct 5 14:26:05 mysql1 kernel: [ 8.286125] block drbd1: helper command: /sbin/drbdadm split-brain minor-1 exit code 0 (0x0)
Oct 5 14:26:05 mysql1 kernel: [ 8.286144] drbd r0: conn( NetworkFailure -> Disconnecting )
Oct 5 14:26:05 mysql1 kernel: [ 8.286146] drbd r0: error receiving ReportState, e: -5 l: 0!
Oct 5 14:26:05 mysql1 kernel: [ 8.287009] drbd r0: Connection closed
Oct 5 14:26:05 mysql1 kernel: [ 8.287017] drbd r0: conn( Disconnecting -> StandAlone )
Oct 5 14:26:05 mysql1 kernel: [ 8.287018] drbd r0: receiver terminated
Oct 5 14:26:05 mysql1 kernel: [ 8.287019] drbd r0: Terminating drbd_r_r0

Esto se debe a que, ahora que tenemos dos nodos primarios, eso no es posible en una configuración primaria/secundaria. Entonces, asumiendo una identificación de datos nueva en mysql2, tenemos que degradar mysql1 a Secundario.

Así que en mysql1 ejecute:

[email protected]:~# drbdadm secondary r0
[email protected]:~# drbdadm connect --discard-my-data r0

En cambio, en mysql2, que es el superviviente del cerebro dividido , tenemos que ejecutar:

[email protected]:~# drbdadm connect r0

ahora puede verificar y ver que todo se está reconstruyendo correctamente, pero ahora mysql1 es secundario y mysql2 es primario.

[email protected]:~# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
srcversion: 1A9F77B1CA5FF92235C2213
1: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r-----
ns:0 nr:28224 dw:28224 dr:0 al:0 bm:1 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:229628
[=>..................] sync'ed: 11.2% (229628/257852)K
finish: 0:01:04 speed: 3,528 (3,528) want: 6,600 K/sec