Nodes im Cluster teilen sich über Corosync eine gemeinsame Konfiguration im pmxfs.
Sie benötigen ein Quorum und reagieren empfindlich auf Netzwerklatenzen.
Deshalb läuft ein Cluster üblicherweise nur an einem räumlich begrenzten Standort.

Proxmox Remote Migration

• Migration von VM oder LXC von einem Host auf einen anderen über das Netzwerk
• kein Cluster erforderlich, verteilte Standorte und getrennte Systeme möglich
• Berechtigung über API-Token
• Anleitung: https://www.thomas-krenn.com/de/wiki/Proxmox_Remote_Migration?xtxsearchselecthit=1
  
  

Proxmox Datacenter Server (PDM v.1.1)

• Verwaltung von mehreren Proxmox VE oder PBS-Servern und Cluster
• Server müssen nicht im selben Cluster sein, lose Kopplung der autarken Cluster
• Migration von VMs zwischen Clustern über GUI (wenn die CPU-Typen der Hosts kompatibel sind)
• kein Loadbalancing oder DRS
• zentrales Ceph Monitoring
• clusterübergreifende VM-Verwaltung
• zentrale Snapshot-Verwaltung
• zentrales Update-Management
• Vertrauensstellung wird durch API mit Fingerprint hergestellt (PVE: Zertifikate -> pve-ssl.pem)
• zentrale Rolle erfordert strikte Security-Einstellungen (2FA, Management-VLAN..)

Cluster (ermöglicht Livemigration, Hochverfügbarkeit, gemeinsame Oberfläche)
-> Datacenter -> Cluster (Cluster erstellen, weitere Hosts beitreten)

• zentrales Management: Single web interface allows you to manage all servers in the cluster
• Voraussetzung: Nodes mit selber Version, Hosts mit gleichem CPU-Vendor erforderlich (kein Mischbetrieb AMD - Intel), neuer Host muss leer sein
• VM Live-Migration: move virtual machines between physical servers without interrupting their service (99ms).
• VM Replication: Replicate virtual machines for backup and disaster recovery purposes (nur ZFS).
• High Availability (HA): With features like shared storage or replication, you can automatically restart virtual machines on another node if one server fails.
  (1 Min. Umschaltzeit, ohne zentralen Storage wird die letzte Replication-Kopie genutzt)
• Cluster-wide Firewall
• ungerade Anzahl an Host erforderlich (Corosync Quorum), wichtig wenn man HA nutzt
  (Lösung: zusätzliches QDevice (auf Raspberry, Backup-Server...), oder höhere Votes für einen Host festlegen)
• IDs dürfen im Cluster nur einmal vorhanden sein -> hinzu gefügter Host sollte leer sein
• ZFS erforderlich (also kein RAID-Controller + LVM)
• NTP Zeit muß synchron sein
• LANs (empfohlen):
  - Corosync - PVE-Cluster
  - Ceph - Storage
  - vmbr0 - VMs
• Cluster synchronisiert /pve/ Konfigurationen
• fügt 2 oder mehr Proxmox-Hosts zu einer Oberfläche hinzu, auch ohne zentralen oder replizierten Storage (2 Instanzen bilden "Mehrheit")
• mit zentralem Storage können VM im laufenden Betrieb verschoben werden (HA, Failover)
• auch ohne zentralem Storage geht Livemigration im Cluster (entsprechend langsam), Server-Sync (Bsp. minütlich)
• dediziertes (schnelles!) Storage-Netz für ZFS Sync
• Achtung: VMs dürfen keine gleichen Namen (101) haben! Am Besten leeren Host hinzu fügen. Sync. Storage-Pools müssen gleichen Namen haben.
• Achtung: Cluster geht nur bei Hosts mit gleichem Service-Level! (Community oder Enterprise)
• https://pve.proxmox.com/wiki/Cluster_Manager
• CEPH (empfohlen) ist ein selbstheilender, sich selbst verwaltender, frei skalierbarer Speicher über mehrere Geräte hinweg (Open Source Software)
  - min. 3 Server
  - min. 4 Datenträger je Server
  - dediziertes Storage-LAN (min. 25 Gb/s bei NVMe)

Beide HA Speicheranbindungen funktionieren bei Proxmox immer mit einer Downtime beim Desaster Recovery.
Die Live Migration von VM ist möglich, selbst bei lokalem Storage.

• Datacenter mit 2 Nodes + lokalen Storages (mehr als 2 Nodes -> CEPH)
• lokales File- und Block-Storage
• bessere Performance gegenüber CEPH (Zugriff lokal)
• asynchrone Verteilung auf alle Storage
• für Datenbanken nicht geeignet, besser DB-Cluster oder CEPH
• ZFS Pool muß auf beiden Storages identisch heißen -> Storage wird repliziert
  rpool = lokales System
  vm-pool = für VMs
• VM erstellen, dann Replication einrichten (Bsp. alle 5 min)
  -> Container wird in definierter Zeit repliziert
  -> HA wird pro VM definiert
    More (rechts) -> Manage HA -> HA aktivieren
• HA wartet 2 min. (Zeit fest!) bei Serververlust
  -> dann startet VM auf 2. Host
  -> Downtime = 2 min. immer beim HA-Wechsel
• drittes Quorum erforderlich, Mehrheit hat gültigen Storage
  Quorum ist nur in Shell sichtbar (pvecm status)
• Datacenter: HA zeigt Status
• HA-Gruppen: Priorität des Hostes für VM definieren
• laufende VM können live zwischen den Hosts migriert werden
• laufende CT können nicht migriert werden

Installation:

• Management-Port fest auf IP legen
  - vmbr0 Config-Bridge löschen
• Corosync (Cluster-Netzwerk) direkt auf ein Interface legen
  2. Netzwerkkarte sinnvoll (ggf. GUI-Netz)
• falls möglich Ports bündeln
  - Linux Bond, Mode= LACP oder Balance
• Bond für Storage ohne Switch (performanter)
• VM-LAN: Linux Bridge vmbr0 -> Port oder Bond zuweisen
  (VLAN aware, keine IP)
• PVE1: Join Info kopieren
• PVE2: Join Cluster
  - Netzwerke wählen
• PVE3 für Quorum
  - Quorum auf Debian Mini-PC  (apt install corosync-qdevice /em)
  - physischer PBS-Server gut als Quorum geeignet

• verteilte open source Storage Lösung (File, Block, Object-Storage)
• bessere Redundanz und Datensicherheit gegenüber ZFS
• CEPH Netzwerk Latenz darf 9ms nicht überschreiten! (10..25 Gb/s)
  -> CEPH geht nicht über mehrere Standorte
  -> CEPH hat vergleichsweise hohe Latenz
• synchrone Verteilung auf alle Storage
• selbstheilend
• gutes Dashboard im PVE
• Update-Installation wie PVE Updates
• läuft auf Standard-Hardware, keine Hersteller-Liste
• Subscription- (mit PVE Subscription) oder NoSubscription Updates
• HDs zufügen / verschiedene HD-Größen / Hosts zufügen
• RADOS Block Device für PVE VMs
• PVE Client verhandelt mit CEPH und speichert auf einen Datenträger
  CEPH synchronisiert Daten selbständig auf (min. 2) weitere Kopien
• CEPH wird über PVE pro Host installiert
• eigenes, performantes Netzwerk verwenden! (25 Gb/s) - (Public Network + Cluster Network gemeinsam)
  -> Full Meshed Network for 3x CEPH (=keine Switche, spart ca. 35.000,-)
• CEPH Monitor für Host2 + Host3 nachinstallieren, Host1 wird automatisch installiert
• CEPH Manager für Host2 oder 3 installieren, 2x Manager genügt
• CEPH OSD = Datenträger, nur NVMe/ SSD, alle Datenträger pro Host hinzu fügen  (OSD zu phys. HD dokumentieren)
• CEPH Pools anlegen, Size=3 (Anzahl der Replikate), Min.Size=2 (sonst geht CEPH down)
• CEPH / DephFS: 3x Metadaten Server pro Host erstellen
• VM: Storage Move-to: CEPH-Pool
• CEPH / OSD: Global Flags (noaut usw.) setzen für Wartung

Grundvoraussetzungen:

• min. 3 Ceph-Server
  3x CEPH (immer ungerade Anzahl) Monitor für Quorum, Client-Management
  CEPH Manager (Monitoring-Daten, Schnittstelle für ext. Monitoring)
• min. 4x OSD (Datenträger) pro Cluster, gleiche Anzahl pro Host empfohlen
• ausschließlich Einsatz von Flash statt HDs
• Implementierung eines Monitoringsystems für Disk- und Poolauslastung

• UK: Proxmox PVE Virtualisierer
• UK: Proxmox Befehle und Tips