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

• Verwaltung von mehreren Proxmox VE oder PBS-Servern
• Server müssen nicht im selben Cluster sein
• Vertrauensstellung wird durch Fingerprint hergestellt (PVE: Zertifikate -> pve-ssl.pem)

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
• Nodes mit selber Version, Hosts mit gleichem CPU-Vendor erforderlich (kein Mischbetrieb AMD - Intel)
• 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.
• 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