2026 OpenClaw Cluster-Praxis
Canary-Verkehr, Skill-Pack-Slices & gemergte Probes

Dieses HowTo ergänzt — wiederholt aber nicht — die notifier-zentrierte Geschichte in OpenClaw Multi-AZ-Gateways, Probes, Webhooks & Token-Rotation. Dort ist die Steuerungsebene Digest-Broadcast und Token-Überlappung. Hier sind es Verkehrsanteile, unveränderliche Skill-Slices und Promotion-Gates, die Sie auf drei clustervps-Hosts proben können, ohne zu raten, welcher Mac maßgeblich ist.

OpenClaw-Mehrknoten-Release (bevor Sie Verkehrsanteile schieben)

Veröffentlichen Sie als Vertrag über alle Gateways hinweg, nicht als einen einzelnen git-pull-Heldenmoment. Jeder beteiligte Mac muss vier Artefakte teilen: die openclaw.lock-Zeile mit Daemon- und CLI-Hashes, das Mandanten-Fragment-Set aus Mandanten-Fragmente, Doctor-Merge & Webhook-Fehler-Digests, das Skill-Pack-Verzeichnis passend zur Lockfile-Semver und die unten beschriebene zusammengesetzte Readiness-Route. Promotions-Reihenfolge: Shadow auf Canary-Host → Doctor plus gemergte Probe grün → LB-Gewicht schieben → Peer spiegeln → Audit anhängen. Wer Shadow überspringt, riskiert zwei verschiedene Skill-Bäume bei weiterhin „healthy“ Load Balancer.

• Autoritative Quelle: Git-Tag pro Promotion; launchd-Reload verweigern, wenn der Working Tree dirty ist.
• Parallele Gateways: Ein Writer-Mac setzt den Tag; Canary-Gateway zieht zuerst; stabile Gateways erst nach bestandenen Ratio-Gates.
• Worker und Notifier: Dürfen Gateways um eine Revision hinterherhinken, niemals voraus — sonst lügen gemergte Probes über Skill-Kompatibilität.

#!/usr/bin/env bash
set -euo pipefail
cd /usr/local/share/openclaw-infra
/usr/bin/git fetch --tags origin
/usr/bin/git checkout "refs/tags/${PROMOTE_TAG}"
/usr/bin/shasum -a 256 openclaw.lock | /usr/bin/tee /tmp/lock.sha
/usr/local/bin/openclaw version --json | /usr/bin/tee /tmp/version.json
/usr/bin/diff -q openclaw.lock <(ssh canary-gw "cat /usr/local/share/openclaw-infra/openclaw.lock")

Ist der Diff leer, dürfen Sie Load-Balancer-Gewichte anfassen. Ist er nicht leer: Stopp — Sie splitten gerade Gehirne über AZs hinweg.

Traffic-Verhältnis: Canary-Gates auf clustervps Multi-AZ-Gateways

Canary-Promotion ist eine Folge diskreter Verhältnisse, kein Bauchgefühl. Leiten Sie zunächst etwa fünf Prozent neuer Sessions auf das Gateway, das bereits das Shadow-Skill-Verzeichnis trägt (/var/db/openclaw/skills/next neben current per Symlink). Halten Sie dieses Verhältnis mindestens über zwei zusammengesetzte Probe-Intervalle — typisch zehn Minuten — und beobachten Sie Gateway-p95, Queue-Tiefe und Error-Budgets unabhängig von Webhook-Rauschen. Steigern Sie nur in 10–20-Punkte-Schritten, wenn das gemergte JSON grünen Doctor zeigt und der Digest-Block sauber ist oder bereits als harmloser Back-Pressure klassifiziert wurde.

Dokumentieren Sie exakt API oder CLI Ihres LB-Anbieters zum Verschieben der Gewichte; viele clustervps-Betreiber:innen setzen Mac-Gateways hinter Anycast oder GeoDNS — reproduzieren Sie die Vendor-Aufrufe in einer Shell-Funktion, die Sie im Incident in den Chat einfügen können.

Konfigurationsfragmente pro Mandant (Grenzen der Skill-Slices)

Skill-Pack-Versionsschnitte scheitern, wenn Mandanten-Fragmente über Include-Reihenfolge uneins sind. Spiegeln Sie /etc/openclaw/tenants/<tenant>/skills.d/ auf jedem Gateway, bevor Sie next auf einen neuen Semver-Ordner zeigen lassen. Jedes Fragment soll nur die Slice-Grenze definieren — erlaubte Tool-Namespaces, Modellprofile, Plattenkontingente — keine Secrets. Secrets aus /var/db/openclaw/secrets/<tenant> mit POSIX-ACLs mounten, damit der Canary-Host Parsen validieren kann, ohne Tokens in CI-Logs zu leaken.

# Auf jedem Gateway nach Git-Tag-Checkout
sudo install -d -o root -g wheel /etc/openclaw/tenants/acme/skills.d
sudo /usr/local/bin/openclaw config lint --tenant acme
sudo /bin/ln -sfn "/var/db/openclaw/skills/1.4.2" /var/db/openclaw/skills/next
sudo launchctl kickstart -k system/com.openclaw.gateway

Canary-Mandanten können skills.d/10-canary.yaml auf next zeigen lassen, während Produktionsmandanten auf current bleiben, bis das Audit freigibt — minimaler Mandanten-Slice ohne ganze Cluster zu forken.

Health-Probes mergen: Doctor, Queues, Digest und Skill-Semver

Load Balancer rufen weiter eine URL, der Handler muss aber beantworten, ob die deklarierte Skill-Semver auf Platte mit openclaw.lock übereinstimmt, ob Doctor für Mandanten mit Traffic im letzten Intervall grün ist und ob die Queue-Tiefe im SLO blieb. Webhook-Digest-Zeilen bleiben nützlich, sind aber ein Feld in der gemergten Antwort — nicht der Promotion-Trigger. So bleibt dieser Text orthogonal zu reinen Broadcast-Architekturen.

#!/usr/bin/env bash
set -euo pipefail
TENANT_CANARY="${TENANT_CANARY:-acme}"
SKILL_PATH="/var/db/openclaw/skills/current"
/usr/bin/readlink "${SKILL_PATH}" | /usr/bin/tee /tmp/skill_path.txt
/usr/local/bin/openclaw doctor --tenant "${TENANT_CANARY}" --json >/tmp/doctor.json
/usr/bin/curl -fsS --max-time 3 "http://127.0.0.1:9099/v1/webhook-digest" -o /tmp/digest.json
/usr/bin/python3 - <<'PY'
import hashlib, json, pathlib
blob = pathlib.Path("/tmp/doctor.json").read_bytes() + pathlib.Path("/tmp/digest.json").read_bytes()
print(json.dumps({"probe_sha256": hashlib.sha256(blob).hexdigest(),"skill_resolved": pathlib.Path("/tmp/skill_path.txt").read_text().strip()}))
PY

Liefern Sie status: degraded, wenn Doctor gelb ist, Semver und Digest aber akzeptabel — Verkehr läuft, Dashboards schreien. Hartes Fail bei Semver-Mismatch zur Lockfile — kein noch so sauberer Webhook soll diesen Build promoten.

Rollback: Verkehr, Symlinks und launchd in einem Zug

Rollback hat zwei Hebel: LB-Gewichte zurück auf den Pre-Canary-Snapshot und /var/db/openclaw/skills/current zurück auf das vorherige Semver-Verzeichnis. Nicht teilweise zurückrollen — Gewichte splitten ohne Symlink-Kette erzeugt alten Verkehr gegen neue Skills oder das Gegenteil. Nach beiden Hebeln launchd einmal anstoßen und warten, bis die gemergte Probe-JSON dem archivierten guten Snapshot aus Ihrer Audit-Datei entspricht.

#!/usr/bin/env bash
set -euo pipefail
/usr/bin/scp stable-gw:/var/db/openclaw/audit/last_good_weights.json /tmp/weights.json
./lb_restore_weights.sh /tmp/weights.json
sudo /bin/ln -sfn "/var/db/openclaw/skills/${ROLLBACK_SEMVER}" /var/db/openclaw/skills/current
sudo launchctl kickstart -k system/com.openclaw.gateway
/usr/bin/curl -fsS http://127.0.0.1:8088/readyz | /usr/bin jq .

Kombinieren Sie Rollback-Drills mit Artefakt-Hygiene aus Mac mini M4 Multi-Region-Cluster: Artefakt-Matrix, damit Sie nicht rsync-rennen, während der Load Balancer noch auf die falsche AZ zeigt.

Audit: append-only JSONL, das Ihr Security-Team per grep lesen kann

Jeder Ratio-Schritt hängt eine JSON-Zeile an /var/db/openclaw/audit/promotions.jsonl auf dem Writer-Gateway (nächtlich in Objektstorage replizieren). Erfassen Sie actor, ticket, vorherige und neue Skill-Semver, die LB-Gewichtsabbildung und probe_sha256 aus dem Merge-Skript. Security interessiert weniger Webhooks als der Nachweis, dass Menschen Binärbewegung freigegeben haben.

/usr/bin/printf '%s\n' \
  "{"ts":"$(date -u +%Y-%m-%dT%H:%M:%SZ)","actor":"${USER}","ticket":"${TICKET}","from":"1.4.1","to":"1.4.2","weights":"${WEIGHT_BLOB}","probe_sha256":"${PROBE_SHA}"}" \
  | /usr/bin/tee -a /var/db/openclaw/audit/promotions.jsonl

Wenn Audit nachfragt, antworten Sie mit jq-Filtern — nicht mit Slack-Scrollback.

FAQ: Canary vs. webhook-first Betrieb

Brauche ich den Notifier-Digest noch? Ja — in der gemergten Probe anzeigen, damit Operator:innen systemische Partner-Ausfälle sehen. Digest-Gesundheit allein darf Verkehr nicht erweitern; Semver und Doctor müssen zuerst übereinstimmen.

Nur ein Mandant will neue Skills? Fragmente auf dem Canary-Gateway halten und LB-Sticky-Cookies oder Header für diese Kohorte auf den Canary-Pool pinnen, während alle anderen stabile Gewichte behalten.

Wie viele Mac-Knoten minimum? Drei clustervps-Hosts bleiben das kleinste ehrliche Proben: stabile AZ-A, stabile AZ-B und ein Canary-Gateway, das Ratio-Verkehr annimmt, bevor Peers spiegeln.