Technologievorschau: Monitoring des Stromverbrauchs für Red Hat OpenShift

Im Oktober letzten Jahres haben wir die Entwicklungsvorschau zum Monitoring des Stromverbrauchs für Red Hat OpenShift angekündigt, in der auch Kepler vorgestellt wurde, eine wesentliche Komponente der Upstream Community-Initiative für nachhaltiges Computing. Dank dieser Initiative können Early Adopter mit der vielversprechenden Technologie experimentieren. Seit der Ankündigung hat unser Team intensiv an der Entwicklung von Pipelines und Tools gearbeitet, die den Produktsicherheits- und Teststandards von Red Hat entsprechen.

Wir freuen wir uns, heute einen neuen Meilenstein auf unserem Weg bekanntzugeben – die Technologievorschau zum  Monitoring des Stromverbrauchs für Red Hat OpenShift. Wir bedanken uns bei allen Early Adopters und Fans disruptiver Technologie, die sich aktiv an der Entwicklung der Überwachung des Stromverbrauchs beteiligt und wertvolles Feedback gegeben haben.

Für diejenigen, die noch nicht mit dem Monitoring des Stromverbrauchs für Red Hat OpenShift experimentieren konnten, gibt es nun eine Reihe von Tools, mit denen Sie den Stromverbrauch von Workloads überwachen können, die in einem OpenShift Cluster ausgeführt werden. Diese Informationen können für verschiedene Zwecke genutzt werden, etwa um die Namespaces mit dem höchsten Stromverbrauch zu ermitteln oder um einen strategischen Plan zur Minimierung des Stromverbrauchs zu entwickeln.

Wenn Sie daran interessiert sind, mit dieser Vorschauversion zu experimentieren, finden Sie unten Details zum Einstieg. Weitere Informationen zum offiziellen Support finden Sie im Dokument Technologievorschau.

Installation des Stromverbrauch-Monitorings für Red Hat OpenShift

Unser Ziel ist, ein einheitliches Erlebnis bereitzustellen. Daher ähneln diese Installationsschritte denen der vorherigen Version des Stromverbrauch-Monitorings, die auf dem Community-Operator basierte.

1. Aktivieren Sie user-workload-monitoring nach den Anweisungen in der entsprechenden Dokumentation zu Red HatOpenShift.
2. Um unnötige Konflikte zu vermeiden, deinstallieren Sie zunächst sämtliche alte Versionen von kepler-operator, die Sie ggf. über den Operator-Katalog der Community installiert haben.
3. Sie können den Operator über die Konsole von OpenShift 4.14 (und höher) installieren. Navigieren Sie dazu zu Operators –> OperatorHub. Suchen Sie über das Suchfeld nach dem Monitoring des Stromverbrauchs für Red Hat OpenShift, klicken Sie darauf und wählen Sie dann die Option „Install“ (installieren).
4. Erstellen Sie nach der Installation des Operators eine Instanz der Custom Resource Definition von Kepler (benutzerdefinierte Ressourcendefinition), indem Sie auf „View Operator“ (Operator ansehen) und anschließend in der Kepler-API auf „Create instance“ (Instanz erstellen) klicken.

Fertig! Nach der Installation von Kepler stehen Ihnen in der Konsole von OpenShift in der Benutzeroberfläche auf der Registerkarte „Observe –>Dashboards“ (Beobachten –> Dashboards) 2 neue Dashboards zur Verfügung:

Weitere Informationen zum Monitoring des Stromverbrauchs finden Sie in der offiziellen Dokumentation im Bereich Dokumentation zu OpenShift.

Die Vorteile des Monitorings

Mit diesen Dashboards können Sie nun die folgenden Erkenntnisse über den Cluster und seine Workloads gewinnen:

• Überwachen Sie den gesamten Stromverbrauch Ihres Clusters in den letzten 24 Stunden. Dabei wird Ihnen die jeweils ausgewählte CPU-Architektur und die Anzahl der überwachten Knoten angegeben.
• Sehen Sie sich eine Aufschlüsselung der Namespaces mit dem höchsten Stromverbrauch an.
• Ermitteln Sie die Container und Pods mit dem höchsten Stromverbrauch . Dies erreichen Sie, indem Sie die von Kepler auf der Registerkarte „Observe –> Metrics“ (Beobachten –> Metriken) bereitgestellten Metriken analysieren.
  • Profi-Tipp: Sie können alle verfügbaren Metriken zum Monitoring des Stromverbrauchs mit diesem regulären Ausdruck abfragen: { __name__ =~ "kepler.+"}

Wie bereits erwähnt, werden diese Metriken durch die Integration von Kepler in OpenShift verfügbar. Die von Kepler abgerufenen Metriken hängen stark von der zugrunde liegenden Hardware- und Cluster-Konfiguration ab. Derzeit bietet Kepler genaue Messungen von einem bestimmten Satz von Cloud-Konfigurationen, insbesondere von denen, die auf Intel-Hardware basieren und in der Lage sind, Running Average Power Limit (RAPL) und Advanced Configuration and Power Interface (ACPI) in Bare Metal-Deployments verfügbar zu machen.

Für andere Konfigurationen wird ein anfängliches ML-Modell (maschinelles Lernen) bereitgestellt. Red Hat arbeitet mit der breiten Community daran, die Genauigkeit der  auf maschinellem Lernen basierenden Schätzungen weiter zu verbessern. Da diese Schätzungen derzeit Konsistenz aufweisen, können Sie darauf basierend Variationen bei Ausführungen derselben Workload aufzeigen. Sie sollten jedoch unbedingt beachten, dass es sich dabei um Näherungswerte zum tatsächlichen Stromverbrauch handelt.

Damit Nutzende leichter erkennen, ob Kepler standardmäßig metrikbasierte Werte oder modellbasierte Werte bereitstellt, haben wir in der Übersichtsseite im Bereich „Node – CPU Architecture“ (Knoten – CPU-Architektur) eine zusätzliche Spalte mit dem Namen „Components Source“ (Komponentenquelle) hinzugefügt.

Diese Verbesserung bietet Transparenz und ermöglicht es Nutzenden zu sehen, woher die Metriken stammen, etwa rapl-sysfs oder rapl-msr. Wenn Kepler keine Metriken für den Stromverbrauch der Hardware abrufen kann, wird stattdessen „estimator“ (Schätzung) als Quelle angezeigt. In solchen Fällen greift Kepler auf das ML-Modell und die daraus resultierenden oben genannten Schätzungsfunktionen zurück. Die fortlaufenden Entwicklungsinitiativen zielen auf die Optimierung dieser Modelle ab, um sowohl die Genauigkeit als auch den Umfang der Footprints zu verbessern, die damit gehandhabt werden können.

Die Metriken

Sehen wir uns anhand eines Beispiels die genaueren Details an. Nach der Installation von Kepler gemäß der offiziellen Dokumentation haben wir einen HTTP/2-Datenverkehrsgenerator und ein Mock-Objekt installiert und das System ein wenig belastet.

Sehen wir uns nun die Auswirkungen auf den Stromverbrauch des OpenShift Clusters an. Wenn Sie in der OpenShift-Konsole zum Dashboard „Observe –> Dashboards –> Power Monitoring Overview“ (Beobachten –> Dashboards –> Überblick über den Stromverbrauch) navigieren, wird nun Folgendes angezeigt:

• Die im Bereich Architektur aufgeführten Knoten melden metrikbasierte Ergebnisse, da rapl-sysfs in der Spalte „Components Source“ (Komponentenquelle) angezeigt wird.
• Der Cluster war eine Weile in Betrieb, wurde aber nicht genutzt und hatte daher einen geringen Kilowattverbrauch.
• Außerdem wird eine Liste der Namespaces angezeigt, die am meisten zur Stromrechnung beitragen.

Um die Profile zum Stromverbrauch besser zu verstehen, sehen wir uns das zweite Dashboard „Power Monitoring/Namespace“ (Stromverbrauch/Namespaces) an und wählen den Namespace (hermes-ns):

• Als Erstes lässt sich feststellen, dass nach einigen Spitzen der Stromverbrauch in Watt im Zeitverlauf stabil ist und die PKG-Komponente den größten Anteil hat. PKG-Domain (Package) misst den Stromverbrauch des gesamten Sockets. Dies umfasst den Verbrauch aller Kerne, der integrierten Grafiken und auch der Komponenten außerhalb des Kerns (Caches der letzten Ebene, Speicher-Controller). Hier scheint alles richtig zu sein, und es werden keine Häufungen gefunden, da der Stromverbrauch die Energiequote ist.
• Wir können auch sehen, dass der Stromverbrauch im Laufe der Zeit zunimmt. Der DRAM (misst den Stromverbrauch des RAM, der an den integrierten Speicher-Controller angeschlossen ist) scheint in diesem Fall einen zu vernachlässigenden Anteil am Stromverbrauch zu haben. 

Wenn wir etwas nach unten scrollen, können wir die Beiträge für PKG und DRAM pro Container weiter analysieren. Hier fällt zunächst auf, dass die ersten Spitzen anscheinend von einer früheren Workload verursacht wurden. Das hört sich interessant an, aber wir müssen das vielleicht in der App bzw. im Mock-Objekt debuggen.

Nachdem das zweite Deployment bereit ist, können wir beobachten, dass beide Container gleichermaßen zum Stromverbrauch beitragen.

Was sagt uns das? Bedeutet das, dass ein Datenverkehrsgenerator mit einer komplexen Logik und Instrumentalisierung mit OpenTelemetry, Metriken und Nachverfolgung genauso viel Energie verbraucht wie ein einfaches Mock-Objekt, das nur „200 OK“ sagt und dies in der Konsole ausgibt? Uns gefällt die moderne Beobachtbarkeit, aber man muss trotzdem von Zeit zu Zeit einen Ausdruck in der Standardausgabe ausgeben.

func exampleHandler(w http.ResponseWriter, r *http.Request) {
	time.Sleep(2 * time.Millisecond)
	fmt.Println("Request received. URI:", r.RequestURI, "Method:", r.Method)
	w.WriteHeader(200)
}

Der Datenverkehrsgenerator ist in C++ und das Mock-Objekt in Go geschrieben. Aktuelle Studien haben gezeigt, dass – unter bestimmten Bedingungen – C++ energieeffizienter sein kann als Go, und zwar um den Faktor 2,5. Diese Diskussion geht jedoch weit über den Rahmen dieses Blogs hinaus. Wir mögen alle Sprachen, und jede von ihnen hat ihre eigenen Bereiche, in denen sie von Vorteil ist. Wir sind gespannt darauf, wie Sie das Monitoring des Stromverbrauchs nutzen werden. Vielleicht können Sie das Problem hinsichtlich Programmiersprache und Stromverbrauch sogar mit Ihren eigenen Daten in Angriff nehmen. 

Nächste Schritte

Wir sind weiterhin bemüht, Ihr Feedback zu integrieren, Anpassungen vorzunehmen und Verbesserungen einzuführen. Wir werden auch weiterhin mit der Community zusammenarbeiten und so zur globalen Initiative für ein effektiveres Monitoring des Stromverbrauchs beitragen. Die Perspektiven sind vielversprechend. Die möglichen Pläne reichen von der Integration der Energieüberwachung mit umfassenderen Nachhaltigkeitsinitiativen über die Unterstützung von Entwickungsteams bei der Beobachtung von Code in der OpenShift-Plattform bis hin zum Export von Daten über OpenTelemetry. 

Weitere Informationen

• Offizielle Dokumentation zu Red Hat OpenShift
• Entwicklungsvorschau von Kepler: Monitoring des Stromverbrauchs für Red Hat OpenShift
• https://sustainable-computing.io/
• Das Potenzial von Kepler: Offenlegen des Stromverbrauchs von Cloud-Anwendungen | CNCF
• The New Stack: Welche Programmiersprachen verbrauchen den geringsten Strom?
• Supportumfang der Entwicklungsvorschau – Red Hat Customer Portal
• Features der Technologievorschau – Supportumfang – Red Hat Customer Portal
• Entwicklungs- und Technologievorschau im Vergleich – Red Hat Customer Portal
• Aktivieren des Monitorings für benutzerdefinierte Projekte | Monitoring | Red Hat OpenShift Platform 4.14