Cluster-Speicher für kleine Web-Cluster auf Basis von drbd+ocfs2

Was wir behandeln werden:
Wie man schnell ein gemeinsames Speicher für zwei Server auf Basis von drbd+ocfs2 Lösungen einrichtet.

Für wen ist das nützlich:
Dieses Tutorial ist hilfreich für Systemadministratoren und alle, die eine Speicherlösung auswählen oder eine neue Methode ausprobieren möchten.

Von welchen Lösungen wir abgesehen haben und warum

Häufig stehen wir vor der Herausforderung, in einem kleinen Web-Cluster einen gemeinsamen Speicher mit guter Lese- und Schreibleistung zu realisieren. Wir haben verschiedene Ansätze zur Implementierung von gemeinsamem Speicher für unsere Projekte ausprobiert, aber wenig war in der Lage, mehrere unserer Anforderungen gleichzeitig zu erfüllen. Jetzt erzählen wir, warum.

• Glusterfs hat uns hinsichtlich der Lese- und Schreibperformance nicht überzeugt; es trat ein Problem bei gleichzeitigen Lesevorgängen vieler Dateien auf und die CPU-Auslastung war hoch. Das Problem mit dem Lesen von Dateien hätte man lösen können, indem man direkt auf die Bricks zugreift, aber das ist nicht immer anwendbar und insgesamt nicht korrekt.

• Ceph gefiel uns nicht aufgrund übermäßiger Komplexität, die für Projekte mit 2-4 Servern gearbeitet werden., insbesondere wenn das Projekt später gewartet wird. Zudem gibt es erhebliche Leistungsgrenzen, die den Aufbau separater Storage-Cluster erforderlich machen, ähnlich wie bei glusterfs.

• Die Nutzung eines einzelnen NFS-Servers für die Bereitstellung eines gemeinsamen Speichers wirft Fragen zur Ausfallsicherheit auf.

• S3 ist eine ausgezeichnete, beliebte Lösung für bestimmte Anwendungsfälle, aber es handelt sich nicht um ein Dateisystem, was die Einsatzmöglichkeiten einschränkt.

• Lsyncd. Wenn wir bereits über 'Nicht-Dateisysteme' sprechen, sollten wir auch diese beliebte Lösung erwähnen. Es eignet sich nicht für bidirektionalen Austausch (aber wenn man wirklich möchte, ist es möglich) und funktioniert zudem instabil bei einer großen Anzahl von Dateien. Ein angenehmer Aspekt ist, dass es einspart. Die Ursache dafür liegt in der Programmarchitektur: Sie verwendet Inotify zur Überwachung von Arbeitsobjekten, die beim Start und beim Rescannen hinzugefügt werden. Der Übertragungsmechanismus nutzt Rsync.

Tutorial: So implementieren Sie einen gemeinsamen Speicher auf Basis von DRBD + OCFS2

Eine der bequemsten Lösungen für uns war die Kombination OCFS2 + DRBD. Jetzt werden wir Ihnen erklären, wie Sie schnell einen gemeinsamen Speicher für zwei Server Datenbanklösungen bereitstellen können. Aber zunächst etwas zu den Komponenten:

DRBD — ein Speichersystem, das standardmäßig mit Linux geliefert wird und es ermöglicht, Daten zwischen Servern blockweise zu replizieren. Die Hauptanwendung besteht darin, ausfallsichere Speicherlösungen zu erstellen.

OCFS2 — ein Dateisystem, das die gemeinsame Nutzung desselben Speichers durch mehrere Systeme ermöglicht. Es ist Bestandteil der Linux-Distribution und besteht aus einem Kernel-Modul sowie Tools im Userspace für die Arbeit mit dem Dateisystem. OCFS2 kann nicht nur über DRBD, sondern auch über iSCSI mit mehrfacher Verbindung verwendet werden. In unserem Beispiel verwenden wir DRBD.

Alle Aktionen werden auf Ubuntu Server 18.04 in der Minimal-Konfiguration ausgeführt.

Schritt 1. DRBD konfigurieren:

Im Datei /etc/drbd.d/drbd0.res beschreiben wir unser virtuelles Blockgerät /dev/drbd0:

resource drbd0 {
    syncer { rate 1000M; }
    net {
        allow-two-primaries;
        after-sb-0pri discard-zero-changes;
        after-sb-1pri discard-secondary;
        after-sb-2pri disconnect;
    }
    startup { become-primary-on both; }
    on drbd1 {
        meta-disk internal;
        device /dev/drbd0;
        disk /dev/vdb1;
        address 10.10.10.192:7789;
}
    on drbd2 {
        meta-disk internal;
        device /dev/drbd0;
        disk /dev/vdb1;
        address 10.10.10.193:7789;
}
}

meta-disk internal — dieselelben Blockgeräte zur Speicherung der Metadaten verwenden
device /dev/drbd0 — verwenden Sie /dev/drbd0 als Pfad zu drbd.
disk /dev/vdb1 — verwenden Sie /dev/vdb1
syncer { rate 1000M; } — nutzen Sie Gigabit-Bandbreite
allow-two-primaries — eine wichtige Option, die Änderungen auf zwei Primary-Servern zulässt
after-sb-0pri, after-sb-1pri, after-sb-2pri — Optionen, die das Verhalten des Knotens bei Split-Brain-Szenarien steuern. Weitere Informationen finden Sie in der Dokumentation.
become-primary-on both — setzt beide Knoten auf Primary.

In unserem Fall haben wir zwei vollständig identische VMs mit einer dedizierten virtuellen Netzwerkbandbreite von 10 Gigabit.

In unserem Beispiel sind die Netzwerknamen der beiden Clusterknoten drbd1 und drbd2. Für das richtige Funktionieren müssen die Namen und IP-Adressen der Knoten in /etc/hosts zugeordnet werden.

10.10.10.192 drbd1
10.10.10.193 drbd2

Schritt 2. Konfigurieren Sie die Knoten:

Führen Sie auf beiden Servern aus:

drbdadm create-md drbd0

modprobe drbd
drbdadm up drbd0
cat /proc/drbd

Wir erhalten Folgendes:

Jetzt können wir die Synchronisierung starten. Auf dem ersten Knoten müssen wir Folgendes ausführen:

drbdadm primary --force drbd0

Status überprüfen:

cat /proc/drbd

Ausgezeichnet, die Synchronisierung hat begonnen. Wir warten auf den Abschluss und sehen folgendes Bild:

Schritt 3. Wir starten die Synchronisierung auf dem zweiten Knoten:

drbdadm primary --force drbd0

Wir erhalten Folgendes:

Jetzt können wir von beiden Servern in drbd schreiben.

Schritt 4. Installation und Konfiguration von ocfs2.

Wir werden eine relativ triviale Konfiguration verwenden:

cluster:
     node_count = 2
     name = ocfs2cluster

node:
     number = 1
     cluster = ocfs2cluster
     ip_port = 7777
     ip_address = 10.10.10.192
     name = drbd1

node:
     number = 2
     cluster = ocfs2cluster
     ip_port = 7777
     ip_address = 10.10.10.193
     name = drbd2

Diese muss in /etc/ocfs2/cluster.conf beiden Knoten eingetragen werden.

Wir erstellen ein Dateisystem auf drbd0 auf einem beliebigen Knoten:

mkfs.ocfs2 -L "testVol" /dev/drbd0

Hier haben wir ein Dateisystem mit dem Label testVol auf drbd0 erstellt, wobei die Standardparameter verwendet wurden.

In /etc/default/o2cb müssen wir einstellen (wie in unserer Konfigurationsdatei)

O2CB_ENABLED=true 
O2CB_BOOTCLUSTER=ocfs2cluster 

und auf jedem Knoten ausführen:

o2cb register-cluster ocfs2cluster

Danach aktivieren wir alles erforderliche Unit und fügen es zum Autostart hinzu:

systemctl enable drbd o2cb ocfs2
systemctl start drbd o2cb ocfs2

Ein Teil davon wird bereits im Zuge der Konfiguration gestartet.

Schritt 5. Wir fügen die Einhängepunkte in fstab auf beiden Knoten hinzu:

/dev/drbd0 /media/shared ocfs2 defaults,noauto,heartbeat=local 0 0

Verzeichnis /media/shared Dabei sollte im Voraus ein Volume erstellt werden.

Hier verwenden wir die Option noauto, was bedeutet, dass das Dateisystem beim Start nicht automatisch gemountet wird (ich bevorzuge, Netzwerkdateisysteme über systemd zu mounten) und heartbeat=local, was den Einsatz des Heartbeat-Dienstes auf jedem Knoten bedeutet. Es gibt auch globalen Heartbeat, der besser für große Cluster geeignet ist.

Anschließend kann gemountet werden /media/shared und die Synchronisierung des Inhalts überprüft werden.

Fertig! Das Ergebnis ist ein mehr oder weniger ausfallsicherer Speicher mit Skalierbarkeit und anständiger Leistung.

Quelle: habr.com