Cluster – mehrere Nodes abgleichen

Betreibst du mehr als eine Node64 – etwa den Raspberry Pi im Keller, eine VM auf dem Server und eine Node bei den Eltern –, verbindest du sie zu einem Cluster. Die Nodes gleichen Einstellungen und Einträge dann direkt untereinander ab: verschlüsselt, auch über verschiedene Netze und auch ganz ohne ipv64.net.

Wozu ein Cluster?

• Ein Bild auf allen Nodes: Checks, Wartungsfenster, Benachrichtigungs-Einstellungen und weitere Bereiche sind auf jeder Node gleich – ändern kannst du überall.
• Mehrere Messstellen: Ein Check kann von mehreren Nodes gemessen werden; jede Node erscheint als eigene Messstelle. Benachrichtigt wird trotzdem genau einmal.
• Zertifikate verteilen: Zertifikate, ACME-Konto, DNS-Zugänge und eigene CAs einmal einrichten und auf allen Nodes nutzen.
• Unabhängig von der Cloud: Ein Cluster ohne ipv64-Account funktioniert vollständig lokal – auch Healthchecks mit eigener Bewertung und Benachrichtigung.
• Kein zusätzlicher Port: Die Nodes sprechen über den normalen Web-Port miteinander.

Voraussetzungen

• Derselbe ipv64-Account oder keiner: Alle Nodes eines Clusters haben denselben ipv64-Account – oder alle keinen. Gemischt geht nicht.
• Erreichbarkeit: Die Nodes müssen sich gegenseitig unter ihrer Adresse und dem Web-Port erreichen, im Heimnetz oder über verschiedene Netze (z. B. per VPN oder Portfreigabe).
• Richtige Uhrzeit: Die Uhren der Hosts sollten per NTP stimmen – die Anfragen zwischen den Nodes sind mit Zeitstempel signiert.
• Gleiche Version: Am besten alle Nodes auf demselben Stand halten; eine zu alte Node wird ausgesetzt.

So sieht das aus

  # Drei Nodes desselben Accounts (oder alle ohne Account)
 ┌───────────────┐   HTTPS, Web-Port      ┌───────────────┐
 │ Node64 „Pi“   │◄──────────────────────►│ Node64 „NAS“  │
 │ Heimnetz      │   signiert             │ Heimnetz      │
 └──┬────────────┘                        └────────┬──────┘
    │  ▲                                           ▲
    │  │   Checks · Zertifikate · Messwerte        │
    │  │            ┌───────────────┐              │
    │  └───────────►│ Node64 „Büro“ │◄─────────────┘
    │               │ anderes Netz  │
    │               └───────────────┘
    │ ausgehend, HTTPS 443 (optional)
    ▼
 ┌───────────────┐
 │   ipv64.net   │  Healthchecks laufen weiter über die ipv64-Server;
 └───────────────┘  der Cluster ist ein zusätzlicher Weg

Eine weitere Node aufnehmen

Auf einer Node, die schon im Cluster ist (oder der ersten Node), klickst du unter Cluster auf Code für eine weitere Node.

• Die Node zeigt einen 8-stelligen Code (z. B. ABCD-EFGH) und ihre eigene Adresse an.
• Der Code gilt 10 Minuten und nur einmal; du kannst ihn jederzeit verwerfen.

Einem Cluster beitreten

Auf der neuen Node öffnest du Cluster → Einem Cluster beitreten und füllst drei Felder aus:

1. Adresse einer Node des Clusters
   mit https://, z. B. https://node64-pi.lan:8080.
2. Code
   den Code von dort.
3. Adresse dieser Node
   so, wie die anderen sie erreichen. Vorgeschlagen ist https:// plus die Adresse, unter der du die Seite gerade aufrufst; ist NODE64_HTTPS_PORT gesetzt, mit diesem Port.

Danach erscheint die Node bei allen Mitgliedern. Jede Node kann den Cluster auch selbst wieder verlassen – die anderen erfahren es automatisch.

Verbindung immer per HTTPS

• Die Nodes sprechen immer verschlüsselt miteinander. Einen eigenen HTTPS-Port brauchst du nicht: Der normale Web-Port (NODE64_HTTP_PORT, Standard 8080) spricht auch TLS.
• Das Zertifikat muss nicht gültig sein – ein selbst signiertes genügt. Schutz gegen Mitlesen und gegen einen Mittelsmann bietet die Bindung an die Schlüssel, die bei der Kopplung ausgetauscht werden.
• Ein Proxy dazwischen, der TLS aufbricht, funktioniert deshalb nicht (die Node wird mit dem Grund tls_binding ausgesetzt). Sprich die Nodes direkt an.

Was wird abgeglichen?

Unter Was wird abgeglichen gibt es je Modul einen Schalter und darunter je Bereich einen eigenen:

• Ein Bereich wird nur mit Nodes abgeglichen, bei denen er ebenfalls an ist – also nur, wenn er auf beiden Nodes an ist.
• Module, die auf dieser Node nicht laufen, sind ausgegraut.
• Konflikte: Ändern zwei Nodes dasselbe, gewinnt die jüngere Änderung. Gelöschtes bleibt gelöscht.
• Benachrichtigungskanäle bleiben die eigene Einstellung jeder Node.
• Zertifikate: Erneuert wird nur von einer Node – der, die zuletzt ausgestellt hat. Eine andere übernimmt erst, wenn ein Drittel der Erneuerungsfrist verstrichen ist (bei Let's Encrypt 10 Tage). Löschen auf einer Node löscht überall.
• Mitglieder ohne eingeschaltetes Modul Healthchecks und ausgesetzte Nodes zählen nicht für Messwerte, Benachrichtigungen und das Weiterreichen an ipv64.
• Geschaltet wird nur hier auf der Seite Cluster. Die Seite Healthchecks-Sync zeigt nur noch an, ob der Abgleich an oder aus ist, und verweist hierher.

In Planung: PROXY64

PROXY64 soll später ebenfalls über den Cluster abgeglichen werden können – mit Schaltern je Bereich wie bei den anderen Modulen. Umgesetzt wird das, sobald die Nachfrage hoch genug ist; der Cluster ist dafür bereits vorbereitet. Geplant ist zum Beispiel:

• PROXY64: Proxy-Hosts und Zugriffslisten gemeinsam auf allen Nodes – das Ziel eines Hosts darf je Node abweichen, und ein Host lässt sich auf einer Node gezielt ausschalten (Dienst nur an einem Standort).
• Statistiken werden nicht kopiert, sondern live von jeder Node abgefragt und mit Node-Namen und als Summe angezeigt.

Bewusst nie abgeglichen werden DynDNS (zwei Nodes würden dieselbe Domain abwechselnd überschreiben), Anmeldung, Zwei-Faktor, Passkeys, SSO und API-Keys sowie Ports, Logging, Backup und Updates.

Mitglieder verwalten

Oben steht, ob diese Node zu einem ipv64-Account gehört („Diese Node gehört zum ipv64-Account #…“) oder keinen hat. Darunter die Liste aller Mitglieder:

Mit Aus dem Cluster nehmen entfernst du eine Node; alle anderen erfahren es.

Ausgesetzte Nodes

Ändert sich an einer Node etwas Grundlegendes, wird sie ausgesetzt: Die anderen sprechen nicht mehr mit ihr, arbeiten untereinander aber normal weiter.

Außer bei version_too_old wird eine Node nur von Hand mit Wieder aufnehmen zurückgeholt. Dabei wird erneut geprüft; passt es noch nicht, bleibt sie ausgesetzt und die Oberfläche nennt den Grund.

Wenn eine Node weg ist

1. Offline, nicht ausgesetzt
   Die anderen pingen sie weiter alle 30 Sekunden; nach 2 Minuten ohne Antwort gilt sie als offline (in der Liste mit letztem Fehler). Sie wird weder ausgesetzt noch entfernt – offline ist kein Grund dafür.
2. Die anderen arbeiten weiter
   Die übrigen Nodes gleichen normal untereinander ab.
3. Benachrichtigen
   Misst sie einen Check zusammen mit anderen, übernimmt die nächste erreichbare messende Node die Meldungen – ohne Doppelmeldung. Misst nur sie einen Check, wird er nach 3 Intervallen (mindestens 5 Minuten) ohne Messung „nicht überwacht“.
4. Weiterreichen an ipv64
   War sie die Node, die Änderungen an ipv64 weiterreicht, übernimmt die nächste verknüpfte und erreichbare Node.
5. Sie kommt zurück
   Beide Seiten holen ab ihrem letzten Stand alles nach, was sich in der Zwischenzeit geändert hat – auch Änderungen, die auf ihr selbst gemacht wurden –, Messwerte ebenso. Dauerhaft entfernt wird eine Node nur mit Aus dem Cluster nehmen.

Meldung: Ist eine Node länger als 5 Minuten nicht erreichbar oder ausgesetzt, kommt über deine Benachrichtigungskanäle „🔴 Cluster: Node … nicht erreichbar“ (mit dem letzten Fehler bzw. dem Grund fürs Aussetzen), bei ihrer Rückkehr „🟢 … wieder erreichbar“ – jeweils mit Link auf die Cluster-Seite. Es meldet genau eine Node: die mit der kleinsten Kennung unter den erreichbaren; die Entwarnung schickt, wer gemeldet hat. Das Dashboard zeigt dann oben einen Hinweis, und die Kachel Cluster (nur mit Mitgliedern) zeigt den Zustand jeder Node.

Split-Brain: Teile des Clusters länger getrennt

Es gibt keinen Anführer und keine Mehrheitsregel: Ist die Verbindung zwischen Teilen des Clusters weg, arbeitet jeder Teil allein weiter, nichts wird gesperrt. Nach der Wiederverbindung holt jede Node ab ihrem letzten Stand alles nach, und alle landen beim selben Ergebnis:

Wer benachrichtigt?

• Misst nur eine Node einen Check, benachrichtigt diese Node – oder ipv64, wenn sie verknüpft ist.
• Messen mehrere Nodes des Clusters einen Check, benachrichtigt genau eine. Fällt sie aus, übernimmt die nächste – ohne doppelte Meldung.
• Auf der Detailseite eines Checks steht unter Benachrichtigt, wer meldet.

Zusammenspiel mit ipv64.net

• Healthchecks laufen für verknüpfte Nodes weiter über die ipv64-Server; der Cluster ist ein zusätzlicher Weg.
• Eine verknüpfte Node reicht Änderungen der Nodes ohne eigenen Healthchecks-Sync an ipv64 weiter.
• Ist keine verknüpfte Node erreichbar, bleiben Änderungen und Meldungen einfach im Cluster.

Mehr dazu unter Mit ipv64.net verknüpfen.

Sicherheit

• Jede Node hat einen eigenen Ed25519-Schlüssel, der verschlüsselt in ihrer Datenbank liegt.
• Jede Anfrage und jede Antwort zwischen den Nodes ist signiert – über Methode, Pfad, Zeit, Account, eine Einmal-Kennung, den Inhalt und eine Kennung der TLS-Verbindung. Ein Mittelsmann hätte zu beiden Seiten andere Verbindungen und wird abgelehnt, bevor Daten fließen.
• Wiederholte Anfragen werden erkannt und abgelehnt.
• Der Beitritt ist nur mit dem einmaligen Code möglich (10 Minuten, nach 5 Fehlversuchen verworfen).
• Ändern sich Account oder Schlüssel einer Node, wird sie automatisch ausgesetzt.
• Die Endpunkte für die Nodes liegen auf dem normalen Web-Port unter /peer/; sie nehmen nur signierte Anfragen von Mitgliedern bzw. den Beitrittscode an.

Technik: Port, Endpunkte, Zeiten

Port und Verbindung

Endpunkte

Auf dem Web-Port, ohne Anmeldung in der Oberfläche – sie nehmen nur signierte Anfragen von Mitgliedern bzw. den Beitrittscode an:

Zeiten und Grenzen

API

Der Bereich heißt in der API-Referenz „Cluster“; die Pfade beginnen weiter mit /api/group.

Jede Änderung steht im Audit-Log (Bereich Cluster). Für das Monitoring gibt es Prometheus-Werte zu den Mitgliedern – siehe Prometheus.

Beobachten

• Dashboard: Kachel Cluster mit dem Zustand jeder Node und ein Hinweis oben, wenn eine Node weg oder ausgesetzt ist; dazu die Meldung nach 5 Minuten.
• Oberfläche Cluster und GET /api/group – je Mitglied online, Zustand, Grund, Bereiche, zuletzt erreicht und letzter Fehler.
• Prometheus: node64_group_members, node64_group_members_online und node64_group_member_up{node_id,node_name} – siehe Prometheus.
• Log (Bereich peer): „cluster member suspended/resumed“, „peer request rejected“, „cluster entries updated“; Abholfehler auf Debug. Im Audit-Log steht alles im Bereich Sync.

Etwas unklar, fehlt etwas oder hast du eine Frage zu Node64? Frag im offiziellen Forum v64.tech.