Energie sparen ohne viel Aufwand

Viele Maßnahmen zum Energiesparen in der IT setzen größere Umbauten oder Neuanschaffungen voraus. Dabei bietet auch die vorhandene Umgebung genügend Handlungsspielraum.

Von M. A. Susanne Nolte

Energie sparen kann man auf vielfältige Weise, auch dort, wo man es nicht erwartet. Gefragt ist dabei vor allem mehr Achtsamkeit im Umgang mit den Ressourcen. Ein vielleicht extremes Beispiel hat SAP für eine verbreitete Unternehmensanwendung vorgerechnet [1]: Spart man dort bei einer Transaktion eine CPU-Sekunde ein, entspricht das einer Energiereduktion von 10 Wattsekunden pro Transaktion. Wenn 500 Entwickler und Entwicklerinnen jeweils zehn Transaktionen so verbessern, die dann von jeweils 1,5 Millionen Anwenderinnen und Anwendern an 230 Werktagen zwanzigmal täglich durchgeführt werden, ergibt dies eine Energieersparnis von 95 000 MWh – so viel verbrauchen laut Stromspiegel der Regierung 30 000 Zweipersonenhaushalte in einem Jahr.

Welche Effekte kleine oder große Änderungen hervorrufen, ist also nicht immer auf den ersten Blick zu erkennen. Eine umfassende Änderung wie das Auslagern von Ressourcen in die Cloud kann zu insgesamt höherem Verbrauch führen, weil der dadurch entstehende Netztraffic die eigenen Switches und Router zum Glühen bringt. Zudem verschlingt die Produktion der Hardware dadurch, dass die Hyperscaler ihre Hardware alle zwei bis drei Jahre wechseln, weit mehr Energie, als die Systeme während ihrer Laufzeit je aufnehmen, während die nun ungenutzte eigene Hardware womöglich vorzeitig und unnötigerweise der Entsorgung zugeführt wird.

Wer also nach den Hebeln sucht, mit denen er den Energie- und Ressourcenbedarf seiner IT senken kann, sollte systematisch und überlegt vorgehen. Empfehlenswert ist der Rückgriff auf vorhandene Systematiken oder Bestandslisten. Die Einteilung darf auch mehrdimensional sein und sollte die anderen Anforderungen, denen die IT ausgesetzt ist, nicht unberücksichtigt lassen.

Verschwender systematisch aufspüren

Als Beispiel dient hier der recht allgemein gehaltene IT-Cube, der eine dreidimensionale Unterteilung vornimmt, sich aber jederzeit anpassen lässt (siehe Abbildung). Gängig in der IT ist die Einteilung in Ebenen oder Layer, in diesem Beispiel in Daten, Anwendungen, Middleware, Betriebssysteme, Systemhardware einschließlich Firmware, Netzwerk mit allen seinen Komponenten und die Infrastruktur samt Kühlung, Stromversorgung, Unterbringung und Zugangsschutz.

Die zweite Dimension beschreibt die Verteilung der IT: Recht neu ist die Edge-IT, die etwa in der Produktion die Maschinen-, Sensor- oder Produktionsdaten zur Weiterverarbeitung liefert. Das klassische Desktop-Computing wird immer mehr vom Mobile Computing abgelöst oder flankiert. Einen großen Teil der IT findet man im hauseigenen RZ zentralisiert, einen Teil eventuell ausgelagert in eine Colocation oder in die Cloud. Eine ganz eigene Welt bildet daneben das High-Performance Computing.

Die dritte Dimension gehört den Anforderungen: Zur Performance zählen etwa der Datendurchsatz, aber auch die Antwortzeiten einer Datenbank oder die Latenzen. Regelmäßig präsent sind die Verfügbarkeits- und Sicherheitsanforderungen, aber auch die der Wirtschaftlichkeit. Nicht zu unterschätzen sind die gebotene Anwend- und Handhabbarkeit sowie die Wart- und Managebarkeit. Neben all diesen Anforderungen müssen sich als jüngste die nach Nachhaltigkeit, Ressourceneffizienz und Umweltverträglichkeit einreihen.

So wie den Wirtschaftlichkeits- oder Sicherheitsanforderungen auf allen Ebenen und in allen Computing-Bereichen Rechnung zu tragen ist, ziehen sich auch Nachhaltigkeit und Ressourceneffizienz durch alle Segmente hindurch. Welche Optionen die Infrastruktur bietet, vor allem die Kühlung, aber auch das Energiemanagement, beschreibt das iX Special 2022 „Green IT“ ausführlich. Einen aktuellen Überblick über energieeffiziente Kühlmethoden liefert außerdem der Artikel „RZs energieeffizient kühlen“ ab Seite 52.

Doch auch die IT-Systeme selbst bieten jede Menge Handlungsspielräume. Wer ineffiziente Systeme und Komponenten aufspüren will, muss messen. Dazu und zum Fakturieren der laufenden Kosten verfügt jeder Server, jedes Storage-System und jede RZ-Steckdosenleiste über einen BMC (Baseboard Management Controller). Monitoringsysteme ermitteln den Stromverbrauch etwa der CPUs und der Netzteile zu jedem Zeitpunkt.

Wer weder Monitoringsysteme noch externe Leistungsmessgeräte einsetzt, fragt den BMC mit den ipmi-tools ab. Deren Kommando ipmi-sensors liefert eine Reihe von Messwerten, deren Zusammensetzung sich je nach BMC, CPU, BIOS und Protokollversion der Server unterscheidet. Die Werte in Listing 1 stammen von einem Lenovo ThinkSystem SR655 aus dem iX-Labor [2].

Zombies abschalten, unproduktive Systeme auslasten

Bedenken sollte man, dass die Last der Server nicht immer gleich ist. Relevant sind neben den Lastspitzen auch die Lastkurven, aus denen sich die Verbrauchskurven ergeben. Vor allem, wenn eine neue Applikation oder ein neues Release vor der Produktivsetzung einen Lasttest durchläuft, sollte man dabei auch den Energieverbrauch messen. Beispielsweise wirft das Kommando

perf stat -e power/energy-cores/,power/energy-pkg/,power/energy-ram/

nach Ende oder Abbruch die benötigte Energie in Joule aus. Gerade wenn ein Server zwischen womöglich kurzen, hohen Lastspitzen und langen Idle-Zeiten pendelt, sollte man über eine alternative Verteilung seiner Rechen- oder I/O-Lasten nachdenken. Ideal wäre es, die Lasten so zu verteilen, dass man ganze Systeme entweder abspecken, außer Betrieb setzen oder zeitweise herunterfahren kann. Langfristig müssen Bedarfsvorhersagen und Strategien zum dynamischen Bereitstellen von Ressourcen an Gewicht gewinnen. Dazu muss aber auch die Software bei einer eintreffenden Anfrage innerhalb von Millisekunden starten können. Heute ist das selbst mit Java möglich, etwa mit der GraalVM-Technik zum Kompilieren von Native Executables.

Völlig unterschätzt wird inzwischen, wie viele Zombies und Idle-Systeme die RZs bevölkern. Auch wenn ungenutzte Server weniger Energie als ausgelastete ziehen, ist ihr Bedarf erheblich. Jon Taylor und Jonathan Koomey haben für ihre Studie „Zombie/Comatose Servers Redux“ die Netzwerk-, CPU-, Memory- und Benutzeraktivitäten von insgesamt etwa 16 000 virtuellen und physischen Servern in zwölf Rechenzentren über zwei Zeiträume von je sechs Monaten untersucht [3].

Zwischen 23 und 30 Prozent der Maschinen zeigten über sechs Monate keinerlei Aktivität, entpuppten sich also als Zombies oder komatöse Maschinen. Dabei unterschieden sich die Zahlen bei den virtuellen Maschinen nicht signifikant von denen physischer Maschinen. 25 bis 50 Prozent der Server waren idle, wiesen also nur bei weniger als 5 Prozent der Messungen Aktivitäten auf. In keinem der untersuchten RZs kam die Menge der aktiven Server, die also bei mehr als 5 Prozent der Messungen aktiv waren, über 45 Prozent hinaus.