Diese Seite richtet sich an die Person, deren Aufgabe es ist, eine Eldric-Installation im Alltag gesund zu halten — Installation, Nutzer, Mandanten, Monitoring, Backup, Upgrade. Sie geht die übliche Betriebs-Oberfläche der Reihe nach durch; für die tiefen Referenzen (jeder Endpunkt, jedes Flag) führen die Verweise in die API-Referenz und die einzelnen Funktions-Seiten.
Ein Eldric-Cluster besteht aus einem Controller, einem oder mehreren Routern, einem oder mehreren Inferenz-Workern, einem oder mehreren Daten-Workern und einem optionalen Kreis spezialisierter Worker (Agent / Medien / Comm / Wissenschaft / Training / xLSTM / IoT). Das Edge-Gateway ist der öffentliche Eingang. Alle Daemons laufen als systemd-Units auf jedem Host.
Für ein kleines Evaluierungs-Cluster läuft ein einzelner Host über das eldric-aios-Meta-Paket. Für den Produktivbetrieb teilt man auf mehrere Hosts auf — typischerweise tragen die GPU-Boxen Inferenz und xLSTM, die Storage-Boxen die Daten-Worker, ein kleiner Management-Host den Controller und Edge. Die Installations-Seite deckt den Einzelknoten-Pfad ab; den Multi-Node-Pfad zeigt der nächste Abschnitt.
Ein Host, ein Meta-Paket:
curl -fsSL https://repo.eldric.ai/install.sh | sudo bash sudo dnf install eldric-aios sudo systemctl enable --now eldric-aios
Nach 30 Sekunden steht die Chat-Oberfläche unter https://<host>/chat. Wer sich zuerst registriert, wird zum Administrator. Den Ablauf danach beschreibt Erste Schritte.
Derselbe Installations-Befehl auf jedem Host, mit Rollen-Flag:
# Management-Host
sudo dnf install eldric-aios-controller eldric-aios-edge
# Inferenz-Hosts (mit GPU)
sudo dnf install eldric-aios-worker eldric-aios-inferenced
sudo systemctl set-environment ELDRIC_CONTROLLER=https://mgmt-host:8880
# Daten-Hosts
sudo dnf install eldric-aios-data
# Optionale spezialisierte Worker
sudo dnf install eldric-aios-{agent,media,comm,science,training,xlstmd,iiotd}
Jeder Daemon registriert sich beim Controller beim ersten Start. systemctl status eldric-* auf jedem Host bestätigt den Lifecycle. Die Cluster-Topologie-Seite in der Chat-Shell (Admin-Konsole → Cluster) zeigt die registrierten Worker in Echtzeit.
Admin-Konsole → Nutzer zum Hinzufügen, Sperren oder Entfernen. Rollen: Viewer / Developer / Admin / SuperAdmin (letzterer nur für mandantenübergreifende Operationen). Admin-Konsole → Mandanten zum Anlegen neuer Mandanten — einer pro Abteilung / Studie / Projekt / Kunde. Der Mandanten-Scope wird am Gateway durchgesetzt; mandantenübergreifender Zugriff wird unbedingt abgewiesen.
Admin-Konsole → Wissensbasen zum Bereitstellen mandanten-eigener Wissensbasen. Jede Wissensbasis hat ein eigenes Embedding-Modell, einen eigenen Vektor-Speicher und (optional) eine Matrix-Memory-Schicht. Die komprimierte-Memory-Preview hängt hier dran — siehe Erweiterte Retrieval für den Opt-in-Pfad.
Admin-Konsole → Lizenz, um die signierte Lizenz-Datei einzuspielen. Der Controller prüft die Ed25519-Signatur und hebt die Limits an. Lizenz-Updates greifen hot — kein Neustart. Lizenz-E-Mail: license@core.at.
journalctl -u eldric-aios für die vereinigte Meta-Unit; pro Daemon journalctl -u eldric-aios-controller usw. Das Audit-Protokoll unter /var/lib/eldric/audit/ verkettet jede admin-seitige Aktion und jede KI-gestützte Entscheidung in einer Hash-Kette — belastbarer Nachweis für Compliance-Prüfungen.
/health auf seinem Hauptport. Eine einfache Liveness-Probe Ihres Monitoring-Stacks trifft sie./metrics im Prometheus-Format. Standard-Counter (Anfrage-Rate, Fehler-Rate, Latenz-Perzentile) plus Aufschlüsselung pro Mandant und Modell.Zwei Backup-Pfade decken den Cluster-Zustand ab:
Für Offsite-/Disaster-Recovery-Kopien den Offsite-Speicher am Daten-Worker mounten und das Snapshot-System dorthin zeigen lassen — das ist der 5.0-Pfad. 5.1 ergänzt die Offsite-Ziel-Automatisierung.
Der Controller betreibt einen Rolling-Update-Orchestrator, der jeden Knoten der Reihe nach durchgeht: Drain → Installieren → Neu starten → Verifizieren, dann weiter. Über die Admin-Konsole → Updates die Ziel-Version wählen und starten; der Orchestrator übernimmt die Reihenfolge und meldet pro Knoten den Status.
Für Einzelknoten-Installationen funktioniert das übliche sudo dnf update eldric-aios direkt. Für Air-Gapped-Cluster repo.eldric.ai/5.0/ lokal spiegeln und dnf auf den Spiegel zeigen lassen.
Rollback-Automatisierung kommt mit 5.1 (§70). In 5.0 erfolgt der Rollback manuell: vorherige Version pinnen und den Orchestrator erneut laufen lassen.
Die Plattform liefert ein Stress-Test-Gerüst mit — Parallel-Nutzer × Anfrage-Zahl als Last gegen einen Cluster-Host, mit pass/fail-Schwellen für p99-Latenz und Fehler-Budget. Bei der Inbetriebnahme eines Clusters einmal vor der Soak-Phase laufen lassen, und nach jeder relevanten Kapazitäts-Änderung erneut. Die Ergebnisse vergleichen sich gegen die veröffentlichte Demo-Cluster-Baseline.
journalctl -u eldric-aios --since today --no-pager — erster Anlaufpunkt für jedes Daemon-Problem.Für die Entwickler-Sicht: Für Entwickler und API-Referenz. Für die tiefere Plattform-Sicht: Wie es funktioniert. Für die GA-Vorbereitung: Weg zur 5.0 GA. Fragen: office@eldric.ai.