Proxmox Multi-Cluster Auto-Update

Wer mehrere Proxmox-Cluster betreibt, kennt das Problem: Updates sollen automatisch laufen, aber nicht beide Cluster gleichzeitig durchgestartet werden – vor allem dann nicht, wenn HA (High Availability) aktiv ist und VMs zwischen Nodes migriert werden. Genau dafür habe ich mir ein Bash-Script gebaut, das die Cluster nacheinander abarbeitet.

Wie das Script arbeitet

Das Script denkt konsequent in Cluster-Gruppen:

• Nodes werden zwei Clustern zugeordnet (CLUSTER_A_NODES / CLUSTER_B_NODES).
• Der Cluster mit aktiver HA wird zuerst komplett aktualisiert, danach der zweite.
• Innerhalb eines Clusters wird der lokale Node zuerst gepatcht, dann jeder Remote-Node nacheinander.
• Gibt es keine Cluster-Gruppen in der Config, fällt das Script auf Single-Cluster-Betrieb mit Autoerkennung über pvecm zurück.

So wird immer erst ein Cluster sauber fertig aktualisiert, bevor der nächste angefasst wird – die HA-Ressourcen bleiben planbar.

Warum HA zuerst?

Wenn ein Cluster HA-Dienste betreibt, will man dort die Kontrolle behalten und den Vorgang abgeschlossen haben, bevor ein zweiter Cluster ins Spiel kommt. Das Script fragt dafür ha-manager status ab – entweder lokal oder über SSH auf dem ersten erreichbaren Node der Gruppe – und erkennt daran, ob aktive HA-Services vorhanden sind. Nur wenn genau ein Cluster HA hat, wird die Reihenfolge automatisch getauscht. Haben beide oder keiner HA, bleibt es bei Cluster-A zuerst.

Konfiguration

Die relevanten Variablen stehen oben im Script:

# Nodes je Cluster (leer lassen = Single-Cluster-Fallback)
CLUSTER_A_NODES="pve-a1.lab pve-a2.lab pve-a3.lab"
CLUSTER_B_NODES="pve-b1.lab pve-b2.lab"

CLUSTER_A_LABEL="Cluster-A"
CLUSTER_B_LABEL="Cluster-B"

MAIL_TO="root@localhost"     # eigene Adresse eintragen
SSH_PASSWORD=""              # optional, für automatisches Key-Setup

Der lokale Node muss nicht zwingend in der Liste stehen – er wird automatisch erkannt und, falls gelistet, innerhalb seines Clusters zuerst aktualisiert.

Die HA-Erkennung im Kern

Das Herzstück der Reihenfolge-Logik ist diese Funktion:

cluster_has_ha() {
    local list="$1"

    # Lokaler Shortcut: gehört dieser Node zum Cluster, lokal fragen
    if local_in_list "${list}"; then
        if command -v ha-manager &> /dev/null; then
            if ha-manager status 2>/dev/null | grep -qE "^service "; then
                return 0
            fi
        fi
        return 1
    fi

    # Sonst den ersten erreichbaren Remote-Node fragen
    for node in ${list}; do
        if ssh ${SSH_OPTS} -o BatchMode=yes "root@${node}" \
            "command -v ha-manager >/dev/null 2>&1 && ha-manager status 2>/dev/null | grep -qE '^service '" 2>/dev/null; then
            return 0
        fi
        if ssh ${SSH_OPTS} -o BatchMode=yes "root@${node}" "exit" 2>/dev/null; then
            return 1
        fi
    done
    return 1
}

Einrichtung per Cron

# Wöchentlich, sonntags um 3 Uhr
0 3 * * 0 /root/proxmox-auto-update.sh

Danach lässt sich der Ablauf im Log nachvollziehen:

tail -f /var/log/proxmox-cluster-auto-update.log

Fazit

Mit der Cluster-Gruppierung wird das Script zum Werkzeug für Multi-Cluster-Umgebungen. Ein Cluster wird immer erst komplett fertig, bevor der nächste startet – und der Cluster mit aktiver HA kommt zuerst dran. Wer nur einen Cluster hat, lässt die Variablen einfach leer und bekommt den klassischen Single-Cluster-Ablauf.