Projekte, Abschlussarbeiten

Im Zuge mehrerer Infrastrukturentwicklungsprojekte entsteht ein Virtual-Desktop-Infrastructure-Framework (auf Basis von Hypervisor- und Cloud-Umgebungen), welches für verschiedene Anwendungsfälle über ein (oder mehrere) Web-UI(s) erreicht werden soll. Wegen der Vielfalt der Nutzer, ihrer verschiedenen Rollen und davon abgeleiteten Rechten in ihren Einrichtungen soll auf OAuth 2.0/OIDC gesetzt werden, welches im Hintergrund mit Keycloak interagiert.

In diesem Zusammenhang sind verschiedene Fragestellungen zu untersuchen, die von der Auswahl geeigneter Module, der Abbildung bestimmter User-Attribute auf Rechte in der Web-UI und davon abhängige Views auf bestimmte Ressourcen und Informationen, bis zur Arbeit mit Application Tokens für den Zugriff auf andere durch Keycloak verwaltete Ressourcen reichen. Das Web-UI interagiert dabei mit einem Backend (als weitere Komponente des Access Gateways), um bestimmte Funktionen ausführen zu können.

Sinnvolle Vorkenntnisse

Programmiererfahrung, Umgang mit modernen Web-Frameworks, Schnittstellenprogrammierung

Kontakt

Dirk von Suchodoletz

bwLehrpool und weitere Infrastrukturen basieren auf einem im Haus entwickelten Distributed Network Block Device für den Linux-Kernel (DNBD3). Dieses ist bisher nicht Bestandteil des Mainline-Kernels und muss daher regelmäßig nachgezogen werden. Ein Ansatz könnte sein, statt DNBD3 in den Kernel zu bekommen ("Mainlining"), das Block Device in einen Userspace-Client umzubauen, der auf dem ublk-Framework des Kernels aufsetzt.

Damit vereinfachen sich Entwicklung und Portierung deutlich (und die Bindung an bestimmte im Kernel verfügbare Programmiersprachen entfällt). Eine Herausforderung bleibt das Verhalten während des Switch-Roots (Zusammenbau des Root-Filesystems im Init-Prozess vor dem eigentlichen Start). Beispiele für die Umsetzung existieren bereits für QEMU/qcow2.

Aufgabe

Die Aufgabe des Projekts bzw. Arbeit besteht darin, das bestehende DNBD3 in die neue Struktur zu überführen. Hierzu sind entsprechende Vorüberlegungen und Planungen vorzunehmen, bevor eine prototypische Implementierung erfolgen sollte. Am Ende sollte eine Evaluation im Vergleich zur bestehenden Implementierung stehen und die Leistung verglichen werden.

Sinnvolle Vorkenntnisse

Programmierkenntnisse in geeigneten Programmiersprachen; Vertiefte Linux-Kenntnisse; Grundverständnis von Netzwerken

Umfang

• B.Sc.-Projekt oder -Thesis

Kontakt

Dirk von Suchodoletz

bwLehrpool und weitere Infrastrukturen basieren auf einem im Haus entwickelten Distributed Network Block Device für den Linux-Kernel (DNBD3). Dieses ist bisher nicht Bestandteil des Mainline-Kernels und muss daher regelmäßig nachgezogen werden. Inzwischen gab es eine Reihe interessanter Entwicklungen, getrieben beispielsweise durch Kubernetes und Co. (z. B. Longhorn), die alternativ iSCSI einsetzen. Wichtige Features wie Failover und Performance/-Optimierung sind in einer Anforderungsanalyse zusammenzufassen und zu evaluieren. Das Ziel besteht aus diesen Erkenntnissen heraus, die weitere Entwicklung für DNBD3 abzuschätzen, die von einem weiteren Anlauf zum "Mainlining" bis zur Ersetzung durch etablierte Alternativen reichen kann.

Aufgabe

Die Aufgabe des Projekts bzw. Arbeit besteht darin, eine saubere Anforderungsanalyse für die verschiedenen Einsatzszenarien zu erstellen, um darauf aufsetzend eine experimentell untermauerte Evaluation aufzubauen. Dabei sind verschiedene Parameter zu betrachten, die von der Nutzbarkeit über verschiedene Netzwerkinfrastrukturen (unterschiedliche Bandbreiten, Qualitäten, Jitter), den Anpassungsaufwand des Codes, Performance bis zu Ease-of-Use etc. reichen sollten. Am Ende sollte eine Einschätzung bzw. Empfehlung stehen.

Sinnvolle Vorkenntnisse

Programmierkenntnisse Python und C; Vertiefte Linux-Kenntnisse; Grundverständnis von Netzwerken

Umfang

• B.Sc.-Projekt oder -Thesis

Kontakt

Dirk von Suchodoletz

Verschiedene Usecases im Bereich des Full-Desktop Remote-Zugriffs für E-Prüfungsumgebungen in der Cloud, Remote-Visualisierung für HPC, Zugriff auf leistungsfähige Imaging-VM erfordern einen effizienten und je nach Anforderung qualitativ hochwertigen Video-Strom. Hier geht es um Parameter wie Round-Trip-Time (Reaktion auf User-Input), Auflösung, Bandbreite, Bildqualität etc., die sich als "Quality-of-Experience" (QoE) beschreiben lassen.

Für einen schnellen Remote-Zugriff wird ein effizientes Encoding der Desktop-Anzeige benötigt, wozu potenziell Kombinationen aus Hardware (verschiedene Typen Grafikkarten) und einschlägige Video-Libraries (FFmpeg, GStreamer, ...) zum Einsatz kommen. Für den Transport zum Endnutzer werden weitere Kanäle beispielsweise für bidirektionales Audio, den Zugriff auf USB oder Teile des Filesystems oder Security Tokens genutzt, die Bestandteil der Open-Source-Implementierung SPICE sind und auch Einfluss auf die QoE haben können.

Hier gilt es an der für verschiedene Projekte entwickelten aktuellen Implementierung zu untersuchen, welche Parameter sich optimieren lassen, so dass verschiedene Qualitäten der Netzwerkverbindung (Bandbreite, Jitter, Delay; Schwankungen dieser Parameter) zu einem guten (durch den Nutzer beeinflussbares) Ergebnis führen. Diese Thematik wird in Forschung und Praxis, beispielsweise an den verschiedenen VNC-Implementierungen schon länger diskutiert und soll auf SPICE im gegebenen Setup mit der auf Open Stack basierenden bwCloud untersucht werden. Verbesserungspotenziale sind zu ermitteln und zu evaluieren.

Sinnvolle Vorkenntnisse

Umgang mit Video-En-/Decoding(-workflows), Netzwerkkenntnisse, grundlegende Systemkenntnisse Linux (Treiber, Hardware, Bibliotheken, Compiler, ...)

Kontakt

Dirk von Suchodoletz

“Desktop-as-a-Service” (DaaS) bzw. Virtual Desktop Infrastruktur (VDI) ist ein Dienst zur Bereitstellung interaktiver Desktops (VMs) in einer Cloud (z. B. OpenStack) für den Fernzugriff. Etablierte Techniken zur Ressourcenverwaltung (z. B. OpenStack Placement) sind häufig beschränkt auf die Gegenwart. Es gibt bestimmte Use Cases, die eine längerfristige Planung der Ressourcen für VMs (z. B. CPU, RAM, GPU, ...) erfordern, die über das übliche Ad-hoc-Placement von VMs in OpenStack hinausgeht. Für geplante Ressourcen besteht eine Garantie auf deren Verfügbarkeit durch ein Unterbinden von Overbooking. Neben der Planung ist der Scheduler auch in der Lage, bestehende Ressourcenbelegungen zu optimieren, indem VMs zwischen Compute-Nodes verschoben werden.

Aufgabe

Ausgehend von einer bereits durchgeführten Anforderungsanalyse und Konzipierung (siehe Paper unten) soll eine prototypische Entwicklung erfolgen, die eine langfristig planbare Zeitsteuerung der Cloud ermöglicht.
Sie entwickeln einen Scheduler, welcher die folgenden Anforderungen erfüllt:

• Anfragen zur Resservierung von Ressourcen für einen begrenzten Zeitraum werden auf Erfüllbarkeit geprüft und anschließend vorgenommen oder abgelehnt.
  Use Case: Ein Seminar benötigt in drei Wochen 20 VMs vom Typ A. Ihr Scheduler plant die Vergabe dieser Ressourcen, sodass benötigte Ressourcen am Stichtag nicht belegt sind.
• Das Anlegen, Start, Stop, Suspend/Resume und Löschen von VMs, welche durch den Scheduler geplant oder verwaltet sind, kann angeregt werden. Der Erfolg der angeregten Aktion wird überwacht und gegebenenfalls gemeldet.
• Geplante und verwaltete VMs werden zu den Stichtagen bereitgestellt und nach Ablauf des Zeitfensters auch wieder entfernt.
  Use Case: Am Stichtag wird sichergestellt, dass 20 VMs für ein Seminar erzeugt werden können.
  Use Case: Sind nicht ausreichend Ressourcen verfügbar (schlecht), müssen VMs zwischen Compute-Nodes verschoben oder (sehr schlecht!) gelöscht werden.

Green-IT-Scheduling minimiert den Energieverbrauch bei gleichzeitigem Erhalt aller Dienste. Ihr Scheduler ist nach obigem ebenfalls in der Lage:

• Auf Wunsch den Stromverbrauch der Cloud zu minimieren.
  Use Case: Wenn alle VMs von einem Compute-Node weg verschoben werden, kann diese abgeschaltet werden.

Vorgehen

Die Realisierung des oben beschriebenen Scheduler benötigt voraussichtlich eine theoretische Vorarbeit.

• MS I: Analyse der erforderlichen Informationen für den Scheduler.
• MS II: Beispielszenario (wie ein Unit-Test) zur Demonstration der Arbeit des Schedulers.
• MS III: Integration der Scheduler-Implementierung in OpenStack.

Vorangegangene Arbeiten und Weiterführendes

• A Resource-aware Scheduling Concept for an OpenStack-based VDI
• bwCloud usage (OpenStack)
• Knapsack-Problem mit einem multidimensionalen Gewicht (Priority, CPU, RAM, ...), mehreren Knapsacks (Compute-Nodes) und semi-online (due to reservations).

Sinnvolle Vorkenntnisse

Programmierkenntnisse Python; Erfahrungen im Umgang mit REST; Gundverständniss von Cloud und Virtualisierung; Verständnis von Algorithmen

Kontakt

Dirk von Suchodoletz

Verschiedene Usecases erfordern einen effizienten und performanten Remote-Zugriff auf komplette Desktop-Umgebungen (GUI mit teilweise hohen Auflösungen, in denen 3D-beschleunigte Inhalte etc. angezeigt werden), die über die Möglichkeiten von beispielweise Xvnc, Xpra etc. hinausgehen.

Für den Remote-Zugriff soll SPICE zum Einsatz kommen, welches geeignet den Framebuffer der lokalen Grafikkarte abgreift und diesen für den Remote-Transport in ein effizientes Encoding der Desktop-Anzeige schiebt. Hierzu sollen entsprechende Kombinationen aus Hardware (verschiedene Eigenschaften der Grafikkarten für Rendering und Video-Encoding) und einschlägige Video-Libraries (FFmpeg, GStreamer, ...) zum Einsatz kommen. Mit SPICE liegen die für den Transport zum entfernten Endnutzer benötigten weitere Kanäle beispielsweise für bidirektionales Audio, den Zugriff auf USB oder Teile des Filesystems oder Security-Tokens bereits vor. Es gibt Vorarbeiten für den Zugriff auf den Framebuffer in QEMU/KVM-Szenarien in Kombination mit bestimmter Grafikhardware, auf die zurückgegriffen werden kann.

Sinnvolle Vorkenntnisse

Systemkenntnisse Linux (Treiber, Hardware, Bibliotheken, C-Compiler, ...), Programmierkenntnisse C/C++, Umgang mit Video-En-/Decoding(-workflows), grundlegende Netzwerkkenntnisse

Kontakt

Dirk von Suchodoletz

The trend towards cloud-based solutions is accelerating, affecting desktop PCs as well, which will be offered as a remote desktop VM. A service providing these remote desktop VMs is called Virtual Desktop Infrastructure (VDI). A remote access protocol (RAP) (e.g., SPICE) handles the interaction between a user (remote client) and the VM (remote server). The RAP is designed to be as close to the local desktop PC behavior and experience as possible. However, changes in the network environments, VM usage, or different hardware may lead to a non-optimal RAP usage. Implementing remote access quality management (RAQM) improves a remote session to be more resilient, performant, and of a higher quality.

Task

The student has to implement a RAQM by

• defining a protocol for exchanging relevant features between a remote client and remote server
• and evaluate incoming information, to improve the remote session.

Approach

Using the SPICE protocol as a RAP, the features of RAQM are sparsely supported. Even features supported by SPICE addressing this are not working by default.

• Milestone I: A RAQM protocol and client-server implementations are available.
• Milestone II: A remote server updated the settings of an existing SPICE session.
• Milestone III: The remote client displays messages/updated setting received by the remote server.

Useful previous knowledge

Network protocols like SPICE, TCP, REST; Network sockets; Programming languages like Python, C

Kontakt

Dirk von Suchodoletz

The trend for cloud solutions is going on and affects also desktop PCs, which can be replaced by a remote desktop VM. This VM remote access aims to come as close as possible to the local desktop PC behavior and experience. The list of existing and relevant remote access protocols and techniques (e.g., SPICE, RDP, VNC, ICA) is comparably short. One major difference between these techniques is the lossy transmission of the graphical desktop content as a picture or video stream from the VM to the end user’s client device. Image compressions, update frequencies, and network latencies are examples of parameters influencing the video stream received at a client.

Task

What video stream, recorded at the client, is closer to the original, from a human perspective?
The student should solve the problem stated above, by providing

• different test environments, each creating a reproducible behavior and video stream, and
• a tool, measuring the similarity between two video streams (e.g., VMAF).

Approach

• Milestone I: A basic setup for a remote access protocol measurement exists, e.g.:

1. Create and prepare a VM (with GPU passthrough) and a remote client.
2. On the VM, create some (GPU-demanding) changes in the graphical content.
3. Connect the remote client to the remote server.
4. Record these changes during timeframe T on the VM (ground truth) and on the remote client.
5. Compute a similarity score between these two video streams.

• Milestone II: The task of comparing a video with its video streams is complex and (may) be delegated to a Machine Learning (ML) model. The student has therefore researched about existing pre-learned models, now adapted for this use case.

• Milestone III: Variable features in the test environment are eliminated, allowing reproducible tests.

Useful previous knowledge

Network protocols like SPICE, TCP; Programming languages like Python, C; ML basics

Kontakt

Dirk von Suchodoletz

Mobile Geräte wie Tablets werden zunehmend in verschiedenen Konstellationen als kompakte nutzerseitige Clients für den Zugriff auf diverse Online-Ressourcen eingesetzt. Das zeigt die Verfügbarkeit diverser entsprechender VDI-Clients (Remote-Desktop-Zugriff) für iOS und Android. Für iOS fehlt bisher jedoch ein Client (was auch dem restriktiven Plattform- und Business-Modell geschuldet ist). Da SPICE ein offenes Protokoll ist (in den Funktionen vergleichbar zu RDP) und verschiedene Client-Implementierungen sowohl für SPICE als auch für andere Remote-Desktop-Zugriffsprotokolle vorliegen, sollte sich auf dieser Basis eine IOS-Implementierung realisieren lassen.

Aufgabe des Projektes ist es, ausgehend von diversen vorliegenden Desktop-Clients, eine Umsetzung mit performantem Videostreaming und Unterstützung weiterer Interaktionskanäle (Zugriff auf Verzeichnisse, USB, bidirektionales Audio, 2FA) zu planen. Das sollte auf Basis vorliegender Codes prototypisch umgesetzt werden. Grundlage sind zudem die Entwicklungen für den Remote Access im Rahmen des laufenden VDI-Projekts. Das würde die Einsetzbarkeit um eine Reihe populärer Endgeräte ergänzen.

Sinnvolle Vorkenntnisse

iOS-App-Programmierung

Kontakt

Dirk von Suchodoletz

Für die Anforderungen eines Desktop-Remote-Zugriffs mit diversen Funktionalitäten bietet sich SPICE an, welches einerseits ein offenes Protokoll ist (in den Funktionen vergleichbar zu RDP) und andererseits in verschiedenen Client-Implementierungen vorliegt. So existiert seit geraumer Zeit eine Referenzimplementierung für den Desktop, die im  Rahmen eines Projekts für hardware-unterstütztes 3D-Rendering und schnellen Remote-Transport (Video) erheblich aktualisiert und ausgebaut wird. Von der ursprünglichen Version abgeleitet, gibt es Varianten für die Nutzung im Browser wie EyeOS oder als Option in Guacamole. Leider sind die Entwicklungen teilweise 10 Jahre alt und unterstützen kein Video-Streaming.

Aufgabe der Arbeit ist es, ausgehend von Vorarbeiten im Desktop-Client, ersten Anpassungen im Web-Client und anderen webbasierten Tools die Möglichkeiten performanten Videostreamings und die Unterstützung weiterer Interaktionskanäle (Zugriff auf Verzeichnisse, USB, bidirektionales Audio, 2FA) auszuloten. Dabei soll auf Basis vorliegender Codes eine Weiterentwicklung vorgeschlagen und prototypisch umgesetzt werden. Basis sind die Entwicklungen für den Remote Access im Rahmen des laufenden VDI-Projekts. Das würde die Einsetzbarkeit des Systems um eine Reihe weiterer Endgeräte ergänzen und dabei zusätzliche Kanäle, wie beispielsweise bidirektionales Audio, USB-Zugriff, Zugriff auf Drucker oder Homeverzeichnisse schaffen, was das jetzige System in bwLehrpool (Remote Access) noch nicht bietet.

Sinnvolle Vorkenntnisse

(Web-)Programmierung, Netzwerkgrundkenntnisse

Kontakt

Dirk von Suchodoletz

Das Rechenzentrum betreibt bwLehrpool als Grundlage für PC-Pools und Digital Signage (elektronische Türschilder, Info-Displays) in unterschiedlichen Varianten. Diese Umgebung ist derzeit X86-zentriert. Für eine Reihe einfacherer Einsatzgebiete, wie Recherche-Terminals, el. Türschilder, Kiosk-Systeme, wäre die ARM-Architektur eine attraktive Alternative, insbesondere, da eine große Auswahl an Hardware in Form sog. Single Board Computer (SBC) zur Auswahl steht. Moderne Boot-Methoden erlauben zunehmend das Laden initialer Betriebssystembestandteile via HTTP(S), was eine sinnvolle Alternative zum klassischen (i)PXE-Boot sein könnte. Das U-Boot ist hier ein klassischer Ansatz im Bereich der SBC.

Im Projekt wäre zu analysieren, welche Komponenten wie angepasst bzw. geändert werden müssen, so dass auf der bestehenden Code-Basis eine funktionierende Boot-Umgebung sowohl für X86 als auch ARM erzeugt werden kann. Hierbei spielen die Virtualisierung und virtuelle Lehr- und Lernumgebungen eine nachgelagerte Rolle, Container-Support sollte betrachtet werden. Die Generierung und Bereitstellung der Umgebung würde auf Basis der bisherigen X86-Server-Infrastruktur erfolgen. Der Fokus liegt primär auf alternativer Client-Hardware (am Beispiel eines Raspberry Pi 4/5), die sich möglichst nahtlos in die bestehende Landschaft integrieren lassen sollte.

Sinnvolle Vorkenntnisse

Weitergehende Betriebssystemkenntnisse, Programmierkenntnisse, Cross-Plattform-Entwicklung

Kontakt

Dirk von Suchodoletz

Software and system testing is still a major issue in certain scenarios. Especially if (semi-)automated update procedures are deployed on complex software stacks (like desktop operating system with a plethora of installed applications and dependencies or HPC environments with complex software stacks for different science domains), a verification of proper execution of tasks would be very helpful to evaluate the result. Modern project development environments like GitLab or GitHub allow to integrate "Continuous Integration", "Continuous Development" workflows.

This would be desirable for automated setups of operating systems (like scripted installation of Linux plus additional applications with Ansible or Packer). Implicit software updates take place, which might break required workflows or applications. Virtualization encapsulates such software stacks and makes them easier to operate compared to physical machines (start, stop, suspend/resume, checkpointing, ...).

For ongoing research and development projects of the eScience department, solutions on continuous integration (CI) are sought after. This project should look for usable approaches to system and unit testing of service environments (e.g., running in virtualization or containers). This is to be integrated into development frameworks like GitLab for demonstration and evaluation purposes.

Desirable/Required knowledge

Linux, Operating Systems, Virtualization, Development & Testing

Contact

Dirk von Suchodoletz

Das Rechenzentrum betreibt verschiedene Scientific- und High-Performance-Computing-Systeme mit insgesamt deutlich über 1000 Knoten und entsprechendem Energiebedarf. Auf diesen Systemen rechnen sehr verschiedene Forschungsgruppen mit unterschiedlicher Software auf Basis verschiedener Programmiersprachen (so ist beispielsweise Python deutlich ineffizienter in der Code-Ausführung als C/C++/Rust). Die Forschenden sind dabei nicht zwingend Experten in der Optimierung der jeweiligen Problembearbeitung. Es gibt viele Ansätze zu einer besseren Effizienz zu kommen, die teilweise jedoch recht aufwändig sein können. In dieser Arbeit geht es deshalb darum, bezogen auf die gegebenen Umgebungen einen Überblick zu gewinnen, welche Optimierungspotenziale generell bestehen, und anhand der gegebenen Jobs und der genutzten Software eine erste Prioritätenliste zur Verbesserung der Effizienz zu erstellen.

Erforderliche Kenntnisse

Linux, Systemmonitoring, Programmierkenntnisse

Kontakt

Dirk von Suchodoletz

Am Rechenzentrum werden Dienste und Infrastrukturen für das Forschungsdatenmanagement angeboten, die zunehmend von den unterschiedlichsten Fachdisziplinen nachgefragt werden. Je nach Fachkultur unterscheiden sich die Anforderungen erheblich, so dass es nicht eine Plattform für alle Bedürfnisse gibt. Während erste Angebote Dienste wie abgesicherte SMB/NFS-Bereiche bereitstellen, gibt es mit GitLab eine Plattform zum Versionieren und Teilen von Daten und Code und mit InvenioRDM eine Datenpublikationsplattform. Damit sind jedoch nur Teile der Bedürfnisse der Forschenden bedient.

Aufgabe dieser Arbeit ist es, geeignete Kandidaten an Software bzw. Frameworks zu evaluieren, die einen Teil der Anforderungen, wie Open Source, S3-Backend, Nutzbarkeit via Web-interface, Benutzerverwaltung durch Anbindung an LDAP/AD, oder besser OAuth/OIDC, Möglichkeit zum Teilen von Daten mit Nutzern/Gruppen oder per WWW, umsetzen. Weitere zu untersuchende Punkte wären Cross-Plattform-CLI-Client-Software (zum Transfer größerer Datenmengen) oder die optionale Verfügbarkeit eines GUI-Clienten (wobei Webinterface + CLI + API ausreichen). Für bestimmte Anforderungen könnten Fuse-Implementierungen von Vorteil sein. Weitere Kriterien wären die Einfachheit der Benutzung, Zuverlässigkeit, Skalierbarkeit, Performanz und, ob sich die Software in aktiver Entwicklung befindet und über eine größere Gemeinde verfügt. In Frage kommen die folgenden Tools (wobei eigene Recherchen diese Liste ergänzen können):

• girder, girder-demo
• lakeFS, lakeFS-demo
• stripped down Nextcloud/ownCloud

Erforderliche Kenntnisse

Grundlegende Programmierkenntnisse, Umgang mit verschiedenen Softwareumgebungen/OS, evtl. Erfahrungen mit Containerisierung etc.

Kontakt

Dirk von Suchodoletz

Das Rechenzentrum betreibt die zentralen IT-Infrastrukturen für den Campus der Universität. Zu diesen zählen die bw- und de.NBI Cloud, die zusammen mit über weit 100 Compute-Knoten zum Hosten von Virtuellen Maschinen u. a. für das wissenschaftliche Rechnen dienen. Wegen der Energiekrise und ökologischen Anforderungen besteht das Ziel, den Betrieb dieser Infrastruktur zu optimieren, ohne dass sich dabei für Nutzende (erhebliche) Leistungseinbußen bemerkbar machen.

Hierzu soll ausgehend von der Nutzung der Rest-API bzw. des CLI für die Steuerung der Cloud zum Starten, Stoppen, Verschieben, Einfrieren und Wiederauftauen von virtuellen Maschinen untersucht werden, wie sich hier eine Optimierung vornehmen lässt. Ein möglicher Input könnte das Lastmonitoring der Compute-Hosts sein, um festzustellen, ob die Menge der laufenden Systeme auf insgesamt weniger Maschinen konsolidiert werden kann und der Rest dann abgeschaltet würde. Hierfür wäre zu untersuchen, wie gut sich aus vorliegenden Informationen Pläne für die Verschiebung erstellen lassen. Ebenfalls wäre zu überlegen, ob man eine generelle "Nachtabsenkung" für einen bestimmte Typ von VMs vornimmt (die beispielsweise Dienste bereitstellen, die nur im Laufe des Tages nachgefragt werden, wie BBB). Dabei wäre anhand einer prototypischen Implementierung zu evaluieren, wie hoch der Aufwand der jeweils einzelnen Schritte der API-Steuerung ist und wie zuverlässig die Aktionen ablaufen. Daraus sollte dann eine generelle Abschätzung von Einsparpotenzialen erfolgen.

Sinnvolle Vorkenntnisse

Grundsätzliche Erfahrung im Umgang mit Cloud-Systemen, virtuellen Maschinen; Programmierkenntnisse, sinnvollerweise Plattformkenntnisse Linux

Kontakt

Dirk von Suchodoletz