# Proxmox HA Orchestrierung: Ressourcen, Gruppen & intelligente Priorität

TL;DR / Management Summary Ein einfacher Failover ist gut, ein orchestrierter Failover ist besser. Mit HA Groups steuern wir exakt, welche VMs auf welchen Knoten schwenken dürfen. Durch den Einsatz von Prioritäten stellen wir sicher, dass bei einem Host-Ausfall der Domain Controller vor dem Datenbank-Server startet. Ein Senior Admin nutzt diese Werkzeuge, um Ressourcen-Engpässe zu vermeiden und die Abhängigkeiten der Applikations-Stacks (Artikel 641) im Cluster abzubilden.

# 1. HA Ressourcen verstehen

Was wird überwacht?

Eine HA-Ressource in Proxmox kann sein:

• Eine virtuelle Maschine (VM).
• Ein Linux Container (LXC).
• Wirkung: Der HA-Manager (Artikel 676) sorgt dafür, dass die Ressource immer den Status Started hat (es sei denn, sie wurde manuell gestoppt).

# 2. HA Gruppen: Die Schwenk-Domains

Den Aktionsradius begrenzen.

Standardmäßig schwenkt eine VM auf jeden freien Knoten im Cluster.

• Problem: Eine VM mit 128 GB RAM schwenkt auf einen Ersatz-Knoten mit nur 64 GB RAM -> Crash.
• Lösung: Erstellen Sie Gruppen (Datacenter -> HA -> Groups).
  • Restricted: Die VM darf nur auf Knoten dieser Gruppe laufen.
  • Nodes: Liste der erlaubten Hosts (z.B. pve01, pve02).

# 3. Deep Dive: Prioritäten & Startreihenfolge

Wer darf zuerst?

In den Einstellungen einer HA-Ressource können Sie eine Priority (0-1000) vergeben.

• Logik: Der HA-Manager startet Ressourcen mit höherer Priorität zuerst.
• Empfehlung:
  • Priorität 1000: Core Dienste (DNS, DHCP, DC).
  • Priorität 500: Datenbanken (SQL, Redis).
  • Priorität 100: Web-Applikationen.
  • Priorität 0: Unkritische Dienste.

# 4. Day-2 Operations: ‘No-Failback’ Strategien

Unnötiges Wandern vermeiden.

Standardmäßig schwenkt eine VM sofort wieder auf ihren “Lieblings-Host” zurück, sobald dieser wieder online ist (Failback).

• Aktion: Setzen Sie in der HA-Gruppe den Haken bei No Failback.
• Warum?: Dies verhindert einen zweiten Reboot der VM kurz nach dem ersten Failover. Der Admin entscheidet dann manuell, wann die VM im Wartungsfenster wieder zurückwandern darf.

# 5. Troubleshooting & “War Stories”

Wenn die Logik gegen die Realität verliert.

# Top 3 Fehlerbilder

1. Symptom: VM startet nicht am Ersatz-Knoten trotz hoher Priorität.

   • Ursache: Der Host ist in der HA-Gruppe als Maintenance markiert oder hat einen fehlerhaften Storage-Mount.
   • Lösung: ha-manager status prüfen.

2. Symptom: Zwei VMs starten gleichzeitig und überlasten die Disk (Boot-Sturm).

   • Fix: Nutzen Sie die Start-Verzögerung (Startup Delay) in den VM-Optionen zusätzlich zur HA-Priorität.

3. Symptom: VM wandert im 5-Minuten Takt zwischen Hosts hin und her.

   • Ursache: Flapping-Gateway oder ungleiche Load-Werte in der Gruppe.

# “War Story”: Der “Blindstart” des SQL-Servers

Ein Admin setzte den SQL-Server auf Priorität 1000, den Domain Controller auf 0. Das Ereignis: Stromausfall. Der Cluster startete neu. Das Ergebnis: Der SQL-Server startete zuerst. Da der Domain Controller noch nicht online war, konnte der SQL-Dienst den Service-Account nicht validieren und verweigerte den Start. Der Admin musste morgens alle SQL-Dienste manuell neustarten. Lehre: Prioritäten spiegeln die logische Abhängigkeit wider. Die Infrastruktur (Authentifizierung) muss immer vor der Applikation kommen.

# 6. Monitoring & Reporting

Dashboard-Status.

# HA Group View

Prüfen Sie im Datacenter-Dashboard:

• Ressourcen-Verteilung: Sind die VMs gleichmäßig über die Gruppen verteilt?
• Failover Events: Werden in den Cluster-Tasks geloggt. Suchen Sie nach ha-manager Events.

# 7. Fazit & Empfehlung

Intelligentes Ressourcen-Management macht den Unterschied zwischen einem “Haufen VMs” und einem “professionellen Service”.

• Empfehlung: Nutzen Sie Restricted HA Groups für schwere Datenbanken, um sicherzustellen, dass sie immer auf Hardware mit ausreichendem RAM landen.
• Wichtig: Dokumentieren Sie die Start-Prioritäten in Ihrem DR-Plan, damit bei einem manuellen Neustart die Reihenfolge gewahrt bleibt.

# Anhang: Cheatsheet (Priority Schema)

# Referenzen

• Proxmox VE: HA Group Settings
• Veeam: Best Practices for VM Recovery Order
• Linux Academy: Managing Proxmox HA Resources