Installa e configura DRDB per la replica del filesystem di rete su Debian 8

Parliamo della replica del filesystem di rete.

La replica del filesystem di rete viene spesso utilizzata oggi in molti scenari:

• Replica di un filesystem per motivi di sicurezza:se un nodo si guasta, l'altro nodo è accessibile.
• Per replicare un filesystem in un'altra sede aziendale, in modo che ogni dipendente abbia accesso ai propri dati in locale e non attraverso una rete pubblica. Ma se va nell'altra sede ha tutti i suoi dati e di nuovo può accedere localmente.

Come puoi immaginare, questo tipo di sistema viene spesso utilizzato per creare filesystem per ambienti cluster.

Abbiamo scelto di implementare la soluzione con DRDB. Il suo scopo principale è (come altri sistemi come questo) High Availability e Disaster Recovery per i file system.

Implementiamo la soluzione con Debian 8, ma dovrebbe funzionare anche su Ubuntu.

Prerequisiti

Prima di iniziare, ecco i prerequisiti:

• Almeno 2 server Debian.
• Debian è installato come installazione minima (non necessaria se sai cosa stai facendo sui sistemi di produzione) guida consigliata https://www.howtoforge.com/tutorial/debian-8-jessie-minimal-server/
• Almeno 2 dischi Linux in ogni server:/dev/sda per l'installazione linux, /dev/sdb per l'installazione DRDB.

ATTENZIONE!!!:Durante l'installazione, tutti i dati sul disco /dev/sdb verranno distrutti, quindi non lavorare su un disco con dati all'interno.

Installazione DRBD

Nel nostro esempio userò due nodi, che sono:

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

Su tutti i nodi, modifica il file /etc/hosts come segue:

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

Quindi esegui i seguenti comandi per installare DRDB:

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

Configurazione primaria/secondaria - Disaster Recovery

Il file di configurazione principale è /etc/drbd.conf che assomiglia al seguente:

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

Per convenzione, /etc/drbd.d/global_common.conf contiene le sezioni globali e comuni della configurazione DRBD, mentre .res i file contengono una risorsa in ogni sezione.

Nel nostro esempio eseguiamo una configurazione minima che replica i dati sui due nodi. Su ogni nodo esegui la seguente modifica:

Inizieremo a modificare il file /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
}
...

Ora creeremo il file di configurazione /etc/drbd.d/r0.res per la nostra risorsa. Crea il file su tutti i nodi e aggiungilo all'interno:

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;
  }
}

Quello che abbiamo fatto fino ad ora è il seguente:

• Sei "attivato" per essere incluso nelle statistiche di utilizzo di DRBD con parametro di conteggio dell'utilizzo.
• Le risorse sono configurate per utilizzare la replica completamente sincrona con il protocollo C, salvo diversamente specificato.
• Il nostro cluster è composto da due nodi: mysql1 e mysql2.
• Abbiamo una risorsa chiamata arbitrariamente r0 che utilizza /dev/sdb come dispositivo di livello inferiore ed è configurato con metadati interni.
• La risorsa utilizza la porta TCP 7789 per le sue connessioni di rete e si collega agli indirizzi IP 192.168.152.100 e 192.168.152.110 rispettivamente.

Su tutti i nodi inizializzare i metadati con il seguente comando:

drbdadm create-md r0

Dovresti vedere qualcosa del genere:

--== 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

Successivamente, abilitiamo la risorsa e inizializziamo la prima replica eseguita, solo sul primo nodo, dovrebbe iniziare a replicare:

drbdadm up r0
drbdadm primary --force r0

Per verificare se tutto funziona bene puoi controllare il file /proc/drbd su entrambi i nodi e dovresti vedere qualcosa del genere:

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 di costruzione puoi notare UpToDate/Incoerente , è corretto perché questa è la prima sincronizzazione dei dati.

Dopo che il filsystem è stato sincronizzato, questo cambia in UpToDate/UpToDate come nel seguente 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

Ora abbiamo un nuovo dispositivo a blocchi, chiamato /dev/drbd1 che possiamo formattare con il nostro tipo di filesystem preferito. Ad esempio, se vogliamo formattarlo in ext4 e montarlo su /var/www possiamo semplicemente fare: 

[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

Quindi possiamo montare il nostro filesystem:

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

La directory /var/www è ora montata tramite il sistema drbd.

In questo scenario, con una configurazione primaria/secondaria, abbiamo implementato un sistema di ripristino di emergenza.

In questo caso, se provi a montare il filesystem sul secondo nodo, riceverai un errore:

[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

Questo è normale e previsto a causa della nostra configurazione.

Ora possiamo simulare un errore su mysql1, quindi spegnilo con il comando poweroff.

Su mysql2 possiamo vedere cosa succede:

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 )

Il nodo mysql2 rileva che mysql1 è morto e se controlliamo /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

possiamo vedere lo stato cambiato da Secondary/primary a Secondary/sconosciuto. Quindi ora facciamo il trucco, promuovendo mysql2 come primario. Su mysql2 esegui semplicemente:

drbdadm primary r0

controlliamo ancora /proc/drbd e vediamo 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

Come puoi vedere, il nostro nodo ora è primario e può essere montato regolarmente.

[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

Ora assumiamo di voler riprendere mysql1, se iniziamo ora arriveremo a dividere il cervello, infatti puoi controllare il log e vedere questi errori:

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

Questo perché ora abbiamo due nodi primari, cosa che non è possibile in una configurazione Primario/Secondario. Quindi, supponendo un nuovo ID dati su mysql2, dobbiamo retrocedere mysql1 a secondario.

Quindi su mysql1 esegui:

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

Su mysql2 invece, che è il sopravvissuto al cervello diviso , dobbiamo eseguire:

[email protected]:~# drbdadm connect r0

ora puoi controllare e vedere che tutto si sta ricostruendo correttamente, ma ora mysql1 è secondario e mysql2 è 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