Aktiv / Passiv-Cluster werden an vielen Orten immer noch häufig verwendet und laufen in der Produktion. Nachfolgend finden Sie unser Produktionssetup . Es funktioniert einwandfrei. Sie können es entweder im manuellen Modus ( orchestrate=start) laufen lassen oder das automatische Failover aktivieren ( orchestrate=ha). Wir verwenden zfs, um von zfs Sende- / Empfangs- und zfs-Snapshots zu profitieren. Es ist jedoch auch möglich, drbd zu verwenden, wenn Sie eine synchrone Replikation bevorzugen.
Voraussetzungen:
- 2 Knoten (in meinem Setup 2 physische Knoten 400 Kilometer Entfernung)
- interne Festplatten
- 1 zfs-Pool auf jedem Knoten
- Stretched VLAN (in meinem Setup verwenden wir "Vrack" bei OVH Hosting Provider)
Schritte :
- Installieren Sie den opensvc-Agenten auf beiden Knoten ( https://repo.opensvc.com ).
- Formular opensvc cluster (3 Befehle erforderlich, beschrieben im Screencast unter https://www.opensvc.com )
- Erstellen Sie eine Root-SSH-Vertrauensstellung zwischen beiden Knoten
- Erstellen Sie 1 opensvc-Dienst pro kvm-Gast [Dienstkonfigurationsdatei unten]
root @ node1: ~ $ svcmgr -s win1 print config
[DEFAULT]
env = PRD
nodes = node1.acme.com node2.acme.com
id = 7a10881d-e5d5-4817-a8fe-e7a2004c5520
orchestrate = start
[fs#1]
mnt_opt = rw,xattr,acl
mnt = /srv/{svcname}
dev = data/{svcname}
type = zfs
[container#0]
type = kvm
name = {svcname}
guestos = windows
shared = true
[sync#1]
src = data/{svcname}
dst = data/{svcname}
type = zfs
target = nodes
recursive = true
schedule = @12h
Einige Erklärungen:
- Der Dienst heißt "win1" und jeder
{svcname}in der Dienstkonfigurationsdatei ist eine Referenz, die auf den tatsächlichen Dienstnamen (win1) verweist.
- Service-Start Gehen Sie wie folgt vor:
- Mount-ZFS-Dataset
data/win1auf Mountpoint/srv/win1
- Starten Sie den KVM-Container
win1
- ressource
sync#1wird verwendet, um eine asynchrone zfs-Dataset-Replikation an den Slave-Knoten zu deklarieren (data / win1 auf Knoten1 wird an data / win1 auf Knoten2 gesendet), einmal pro 12 Stunden im Beispiel (zfs-Senden / Empfangen wird vom opensvc-Agenten verwaltet).
- Der opensvc-Agent befasst sich auch mit der Replikation von kvm qemu config und definiert diese, wenn der Dienst auf den Slave-Knoten verlagert wird
Einige Verwaltungsbefehle:
svcmgr -s win1 start Starten Sie den Dienstsvcmgr -s win1 stop Beenden Sie den Dienstsvcmgr -s win1 stop --rid container#0 Stoppen Sie den Container-referenzierten Container # 0 in der Konfigurationsdateisvcmgr -s win1 switch Verschieben Sie den Dienst auf den anderen Knotensvcmgr -s win1 sync update Lösen Sie eine inkrementelle Kopie des zfs-Datasets aussvcmgr -s win1 sync full Lösen Sie eine vollständige Kopie des zfs-Datasets aus
Einige von mir verwaltete Dienste benötigen außerdem regelmäßig (täglich / wöchentlich / monatlich) zfs-Snapshots mit Aufbewahrung. In diesem Fall füge ich der Dienstkonfigurationsdatei das folgende Konfigurations-Snippet hinzu, und der opensvc-Agent erledigt den Job.
[sync#1sd]
type = zfssnap
dataset = data/{svcname}
schedule = 23:00-23:59@61
keep = 7
name = daily
recursive = true
sync_max_delay = 1d
[sync#1sw]
type = zfssnap
dataset = data/{svcname}
schedule = 23:00-23:59@61 sun
keep = 4
name = weekly
recursive = true
sync_max_delay = 7d
[sync#1sm]
type = zfssnap
dataset = data/{svcname}
schedule = 23:00-23:59@61 * *:first
keep = 6
name = monthly
recursive = true
sync_max_delay = 31d
Wie gewünscht füge ich auch eine lvm / drbd / kvm-Konfiguration hinzu:
drbd resource config /etc/drbd.d/kvmdrbd.res:
resource kvmdrbd {
device /dev/drbd10;
disk /dev/drbdvg/drbdlv;
on node1 {
address 1.2.3.4:12345;
meta-disk internal;
}
on node2 {
address 4.3.2.1:12345;
meta-disk internal;
}
}
opensvc service config file /etc/opensvc/kvmdrbd.conf:
root@node1# svcmgr -s kvmdrbd print config
[DEFAULT]
env = PRD
nodes = node1.acme.com node2.acme.com
id = 7a10881d-f4d3-1234-a2cd-e7a2018c4321
orchestrate = start
[disk#1]
type = lvm
vgname = {env.drbdvgname}
standby = true
[disk#2]
type = drbd
standby = true
shared = true
res = {svcname}
[fs#0]
mnt = {env.basedir}/{svcname}
type = ext4
dev = /dev/{env.drbddev}
shared = true
[container#0]
type = kvm
name = {svcname}
shared = true
[sync#i0]
schedule = @1440
[env]
basedir = /srv
drbddev = drbd10
drbdvgname = drbdvg
Einige Erklärungen :
- In meinem Setup repliziere ich lvm lv mit drbd. Ich erstelle ein Dateisystem auf dem drbd-Blockgerät. In diesem Dateisystem erstelle ich 1 Flatfile pro Festplatte, die ich dem kvm-Gast präsentieren möchte.
disk#1: ist die lvm vg, die das große logische Volume hostet. sollte mindestens 5 GB betragen.disk#2: ist die drbd-Festplatte, auf die der drbd-Ressourcenname verweist. Wenn der opensvc-Dienst "foo" heißt, sollten Sie /etc/drbd.d/foo.res haben. Oder ändern Sie den Parameter disk # 2.res in der Servicekonfigurationsdatei.fs#0 : Das Hauptdateisystem, in dem alle Festplattendateien für kvm guest gehostet werdencontainer#0: der kvm-Gast, gleicher Name wie der opensvc-Dienst im Beispiel. Der Agent muss in der Lage sein, den kvm-Gast mit DNS aufzulösen und eine Ping-Prüfung durchzuführen, bevor er den Start des Dienstes akzeptiert (wenn eine Ping-Antwort vorliegt, wird der kvm-Gast bereits irgendwo ausgeführt, und es ist keine gute Idee, ihn zu starten. Der doppelte Startschutz ist gewährleistet von opensvc agent)standby = true: bedeutet, dass diese Ressource aktiv bleiben muss, wenn der Dienst auf dem anderen Knoten ausgeführt wird. In unserem Beispiel ist es erforderlich, dass drbd weiterhin einwandfrei funktioniertshared = true: https://docs.opensvc.com/latest/agent.service.provisioning.html#shared-resources