## Excerpt

Die Umweltwirkung von Cloud-Workloads zu messen ist technisch anspruchsvoll: In virtualisierten Umgebungen sind Workloads von der physischen Infrastruktur isoliert, und Sicherheitsanforderungen erschweren die Weitergabe serverseitiger Daten an die Workloads. Mit NADIKI haben wir eine Observer-Architektur entwickelt, die diese Lücke schließt — sie erfasst Infrastrukturmetriken, wandelt sie in Umweltwirkungsindikatoren um und stellt sie der Workload bereit, ohne sensible Daten preiszugeben.

## Content

Die Umweltwirkung von Cloud-Workloads zu messen, ist schwierig. In komplexen virtualisierten Umgebungen ist eine virtuelle Maschine von dem physischen Server, auf dem sie läuft, isoliert — und Sicherheitsanforderungen erschweren es, serverseitige Daten mit Kunden bzw. der Workload zu teilen. Gleicherßmaßen hat der physische Server auf das Netzwerk der Gebäudetechnik keinen Zugriff. Mit NADIKI haben wir eine Architektur und Open-Source Implementierung für ein Observer-System ("Registrar") entwickelt, das diese Lücke schließt: Es erfasst und konvertiert Infrastrukturmetriken in Umweltwirkungsindikatoren und stellt sie Kunden zur Verfügung, ohne sensible oder proprietäre Daten preiszugeben.

Die Observer-Architektur

Die zentrale Innovation ist ein externes System — der Observer —, das zwischen der physischen Infrastruktur und der Workload des Kunden sitzt. Er pflegt ein Inventar aller relevanten IT-Assets und den Assets in der Gebäudetechnik, bekommt von den Assets Metriken bereitgestellt und stellt Umweltwirkungsdaten über eine saubere Query-Schnittstelle bereit. In Produktivumgebungen ist eine Synchronisierung mit einer CMDB oder anderen IT-Asset-Management-Systemen denkbar. Sicherheitsperimeter bleiben auf beiden Seiten intakt.

• Registrar: Pflegt ein Inventar aller Assets — Rechenzentren, Racks, Server, Container und Anwendungen. Jedes Asset registriert sich selbst und erhält eine eindeutige Kennung. Die Registry teilt jedem Asset mit, welche Metriken gemeldet und an welchen Prometheus-kompatiblen Endpunkt sie übermittelt werden sollen. Außerdem speichert sie statische Annahmen und Konfigurationen, die verwendet werden, wenn keine Echtzeitmessdaten vorliegen.

• Metriken-Datenbank: Aufbauend auf InfluxDB, werden unterstützt sowohl Push- als auch Pull-Mechanismen unterstützt. Assets wählen selbst, welche Metriken sie übermitteln und über welchen Weg — Sicherheitsperimeter werden dabei nicht durchbrochen. Die Datenbank aggregiert Zeitreihendaten aller registrierten Assets. Zusätzlich können mit Telegraf Messdaten, falls notwendig, umgewandelt und normalisiert werden, z.B. wenn Geräte in der Gebäudetechnik Messdaten nur in nicht-konformen Formaten übertragen können.

• Query-Schnittstelle: Workload-Betreiber können beim Observer mit der eindeutigen Kennung einer Workload und einem gewünschten Zeitraum die berechneten Informationen zur Umweltwirkung abfragen. Der Observer berechnet, welchen Anteil des physischen Servers und Infrastruktur die Workload belegt, und führt die vollständige Umweltwirkungszurechnung durch — ohne dabei geschäftssensible Informationen der Infrastruktur-Betreiber preiszugeben.

Der "Observer-Pattern" (Wikipedia) ist ein etabliertes Software-Engineering-Konzept: Ein einzelner Observer wird benachrichtigt, sobald seine Observables — IT-Assets, Racks, Rechenzentren — sich ändern oder neue Metriken aufzeichnen. Im NADIKI-Kontext ermöglicht das eine lose Kopplung zwischen Infrastruktur-Assets und Monitoring-Systemen und stellt sicher, dass Umweltwirkungsdaten konsistent erfasst werden, ohne enge Abhängigkeiten zwischen Systemen zu schaffen.

Umweltwirkungsindikatoren

In Übereinstimmung mit aktuellen Regulierungsanforderungen wie der CSRD und LCA-Methoden liefert Query Schnittstelle des Observers die folgenden Umweltwirkungsindikatoren auf Workload-Ebene:

• Primärenergieverbrauch (kWh): Gesamtenergieverbrauch des Workloads, einschließlich erneuerbarer und nicht erneuerbarer Anteile.

• Wiederverwendete Energie (kWh): Zurückgewonnene und wiederverwendete Energie, typischerweise als Abwärme.

• Wasserverbrauch (m³): Wasserverbrauch auf Rechenzentrumsebene, ohne Berücksichtigung von Energieproduktion und Herstellung.

• Treibhauspotenzial (CO₂-Äq.): Graue Emissionen entstanden bei der Herstellung der Infrastruktur und Server sowie energiebezogene Emissionen.

• Abiotisches Ressourcenverbrauchspotenzial (kg Sb-Äq.): Mineralischer Ressourcenverbrauch bei der Fertigung von Servern sowie mechanischer und elektrischer Infrastruktur im Rechenzentrum.

System-Perspektive schaffen, dann optimieren

Der aktuelle Stand der Umweltmessung für Cloud-Workloads beruht stark auf Schätzungen. Genaue Daten über Server, Racks und Rechenzentren sind für Kunden selten zugänglich — schlicht weil die Verbindung zwischen physischer Infrastruktur und Anwendungsebene bisher nie hergestellt wurde. NADIKI verfolgt einen pragmatischen Ansatz um eine System-Perspektive herzustellen, den wir Durchstich nennen: erst den Tunnel von Ende zu Ende verbinden, dann ausbauen. Bestehende Asset-Management-Systeme wie Netbox oder DCIM-Systeme können so erweitert werden, dass sie Daten in den Observer einspeisen — ohne ersetzt zu werden.

”Rhätische Bahn feiert Durchstich von Albulatunnel ins Engadin” (Luzerner Zeitung)

Alle NADIKI-Spezifikationen und -Implementierungen werden als Open Source veröffentlicht. Eine erste technische Implementierung des Observer-Systems folgt in Kürze.