Projekt »GreenICT – EdgeLimit«

Energieeffiziente Orchestrierung

20. Juni 2024, 17:15 Uhr | Von Peter Heusinger, Zekeriya Mansuroglu und Michael Wagner
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Energieeffiziente Orchestrierung

Die energieeffiziente Orchestrierung setzt Technologien ein, die gute Unterstützung für Softwarevirtualisierung und Anwendungsorchestrierung bieten. »Containerd« ist die Lightweight-Implementierung einer Container-Laufzeitumgebung und »K3s« ist die Implementierung des K8s-Frameworks (Kubernetes), ebenfalls ausgerichtet auf ressourcenlimitierte Systeme.

passend zum Thema

Protokoll-Stack der energieeffizienten Orchestrierung
Bild 6: Protokoll-Stack der energieeffizienten Orchestrierung.
© Fraunhofer IIS

Für die Entwicklung und den Test einer energieeffizienten Orchestrierung wurde ein K8s-Cluster aufgebaut, bestehend aus einer Control-Plane, einem Edge-Server und 4 Arm-basierten, in Form von XILINX-Evaluationsboards emulierten Recheneinheiten von 5G-Radio-Units. Die Control-Plane dient als Verwaltungseinheit des Clusters, während der Edge-Server und die Radio-Units die sogenannten Worker-Nodes darstellen. Sie führen die eigentlichen Anwendungen aus. Bild 6 zeigt die einzelnen Komponenten in Form eines Stack.
Im klassischen Multi-Access-Edge-Computing (MEC) werden Anwendungen auf Edge-Servern ausgeführt. Um die Energieeffizienz zu steigern, sollen im Teillastbetrieb freie Ressourcen auf den Embedded-Systemen der Radio-Units zur Ausführung von Anwendungen genutzt werden, die sich auf einem Server befinden.

Bei der Verteilung der Anwendungen sollen Knoten mit niedrigerem Energiebedarf bevorzugt werden. Dadurch verbrauchen die Anwendungen weniger Energie. Durch die Konzentrierung der Anwendungen auf die effizienteren Knoten können weniger effiziente Systeme leergeräumt und abgeschaltet werden.

Die Aufgabe des K8s-Schedulers ist es, einen geeigneten Knoten für eine Anwendung auszuwählen, die aktuell neu installiert oder reorchestriert werden soll. Der Standard-Scheduler in K8s erfüllt diese Aufgabe, indem er nach dem erstbesten Knoten sucht, der die Anforderungen der Anwendung nach Speicher- und Rechenressourcen erfüllt. Dabei werden Aspekte wie Energieeffizienz nicht berücksichtigt.

Der EdgeLimit-Scheduler hingegen bevorzugt Knoten mit dem niedrigsten Energiebedarf. Damit der Scheduler die Energieeffizienz der Knoten beurteilen kann, werden offline ermittelte Parameter als Metadaten an die Knoten angeheftet. Die Leistungsaufnahme abhängig von der CPU-Auslastung wird als linearer Verlauf modelliert, wie es Bild 2 und Bild 3 für das FPGA-SoC und den Intel-Server zeigen.

Die Parameter dieses linearen Verlaufs werden als Metadaten an den Knoten angeheftet. Mithilfe dieser Daten errechnet der EdgeLimit-Scheduler den Leistungsbedarf einer Anwendung entsprechend deren Anforderung nach CPU-Ressourcen. Dann wählt er den Knoten mit dem geringsten Energiebedarf aus, um die Anwendung auszubringen. Dies geschieht, wenn sich im System etwas ändert, also eine Anwendung neu installiert oder verschoben werden soll.

Abläufe bei der Reorchestrierung einer App
Bild 7. Abläufe bei der Reorchestrierung einer App.
© Fraunhofer IIS

Als zentrale Komponente bei der energieeffizienten Orchestrierung dient der Energiemanager. Er agiert als Supervisor für die energieeffiziente Orchestrierung. Wenn sich die Konfiguration der freien Rechenressourcen im Cluster verändert, errechnet er die günstigste Verteilung der Anwendungen und parametriert den EdgeLimit-Scheduler entsprechend, bevor er eine Reorchestrierung anstößt.

Der Energiemanager bietet eine Schnittstelle für externe Akteure. Diese Akteure können Maschinen wie z. B. ein KI-Agent oder ein Managementmodul auf der Radio-Unit sein. Die gleiche Aufgabe kann ein Administrator an der Mensch-Maschine-Schnittstelle übernehmen.

Über diese Schnittstelle empfängt der Energiemanager Anforderungen wie die Anpassung der Anwendungsverteilung an die aktuellen Rechenkapazitäten im Cluster. Je nach Auslastung des Clusters wählt er eine Untermenge oder alle Anwendungen auf dem Edge-Server und veranlasst deren Verteilung auf die freien Ressourcen der Worker-Knoten.

Weiterhin besteht die Möglichkeit, eine Reorchestrierung von außen zu steuern. Dazu stehen verschiedene Funktionen zur Verfügung, zum Beispiel alle belegten Ressourcen auf einem Knoten zu räumen und diesen anschließend für neue Anwendungen zu sperren oder den Knoten herunterzufahren. Es besteht die Möglichkeit, auf einem Knoten mit sofortiger Wirkung keine weiteren Ressourcen mit Anwendungen zu belegen oder umgekehrt auf diese Weise gesperrte Knoten erneut zu öffnen.

Des Weiteren kann ein Knoten über den Energiemanager geregelt herunter- oder hochgefahren werden. Er besitzt einen Treiber für sogenannte Power-Distribution-Units. Über diese Einheiten werden Knoten ein- bzw. physisch ausgeschaltet und sie ermöglichen die Messung des Energieverbrauchs innerhalb des Clusters.

Weitere Aspekte

Stateful- und Stateless-Applikationen
Bei dem Verteilen von Applikationen wird in zwei verschiedene Arten von Apps unterschieden. Applikationen, die ihre Daten über Kommunikationsschnittstellen von Sensoren holen, daraus ein Ergebnis ermitteln und dieses weiterleiten, besitzen in der Regel keinen internen Speicher.Man spricht von Stateless-Applikationen. Diese Art von Anwendungen können jederzeit von einem System auf ein anderes System geschoben werden. Aufwendiger sind Applikationen zu managen, die Daten speichern und diese für weitere Berechnungen benötigen. In diesem Fall muss beim Verschieben der Funktionalität ebenfalls der interne Zustand transferiert werden. Für diese Art von Applikationen stellt Kubernetes entsprechende Ressourcen zur Verfügung.

Energieaufnahme der Kommunikation und Latenz
Eine Verschiebung von Containern zwischen einzelnen Komponenten ändern die Kommunikationsbeziehungen zwischen diesen SW-Komponenten. Dies gilt insbesondere, wenn Container, die auf einem Prozessorsystem liefen, nach der Orchestrierung auf verschiedenen Komponenten arbeiten. Um die Funktion sicherzustellen, muss auf die Latenzvorgaben geachtet werden. Außerdem wurde die zusätzliche Energieaufnahme der Kommunikationsverbindungen zwischen den Komponenten untersucht. Dabei stellte sich heraus, dass sowohl bei Ethernet als auch WLAN der größte Anteil der aufgenommenen elektrischen Leistung für die Aufrechterhaltung der Kommunikation genutzt wird. Der Vorgang der reinen Kommunikation kann von der Leistungsaufnahme im Vergleich zur Rechenleistung in der Regel vernachlässigt werden.

Designregeln
Damit verschiedene Applikationen in Container innerhalb eines verteilten Prozessorsystem orchestriert werden können, müssen beim Design einige Dinge beachtet werden. So spielt die Größe einer Applikation eine wichtige Rolle. Gut eignen sich sogenannte Microservices zur Verteilung. Bei diesem Konzept entsteht eine größere Applikation durch die Zusammenarbeit vieler kleiner Microservices. Der Designer sollte darauf achten, dass möglichst alle Funktionen in einen gemeinsamen Container gepackt werden, die mit niedriger Latenz miteinander kommunizieren sollen. Bei unkritischer Kommunikation können Funktionen jederzeit auf unterschiedliche Embedded-Systeme orchestriert werden. Viele Messungen in diversen Use Cases haben gezeigt, dass die elektrische Leistungsaufnahme einer Kommunikation in der Regel deutlich weniger Energie aufnimmt als die Rechenvorgänge in den Containern.

Technische Umsetzung und Verifikation

Technische Realisierung des verteilten Clusters
Bild 8. Technische Realisierung des verteilten Clusters.
© Fraunhofer IIS

Um die Energieeffizienz der neuartigen energieeffizienten Orchestrierung zu zeigen, wurde ein kleines Testbed aufgebaut. Bild 8 zeigt einen Teil des verteilten Clusters bestehend aus den vier Evaluationsboards für die FPGA-SoCs und einem Raspberry PI, der auf dem Ethernet Switch liegt.

Bild 9 zeigt die Visualisierungsschnittstelle des Energiemanagers. Der Energiemanager verfügt über eine Zeitreihendatenbank, in der die CPU-Auslastung und die Daten zur Leistungsaufnahme der Knoten abgelegt werden und für eine spätere Verwendung jederzeit abgerufen werden können. In der Abbildung sind von oben nach unten die Leistungsaufnahmen der einzelnen Knoten, die CPU-Auslastung derselben und die Gesamtleistungsaufnahme des Clusters aufgetragen.

Visualisierung des Energiemanagers
Bild 9. Visualisierung des Energiemanagers.
© Fraunhofer IIS

Es werden verschiedene typische Zustände des Clusters dargestellt. Zu Beginn vor dem Zeitpunkt t1 befindet sich der Edge-Server im ausgeschalteten Zustand, die Radio-Units arbeiten im Idle-Zustand. In dieser Situation besitzt der Cluster eine Leistungsaufnahme von 28 W.
Zum Zeitpunkt t1 fahren die 4 Radio-Units die RAN-Funktionalität hoch. Das führt zu einer Mehraufnahme an Leistung von ca. 4 W.

Zum Zeitpunkt t2 sollen eine Reihe an MEC-Anwendungen in dem Cluster orchestriert werden. Zu diesem Zeitpunkt existieren keine freien Ressourcen auf den Radio Units. Der EdgeLimit Scheduler erkennt, dass ein Worker-Node heruntergefahren ist. Es handelt sich um den Edge-Server. Mithilfe des Energiemanagers veranlasst der Scheduler, dass der Server hochgefahren wird und bringt die Apps auf diesen Knoten aus. Dieser Betriebszustand verursacht ca. 53 W zusätzlich an Leistungsaufnahme.

Zum Zeitpunkt t3 werden Rechenressourcen auf den Radio Units frei und zum Zeitpunkt t4 erhält der Energiemanager das Signal für die Reorchestrierung der Apps. Daraufhin werden alle Apps von dem Server auf die Radio Units verteilt. Allein dieses Vorgehen führt zu einer geringeren Leistungsaufnahme von circa. 14 W. In dieser Situation sind alle MEC-Apps auf die Radio-Units orchestriert worden. Der Edge-Server befindet sich im Idle-Mode. Wenn die Rechenressourcen des Servers nicht unmittelbar benötigt werden, kann der Server im Zuge der Reorchestrierung heruntergefahren werden. Dies passiert zum Zeitpunkt t5. Nach diesen Maßnahmen pendelt sich die Gesamtleistungsaufnahme auf circa 29 W ein.

An dieser Stelle ist ein Vergleich der Zeitabschnitte vor t1 und nach t5 interessant. Der Unterschied sind die 9 MEC-Anwendungen, die nach t5 auf den Radio-Units verteilt sind und eine Leistungsaufnahme von ca. 1 W produzieren. Die gleichen Anwendungen laufen im Zeitabschnitt zwischen t3 und t4 auf dem Edge-Server und haben eine Leistungsaufnahme von ca. 14 W produziert, dabei ist die Serverbereitschaft, die dafür notwendig geworden ist und ca. 39 W benötigt, noch nicht berücksichtigt.

 

Die Autoren

 

Peter Heusinger vom Fraunhofer IIS
Peter Heusinger vom Fraunhofer IIS
© Fraunhofer IIS

Peter Heusinger
studierte Elektrotechnik an der Friedrich-Alexander-Universität Erlangen. Seit 1988 arbeitete er in verschiedenen Positionen und Themenbereichen beim Fraunhofer Institut für Integrierte Schaltungen. Seine aktuellen Schwerpunkte sind Multi-Access Edge Computing, Security und Sustain- ability.

Zekeriya Mansuroglu vom Fraunhofer IIS
Zekeriya Mansuroglu vom Fraunhofer IIS.
© Fraunhofer IIS

Zekeriya Mansuroglu
studierte Elektrotechnik an der Friedrich-Alexander-Universität Erlangen. Seit 2000 arbeitete er beim Fraunhofer Institut für Integrierte Schaltungen. Sein aktueller Schwerpunkt ist Softwarevirtualisierung in den Bereichen Multi-Access Edge Computing und Sofware Defined Networking.

Michael Wagner vom Fraunhofer IIS
Michael Wagner vom Fraunhofer IIS
© Fraunhofer IIS

Michael Wagner
studierte an der TU München Elektrotechnik mit Abschluss 1988. Danach war er in einem mittelständischen Unternehmen im Bereich Security tätig in der Entwicklung von Hardware, Software und FPGA-Designs. Seit 2001 arbeitet er am Fraunhofer IIS mit den Schwerpunkten Kommunikation, Security, Energieeffizienz und Virtualisierung.


  1. Energieeffiziente Orchestrierung
  2. Energieeffiziente Orchestrierung

Lesen Sie mehr zum Thema


Das könnte Sie auch interessieren

Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Fraunhofer IIS Inst. f. Integrierte Schaltungen

Weitere Artikel zu Embedded

Weitere Artikel zu Echtzeit-/Embedded Software

Weitere Artikel zu Stromversorgung Sonstige

Weitere Artikel zu Embedded-Systeme