cloudscaleKnowledge Base

Die Scratch Disk befindet sich direkt im gleichen physischen Host, wo auch der virtuelle GPU-Server läuft, um so minimale Latenz und maximale Performance zu gewährleisten. Dies im Gegensatz zu den normalen NVMe-SSD- und Bulk-Volumes, die sich in unseren Storage-Clustern befinden und damit von allen Compute-Hosts aus erreichbar sind, durch den Zugriff via Netzwerk jedoch eine spürbar höhere Latenz aufweisen.

Beim Skalieren von GPU-Servern und bei Wartungsarbeiten durch uns kann der Inhalt der Scratch Disk – zusammen mit dem zugehörigen, ausgeschalteten GPU-Server – auf andere Hardware migriert werden, was allerdings einige Zeit in Anspruch nimmt. Im Übrigen ist die Scratch Disk an den jeweiligen GPU-Server gebunden und kann nicht von diesem getrennt, an einen anderen Server angeschlossen oder unabhängig vom Server weiter aufbewahrt werden.

Es ist jedoch möglich, ein normales NVMe-SSD-Volume an einen GPU-Server anzuschliessen. Dieses kann, wenn der GPU-Server gelöscht wird, lose im jeweiligen Projekt bestehen bleiben und an einen anderen bzw. künftigen Server wieder angeschlossen werden. Je nach Anwendungsfall bzw. benötigter Disk-Performance kann dann allenfalls direkt auf diesem Volume gearbeitet werden. Wird im Betrieb die minimale Latenz einer Scratch Disk benötigt, so kann deren Inhalt vor dem Löschen des GPU-Servers auf das normale NVMe-SSD-Volume gesichert und eine künftige, frische Scratch Disk wieder von diesem Volume vorbefüllt werden (ggf. sogar automatisiert, z.B. über cloud-init).

Wichtig: Auch im laufenden Betrieb muss damit gerechnet werden, dass der Inhalt der Scratch Disk nach einem technischen Problem nicht mehr verfügbar ist (und z.B. auf Ersatz-Hardware eine neue, leere Scratch Disk bereitgestellt wird). Je nach Anwendungsfall kann es sich daher sowieso empfehlen, den Inhalt der Scratch Disk kontinuierlich an einen anderen Speicherort zu sichern.