Installation und Konfiguration von DRBD für die Replikation von Netzwerk-Dateisystemen unter Debian 8

von howtoforge · Juni 4, 2019

Lassen Sie uns über die Replikation des Netzwerk-Dateisystems sprechen.

Die Replikation von Netzwerk-Dateisystemen wird heute in vielen Szenarien häufig verwendet:

Replikation eines Dateisystems aus Sicherheitsgründen: Wenn ein Knoten ausfällt, ist der andere Knoten zugänglich.
Ein Dateisystem in eine andere Unternehmenszentrale zu replizieren, so dass jeder Mitarbeiter lokal und nicht über ein öffentliches Netzwerk Zugriff auf seine Daten hat. Aber wenn er zu der anderen Zentrale geht, hat er alle seine Daten, und wieder kann er vor Ort zugreifen.

Wie Sie sich vorstellen können, wird diese Art von System oft verwendet, um Dateisysteme für Cluster-Umgebungen zu erstellen.

Wir haben uns für die Implementierung der Lösung mit DRBD entschieden. Sein Hauptdarsteller ist (wie andere Systeme auch) High Availability and Disaster Recovery für Dateisysteme.

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

Voraussetzungen

Bevor wir beginnen, sind hier die Voraussetzungen:

Mindestens 2 Debian-Server.
Debian wird als Minimalinstallation installiert (überhaupt nicht notwendig, wenn Sie wissen, was Sie auf Produktionssystemen tun), empfohlene Anleitung https://www.howtoforge.com/tutorial/debian-8-jessie-minimal-server/
Mindestens 2 Linux-Laufwerke 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 gelöscht also nicht auf einer Festplatte mit Daten arbeiten.

DRBD-Installation

In unserem Beispiel werde ich zwei Knoten verwenden, die es sind:

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

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

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

Führen Sie dann die folgenden Befehle aus, um die 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 die folgende aussieht:

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

Durch die Konvention, /etc/drbd.d/global_common.conf enthält die globaleund gemeinsameAbschnitte der DRBD-Konfiguration, während die .res Dateien enthalten eine Ressourcein jedem Abschnitt.

In unserem Beispiel führen wir ein minimales Setup durch, das die Daten auf den beiden Knoten repliziert. Führen Sie auf jedem Knoten die folgenden Änderungen 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 {
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
}
...

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

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

Was wir bisher getan haben, ist folgendes:

Sie „opt-in“, um in die Benutzerstatistik von DRBD mit dem Parameter usage-count aufgenommen zu werden.
Ressourcen sind so konfiguriert, dass sie eine vollständig synchrone Replikation mit dem explizit anders angegebenen Protokoll Cunless verwenden.
Unser Cluster besteht aus zwei Knoten: mysql1 und mysql2.
Wir haben eine Ressource, die willkürlich benannt r0ist und als /dev/sdbuntergeordnetes Gerät verwendet wird und mit internen Metadaten konfiguriert ist.
Die Ressource verwendet den TCP-Port 7789 für ihre Netzwerkverbindungen und verbindet sich mit den IP-Adressen 192.168.152.100 und 192.168.152.110.

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

drbdadm create-md r0

Du solltest so etwas sehen:

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

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

drbdadm up r0
drbdadm primary --force r0

Um zu überprüfen, ob alles gut funktioniert, kannst du die Datei /proc/drbd auf beiden Knoten überprüfen und du solltest so etwas sehen:

Mysql1

root@mysql1:# 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

root@mysql2:# 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

Während der Bauphase können Sie das UpToDate/Inkonsistent feststellen, es ist korrekt, da dies die erste Synchronisation von Daten ist.

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

root@mysql1:/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

Jetzt haben wir ein neues Blockgerät namens /dev/drbd1, das wir mit unserem bevorzugten Dateisystemtyp formatieren können. Wenn wir es zum Beispiel in ext4 formatieren und auf /var/wwww mounten wollen, können wir es einfach tun:

root@mysql1:/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

Dann können wir unser Dateisystem mounten:

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

Das Verzeichnis /var/wwww wird nun über das drbd-System eingebunden.

In diesem Szenario haben wir mit einer Primary/Secondary-Konfiguration ein Disaster Recovery-System implementiert.

Wenn Sie in diesem Fall versuchen, das Dateisystem auf den zweiten Knoten zu mounten, erhalten Sie eine Fehlermeldung:

root@mysql2:~# 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

Dies ist normal und wird aufgrund unserer Konfiguration erwartet.

Jetzt können wir einen Fehler auf mysql1 simulieren, also schalten Sie ihn mit dem Befehl poweroff herunter.

Auf mysql2 können wir sehen, was los ist:

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 )

Der mysql2-Knoten erkennt, dass mysql1 tot ist, und wenn wir /proc/drbd überprüfen:

root@mysql2:~# 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

können wir sehen, dass der Status von Secondary/primary auf Secondary/unknown geändert wurde. Also machen wir jetzt den Trick und promoten mysql2 als primär. Auf mysql2 einfach ausführen:

drbdadm primary r0

lassen Sie uns noch einmal /proc/drbd überprüfen und die Magie sehen…..

root@mysql2:~# 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

Wie Sie sehen können, ist unser Knoten jetzt primär und kann regelmäßig montiert werden.

root@mysql2:~# mount /dev/drbd1 /var/www/
root@mysql2:~# 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

Jetzt gehen wir davon aus, dass wir mysql1 wieder aufnehmen wollen, wenn wir jetzt anfangen, kommen wir zu einer Gehirnteilung, in der Tat können Sie das Protokoll überprüfen und diese Fehler sehen:

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

Dies liegt daran, dass wir jetzt zwei primäre Knoten haben, die in einer Primär/Sekundär-Konfiguration nicht möglich sind. Wenn wir also von einer neuen Daten-ID auf mysql2 ausgehen, müssen wir mysql1 auf Secondary zurückstufen.

Also auf mysql1 laufen:

root@mysql1:~# drbdadm secondary r0
root@mysql1:~# drbdadm connect --discard-my-data r0

Auf mysql2 hingegen, das der Überlebende des gespaltenen Gehirns ist, müssen wir ausführen:

root@mysql2:~# drbdadm connect r0

jetzt können Sie überprüfen und sehen, dass alles korrekt wiederhergestellt wird, aber jetzt ist mysql1 sekundär und mysql2 primär.

root@mysql1:~# 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

Installation und Konfiguration von DRBD für die Replikation von Netzwerk-Dateisystemen unter Debian 8

Voraussetzungen

DRBD-Installation

Konfiguration Primär/Sekundär – Notfallwiederherstellung

Das könnte dich auch interessieren …

Suche

Seiten

Installation und Konfiguration von DRBD für die Replikation von Netzwerk-Dateisystemen unter Debian 8

Voraussetzungen

DRBD-Installation

Konfiguration Primär/Sekundär – Notfallwiederherstellung

Das könnte dich auch interessieren …

So installierst und konfigurierst du HAProxy unter Ubuntu 22.04

Was ist Ingress Controller und wie wird Nginx Ingress Controller in Kubernetes Cluster auf AWS mit Helm bereitgestellt?

Der Perfekte Desktop – Mint 13 (Maya)

Suche

Seiten