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 All-in-one-Bootstrap (empfohlen):
curl -fsSL https://repo.eldric.ai/install-eldric.sh | sudo bash
Das Skript fügt das signierte dnf-Repository hinzu (GPG-Fingerprint-pinned), installiert das eldric-aios-Meta-Paket und führt eldric setup aus. Alternativ in drei Schritten:
curl -fsSL https://repo.eldric.ai/install.sh | sudo bash sudo dnf install eldric-aios sudo systemctl enable --now eldric-aios sudo eldric setup
Nach 30 Sekunden steht die Chat-Oberfläche unter https://<host>/chat — Einzelknoten lauscht standardmäßig auf Port 8880. (Sobald ein dediziertes Edge-Gateway davor sitzt, fällt der Port weg und die URL wird zu https://<host>/chat.) Wer sich zuerst registriert, wird zum Administrator. Den Ablauf danach beschreibt Erste Schritte.
Dasselbe eldric-aios-Meta-Paket auf jedem Host; die Rolle wird per Umgebungsvariable in /etc/eldric/eldric-aios.env festgepinnt — keine separaten Per-Daemon-RPMs:
# Auf jedem Host curl -fsSL https://repo.eldric.ai/install-eldric.sh | sudo bash # Management-Host echo 'ELDRIC_AIOS_ROLE=controller,edge' | sudo tee /etc/eldric/eldric-aios.env # Inferenz-Hosts (mit GPU) — eldric-aios-cuda zusätzlich sudo dnf install eldric-aios-cuda echo 'ELDRIC_AIOS_ROLE=worker,inference' | sudo tee /etc/eldric/eldric-aios.env echo 'ELDRIC_CONTROLLER_URL=http://mgmt-host:8880' | sudo tee -a /etc/eldric/eldric-aios.env # Daten-Hosts echo 'ELDRIC_AIOS_ROLE=data' | sudo tee /etc/eldric/eldric-aios.env # Auf jedem Host nach Konfiguration sudo systemctl restart eldric-aios
Jeder Daemon registriert sich beim Controller beim ersten Start. systemctl status eldric-aios 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. 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 heutige 5.0-Pfad. Ein kommender 5.0.x-Patch 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 in einem kommenden 5.0.x-Patch. Heute 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. Fragen: office@eldric.ai.