Proxmox-Cluster mit Ceph

eine integrierte Lösung für Rechenzentrum ohne single Point of failure

A. 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

B. Prozedur kurz zusammengefasst:
Folgende Schritte werden hier zusammengefasst:

• Auswahl, Dimensionierung und hardwareseitige Konzeption des Clusters

• Installation Proxmox auf jedem Node

C. 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;

D. Installation Proxmox auf den Nodes
Die Installation ist zunächst normal - einige Klippen sollte man aber beachten:

• bei Installationsproblemen mit alter Grafik hilft die verlinkte Information

E. Netzwerk-Config

• 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

• normales Netzwerk (1 Gbps) exklusiv für corosync (Kommunikation im Cluster);

• 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)

• 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

• 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

• auf ens1 wird vmbr2 erstellt

• sie bekommt IP 10.99.2.node

• Advanced Application => VLAN => VLAN Configuration => VLAN Port Setup

• für die Ports, an die die eno1 angeschlossen ist, bei VLAN Trunking Haken setzen!

F. 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.


G. Ceph selbst

• 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)

• SATA-SSD-s für Daten nutzen ("mittel-schnell")

• NVME-SSD-s für Betriebssysteme ("sehr schnell")