Proxmox: Installation 2 Node Cluster mit Replikation und Live-Migration
Aus znilwiki
Changelog:
- 29.09.2024 erste Version
Vorwort
Ich habe mir einen 2 Node Cluster mit Replikation der VMs und möglicher Live-Migration aufgebaut.
Das ganze läuft auf 2 Mini-PCs mit folgender Ausstattung:
- Intel N95 Prozessor (4 Kerne, max 3.4GHz)
- 16GB RAM DDR4
- 512GB M.2 SATA SSD
- 2 x GigaBit-LAN
Die Büchsen kosten um die 200 Euro pro Stück, die Hardware stelle ich separat vor.
Es gab einige Hürden bis ich beide in einem Cluster am laufen hat UND erfolgreich replizieren und eine Live-Migration machen konnte.
Das fing schon damit an das ich beim ersten Setup immer nur Weiter geklickt habe, damit wurde das System mit LVM und 2 Partitionen im EXT4 Format installiert.
Funktioniert an sich - aber ohne ZFS keine Replikation, ohne Replikation keine Live-Migration.
Voraussetzungen
Für ein Failover Cluster mit 2 Nodes, Replikation und Live-Migration brauchen wir folgendes
- 2 Hardware System, möglichst identisch ausgestattet, gleiche CPU-Familie / Generation
- Ein separates Linux-System als Quorum (Es wird nur ein Dienst installiert), dieses darf NICHT mit auf den Proxmox-Servern laufen
- Alternativ ein 3. Proxmox-Server.
USB-Stick für Installation vorbereiten
Wir legen einen USB-Stick mit mindestens 2GB bereit und laden uns die Installations-ISO herunter (dort die neueste Version):
https://www.proxmox.com/de/downloads/proxmox-virtual-environment/iso
und RUFUS:
https://rufus.ie/de/
es reicht die Portable Version.
Wir starten Rufus, ja es richtig das das Programm Administrationsrechte anfordert (wir wollen einen USB-Stick partitionieren):
Unter (1) sollte der USB-Stick eingestellt sein, unter 2 wählen wir die ISO mit Proxmox, z.B. proxmox-ve_8.2-2.iso.
Es kommt einen Warnung
Dann auf START klicken:
Wenn er fertig ist können wir mit der Installation loslegen!
Installation der Nodes von USB-Stick
Wir booten das System vom USB-Stick:
Jetzt kommt der wichtige Teil:
Hier unbedingt auf Options klicken:
und eines der zfs Dateisystem auswählen. Habt Ihr nur die eine Festplatte so sollte das
zfs (RAID0) sein.
Falls Ihr eine Boot-Festplatte habt und die VMs später auf einer separaten Festplatte liegen sollen, so braucht ihr das nicht extra von ext4 ändern, müsste aber dann unten die richtige Festplatte gewählt haben.
Das mit dem zfs ist wichtig - ohne ist keine Replikation möglich.
Dann auf Next und die Sprache auswählen + Passwort und Email setzen.
Beim Netzwerk:
Wählt Ihr - falls mehr als eine Netzwerkkarte die richtige aus. Ggf. beim Setup nur ein Netzwerkkabel stecken.
Diese Netzwerkkarte landet dann automatisch in einer Linux Bridge mit dem Namen vmbr0 über welche dann später unsere VMs laufen. Und das Management ist darüber erreichbar.
Danach startet das System neu und ist unter
https://IP-Adresse:8006
im Webbrowser erreichbar:
Der Benutzername ist root, das Passwort hattet Ihr während des Setups festgelegt.
Repository anpassen und Proxmox Updaten
Das kann man über die Shell / SSH machen oder über die GUI:
per SSH / Shell
Ihr verbindet euch per SSH mit dem frisch installierten Server,
Benutzername ist wiederum root mit eurem Passwort:
Dann bearbeiten wir folgende Dateien:
nano /etc/apt/sources.list
und unten folgende 2 Zeilen anhängen (für Proxmox 8.x.x / basierend auf Debian Bookworm:
# Community Repository deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription
Ggf. müsst Ihr bookworm durch das Wort ersetzen was hinter den anderen dort aufgeführten Repositorys steht
Jetzt noch die vorhandenen Enterprise Repos deaktivieren:
nano /etc/apt/sources.list.d/ceph.list
und ein # vor die Zeile setzen:
sowie
nano /etc/apt/sources.list.d/pve-enterprise.list
und ebenfalls alles auskommentieren:
Jetzt können wir die Repository-Informationen aktualisieren:
apt update
und die Updates einspielen:
apt full-upgrade -y
Im Anschluss neu starten:
reboot
per GUI
Wir melden und an der WebGUI an, markieren den Host und wählen die Einstellungen für die Repos:
Dort dann (3) auf Add:
Die Warnung klicken wir weg,
Im Drop-Down "No Subscription" wählen und hinzufügen.
Dann die beiden unteren Einträge mit dem "Enterprise" in der Spalte "Components" nacheinander markieren und dann auf Disable:
Im Anschluss muss das in etwa so aussehen:
Um die Updates zu suchen und einzuspielen gehen wir links eine Option höher (1), lassen oben dann nach Updates suchen (2) und können die gefundenen dann mit (3) einspielen:
Im Anschluss schadet ein Reboot nicht, den könnte Ihr oben rechts auslösen:
Auf der GUI seht ihr nicht viel davon, die aktualisiert sich einfach nicht mehr bis der Host wieder da ist.
Optional: 2te Netzwerkkarte für Cluster und Replikation/Migration verwenden
Proxmox ab Version 8 kann mit mehren Netzwerkkarten / IP-Adressen umgehen, siehe auch
https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pvecm_redundancy
Ich aktiviere deshalb die 2 Netzwerkkarte in meinen Mini-PCs und weise diesen separate IP-Adressen aus einem anderen Netzwerk zu.
Wir melden uns am Proxmox-Host per Webbrowser an und navigieren zu den Netzwerkeinstellungen:
In diesem Fall sehen wir 3 Netzwerkgeräte, die Namen der einzelnen Netzkarten variiert je nach Hardware:
vmbr0vom Typ Linux Bridge. Ist Active: Yes und enthält die Netzwerkkarteens192. Dahinter steht die IP-Adresse über welche wir auchh gerade auf das System zugreifenens192vom Typ Network Device. Die Kartte ist Active: Yes aber Autostart: No und hat keine IP-Adresse da diese zum Gerätvmbr0gehörtens224vom Typ Network Device. Diese Karte ist noch ungenutzt! Active: No und Autostart: No
In meinem Fall kann ich also eine 2. IP-Adresse auf ens224 legen und nutzen.
Wenn Ihr ein Netzwerkkabel in den Port steckt so wird dieser nicht aktiv / hat keinen Link. Weil der Port noch nicht konfiguriert ist.
Wir klicken die Karte an / markieren diese und oben auf Edit:
Hier trage ich eine IP-Adresse aus einem anderen Netzwerk ein, es sollte NICHT das gleiche Netzwerk wie die andere IP-Adresse des System sein. Nur so können wir gezielt routen.
Das Gateway lasse ich frei da es keines in diesem Netzwerk gibt:
172.31.0.231/24
entspricht
IP.........: 172.31.0.231 Subnetmaske: 255.255.255.0
Den Haken bei Autostart nicht vergessen!
Dann auf Apply Configuration und die Netzwerkkarte wird online geschaltet:
Das ganze wiederholen wir nun auf den weiteren Proxmox-Hosts.
Wir melden uns wieder per SSH an beiden Hosts an und prüfen ob diese sich auf allen Adressen gegenseitig erreichen können:
Cluster erstellen aus 2 Nodes
Wir gehen auf die Weboberfläche des ersten Host und erstellen einen neuen Cluster unter
Datacenter => Cluster => Create Cluster
Bei nur einer Netzwerkkarte vergebt Ihr den Namen, als Link sollte da die IP-Adresse des Systems stehen:
Falls Ihr eine 2. Netzwerkkarte eingerichtet habt, sollte es so aussehen:
per Add fügt Ihr einen Eintrag hinzu. Der Link mit der Nummer 0 sollte die IP-Adresse des separaten Netzwerks enthalten, das wird dann primär bevorzugt / der Datenverkehr zwischen den Proxmox-Hosts primär darüber geleitet.
Nach einem Klick auf Create dauert es nur wenige Sekunden und wir haben unser Cluster mit dem ersten Node:
Wir klicken auf Join Information und im neuen Fenster unten links auf Copy Information:
Nun wechseln wir auf den zweiten Proxmox-Host in die Cluster-Einstellungen. Statt einen neuen zu erstellen, klicken wir nun auf Join Cluster:
In dem Fenster fügen wir nun ein was wir vom anderen Host kopiert haben, sofort ändert sich die Ansicht:
Tragt das Passwort des Benutzer root ein und wählt unten die zueinander passenden Netzwerkadressen.
Dann auf Join 'Clustername':
Es erscheint das Statusfenster ... und dann geht es nicht weiter:
Alles ok! Er hat gerade das Zertifikat ausgetauscht, die Sitzung ist ungültig! Auf dem ersten Host sieht es auch komisch aus:
Jeweils F5 löst das Problem in beiden Browsersitzungen:
Optional: Migrations- und Replikationsnetzwerk setzen bei 2 Netzwerkkarten
Das eingestellte Migrationsnetz wird sowohl für die Live-Migration als auch für die Replikation (z.B. ZFS) verwendet.
Das habe ich per Zabbix-Monitoring geprüft - und es funktioniert wirklich, auch die Replikation geht über das eingestellte Migrationsnetzwerk.
Wir wechseln zu den Cluster-Optionen und bearbeiten den Eintrag Migration Settings:
Im Feld unten wählen wir das gewünschte Netzwerk und speichern:
Quorum hinzufügen
Die beiden Proxmox-Host arbeiten zusammen in einem Cluster. Sie könnten also z.B. Hochverfügbarkeit bieten. Fällt Host A aus so könnte man die VMs die auf diesen liefen auf dem Host B wieder starten. Das Problem bei 2 Hosts ist festzustellen, wer das Problem hat.
Fällt Host A aus, kann Host B nicht wissen ob A nun ausgeschaltet ist - oder ob nur die Netzwerkverbindung unterbrochen wurde.
Oder ob vielleicht sogar Host B selbst das Problem ist weil diese seine Netzwerkverbindung verloren hat.
Im schlimmsten Fall würden dann die gleichen VMs dann auf beiden Hosts laufen und deren Daten sich auseinander entwickeln. Das wird auch als Split Brain bezeichnet.
Um das zu verhindern müssen Cluster am besten immer aus 3 Parteien bestehen. Es ginge auch mit einem 3. Proxmox Server (auf dem dann aber keine VMs laufen müssen), alternativ reicht ein Quorum-Dienst.
Ich habe mich für den Dienst entschieden der bei mir auf einem separaten Server läuft. Geeignet ist jedes Linux-System auf dem man das Paket / den Dienst corosync-qnetd installieren kann.
Also auch ein Raspberry Pi. Es sollte nur unabhängig von den beiden Proxmox-Servern sein.
Ich habe hier ein Ubuntu-System das als VM auf einem anderem System läuft.
Als Überblick hier meine IP-Adressen:
proxmox03 192.168.0.231 proxmox04 192.168.0.232 quorum 192.168.0.233
Natürlich könnten wir hier auch die IP-Adressen des separaten Adressbereiches der 2. Netzwerkkarte nehmen, dann muss das Quorum aber auch eine Adresse aus diesem Bereich haben.
Auf dem separaten Quorum-System
Auf dem separaten System installieren wir den QNet-Daemon:
Debian / Ubuntu / Raspberry Pi:
apt install corosync-qnetd -y
CentOS etc.:
dnf --enablerepo=highavailability install corosync-qnetd
Im Anschluss testen wir ob der Dienst läuft:
systemctl status corosync-qnetd.service
Beispielausgabe:
Die Proxmox-Hosts müssen sich diese bei der Einrichtung mit dem Quorum-System per SSH verbinden können - also als root.
Variante 1: PublicKey per scp holen
Dazu wechseln wir zum Benutzer root und bearbeiten dessen authorized_keys Datei
sudo -i
und kopieren uns den Public Key von unseren beiden Proxmox-Hosts (IP-Adressen anpassen!):
ssh 192.168.0.231 "cat /root/.ssh/id_rsa.pub" >> /root/.ssh/authorized_keys ssh 192.168.0.232 "cat /root/.ssh/id_rsa.pub" >> /root/.ssh/authorized_keys
Die SSH-Key Warnung bestätigen und das Passwort des Proxmox-root eingeben! Wenn Ihr danach
cat /root/.ssh/authorized_keys
eingebt sollten da 2 Schlüssel drin sein von den beiden Proxmox-Hosts:
Variante 2: PublicKey von Hand kopieren Bearbeitet die Datei auf dem Quorum-System:
nano /root/.ssh/authorized_keys
Und fügt den Inhalt der Dateien
/root/.ssh/id_rsa.pub
von den beiden Proxmox-Hosts ein
Auf den Proxmox Hosts
Wir verbinden uns von beiden(!) Systemen 2 x per SSH mit dem Quorum-System. Das ist zum einen ein Verbindungstest, zum anderen wird der SSH-Key des Systems dabei hinterlegt:
ssh 192.168.0.233
und dann mit
exit
wieder abmelden.
Beispielausgabe:
wenn ihr euch dann ein 2. mal verbindet sollte die Verbindung ohne Nachfrage zustande kommen.
Jetzt Installieren wir auf den Proxmox-Hosts das QDevice:
apt install corosync-qdevice -y
Nachdem wir das auf beiden Proxmox-Hosts gemacht haben, sind wir bereit das Quorum-System einzubinden.
Vorher eine kleine Kontrolle:
pvecm status
Beispielausgabe:
ok, fügen wir von einen der beiden Proxmox-Host das Quorum-System hinzu:
pvecm qdevice setup 192.168.0.233
Beispielausgabe:
root@proxmox04:~# pvecm qdevice setup 192.168.0.233
/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/bin/ssh-copy-id: WARNING: All keys were skipped because they already exist on the remote system.
(if you think this is a mistake, you may want to use -f option)
INFO: initializing qnetd server
Certificate database (/etc/corosync/qnetd/nssdb) already exists. Delete it to initialize new db
INFO: copying CA cert and initializing on all nodes
node 'proxmox03': Creating /etc/corosync/qdevice/net/nssdb
password file contains no data
node 'proxmox03': Creating new key and cert db
node 'proxmox03': Creating new noise file /etc/corosync/qdevice/net/nssdb/noise.txt
node 'proxmox03': Importing CA
node 'proxmox04': Creating /etc/corosync/qdevice/net/nssdb
password file contains no data
node 'proxmox04': Creating new key and cert db
node 'proxmox04': Creating new noise file /etc/corosync/qdevice/net/nssdb/noise.txt
node 'proxmox04': Importing CA
INFO: generating cert request
Creating new certificate request
Generating key. This may take a few moments...
Certificate request stored in /etc/corosync/qdevice/net/nssdb/qdevice-net-node.crq
INFO: copying exported cert request to qnetd server
INFO: sign and export cluster cert
Signing cluster certificate
Certificate stored in /etc/corosync/qnetd/nssdb/cluster-ClusterA.crt
INFO: copy exported CRT
INFO: import certificate
Importing signed cluster certificate
Notice: Trust flag u is set automatically if the private key is present.
pk12util: PKCS12 EXPORT SUCCESSFUL
Certificate stored in /etc/corosync/qdevice/net/nssdb/qdevice-net-node.p12
INFO: copy and import pk12 cert to all nodes
node 'proxmox03': Importing cluster certificate and key
node 'proxmox03': pk12util: PKCS12 IMPORT SUCCESSFUL
node 'proxmox04': Importing cluster certificate and key
node 'proxmox04': pk12util: PKCS12 IMPORT SUCCESSFUL
INFO: add QDevice to cluster configuration
INFO: start and enable corosync qdevice daemon on node 'proxmox03'...
Synchronizing state of corosync-qdevice.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable corosync-qdevice
Created symlink /etc/systemd/system/multi-user.target.wants/corosync-qdevice.service -> /lib/systemd/system/corosync-qdevice.service.
INFO: start and enable corosync qdevice daemon on node 'proxmox04'...
Synchronizing state of corosync-qdevice.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable corosync-qdevice
Created symlink /etc/systemd/system/multi-user.target.wants/corosync-qdevice.service -> /lib/systemd/system/corosync-qdevice.service.
Reloading corosync.conf...
Done
root@proxmox04:~#Und wieder die Kontrolle:
pvecm status
Beispielausgabe:
Fertig!
Quellen: