Projekte, Abschlussarbeiten

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

Für die Verwaltung von virtuellen Lern- und Lehrumgebungen in bwLehrpool bzw. zunehmend auch für die Nutzung in der Cloud wird eine geeignete Schnittstelle für Lehrende benötigt, die sie als Web-Applikation bedienen können.

Bisher wird für bwLehrpool eine in die Jahre gekommene Java-Applikation eingesetzt, die eine Reihe von Nachteilen hat. Hier ist auf Basis bisheriger Entwicklungen und Erfahrungen diese geeignet in eine Web-Anwendung zu überführen. Hierbei sind die Anforderungen anhand der bisherigen Applikation und der Erwartungen seitens der Lehrenden zu erstellen. Ebenso sollen die erweiterten Möglichkeiten von DaaS/VDI (Cloud-/Remote-Access) in Betracht gezogen werden. Es liegt bereits eine erste Umsetzung einer solchen Web-Anwendung vor, die jedoch diverse Funktionslücken aufweist. Dabei sollen verschiedene Anforderungen analysiert und geeignet umgesetzt werden. Für die Anwendung sollten moderne Web-Frameworks zum Einsatz kommen.

Sinnvolle Vorkenntnisse

Programmiererfahrung, Umgang mit modernen Web-Frameworks, Schnittstellenprogrammierung

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

Für den entfernten Zugriff auf grafische Desktop-Ressourcen wird gegenwärtig ein Access-Gateway entwickelt, welches aus einem Frontend und Backend besteht. Das Backend ermöglicht es, verschiedene Ressourcen, insbesondere die VMs zur Bereitstellung verschiedener Lehr- und Arbeitsumgebungen, mittels QEMU/KVM/libvirt anzusteuern. Diese Ansteuerung geschieht mittels OpenTofu, welches als Eingabe ein beschriebenes Zielbild erwartet und dieses mittels Providern umsetzt. Schrittweise soll die bestehende bwLehrpool-Remote-Lösung (vgl. derzeitige Guacamole-Implementierung) durch das Access-Gateway mit OpenTofu ersetzt werden.

Beispiel-Use-Case: Erzeugen von fünf VMs vom Typ A und 10 VMs vom Typ B im Projekt “Seminar – Einführung Python”.

Ziel der Arbeit ist es, mit den vom Backend gesammelten Angaben (z. B. Anzahl VMs, Typ, Projekt) die Zielinfrastruktur zu erzeugen. Die Arbeit soll dabei verschiedene Use-Cases (z. B. Lehrveranstaltung mit N Teilnehmenden, E-Assessment, individuelles Lernen) betrachten und eine prototypische Umsetzung entwickeln. Die Arbeit findet in Begleitung von laufenden Projekten statt, welche bereits eine Vorarbeit darstellen.

Vorgehen

Die Hypervisor-Unterstützung kann wie folgt realisiert werden:

• Milestone I: Umsetzung eines Prototyps für die Schnittstelle zum Hypervisor.
• Milestone II: Beispielszenario (wie ein Unit-Test) zur Demonstration der Umsetzung.
• Milestone III: Optimierung der Image-Bereitstellung durch NBD.

Sinnvolle Vorkenntnisse

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

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

Für erweiterte Funktionalität für den Desktop-Remote-Zugriff bietet sich SPICE an, welches einerseits ein offenes Protokoll ist (vergleichbar zum proprietären RDP) und andererseits in verschiedenen Client-Implementierungen vorliegt. So existiert seit geraumer Zeit eine Referenzimplementierung für den Desktop, die im Moment im Rahmen eines Projekts für hardware-unterstütztes 3D-Rendering und schnellen Remote-Transport (Video) 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 und anderen Webbasierten Tools einen aktuellen Überblick zu den Möglichkeiten des Videostreamings zu gewinnen. 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 VDI-Projekts auf Basis einer OpenStack Cloud. 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

Programmierkenntnisse Web, grundlegende Netzwerkkenntnisse

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