Proxmox auf Hetzner installieren & betreiben

Ja - für viele KMU-Setups ist ein sauber betriebener Single Node absolut sinnvoll. Entscheidend sind Backup-Konzept, Restore-Tests, Monitoring und ein Update-Prozess (statt 'HA um jeden Preis').

Single Node löst Ausfälle über Backup/Restore (Disaster Recovery). Ein HA-Cluster bietet Failover und Wartung ohne Downtime, setzt aber saubere Netz-/Storage-Architektur voraus.

Für echtes Quorum-basiertes HA ist ein 3-Node-Design der Standard. 2-Node-Setups sind möglich, brauchen aber eine zusätzliche Quorum-Komponente/Design-Entscheidung (sonst Split-Brain-Risiko).

Für Dev/Test und kleinere Setups kann das passen. Für stabile Performance, lokale NVMe und kalkulierbare Latenzen ist Dedicated oft die bessere Basis.

Orientiert euch an einer stabilen Proxmox-Release, die zur Debian-Basis passt; die Proxmox ISO bringt ein vollständiges Debian-System inkl. Proxmox-Paketen mit.

Gängige Wege sind: Debian via Rescue installieren und anschließend Proxmox einrichten - oder die Proxmox ISO aus dem Rescue System per QEMU/VNC booten. Hetzner dokumentiert beide Methoden.

Ja - z.B. über Rescue + QEMU/VNC oder automatisiert per Script. Das Repo ariadata/proxmox-hetzner zielt genau auf 'ohne Console Access' ab.

Hostname und IP sollten vor Cluster-Erstellung final sein; spätere Änderungen sind im Cluster-Kontext sehr unangenehm bzw. nicht vorgesehen.

Proxmox nutzt den Linux-Netzwerkstack; Konfiguration ist per GUI möglich oder über /etc/network/interfaces. Für Gäste braucht ihr typischerweise Linux Bridges (vmbrX).

Die Web-GUI ist standardmäßig über https://<IP>:8006 erreichbar. Für Remote-Admin plant außerdem SSH (22) ein und steuert Zugriff idealerweise über Allowlist/VPN.

Nicht einfach ins Internet stellen: IP-Allowlist, VPN/Jump Host, ggf. Proxmox Firewall bzw. Upstream-Firewall. Proxmox weist darauf hin, dass ihr für Remote-Admin Regeln für GUI (8006) und oft SSH (22) braucht.

Mit Subscription ist das Enterprise Repository der empfohlene, stabile Pfad. Ohne Subscription nutzt ihr öffentliche Repos; wichtig ist, dass Repos sauber gesetzt sind, damit Updates funktionieren.

Ja: Ein Single Node auf Dedicated (NVMe), saubere Netz-Basics, sofort PBS/Backup-Ziel, Monitoring + dokumentierter Update-Prozess. Damit habt ihr ein 'Minimum viable Setup', das später zum Cluster wachsen kann.

Private Networks sind Layer-3 private Links zwischen Cloud Servern über separate Interfaces - ideal für internen Traffic wie Cluster-Kommunikation oder private Services.

Laut Hetzner Docs ist das Networks-Feature kostenlos und der Traffic auf den privaten Interfaces wird nicht berechnet.

Nein - der Traffic ist privat/isoliert, aber nicht automatisch verschlüsselt. Für sensible Daten: TLS oder VPN/WireGuard einplanen.

Hetzner beschreibt Networks als L3-Feature mit IPv4-Adressierung (und weist auf Einschränkungen hin). Plant IPv6 separat über andere Mechanismen.

Bei Standard-Images wird die private Netz-Schnittstelle automatisch via DHCP konfiguriert (hc-utils).

Ja - Hetzner beschreibt die Kopplung eines Robot vSwitch mit einem Cloud Network (Subnet mit 'vSwitch connection').

Ein vSwitch ist (je nach Einsatz) die Grundlage für private L2-Konnektivität und/oder die Kopplung zwischen Dedicated und Cloud-Networks. Für Proxmox ist das relevant, um Cluster-/Storage-Traffic privat und kontrolliert zu halten.

Corosync ist latency-sensitiv; anderer Traffic kann Jitter erzeugen und Cluster-Stabilität beeinträchtigen. Best practice ist ein separates Corosync-Netz; Storage-Traffic sollte nicht auf demselben Netz laufen.

Auf Hetzner müsst ihr IP/MAC-Binding ernst nehmen; in manchen Szenarien ist nur routed sauber möglich. Bei Bridged-Setups braucht ihr ggf. virtuelle MACs - sonst drohen Probleme bis hin zu Abuse/Block.

Wir prüfen Cluster-Status, Corosync-Bindings und ob der Traffic wirklich über das geplante private Netz läuft (nicht über Public IP). Zusätzlich validieren wir Failover/Quorum unter Last.

Corosync auf einem überlasteten Netz (Storage/Backup/Migration), MTU-Mismatch, aus Versehen Public-Traffic für Cluster, oder Hetzner-spezifische MAC/IP-Fehlkonfiguration.

Für Single Node ist ZFS oft der sweet spot: schnell, stabil, einfach. Für HA-Cluster ist Ceph interessant, weil es verteilten Storage liefert - braucht aber mehr Planung (Netz, Disks, Sizing).

Als Faustregel: plant 2-3× euren aktuellen VM-Datenbedarf plus Backup-Puffer und Wachstum. Bei Ceph kommt Replikation dazu (mehr Rohkapazität nötig).

Ja - typischerweise als 'Einrichtung', 'Co-Managed' oder 'Fully Managed': Updates, Monitoring, Backup-Kontrolle, Troubleshooting und Erweiterungen (z.B. Cluster Growth, Storage, Netzwerk-Härtung).