
Set-Up und Arbeitsumgebung
Infrastructure

Gruppe C
11/24/2021
Anfängliche Probleme
Ursprünglich war vorgesehen, dass mit lokalen Installationen von Kubeflow und Delta Lake gearbeitet wird und diese zum Ende des Projektes, zu einer produktiven Umgebung in der Cloud zusammengeführt werden. Bei dieser Vorgehensweise haben sich drei Probleme herauskristallisiert:
Durch den hohen Bedarf an Hardwareressourcen führte die lokale Nutzung von Kubeflow zu schlechter Performance. Da mit Kubeflow mehrere Microservices hochgefahren werden, sind die Arbeitsspeicheranforderungen hoch. Zudem ist die Anzahl an CPU-Kerne in unseren Laptops und Desktop PCs unzureichend, für die Vielzahl an Services, die parallel betrieben werden müssen. Kubeflow hat die Möglichkeit auf einer Serverumgebung hochskaliert zu werden, was für unsere Hardware nicht zutrifft. Im Rahmen dieses Projektes kann Kubeflow somit nicht optimal genutzt und ausgereizt werden, weshalb wir uns gegen die Nutzung dieser Plattform entschieden haben.
Delta Lake konnte auf Windows-Systemen nicht zum Laufen gebracht werden, da zum Ausführen von Hadoop eine separate Winutils.exe File benötigt wird. Diese ist über ein Repository eines Drittanbieters zu holen, hat jedoch auf unseren Systemen nicht funktioniert.
Das letzte Problem war die Zusammenführung von Kubeflow und Delta Lake. Da Kubeflow lokal auf einer separaten VM-Instanz läuft, wohingegen Delta Lake auf dem Haupt-Betriebssystem der Maschine läuft. Der 2. Ansatz wäre gewesen, Delta Lake auf die Virtuelle Maschine des Kubeflows aufzusetzen, wurde jedoch aufgrund der unzureichenden Performance verworfen.

Warum nutzen wir die Google Cloud Plattform?
Nach den anfänglichen Hürden, galt es unsere Herangehensweise umzudenken und nach einem neuen Ansatz zu suchen. Um von Anfang an kollaboratives Arbeiten zu ermöglichen, haben wir uns nach einer Cloud-Arbeitsumgebung umgeschaut. Durch die Google Cloud haben wir nicht nur die Möglichkeit verschiedenste Dienste zu nutzen, die uns bei unserem Projekt behilflich werden könnten, sondern haben diese durch die intuitiv bedienbare Web-UI, vereint in einer Plattform-Lösung. Die Nutzung von Cloudservices ist normalerweise mit Gebühren behaftet. Mithilfe von Startguthaben, sowie den vom Prof. Dr. Kirenz zur Verfügung gestellten Credits, können wir die Google Cloud kostenfrei nutzen.
Unsere Virtuelle Maschine
Für unsere Arbeitsumgebung verwenden wir den 'Compute Engine'-Service der Google Cloud Plattform. Dieser Dienst ermöglicht uns die leichte Konfiguration und Aufsetzung einer Virtuellen Maschine.
Im Folgenden listen wir die Spezifikation unserer VM:
Hardware:
- CPU: 4-Kerne
- RAM: 16GB
- Storage: 100GB SSD
Betriebssystem:
- Ubuntu 21.4
Mit dieser Hardwarespezifikation sollte die Leistung unserer Arbeitsumgebung ausreichend für unseren Use Case sein. Durch die Verwendung eines Unix-Betriebssystems, wie Linux Ubuntu, umgehen wir die anfänglichen Probleme, die mit Windows aufgetreten sind. Außerdem ist die Navigation über das Terminal mit Linux gut dokumentiert und somit für uns gut anwendbar.
Unsere Arbeitsumgebung
Nachdem die VM aufgesetzt und hochgefahren wurde, galt es eine kollaborative Arbeitsumgebung für die Gruppe aufzusetzen.
Erster Ansatz
Als ersten Ansatz wollten wir ein Arbeitsverzeichnis im "opt"-Ordner anlegen, worauf jedes Gruppenmitglied mit seinem jeweiligen Linux-User zugreifen kann. Die Umsetzung gestaltete sich jedoch zeitaufwändiger und komplexer als andere Methoden. Dieser Ansatz hat vorgesehen, dass die gesamte Entwicklung in einem zentralen Arbeitsverzeichnis, auf das alle User Zugriff haben, stattfindet. Dafür hätte jeder User für jede Software eine Uservariable anpassen müssen, was uns Probleme bereitete. Ein weiteres Problem eines userübergreifenden Verzeichnisses gestaltete sich vorerst auch in der Rechteverteilung, da gewährleistet werden musste, dass jeder User auf jedem Unterverzeichnis Lese- und Schreibrechte hat. Mit weiterer Recherche hätten wir diese Probleme sicherlich lösen können, jedoch hielten wir es für besser einen anderen, einfacheren Ansatz zu wählen.
Zweiter Ansatz
Als zweiten Ansatz haben wir uns dazu entschieden einen neuen 'mlops'-User zu erstellen, auf den sich jedes Gruppenmitglied anmelden kann. Das bietet den Vorteil, dass Software explizit auf diesen User installiert werden kann, wodurch Konfigurationen und Systemvariablen automatisch für den User gesetzt werden.