Installation und Support von GPUs

GPU-Ressourcen werden in SPARCI als vGPU einer virtuellen Maschine zugewiesen. Diese Zuweisung kann nur durch die SPARCI-Administration erfolgen. Für neue GPU-VMs steht das offizielle Template Ubuntu 22.04 LTS vGPU - GRID 550.54.15 bereit. Es enthält bereits den kompatiblen GRID-Gasttreiber, die vGPU-Lizenzkonfiguration, CUDA Toolkit 12.4 und das NVIDIA Container Toolkit. Diese Komponenten müssen bei Verwendung des Templates nicht erneut installiert werden.

GPU-VM beantragen und vorbereiten

GPU-Hosts sollen nur für Workloads verwendet werden, die tatsächlich eine GPU benötigen, zum Beispiel Training, Inferenz oder GPU-beschleunigte Datenverarbeitung. Reine CPU-Workloads sollten normalerweise auf CPU-Instanzen laufen, auch wenn einzelne Programme von höherem CPU-Takt profitieren. GPU-Hosts sind knapp und eine VM ohne GPU-Zuweisung kann dort Ressourcen blockieren, die für GPU-Workloads benötigt werden.

Wählen Sie GPU-Offerings nur für VMs aus, für die tatsächlich eine GPU beantragt und durch die Administration zugewiesen werden soll. Ein GPU-Offering ohne korrekt zugewiesene vGPU hilft dem Workload nicht, kann aber GPU-nahe Ressourcen blockieren und die spätere Platzierung erschweren.

Der typische Ablauf für eine GPU-VM ist:

1. Erstellen Sie die VM in CloudStack aus Ubuntu 22.04 LTS vGPU - GRID 550.54.15 und wählen Sie ausreichend CPU, RAM und Storage für den geplanten Workload.
2. Fahren Sie die VM herunter, falls die Administration dies für die vGPU-Zuweisung anfordert.
3. Stellen Sie eine Anfrage an die Cloud-Administration und nennen Sie VM-Name, Forschungsgruppe, geplanten Zweck, Zeitraum und den ungefähren GPU-Speicherbedarf.
4. Warten Sie auf die Bestätigung, dass eine vGPU zugewiesen wurde und die VM auf einem passenden GPU-Host läuft.
5. Prüfen Sie in der VM mit nvidia-smi den Treiber- und Lizenzstatus. Installieren Sie den GRID-Treiber, CUDA und das NVIDIA Container Toolkit nicht erneut. Installieren und konfigurieren Sie nur noch die benötigte Anwendungssoftware beziehungsweise eine Container-Engine wie Docker.

GPU-Kapazität ist knapp und wird manuell koordiniert. Wenn eine GPU vorübergehend nicht benötigt wird, kann sie durch die Administration von der VM gelöst und für andere Gruppen freigegeben werden. Geben Sie in diesem Fall an, ab wann Sie die GPU voraussichtlich wieder benötigen. Für die Reaktivierung oder den Wechsel auf eine andere GPU kann ein kontrolliertes Herunterfahren der VM erforderlich sein.

Die verfügbare GPU-Klasse hängt von der aktuellen Belegung ab. Es kann vorkommen, dass eine gewünschte 40-GB-GPU nicht kurzfristig verfügbar ist, aber eine andere GPU-Klasse oder ein kleineres vGPU-Profil angeboten werden kann. Prüfen Sie vor längeren Trainingsläufen den realen VRAM-Bedarf Ihrer Modelle. Ein Workload, der auf einer 40-GB-GPU läuft, kann auf einem 20-GB-Profil mit CUDA-Out-of-Memory abbrechen, auch wenn die GPU rechnerisch schneller ist.

GPU-Zuweisungen sind außerdem an Standort, Host und Netzwerksegment gebunden. GPUs aus einem anderen Rechenzentrum oder einer anderen CloudStack-Instanz können nicht ohne Weiteres an eine bestehende VM in einem anderen Netz gehängt werden. Falls ein Workload auf neue Hardware in einem anderen Rechenzentrum wechseln soll, muss in der Regel eine neue VM dort erstellt und die Daten müssen über Snapshot, Template, Backup oder Kopie migriert werden.

Nach Wartungsarbeiten, Host-Problemen, Stop/Start-Vorgängen, Disk-Änderungen oder Skalierungen kann es notwendig sein, dass die Cloud-Administration eine GPU-VM kontrolliert stoppt und wieder startet. Das ist insbesondere dann relevant, wenn eine VM auf dem Host starten muss, auf dem die zugewiesene vGPU physisch verfügbar ist. Fehlermeldungen wie No suitable host found bei GPU-VMs sind deshalb häufig ein Hinweis auf Host-Platzierung oder reservierte GPU-Ressourcen und sollten an die Cloud-Administration gemeldet werden.

GPU-Zuweisung prüfen

Nach der administrativen Zuweisung erscheint die vGPU innerhalb der VM als PCI-Gerät. Eine erste Prüfung ist daher auch möglich, bevor der NVIDIA-Treiber vollständig funktioniert:

lspci | grep -i nvidia

Wenn hier ein NVIDIA-Gerät sichtbar ist, wurde der VM grundsätzlich eine GPU beziehungsweise vGPU durchgereicht. Für die eigentliche Nutzung durch CUDA, ML-Frameworks oder Container reicht das allein aber nicht aus. Mit dem vorbereiteten GPU-Template muss zusätzlich nvidia-smi funktionieren:

nvidia-smi

Wenn lspci ein NVIDIA-Gerät zeigt, nvidia-smi aber fehlschlägt, liegt das Problem meistens in Treiberinstallation, Kernel-Modulen, vGPU-Lizenzierung oder CUDA-Kompatibilität innerhalb der VM. Wenn bereits lspci keine NVIDIA-Hardware zeigt, sollte die GPU-Zuweisung und Host-Platzierung durch die Cloud-Administration geprüft werden.

Support bei GPU-Problemen

Cloud-Administrator:innen können GPU-Probleme nur aus Sicht der Infrastruktur prüfen. Dazu gehört insbesondere:

• ob die GPU-Zuweisung in CloudStack korrekt erfolgt ist
• ob die VM auf einem Host gestartet wurde, auf dem die angeforderte GPU physisch vorhanden ist
• ob die Treiberversion auf dem physischen Host zur empfohlenen Treiberversion in der VM passt

Cloud-Administrator:innen haben grundsätzlich keinen regulären Zugang zu Nutzer-VMs. Die offiziellen Templates enthalten lediglich für absolute Notfälle einen administrativen Benutzer sparci. Dieser Ausnahmezugang soll im Normalbetrieb niemals genutzt werden und ist ausdrücklich kein Supportzugang. Die Cloud-Administration verwendet ihn nicht zur laufenden Verwaltung, Treiberinstallation, Softwarepflege oder zum Debugging einzelner Nutzer-VMs.

Nicht durch die Cloud-Administration abgedeckt sind daher insbesondere:

• Fehler in der Betriebssystemauswahl oder der VM-Konfiguration
• fehlerhafte oder unvollständige Treiberinstallationen innerhalb der VM
• Probleme in CUDA-, Python- oder anderen Software-Stacks der Nutzer:innen
• allgemeines Debugging von Nutzer-VMs

Die SPARCI-Cloud wird auf eigene Verantwortung genutzt. Wenn Infrastrukturfehler ausgeschlossen werden können, müssen Fehler innerhalb der VM grundsätzlich von den Nutzer:innen selbst behoben werden. Auch enge Deadlines ändern diese Zuständigkeit nicht.

Manuelle NVIDIA-Treiberinstallation bei anderen Templates

Für die Installation ist eine CUDA-fähige Grafikkarte, wie etwa NVIDIA A100 oder H100, erforderlich. Zudem wird der GRID-Treiber benötigt, welcher hier heruntergeladen werden kann.

Installieren Sie nicht blind einen generischen NVIDIA-Treiber aus Ubuntu-Paketquellen oder von der öffentlichen NVIDIA-Downloadseite. Für vGPU-Setups muss die Treiberversion in der VM zur vGPU-Software auf dem physischen Host passen. Verwenden Sie daher den hier verlinkten SPARCI-GRID-Treiber beziehungsweise die von der Cloud-Administration genannte Version.

Nach Kernel-Updates, Ubuntu-Upgrades oder Änderungen an der vGPU-Hostsoftware kann eine neuere GRID-Treiberversion erforderlich sein. Prüfen Sie nach jeder Treiberinstallation mit nvidia-smi, ob die GPU erkannt wird und ob Treiber- und CUDA-Kompatibilität zum geplanten Workload passen.

Sofern auf der virtuellen Maschine noch CUDA- und NVIDIA-Pakete vorhanden sind, sollten diese System entfernt und die VM neu gestartet werden:

sudo apt-get purge 'cuda-*' -y
sudo apt-get purge 'nvidia-*' -y
sudo apt autoremove
sudo reboot

Ansonsten kann der heruntergeladene Grid-Treiber direkt installiert werden; Bei Ubuntu Maschinen ist die Installation von einigen Ubuntu-Tools jedoch erforderlich:

sudo apt install build-essential
chmod +x NVIDIA-Linux-<Driver Version>-grid.run
sudo  ./NVIDIA-Linux-<Driver Version>-grid.run
sudo reboot

Nach der Neuinstallation kann die erfolgreiche Installation mit dem Befehl nvidia-smi überprüft werden. Es sollten eine Statusmeldung ähnlich der folgenden angezeigt werden:

+-----------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.15    Driver Version: 550.54.15    CUDA Version: 12.4     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|

Im nächsten Schritt muss nun die vGPU lizenziert werden, dazu muss folgender token heruntergeladen und in den nvidia-grid Systemordner verschoben werden:

sudo -i
cd /etc/nvidia/ClientConfigToken
wget -O token.tok "https://cloud.uni-koblenz.de/public.php/dav/files/tRsfqMqgSEL47GT"
systemctl restart nvidia-gridd

Es kann einige Minuten dauern bis die Lizenz vom Nvidia-Lizenzserver abgerufen wurde. Mittels sudo nvidia-smi -q | grep License lässt sich der Status der Lizenzierung abfragen:

    vGPU Software Licensed Product
        License Status                    : Licensed (Expiry: 2023-11-14 10:22:34 GMT)

Zu beachten ist, dass die Lizenz jeden Tag erneuert wird, bis zum endgültigen Ablaufdatum vom 23.11.2026!

vGPU-Lizenzierung und Client-Konfiguration

Die administrative vGPU-Zuweisung in CloudStack und die Nutzbarkeit der vGPU innerhalb der VM sind zwei getrennte Schritte. Die Cloud-Administration weist die vGPU zu und stellt die passende Host-Seite bereit. Im offiziellen GPU-Template sind GRID-Treiber und vGPU-Lizenzclient bereits eingerichtet; nach der Zuweisung müssen Nutzer:innen nur prüfen, ob die Lizenz erfolgreich bezogen wird. Bei anderen Templates müssen Nutzer:innen die gesamte Gast-Konfiguration selbst bereitstellen und pflegen.

Typische Hinweise auf fehlende oder fehlerhafte Gast-Konfiguration sind:

• lspci zeigt NVIDIA-Hardware, aber nvidia-smi meldet Fehler
• CUDA-Anwendungen brechen bei der Initialisierung ab
• sudo nvidia-smi -q | grep License zeigt keinen lizenzierten Zustand
• nach Kernel- oder Treiberupdates funktioniert die GPU nicht mehr, obwohl sie weiterhin als PCI-Gerät sichtbar ist

Prüfen Sie in diesem Fall die Treiberversion, den Lizenz-Token im Verzeichnis /etc/nvidia/ClientConfigToken, den Dienst nvidia-gridd und die Ausgabe von nvidia-smi. Wenn unklar ist, welche GRID-Version oder welcher Lizenz-Token aktuell verwendet werden soll, fragen Sie die Cloud-Administration. Die Installation und Reparatur innerhalb der VM bleibt Aufgabe der Nutzer:innen.

Installation CUDA

Im offiziellen GPU-Template ist CUDA Toolkit 12.4 bereits installiert. Dort darf die folgende manuelle Installationsanleitung nicht erneut ausgeführt werden. Die vorhandene Installation lässt sich prüfen mit:

nvcc --version

Die folgenden Schritte gelten für andere, bewusst selbst verwaltete Templates. Auswahl, Installation und dauerhafte Kompatibilität liegen dabei vollständig in der Verantwortung der Nutzer:innen. Vermeiden Sie Pakete wie nvidia-driver-*, cuda-drivers oder CUDA-Metapakete, die einen eigenen NVIDIA-Treiber nachziehen und dadurch den GRID-Treiber überschreiben können. Auch sudo apt-get install nvidia-cuda-dev kann unerwünschte Abhängigkeiten installieren.

Planen Sie für GPU-VMs ausreichend Arbeitsspeicher ein. ML-Frameworks, Dataloader, CUDA-Toolkits und Container benötigen zusätzlich zum VRAM auch normalen RAM. Zu wenig RAM kann Trainingsjobs verlangsamen, zu Swap-Druck führen oder Prozesse abbrechen lassen.

Gehen Sie für eine manuelle Installation wie folgt vor:

1. Prüfen Sie zunächst den installierten und funktionsfähigen GRID-Treiber:

   bash nvidia-smi

   Die CUDA-Toolkit-Version muss mit diesem Treiber kompatibel sein. Für die aktuell vorbereitete Kombination aus GRID-Gasttreiber 550.54.15 und Ubuntu 22.04 wird CUDA Toolkit 12.4 verwendet. Die allgemeinen Kompatibilitätsregeln stehen in der NVIDIA-Dokumentation.

2. Laden Sie das passende CUDA Toolkit aus dem CUDA Toolkit Archive herunter. Für die Auswahl gelten typischerweise:

   • Operating System: Linux
   • Architecture: mit lscpu ermitteln
   • Distribution und Version: mit lsb_release -a ermitteln
   • Installer Type: runfile (local)

3. Machen Sie die heruntergeladene Runfile ausführbar und installieren Sie ausschließlich das Toolkit. Der in der Runfile enthaltene NVIDIA-Treiber muss im Installationsdialog unbedingt abgewählt werden, damit der GRID-Treiber erhalten bleibt:

   bash chmod 744 cuda_<CUDA-Version>_<Installer-Version>_linux.run sudo sh cuda_<CUDA-Version>_<Installer-Version>_linux.run \ --override \ --librarypath=/usr/local/cuda-<CUDA-Version>

4. Ergänzen Sie bei Bedarf die Umgebungsvariablen, zum Beispiel in ~/.profile:

   bash export PATH="/usr/local/cuda/bin:$PATH" export LD_LIBRARY_PATH="/usr/local/cuda/lib64:$LD_LIBRARY_PATH"

   Laden Sie die Konfiguration danach neu und prüfen Sie die Installation:

   bash source ~/.profile nvcc --version

NVIDIA Container Toolkit

Im offiziellen GPU-Template ist auch das NVIDIA Container Toolkit bereits installiert. Prüfen Sie es mit:

nvidia-ctk --version

Eine Container-Engine wie Docker ist nicht Teil des Templates. Sie muss bei Bedarf von den Nutzer:innen installiert und anschließend entsprechend der offiziellen NVIDIA-Anleitung für die GPU-Nutzung konfiguriert werden. Bei anderen Templates muss zusätzlich das NVIDIA Container Toolkit nach dieser Anleitung installiert werden. Prüfen Sie zuerst, ob nvidia-smi direkt in der VM funktioniert, und testen Sie erst danach die GPU-Weitergabe an einen Container.

Häufige Probleme

• Die GPU-VM startet nach Stop, Resize oder Disk-Änderung nicht mehr

  • Grund kann sein, dass die VM auf einem bestimmten GPU-Host starten muss, auf dem die zugewiesene vGPU verfügbar oder reserviert ist.
  • Lösung: Melden Sie den Fehler mit VM-Name und Fehlermeldung an die Cloud-Administration. Starten, Host-Platzierung und vGPU-Zuweisung müssen in solchen Fällen häufig administrativ korrigiert werden.

• Die zuvor funktionierende GPU wird nicht mehr erkannt

  • Grund kann ein Update des Kernels des Servers sein (z.B. durch apt upgrade)
  • Lösung: Prüfen Sie zuerst uname -r, nvidia-smi und den Lizenzstatus. Überschreiben Sie den GRID-Treiber nicht durch eine generische Neuinstallation. Bei einer VM aus dem offiziellen GPU-Template ist eine Neuerstellung aus dem Template häufig der sicherere Weg; sichern Sie vorher alle relevanten Daten. Melden Sie einen möglichen Konflikt zwischen Gast- und Hosttreiber an die Cloud-Administration.

• CUDA-Out-of-Memory auf kleinerem vGPU-Profil

  • Grund ist, dass der verfügbare GPU-Speicher des zugewiesenen Profils nicht ausreicht. Eine schnellere GPU mit weniger VRAM kann für große Modelle schlechter geeignet sein als eine langsamere GPU mit mehr VRAM.
  • Lösung: Reduzieren Sie Batch Size, Modellgröße oder Speicherverbrauch des Workloads oder fragen Sie rechtzeitig ein größeres vGPU-Profil an. Die Zuweisung hängt von der aktuellen Verfügbarkeit ab.

• Docker-Container sehen die GPU nicht

  • Grund ist häufig, dass Docker zwar in der VM läuft, die GPU aber nicht an Container weitergereicht wird.
  • Lösung: Im offiziellen GPU-Template ist das NVIDIA Container Toolkit bereits installiert, eine Container-Engine jedoch nicht. Installieren und konfigurieren Sie Docker oder eine andere unterstützte Container-Engine nach der offiziellen NVIDIA-Dokumentation: https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html. Bei anderen Templates müssen Sie auch das NVIDIA Container Toolkit selbst installieren.