Wiki source for ProxmoxCephCluster
===== Proxmox-Cluster mit Ceph =====
== eine integrierte Lösung für Rechenzentrum ohne //single Point of failure// ==
((1)) Ziel
Ziel der Lösung ist
- Cluster
- Proxmox mit - am Ende - //high availability// für virtuelle Maschinen und Container
- also es gibt keinen //single point of failure//
- es werden nicht nur die VM und LXC beliebig verschiebbar, sondern auch weitere Komponenten per Software abgebildet:
- das Netzwerk (SDN und damit Verschiebbarkeit eines Routers oder von Maschinen mit Verbindungen in das LAN, die DMZ oder sonstige verbundene Netzwerke)
- Storage, also Speicherplatz für alle Maschinen und Daten, der sich von den Node´s unabhängig macht, was mit Ceph möglich ist
- die gesamte Lösung wird nicht nur einmal für das gesamte Rechenzentrum umgesetzt, sondern für zwei, o dass mit einer einfachen Replikation unter Ceph praktisch die Rechenzentren als Duplikate füreinander dienen können - und bei Ausfall eines Clusters praktisch verzögerungsfreie Umschaltung auf den zweiten Cluster möglich ist
((1)) Prozedur kurz zusammengefasst:
Folgende Schritte werden hier zusammengefasst:
- Auswahl, Dimensionierung und hardwareseitige Konzeption des Clusters
- Installation Proxmox auf jedem Node
((1)) Auswahl / Konzeption Hardware
Folgendes beachten:
- da Ceph allein schon Rechenleistung nimmt, sind leistungsfähige Nodes über kurz oder lang unersetzlich; bei 6 OSD braucht man schon 8 Kerne - also kleine Geräte mit 8 Kernen müssen sich noch im Betrieb bewähren und werden sicher nie allzu viele Maschinen beherbergen können;
- Netzwerke müssen schnell und redundant sein; ich will es versuchen mit 2x 10 Gb und 4x 1 Gb je Node das Netzwerk (per SDN) umzusetzen;
((1)) Installation Proxmox auf den Nodes
Die Installation ist zunächst normal - einige Klippen sollte man aber beachten:
- bei [[https://www.erdaxo.de/ProxMox#section_11 | Installationsproblemen mit alter Grafik]] hilft die verlinkte Information
((1)) Netzwerk-Config
((2)) Sinnvolle Operationen
Das Netzwerk ist in einem Cluster mit sehr vielen Netzwerkgeräten verbunden - Switche, Netzwerkkarten, Verkabelung... Vor diesem Hintergrund ist es nützlich, einige Funktionen im Linux Netzwerk Stack zu beherrschen. Die [[ Doku dazu ist hier zu finden]].
((2)) Aufteilung des Netzwerkverkehrs bei einem Ceph-Cluster
Ein Cluster hängt maßgeblich vom Netzwerk ab. Wir brauchen bei CEPH - gem. Doku von Proxmox - im Zweifel folgende, parallele Netzwerke in der Konfiguration:
- sehr schnelles Netzwerk (25+ Gbps) => //Ceph INTERNAL//
- schnelles Netzwerk (10+ Gpbs) => //Ceph PUBLIC//
- mit //Ceph PUBLIC// kann auch verbunden werden //virtual guest traffic// und //VM live-migration traffic//
=> aber mit alternativer Lösung auch getrennt sinnvoll?
- normales Netzwerk (1 Gbps) **exklusiv** für //corosync// (Kommunikation im Cluster);
((3)) Ceph INTERNAL
((3)) Ceph PUBLIC
((3)) virtual guest traffic
((3)) VM live-migration traffic
((3)) corosync traffic
Neben **exklusiv** und **niedrige Latenz** ist hier die Besonderheit, dass dieses über mehrere Netzwerke laufen kann! Also kann es so funktionieren:
- Netzwerk corosync 1 = 10.10.1.0/24 über einen separaten Switch (keinerlei Verbindung mit anderen Netzwerken); immer über ersten NIC der __gesteckten__ Netzwerkkarte
- Netzwerk corosync 2 = 10.10.2.0/24 über den normalen Switch für ganzes Netzwerk auf anderem VLAN (?) als Management aber auf der Netzwerkkarte mit Management (Karte __onboard__)
((2)) Konfiguration des SDN
Software Defined Network ist in Proxmox ab V.8.1 standardmäßig aktiv. Es müsste die Konfiguration der Netzwerke wohl erleichtern. Hier werden die essenziellen Informationen gesammelt.
((3)) Struktur
Kurz in etwa so zu verstehen:
""zone <==== vnet <==== subnet""
- Zone = Bestimmung der Möglichkeiten / Techniken für Netzwerke. Getrennter Bereich für Netzwerke
- VNet = virtuelles Netzwerk in einer //zone//
- Subnet = IP range, also wie immer
Sobald ein //VNet// definiert wurde (unter "datacenter" => "SDN"), dann ist es in jedem //node// lokal sichtbar - als eine normale //Linux bridge// und jede VM oder jeder Container kann an diese angebunden werden.
((2)) Schritt für Schritt
Folgende Schritte waren notwendig:
((3)) Netzwerkvorbereitung für cluster
Plan: corosync auf zwei NICs zu verteilen:
(1) NIC 1 onboard
Da hier auch schon Management und Internet für die //nodes// läuft, sollte diese Schnittstelle über VLAN laufen. Also:
- VLAN auf ##eno1## als ##eno1.11## erstellen (ohne IP oder Gateway)
- auf dem VLAN ##eno1.11## die Bridge ##vmbr1## einrichten
- ##vmbr1## bekommt IP ##10.99.1.node##
(2) NIC 1 auf PCIe Netzwerkkarte
Hier wird nur eine normale Bridge erstellt - direkt auf dem NIC:
- auf ##ens1## wird ##vmbr2## erstellt
- sie bekommt IP ##10.99.2.node##
((3)) VLAN Problem auf dem Switch
Zyxel XGS1930 leitete Pakete vom oben genannten VLAN (##vmbr1##) nicht weiter. Lange suche, inkl. switch-reset brachte eine simple Lösung (da war KI zumindest mittelbar hilfreich) - siehe im Zyxel WebUI:
- Advanced Application => VLAN => VLAN Configuration => VLAN Port Setup
- für die Ports, an die die ##eno1## angeschlossen ist, bei **VLAN Trunking** Haken setzen!
Damit ging es schon, zwischen den Nodes über ##vmbr1## zu kommunizieren. Sollte auch noch VLAN 11 im Switch korrekt konfiguriert werden, dann ist wichtig, dass die Ports, die TX Tagging bekommen (TAG 11, Ports an die ##eno1## angeschlossen ist, bekommen dort Haken gesetzt) nicht auf ##Forbidden## oder ##Normal## stehen, sondern auf ##Fixed##
((3)) tbc
((1)) Zeitsynchronisation
Es müssen effiziente und gut funktionierende Zeitserver eingestellt werden, sonst ist die Zeit im Cluster nicht synchron und dies führt zu gravierenden Problemen.
((2)) Welche Zeitserver nehmen?
Lokale! Ganz simpel - sonst sind sie zu langsam!
Eine Möglichkeit ist ein leistungsfähiger Router mit Zeitserver (bei uns: OPNsense) - aber Vorsicht bei dessen Virtualisierung - da wir das vorhaben, muss dann wohl ein dedizierter, sparsamer Zeitserver her (Raspi?)
((2)) Einrichtung des ##chronyd##
Einfach die Datei ##/etc/chrony/chrony.conf## bearbeiten und die Server wie folgt eintragen:
%%(bash)
server 10.1.0.1 iburst prefer
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst
server 3.pool.ntp.org iburst
# Use Debian vendor zone. => auskommentieren!
# pool 2.debian.pool.ntp.org iburst%%
((1)) Ceph selbst
((2)) Bestandteile
Ein Ceph-System setzt sich zusammen aus verschiedenen Diensten (//daemons//):
- Ceph Monitor (ceph-mon, or MON)
- Ceph Manager (ceph-mgr, or MGS)
- Ceph Metadata Service (ceph-mds, or MDS)
- Ceph Object Storage Daemon (ceph-osd, or OSD)
((2)) Einrichtung
Die Einrichtung nach Vorbereitung der passenden Netzwerke ist sehr simpel - hier die etwas komplexeren Fragen, nachdem die einfachen Schritte erledigt sind:
((3)) CRUSH & device classes
Sinnvoll ist vor allem die Trennung verschiedener Arten von Datenträgern - in unserem System wollen wir VM-Datenträger von Anwendungsdaten in der Weise behandeln, dass wir:
- SATA-SSD-s für Daten nutzen ("mittel-schnell")
- NVME-SSD-s für Betriebssysteme ("sehr schnell")
nutzen. Dafür brauchen wir verschiedene Befehle:
%%(bash)
# die Klassen erst mal nur anzeigen:
ceph osd crush tree --show-shadow
# crush rule für die Klasse definieren:
ceph osd crush rule create-replicated <rule-name> <root> <failure-domain> <class>
%%
((3)) Weiterführende Quellen
Auf jeden Fall sinnvoll: https://forum.proxmox.com/threads/ceph-classes-rules-and-pools.60013/
== eine integrierte Lösung für Rechenzentrum ohne //single Point of failure// ==
((1)) Ziel
Ziel der Lösung ist
- Cluster
- Proxmox mit - am Ende - //high availability// für virtuelle Maschinen und Container
- also es gibt keinen //single point of failure//
- es werden nicht nur die VM und LXC beliebig verschiebbar, sondern auch weitere Komponenten per Software abgebildet:
- das Netzwerk (SDN und damit Verschiebbarkeit eines Routers oder von Maschinen mit Verbindungen in das LAN, die DMZ oder sonstige verbundene Netzwerke)
- Storage, also Speicherplatz für alle Maschinen und Daten, der sich von den Node´s unabhängig macht, was mit Ceph möglich ist
- die gesamte Lösung wird nicht nur einmal für das gesamte Rechenzentrum umgesetzt, sondern für zwei, o dass mit einer einfachen Replikation unter Ceph praktisch die Rechenzentren als Duplikate füreinander dienen können - und bei Ausfall eines Clusters praktisch verzögerungsfreie Umschaltung auf den zweiten Cluster möglich ist
((1)) Prozedur kurz zusammengefasst:
Folgende Schritte werden hier zusammengefasst:
- Auswahl, Dimensionierung und hardwareseitige Konzeption des Clusters
- Installation Proxmox auf jedem Node
((1)) Auswahl / Konzeption Hardware
Folgendes beachten:
- da Ceph allein schon Rechenleistung nimmt, sind leistungsfähige Nodes über kurz oder lang unersetzlich; bei 6 OSD braucht man schon 8 Kerne - also kleine Geräte mit 8 Kernen müssen sich noch im Betrieb bewähren und werden sicher nie allzu viele Maschinen beherbergen können;
- Netzwerke müssen schnell und redundant sein; ich will es versuchen mit 2x 10 Gb und 4x 1 Gb je Node das Netzwerk (per SDN) umzusetzen;
((1)) Installation Proxmox auf den Nodes
Die Installation ist zunächst normal - einige Klippen sollte man aber beachten:
- bei [[https://www.erdaxo.de/ProxMox#section_11 | Installationsproblemen mit alter Grafik]] hilft die verlinkte Information
((1)) Netzwerk-Config
((2)) Sinnvolle Operationen
Das Netzwerk ist in einem Cluster mit sehr vielen Netzwerkgeräten verbunden - Switche, Netzwerkkarten, Verkabelung... Vor diesem Hintergrund ist es nützlich, einige Funktionen im Linux Netzwerk Stack zu beherrschen. Die [[ Doku dazu ist hier zu finden]].
((2)) Aufteilung des Netzwerkverkehrs bei einem Ceph-Cluster
Ein Cluster hängt maßgeblich vom Netzwerk ab. Wir brauchen bei CEPH - gem. Doku von Proxmox - im Zweifel folgende, parallele Netzwerke in der Konfiguration:
- sehr schnelles Netzwerk (25+ Gbps) => //Ceph INTERNAL//
- schnelles Netzwerk (10+ Gpbs) => //Ceph PUBLIC//
- mit //Ceph PUBLIC// kann auch verbunden werden //virtual guest traffic// und //VM live-migration traffic//
=> aber mit alternativer Lösung auch getrennt sinnvoll?
- normales Netzwerk (1 Gbps) **exklusiv** für //corosync// (Kommunikation im Cluster);
((3)) Ceph INTERNAL
((3)) Ceph PUBLIC
((3)) virtual guest traffic
((3)) VM live-migration traffic
((3)) corosync traffic
Neben **exklusiv** und **niedrige Latenz** ist hier die Besonderheit, dass dieses über mehrere Netzwerke laufen kann! Also kann es so funktionieren:
- Netzwerk corosync 1 = 10.10.1.0/24 über einen separaten Switch (keinerlei Verbindung mit anderen Netzwerken); immer über ersten NIC der __gesteckten__ Netzwerkkarte
- Netzwerk corosync 2 = 10.10.2.0/24 über den normalen Switch für ganzes Netzwerk auf anderem VLAN (?) als Management aber auf der Netzwerkkarte mit Management (Karte __onboard__)
((2)) Konfiguration des SDN
Software Defined Network ist in Proxmox ab V.8.1 standardmäßig aktiv. Es müsste die Konfiguration der Netzwerke wohl erleichtern. Hier werden die essenziellen Informationen gesammelt.
((3)) Struktur
Kurz in etwa so zu verstehen:
""zone <==== vnet <==== subnet""
- Zone = Bestimmung der Möglichkeiten / Techniken für Netzwerke. Getrennter Bereich für Netzwerke
- VNet = virtuelles Netzwerk in einer //zone//
- Subnet = IP range, also wie immer
Sobald ein //VNet// definiert wurde (unter "datacenter" => "SDN"), dann ist es in jedem //node// lokal sichtbar - als eine normale //Linux bridge// und jede VM oder jeder Container kann an diese angebunden werden.
((2)) Schritt für Schritt
Folgende Schritte waren notwendig:
((3)) Netzwerkvorbereitung für cluster
Plan: corosync auf zwei NICs zu verteilen:
(1) NIC 1 onboard
Da hier auch schon Management und Internet für die //nodes// läuft, sollte diese Schnittstelle über VLAN laufen. Also:
- VLAN auf ##eno1## als ##eno1.11## erstellen (ohne IP oder Gateway)
- auf dem VLAN ##eno1.11## die Bridge ##vmbr1## einrichten
- ##vmbr1## bekommt IP ##10.99.1.node##
(2) NIC 1 auf PCIe Netzwerkkarte
Hier wird nur eine normale Bridge erstellt - direkt auf dem NIC:
- auf ##ens1## wird ##vmbr2## erstellt
- sie bekommt IP ##10.99.2.node##
((3)) VLAN Problem auf dem Switch
Zyxel XGS1930 leitete Pakete vom oben genannten VLAN (##vmbr1##) nicht weiter. Lange suche, inkl. switch-reset brachte eine simple Lösung (da war KI zumindest mittelbar hilfreich) - siehe im Zyxel WebUI:
- Advanced Application => VLAN => VLAN Configuration => VLAN Port Setup
- für die Ports, an die die ##eno1## angeschlossen ist, bei **VLAN Trunking** Haken setzen!
Damit ging es schon, zwischen den Nodes über ##vmbr1## zu kommunizieren. Sollte auch noch VLAN 11 im Switch korrekt konfiguriert werden, dann ist wichtig, dass die Ports, die TX Tagging bekommen (TAG 11, Ports an die ##eno1## angeschlossen ist, bekommen dort Haken gesetzt) nicht auf ##Forbidden## oder ##Normal## stehen, sondern auf ##Fixed##
((3)) tbc
((1)) Zeitsynchronisation
Es müssen effiziente und gut funktionierende Zeitserver eingestellt werden, sonst ist die Zeit im Cluster nicht synchron und dies führt zu gravierenden Problemen.
((2)) Welche Zeitserver nehmen?
Lokale! Ganz simpel - sonst sind sie zu langsam!
Eine Möglichkeit ist ein leistungsfähiger Router mit Zeitserver (bei uns: OPNsense) - aber Vorsicht bei dessen Virtualisierung - da wir das vorhaben, muss dann wohl ein dedizierter, sparsamer Zeitserver her (Raspi?)
((2)) Einrichtung des ##chronyd##
Einfach die Datei ##/etc/chrony/chrony.conf## bearbeiten und die Server wie folgt eintragen:
%%(bash)
server 10.1.0.1 iburst prefer
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst
server 3.pool.ntp.org iburst
# Use Debian vendor zone. => auskommentieren!
# pool 2.debian.pool.ntp.org iburst%%
((1)) Ceph selbst
((2)) Bestandteile
Ein Ceph-System setzt sich zusammen aus verschiedenen Diensten (//daemons//):
- Ceph Monitor (ceph-mon, or MON)
- Ceph Manager (ceph-mgr, or MGS)
- Ceph Metadata Service (ceph-mds, or MDS)
- Ceph Object Storage Daemon (ceph-osd, or OSD)
((2)) Einrichtung
Die Einrichtung nach Vorbereitung der passenden Netzwerke ist sehr simpel - hier die etwas komplexeren Fragen, nachdem die einfachen Schritte erledigt sind:
((3)) CRUSH & device classes
Sinnvoll ist vor allem die Trennung verschiedener Arten von Datenträgern - in unserem System wollen wir VM-Datenträger von Anwendungsdaten in der Weise behandeln, dass wir:
- SATA-SSD-s für Daten nutzen ("mittel-schnell")
- NVME-SSD-s für Betriebssysteme ("sehr schnell")
nutzen. Dafür brauchen wir verschiedene Befehle:
%%(bash)
# die Klassen erst mal nur anzeigen:
ceph osd crush tree --show-shadow
# crush rule für die Klasse definieren:
ceph osd crush rule create-replicated <rule-name> <root> <failure-domain> <class>
%%
((3)) Weiterführende Quellen
Auf jeden Fall sinnvoll: https://forum.proxmox.com/threads/ceph-classes-rules-and-pools.60013/
