Eldric-Cluster überstehen Knotenausfälle, Netzwerk-Partitionen und den Verlust ganzer Rechenzentren — automatisch. Vom Notebook einer einzelnen Entwicklerin bis zur Föderation aus über 50 Knoten über mehrere Kontinente: dieselbe Software, dieselbe Konfigurations-Grammatik, dasselbe Installations-Paket.
Dasselbe eldric-aios-RPM läuft auf einem Raspberry Pi unter dem Monitor einer Entwicklerin ebenso wie auf einem Cluster aus 50 Bare-Metal-Knoten hinter dem Netz eines Krankenhauses. Welche Rolle jeder Knoten übernimmt, ist Konfiguration, nicht Code. Beginnen Sie mit einem. Wachsen Sie auf drei, sobald Verfügbarkeit zählt. Föderieren Sie über Standorte, sobald Sie ein zweites Büro eröffnen.
config.yaml — der Weg vom „Test auf einem Notebook“ zur „Multi-Region-Installation im Konzern“ ist eine Frage der Knoten, die Sie hinzufügen, nicht der Software, auf die Sie umsteigen.
Jeder Knoten in einem Eldric-Cluster hält einen Heartbeat zu seinen Peers. Verschwindet ein Leader — der Host stirbt, das Netz bricht weg, eine Administratorin zieht das falsche Kabel — bemerken die übrigen Knoten das innerhalb von Sekunden und wählen über ein etabliertes Raft-Consensus-Protokoll einen neuen Leader. Der Inferenz-Verkehr wird automatisch neu geroutet. Offene Chat-Sitzungen laufen mit der nächsten Anfrage weiter.
Ein Cluster, der erst nach menschlichem Eingriff wieder hochkommt, ist kein Cluster — er ist ein Single Point of Failure mit zusätzlichen Zwischenschritten.
Ein Unternehmen sitzt selten in einem einzigen Gebäude. Föderation lässt jeden Standort seinen eigenen autonomen Eldric-Cluster betreiben — der bandbreiten-intensive Verkehr bleibt lokal — während eine Föderations-Schicht Verzeichnisse, Wissensbasen und Zugriffsrichtlinien synchron hält. Eine Niederlassung bleibt nutzbar, wenn die WAN-Verbindung wegbricht. Die Zentrale hält eine warme Replik jeder Niederlassung für die regionale Notfall-Wiederherstellung.
Ein föderierter Cluster wird nicht zum Thin Client. Die Niederlassung behält ihre lokalen Modelle, ihr lokales RAG-Korpus und ihre lokalen Nutzer — und gleicht den Zustand mit dem Rest der Föderation ab, sobald die Verbindung zurück ist.
Eine Richtlinie pro Mandant erlaubt es, Wissensbasen als nur-EU, nur-USA oder standortgebunden zu markieren. Die Föderations-Schicht verweigert die Replikation von allem, was außerhalb der erlaubten Regionen markiert ist — eine Regel, die der Cluster durchsetzt, nicht der Operator.
Die warme Notfall-Replik erhält einen kontinuierlichen Strom von Föderations-Aktualisierungen. Ist das primäre Rechenzentrum offline — Brand, Hochwasser, durchtrennte Glasfaser — ist die Replik bereits auf wenige Minuten aktuell. Der Umschwenk ist eine Operator-Entscheidung, kein Wiederherstellungs-Projekt.
Das Schwierigste am Betrieb eines verteilten Systems ist meist nicht der Konsens — sondern der Überblick darüber, welche Maschine unter welcher Adresse erreichbar ist. Eldric stapelt vier Discovery-Schichten, damit Operatoren keine Liste pflegen müssen. In einem ruhigen Büro-LAN finden sich die Knoten in Sekunden. In einem weit verzweigten WAN setzt eine Handvoll Admin-Hinweise die Kette in Gang.
Eine Übersicht auf einen Blick: von der Knotenzahl zu dem, was sie Ihnen bringt. Jede Zeile ist dasselbe Eldric-Paket — der Unterschied liegt darin, wie viele Knoten Sie ihm geben und welche Rolle Sie jedem zuweisen.
| Knoten | Topologie | Failover | Typischer Anwendungsfall |
|---|---|---|---|
| 1 | Einzel-Host | keines (nur Neustart) | Entwickler-Notebook, Test eines einzelnen Teams, Proof of Concept auf dem Raspberry Pi. Dasselbe Paket — nur eines davon. |
| 2–3 | Quorum-Cluster | automatisch (kommender 5.0.x-Patch) | Kleines Büro, dauerhaft laufende Installation. Drei Knoten sind der ideale Punkt — übersteht den Verlust eines einzelnen Knotens mit klarer Mehrheit. |
| 4–10 | Leader + Worker | automatisch (kommender 5.0.x-Patch) | Abteilung oder mittelständisches Unternehmen. Eine Handvoll Leader-fähiger Knoten; der Rest sind dedizierte Worker, die Modelle, RAG-Indizes oder Fach-Agenten betreiben. |
| 10–50 | Multi-Rollen-Mesh | automatisch + zonal | Konzern an einem einzelnen Standort. Worker über Racks oder Availability Zones verteilt, sodass der Verlust eines ganzen Racks überstanden wird. Der Leader bleibt in einer anderen Zone. |
| 50+ | föderiertes Mesh | automatisch + standortübergreifend | Mehrere Standorte, mehrere Regionen. Cluster pro Standort föderieren über das WAN; warme Notfall-Repliken in einer anderen Region; Daten-Residenz-Regeln pro Mandant, durchgesetzt auf der Föderations-Schicht. |
Eine Einzelknoten-Installation ist für viele Teams ehrlich gesagt schon produktionsreif. Clustering rechnet sich in fünf konkreten Situationen.
Ein dreispaltiges Verzeichnis, wo jedes Teil der Belastbarkeits-Geschichte tatsächlich steht. Alles, was nicht in der linken Spalte steht, läuft noch nicht produktiv — und das geben wir auch so an.
5.0 — ausgeliefert
nächster Patch — entworfen & beauftragt
später in 5.0.x — auf der Roadmap
Roadmap-Zeitpläne ändern sich. Alles in den beiden rechten Spalten ist ernsthaft geplant und budgetiert — aber wir versprechen kein Kalender-Quartal für Software, die wir nicht fertiggestellt haben. Was wir versprechen: Diese Tabelle sagt Ihnen die Wahrheit.
Ein Drei-Knoten-Cluster läuft bequem auf drei handelsüblichen Linux-Rechnern. Eine föderierte Installation über mehrere Standorte läuft auf dem, was die IT-Abteilung ohnehin besitzt. Der Download ist derselbe; die Konfiguration ändert sich.