Installieren und konfigurieren Sie DRDB für die Replikation des Netzwerkdateisystems unter Debian 8

Lassen Sie uns über die Replikation des Netzwerkdateisystems sprechen.

Die Netzwerk-Dateisystemreplikation wird heute oft in vielen Szenarien verwendet:

• Replikation eines Dateisystems aus Sicherheitsgründen:Wenn ein Knoten ausfällt, ist der andere Knoten zugänglich.
• Um ein Dateisystem in eine andere Firmenzentrale zu replizieren, damit jeder Mitarbeiter lokal und nicht über ein öffentliches Netzwerk Zugriff auf seine Daten hat. Aber wenn er in die andere Zentrale geht, hat er alle seine Daten und kann wieder lokal darauf zugreifen.

Wie Sie sich vorstellen können, wird diese Art von System häufig zum Erstellen von Dateisystemen für Clusterumgebungen verwendet.

Wir haben uns entschieden, die Lösung mit DRDB zu implementieren. Sein Hauptzweck ist (wie andere Systeme wie dieses) Hochverfügbarkeit und Notfallwiederherstellung für Dateisysteme.

Wir implementieren die Lösung mit Debian 8, aber es sollte auch auf Ubuntu funktionieren.

Voraussetzungen

Bevor wir beginnen, hier sind die Voraussetzungen:

• Mindestens 2 Debian-Server.
• Debian wird als Minimalinstallation installiert (überhaupt nicht erforderlich, wenn Sie wissen, was Sie auf Produktionssystemen tun). Empfohlene Anleitung https://www.howtoforge.com/tutorial/debian-8-jessie-minimal-server/
• Mindestens 2 Linux-Festplatten in jedem Server:/dev/sda für die Linux-Installation, /dev/sdb für die DRDB-Installation.

ACHTUNG!!!:Während der Installation werden alle Daten auf der Festplatte /dev/sdb zerstört, also nicht auf einer Festplatte mit Daten darin arbeiten.

DRBD-Installation

In unserem Beispiel verwende ich zwei Knoten, nämlich:

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

Ändern Sie auf allen Knoten die Datei /etc/hosts wie folgt:

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

# Die folgenden Zeilen sind für IPv6-fähig wünschenswert hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Führen Sie dann die folgenden Befehle aus, um DRDB zu installieren:

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

Konfiguration Primär/Sekundär – Notfallwiederherstellung

Die Hauptkonfigurationsdatei ist /etc/drbd.conf, die wie folgt aussieht:

fügen Sie „drbd.d/global_common.conf“ hinzu;
fügen Sie „drbd.d/*.res“ hinzu;

Per Konvention /etc/drbd.d/global_common.conf enthält die globalen und gemeinsamen Abschnitte der DRBD-Konfiguration, während die Datei .res Dateien enthalten eine Ressource in jedem Abschnitt.

In unserem Beispiel führen wir eine minimale Einrichtung durch, bei der die Daten auf den beiden Knoten repliziert werden. Führen Sie auf jedem Knoten die folgende Änderung durch:

Wir beginnen mit der Bearbeitung der Datei /etc/drbd.d/global_common.conf modify the default line from

global {
usage-count yes;
# minor-count dialog-refresh disable-ip-verification
}
...
net {
Protokoll C;
# Protokollzeitüberschreitung max. Epochengröße max. Puffer unplug-watermark
# connect-int ping-int sndbuf-size rcvbuf-size ko-count
# allow- Zwei-Primärdateien 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
}
...

Jetzt erstellen wir die Konfigurationsdatei /etc/drbd.d/r0.res für unsere Ressource. Erstellen Sie die Datei auf allen Knoten und fügen Sie Folgendes hinzu:

resource r0 { on mysql1.local.vm { device /dev/drbd1; Festplatte /dev/sdb; Adresse 192.168.152.100:7789; Meta-Festplatte intern; } auf mysql2.local.vm { Gerät /dev/drbd1; Festplatte /dev/sdb; Adresse 192.168.152.110:7789; Meta-Festplatte intern; }}

Was wir bisher gemacht haben, ist Folgendes:

• Sie "stimmen zu", in die Nutzungsstatistiken von DRBD mit  Usage-Count-Parameter aufgenommen zu werden.
• Ressourcen sind so konfiguriert, dass sie eine vollständig synchrone Replikation verwenden, wobei Protocol Cunless ausdrücklich anders angegeben ist.
• Unser Cluster besteht aus zwei Knoten: mysql1 und mysql2.
• Wir haben eine Ressource mit dem willkürlichen Namen r0 welches /dev/sdb verwendet als untergeordnetes Gerät und wird mit internen Metadaten konfiguriert.
• Die Ressource verwendet den TCP-Port 7789 für ihre Netzwerkverbindungen und bindet an die IP-Adressen 192.168.152.100 bzw. 192.168.152.110.

Initialisieren Sie auf allen Knoten die Metadaten mit dem folgenden Befehl:

drbdadm create-md r0

Sie sollten so etwas sehen:

--==Vielen Dank für Ihre Teilnahme an der globalen Nutzungsumfrage ==--
Die Antwort des Servers lautet:

Sie sind der 2963. Benutzer, der diese Version installiert hat
 Aktivitätsprotokoll wird initialisiert
Bitmap wird NICHT initialisiert
Metadaten werden geschrieben...
Neuer drbd-Metadatenblock erfolgreich erstellt.
Erfolg

Als nächstes aktivieren wir die Ressource und initialisieren den ersten Replikationslauf, nur auf dem ersten Knoten sollte die Replikation beginnen:

drbdadm up r0
drbdadm primary --force r0

Um zu überprüfen, ob alles gut funktioniert, können Sie die Datei /proc/drbd auf beiden Knoten überprüfen und Sie sollten so etwas sehen:

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:foos:5188060
[>....................] synchronisiert:1,1% (5064/5116)Mfinish:0:17:21 Geschwindigkeit:4.964 (4.964) K/sek

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:foos:5225188
[>....................] synchronisiert:0,4% (5100/5116)Mfinish:0:29:41 Geschwindigkeit:2.916 (2.916) Soll:5.160 K/sec

Während der Build-Phase können Sie das UpToDate/Inconsistent bemerken , es ist richtig, da dies die erste Synchronisierung von Daten ist.

Nachdem das Dateisystem synchronisiert wurde, ändert sich dieser Schleier zu UpToDate/UpToDate wie im folgenden Protokoll:

[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:foos:0

Jetzt haben wir ein neues Blockgerät namens /dev/drbd1, das wir mit unserem bevorzugten Dateisystemtyp formatieren können. Wenn wir es beispielsweise in ext4 formatieren und unter /var/www mounten möchten, können wir einfach Folgendes tun: 

[email protected]:/home/sysop# mkfs.ext4 /dev/drbd1
mke2fs 1.42.12 (29. August 2014)
Creazione of file system con 1310671 4k blocchi e 327680 inode 
Etichetta del file system=ab3e18c9-e8cb-42c8-977a-ab79bdb18aea
Sicherung der Superblocco Salvati nei blocchi:
32768, 98304, 163840, 229376, 294912, 819200, 884736
 Gruppentabellen zuweisen:fatto
Scrittura delle tavole degli inode:fatto
Journal erstellen (32768 Blöcke):fatto
Scrittura delle informazioni dei super-blocchi e dell'accounting del file system:fatto 

 Dann können wir unser Dateisystem mounten:
 
mkdir /var/www
mount /dev/drbd1 /var/www
 

 Das Verzeichnis /var/www wird jetzt über das drbd-System gemountet.
 

 In diesem Szenario haben wir mit einer primären/sekundären Konfiguration ein Notfallwiederherstellungssystem implementiert.
 

 Wenn Sie in diesem Fall versuchen, das Dateisystem auf dem zweiten Knoten einzuhängen, erhalten Sie einen Fehler:
 
[email protected]:~# mount /dev/drbd1 /var/www/
mount:/dev/drbd1 ist schreibgeschützt, mountet schreibgeschützt
mount:mount /dev/drbd1 auf /var/www fehlgeschlagen:Tipo di supporto errato
 

 Dies ist normal und aufgrund unserer Konfiguration zu erwarten.
 

 Jetzt können wir einen Fehler auf mysql1 simulieren, also schalten Sie es mit dem poweroff-Befehl aus.
 

 Auf mysql2 können wir sehen, was passiert:
 
5. Oktober 13:52:14 mysql2-Kernel:[13458.629215] drbd r0:PingAck kam nicht rechtzeitig an.
5. Oktober 13:52:14 mysql2-Kernel:[13458.629587] drbd r0:peer( Primary -> Unknown ) conn( Connected -> NetworkFailure ) pdsk( UpToDate -> DUnknown )
5. Okt 13:52:14 mysql2 Kernel:[13458.629919] drbd r0:asender beendet
5. Okt 13:52:14 mysql2-Kernel:[13458.629921] drbd r0:drbd_a_r0 wird beendet
5. Okt. 13:52:14 mysql2-Kernel:[13458.630028] drbd r0:Verbindung geschlossen
5. Okt. 13:52:14 mysql2-Kernel:[13458.630035] drbd r0:conn( NetworkFailure -> Unconnected )
5. Okt 13:52:14 mysql2 Kernel:[13458.630035] drbd r0:Empfänger beendet
5. Okt 13:52:14 mysql2 Kernel:[13458.630036] drbd r0:Neustart des Empfänger-Threads
5. Oktober 13:52:14 mysql2-Kernel:[13458.630037] drbd r0:Empfänger (neu) gestartet
5. Oktober 13:52:14 mysql2-Kernel:[13458.630041] drbd r0:conn( Unconnected -> WFConnection )
 

 Der mysql2-Knoten erkennt, dass mysql1 tot ist, und wenn wir die Datei /proc/drbd überprüfen:
 
[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:foos:0
 

 Wir können sehen, dass sich der Status von Sekundär/primär zu Sekundär/unbekannt geändert hat. Also machen wir jetzt den Trick und fördern mysql2 als primär. Führen Sie auf mysql2 einfach Folgendes aus:
 
drbdadm primary r0
 

 lasst uns noch einmal /proc/drbd überprüfen und die Magie sehen...
 
[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:foos:0
 

 Wie Sie sehen können, ist unser Knoten jetzt primär und kann regelmäßig gemountet werden.
 
[E-Mail-geschützt]:~# mount /dev/drbd1 /var/www/
[E-Mail-geschützt]:~# df -h
Dateisystem 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
 

 Jetzt gehen wir davon aus, dass wir mysql1 wieder aufnehmen wollen, wenn wir jetzt anfangen, kommen wir zu Split Brain, tatsächlich können Sie das Protokoll überprüfen und diese Fehler sehen:
 
5. Oktober 14:26:04 mysql1-Kernel:[ 7.760588] drbd r0:conn( StandAlone -> Unconnected )
5. Oktober 14:26:04 mysql1-Kernel:[ 7.760599] drbd r0:Starte Empfänger-Thread ( von drbd_w_r0 [458])
5. Okt 14:26:04 mysql1 drbdadm[435]:Netz anpassen:r0
5. Okt 14:26:04 mysql1 drbdadm[435]:]
Okt 5 14:26:04 mysql1-Kernel:[ 7.769318] drbd r0:Empfänger (neu) gestartet
5. Okt 14:26:04 mysql1-Kernel:[ 7.769327] drbd r0:conn( Unconnected -> WFConnection )
5. Okt. 14:26:04 mysql1 /etc/init.d/mysql[485]:MySQL-PID nicht gefunden, PID-Datei erkannt/geschätzt:/var/run/mysqld/mysqld.pid
5. Okt. 14:26 :04 mysql1 acpid:Starten mit netlink und der Eingabeschicht
5. Oktober 14:26:04 mysql1 acpid:1 Regel geladen
5. Oktober 14:26:04 mysql1 acpid:warten auf Ereignisse:Ereignisprotokollierung ist aus
5. Okt. 14:26:05 mysql1-Kernel:[8.270578] drbd r0:Handshake erfolgreich:Vereinbarte Netzwerkprotokollversion 101
5. Okt. 14:26:05 mysql1-Kernel:[8.270581] drbd r0:Zustimmung zur Unterstützung von TRIM auf Protokollebene 
5. Oktober 14:26:05 mysql1-Kernel:[ 8.270770] drbd r0:conn( WFConnection -> WFReportParams )
5. Oktober 14:26:05 mysql1-Kernel:[ 8.270771] drbd r0:Starten eines Sender-Threads (von drbd_r_r0 [461])
5. Okt. 14:26:05 mysql1-Kernel:[8.272594] block drbd1:drbd_sync_handshake:
5. Okt. 14:26:05 mysql1-Kernel:[8.272597] block drbd1:self 242B364F4A5B9C68:525CC995A3CFBA2B:44A1DE193A6C6701:0000000000000004 Bits:64463 Fahnen:0 
 5. Oktober 14.26.05 mysql1 kernel:[8,272598] Block drbd1:Peer 6903F6042F95F5FF:525CC995A3CFBA2A:44A1DE193A6C6700:0000000000000004 Bits:4 Fahnen:0 
5. Oktober 14:26:05 mysql1-Kernel:[8.272599] Block drbd1:uuid_compare()=100 nach Regel 90
5. Oktober 14:26:05 mysql1-Kernel:[8.272601] Block drbd1:Hilfsbefehl:/sbin /drbdadm initial-split-brain minor-1
5. Okt 14:26:05 mysql1-Kernel:[8.272692] drbd r0:Meta-Verbindung durch Peer beendet.
5. Okt 14:26:05 mysql1-Kernel :[ 8.272720] drbd r0:conn( WFReportParams -> NetworkFailure )
5. Okt 14:26:05 mysq l1-Kernel:[8.272722] drbd r0:asender beendet
5. Oktober 14:26:05 mysql1-Kernel:[8.272722] drbd r0:Beenden von drbd_a_r0
5. Oktober 14:26:05 mysql1-Kernel:[8.279158] block drbd1:Hilfsbefehl:/sbin/drbdadm initial-split-brain minor-1 Exit-Code 0 (0x0)
5. Okt 14:26:05 mysql1-Kernel:[8.279173] block drbd1:Split-Brain erkannt, aber nicht aufgelöst , Verbindungsabbruch!
5. Okt. 14:26:05 mysql1-Kernel:[8.279197] block drbd1:helper command:/sbin/drbdadm split-brain minor-1
5. Okt. 14:26:05 mysql1-Kernel -> Verbindungsabbruch )
5. Okt. 14:26:05 mysql1-Kernel:[ 8.286146] drbd r0:Fehler beim Empfangen von ReportState, e:-5 l:0!
5. Okt. 14:26:05 mysql1-Kernel:[ 8.287009] drbd r0:Verbindung geschlossen
5. Okt 14:26:05 mysql1 Kernel:[ 8.287017] drbd r0:conn( Disconnecting -> StandAlone )
5. Okt 14:26:05 mysql1-Kernel:[ 8.287018] drbd r0:Empfänger beendet
5. Okt 14:26:05 mysql1-Kernel:[ 8.287019] drbd r0:drbd_r_r0 wird beendet
 

 Dies liegt daran, dass wir jetzt zwei primäre Knoten haben, was in einer primären/sekundären Konfiguration nicht möglich ist. Unter der Annahme einer neuen Daten-ID auf mysql2 müssen wir mysql1 auf Secondary herabstufen.
 

 Also auf mysql1 ausführen:
 
[email protected]:~# drbdadm secondary r0
[email protected]:~# drbdadm connect --discard-my-data r0
 

 Stattdessen auf mysql2, dem Split Brain Survivor , müssen wir ausführen:
 
[email protected]:~# drbdadm connect r0
 

 Jetzt können Sie überprüfen und sehen, dass alles korrekt neu erstellt wird, aber jetzt ist mysql1 sekundär und mysql2 primär.
 
[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
[=>..................] synchronisiert:11,2% (229628/257852)K
Ziel:0:01:04 Geschwindigkeit:3.528 (3.528) Soll:6.600 K/Sek.