Der Quellcode des NADIKI Registrar ist als Open Source auf GitHub verfügbar. Wir veröffentlichen diese Implementierung als ersten Prototyp und freuen uns über Feedback, Bug Reports und Contributions — der Registrar ist ein Proof-of-Concept und wird von uns selbst für eine Open Web UI Instanz zusammen mit Rechenzentrumspartnern eingesetzt.

Mit dem Registrar setzen wir die NADIKI API-Spezifikation in eine funktionsfähige API um. Die Software bildet das Kernstück der Observer-Architektur: Sie nimmt Infrastrukturentitäten auf, nimmt Messdaten in Empfang und berechnet daraus die sieben Umweltwirkungsindikatoren, die eine KI-Workload für ihr Reporting abrufen kann (siehe Spezifikation).

Architektur und Komponenten

Die Anwendung besteht aus mehreren Diensten, die per Docker Compose orchestriert werden:

• Registrar API: Eine Flask-basierte REST-API, generiert aus der OpenAPI-Spezifikation mit dem Connexion-Framework. Sie stellt Endpunkte bereit, über die sich Rechenzentren, Racks und Server registrieren und ihre statischen Eigenschaften hinterlegen. Die API-Dokumentation ist über eine integrierte Swagger-UI zugänglich.

• MariaDB: Speichert die statischen Informationen jeder registrierten Entität — Standortdaten, PUE-Werte, Kühlkonfigurationen, Hardware-Inventare und Lebenszyklusdaten. Bei der Ersteinrichtung legt ein Initialisierungsskript die Tabellen für Facilities, Racks und Server automatisch an.

• InfluxDB: Zeitreihendatenbank für alle dynamischen Messwerte. Energieverbrauch, Temperaturen und Leistungsdaten werden als Zeitreihen gespeichert und bilden die Grundlage für die Umweltwirkungsberechnungen. Bei der Registrierung der Assets (Server, Rechenzentren, Rack) werden in der API-Antwort die Endpunkte angegeben, die für das Senden der Daten genutzt werden können.

• Telegraf (optional): Empfängt Metriken von den Infrastruktur-Exportern über Prometheus Remote Write und leitet sie an InfluxDB weiter. Die Konfiguration unterstützt HTTPS und verarbeitet eingehende Daten in 30-Sekunden-Intervallen. Wir nutzen diesen Ansatz, wenn die Daten eines Assets zusätzlich Aufbereitung benötigt, bevor sie in InfluxDB geschrieben wird.

• Flux Tasks: Zwei periodische Berechnungsaufgaben in InfluxDB transformieren die Rohdaten in Umweltwirkungsindikatoren: Der Operational Task berechnet alle vier Stunden den Energieverbrauch (erneuerbar und nicht-erneuerbar), die Eigenproduktion, den Generatorbeitrag und die CO₂-Emissionen pro Facility. Fehlende Messwerte werden linear interpoliert. Für die CO₂-Daten nutzen wir die API von Electricity Maps. Der Embodied Task normalisiert alle 15 Minuten die eingebetteten Emissionen aus der Herstellung von Servern und Gebäudeinfrastruktur auf eine stündliche Rate pro Betriebseinheit, basierend auf Lebensdauer und Klimadaten. Die Daten für diese Berechnung kommen von der Boavizta API.

• JupyterLab: Eine integrierte Analyseumgebung, die direkten Zugriff auf InfluxDB und MariaDB bietet. Hier können die gesammelten Daten explorativ ausgewertet, visualisiert und neue Berechnungsmodelle prototypisch getestet werden. Auch für Wissenschaftlicher ist diese Umgebung nützlich und wurde bereits in Folgeprojekten eingesetzt (SIEC).

Vom AWS-Prototyp zum dedizierten Server

Der erste Versuch lief auf AWS mit Elastic Container Service (ECS). Für die produktive Variante sind wir auf einen dedizierten Hetzner-Server mit Docker Compose umgestiegen. Die Produktionskonfiguration ergänzt das Basissystem um Nginx als Reverse Proxy mit automatischer Let's-Encrypt-Zertifikatsverwaltung über Route53-DNS-Validierung.

Ein Prototyp zur Weiterentwicklung

Der Registrar ist ein erster funktionsfähiger Prototyp. Er zeigt, dass die NADIKI API-Spezifikation implementierbar ist und die Designentscheidung für die Observer-Architektur in der Praxis trägt. Die Software ist bewusst einfach gehalten: Docker Compose statt Kubernetes-Cluster, SQLite-kompatible Schemata, Standard-Tooling wie Flask und InfluxDB.

Bereiche, in denen wir Verbesserungen erwarten und Beiträge begrüßen:

• Datenvalidierung: Strengere Prüfung eingehender Metriken und Registrierungsdaten.

• Berechnungsmodelle: Verfeinerung der Flux Tasks, insbesondere bei der Interpolation fehlender Werte und der Zurechnung auf Workload-Ebene.

• Sicherheit: Granularere Authentifizierung und Autorisierung pro Entität.

• Skalierung: Erfahrungen aus dem Betrieb mit mehreren Rechenzentren und einer höheren Anzahl an Servern.

Der vollständige Quellcode, die Docker-Compose-Konfigurationen und die Flux-Tasks stehen auf GitHub zur Verfügung.