Wie Linode in sechs Wochen von Hardware zu Live-GPUs kam

Im Jahr 2019 setzten sich drei verschiedene Abteilungen das Ziel, bis zum Geburtstag von Linode neue Linode GPU-Instanzen für Kunden einzuführen. Zwischen den Hardware-, Marketing- und Management-Teams waren wir uns nicht sicher, ob das möglich war, besonders mit den anderen Produkten, an denen wir in dieser Zeit arbeiteten.

Also wählten wir das einzige Team, das eine Chance hatte, dies zu verwirklichen: ein handverlesenes Team von eifrigen Mitarbeitern, die mehrere Abteilungen überspannen, um das Team Mission GPU zu bilden. Jetzt, fast zwei Jahre und viele GPU-Instanz-Implementierungen später, machen wir eine Reise in die Vergangenheit, um einen detaillierten Einblick zu geben, wie wir das geschafft haben – und eine Idee in ein erfolgreiches Produkt verwandelt haben, das wir aktiv erweitern.

Ein kurzer Rückblick auf die Geschichte der Virtualisierung bei Linode

Bevor wir damit beginnen, wie wir GPU-Instanzen eingeführt haben, finden Sie hier ein paar leichte technische Details und die Geschichte, wie die Virtualisierung bei Linode begann, bevor wir zu dem Cloud-Anbieter wurden, den Sie heute kennen.

Linode begann als kleines Unternehmen im Jahr 2003 mit der Bereitstellung von virtuellen Maschinen unter UML (User Mode Linux), einem frühen Virtualisierungsparadigma, ähnlich wie Qemu (Quick EMUlator). UML stellte vollständig virtualisierte Hardware zur Verfügung. Wenn sich ein Kunde bei seiner Linode anmeldete, sahen die Geräte, die er sah, wie Festplatten, Netzwerk, Hauptplatine, RAM usw., alle wie echte Hardware-Geräte aus und verhielten sich auch so, aber in Wirklichkeit wurden die Geräte von Software anstatt von der echten Hardware unterstützt.

Einige Jahre später wechselte Linode zu Xen als Virtualisierungsschicht, um unseren Kunden die neuesten Leistungsverbesserungen zu bieten. Xen ist ein Typ1-Hypervisor, d. h. der Hypervisor läuft direkt auf der Hardware, und die Gäste laufen auf dem Xen -Kernel. Der Xen Kernel bietet seinen Gästen Paravirtualisierung, oder die Hardware-Schnittstellen, die die Linode sieht, werden durch den Xen Kernel in tatsächliche Maschinenaufrufe übersetzt und an den Benutzer zurückgegeben. Der Grund für die Existenz dieser Übersetzungsschicht ist die Bereitstellung von Sicherheit und anderen Sicherheitsfunktionen, damit die richtige Anweisung an die richtige Linode geht.

Einige Jahre danach wurde eine neue Technologie namens KVM (Kernel Virtual Machine) entwickelt. KVM besteht aus Teilen des Linux-Kernels, die paravirtuelle Schnittstellen zu CPU-Anweisungen bereitstellen. Qemu ist eine der Virtualisierungstechnologien, die die Vorteile von KVM nutzen können. Linode entschied sich, zum Nutzen der Kunden wieder um zusteigen. Als die Kunden das kostenlose Upgrade auf KVM vornahmen, sahen die meisten Arbeitslasten eine sofortige Leistungssteigerung. Diese Art der Paravirtualisierung unterscheidet sich von Xen: Die CPU-Befehle werden vom Gast (Qemu) an den Host-Kernel und direkt an die CPU weitergegeben, wobei die Anweisungen auf Prozessorebene verwendet werden, was nahezu native Ausführungsgeschwindigkeiten ermöglicht. Die Ergebnisse dieser Anweisungen werden an die Linode zurückgegeben, die sie ausgegeben hat, ohne den Overhead, den Xen benötigt.

Und was hat all dies mit den GPU-Instanzen von Linode zu tun?

Linode führte eine Marktforschung durch und versuche, herauszufinden, was den Kunden, die GPU-Workloads ausführen möchten, den besten Wert bieten würde. Wir haben uns entschieden, die GPUs den Kunden direkt zur Verfügung zu stellen, indem wir eine Technologie namens "Host Passthrough" verwenden. Wir sagen Qemu, welches Hardware-Gerät wir an den Gast weiterreichen möchten, in diesem Fall die GPU-Karte, und Qemu arbeitet mit Linux zusammen, um die GPU-Karte zu isolieren, sodass kein anderer Prozess auf dem System sie nutzen kann. Die Linux-Host-Maschine kann sie nicht nutzen, die anderen Linodes auf der Maschine können sie ebenfalls nicht nutzen. Nur der Kunde, der sie angefordert hat, kann die GPU-Karte nutzen, und er bekommt die komplette Karte. Das eigentliche Hardware-Gerät wird durchgereicht, unverändert und nicht paravirtualisiert, d. h. es gibt keine Übersetzungsschicht.

Woche 1: Hardware kommt bei Linode an

Nachdem die Recherchen abgeschlossen waren, beschloss das gesamte Team, das Projekt voranzutreiben. Damit der Plan funktionierte, waren einige Änderungen im gesamten Low-Level-Stack erforderlich. Die Hardware kam am Montag online und wir hatten fünf Tage Zeit, um zu entscheiden, ob wir mit einer Großbestellung für ein Rechenzentrum weitermachen wollten, um die Frist einzuhalten.

Alle Beteiligten waren sich einig, dass, wenn wir nicht in der Lage waren, den Betrieb in einer normalen 40-Stunden-Woche zu gewährleisten, wir nicht vorankommen würden. Das bedeutete, dass es keinen Druck gab, Überstunden zu machen, aber wir hatten nur fünf Tage, um die Zukunft eines neuen Linode-Produkts zu bestimmen.

Und was passierte schließlich? Es stellte sich heraus, dass sich all unsere Nachforschungen auszahlten. Wir versuchten, einer bestehenden Dokumentation zu folgen, und es funktionierte genau wie erwartet. Innerhalb weniger Tage waren wir in der Lage, GPUs in einer Testumgebung zuverlässig an Linodes anzuschließen. Am Freitag waren wir zuversichtlich, dass wir das durchziehen konnten. Der Test war erfolgreich! Nun war es an der Zeit, eine große Bestellung für Kunden aufzugeben und weiterzumachen.

Woche 2: Hardware Interface Layer mit GPUs zum Laufen bringen

Nach einem erfolgreichen ersten Test kamen wir am Montag mit neuen Kräften ins Büro und waren bereit, den GPU-Anbindungsprozess in unsere bestehenden Linode-Erstellungsabläufe zu integrieren. Wir versuchen, unsere Schnittstelle so einfach wie möglich zu gestalten: nur ein paar Klicks, um eine Linode bereitzustellen, und in diesen wenigen Aktionen steckt eine Menge, die wir berücksichtigen mussten.

Um GPUs zu ermöglichen, mussten mehrere Low-Level-Teile geschrieben und implementiert werden, wie z.B. die Isolierung des RAM für die GPU und die Linode, sowie die Ausstattung der Linode-Instanz mit dedizierten CPU-Kernen, die mit dem isolierten RAM und der GPU gepaart wurden. Wir erforschten die NUMA-Architektur (Non Uniform Memory Access) der Hauptplatine und konnten die NUMA-Gruppe des RAM von der CPU isolieren, mit der sie am engsten verbunden war, und die NUMA-Gruppe, die mit der PCIe-Spur (PCI [Peripheral Computer Interface] express) verbunden war, in die die GPU eingesteckt war. Dies erlaubte uns, eine Linode mit 1, 2, 3 oder 4 angeschlossenen GPUs zu booten und den Teil des RAM und der CPU-Kerne zu verwenden, der der GPU-Karte aufgrund der Struktur der Hauptplatine am nächsten war.

Nachdem die Hardware-Ebene fertig war, arbeiteten wir an der Schnittstelle zu den Linode-Job-Queuing-Mechanismen, so dass wir Linodes über unseren Cloud Manager und unsere API booten konnten. In diesem Stadium konnten wir beginnen, die Zuverlässigkeit zu testen. Das Letzte, was wir wollten, war, dass ein Bereitschaftsingenieur mitten in der Nacht wegen eines ausgefallenen Systems angepiept wird oder, dass ein System während des Arbeitstags für einen Kunden in einer anderen Zeitzone ausfällt. Mit Rücksicht auf die Schlafenszeiten der Kunden und der Techniker, begannen wir früh mit den Tests und stellten sicher, dass die Kunden am Ende ein solides und zuverlässiges Produkt erhielten.

Woche 3: Durchführen von Änderungen an der Administrator-Schnittstelle und in der Buchhaltung

In Woche drei standen wir vor einigen administrativen Fragen: Wie verfolgen wir, welche Kunden welchen Linodes zugewiesen sind? Wie schicken wir Kunden zu einer Linode-Instanz mit einer GPU und nicht zu einer Linode-Instanz ohne GPU?

Die gesamte Verfolgung und Steuerung musste implementiert werden. Wir taten dies, um nachvollziehen zu können, wie viele GPU-Karten wir hatten, wie viele belegt waren, wie viele leer waren und wie viele wir noch an neue Kunden verkaufen konnten. Wir mussten dieses GPU-Tracking auch in unsere internen Administrator-Schnittstellen einbauen. Das mag wie langweilige Buchhaltungsarbeit erscheinen, aber es war eine Menge Einfallsreichtum vom gesamten Team und von externen Teammitgliedern erforderlich, um dieses neue Produkt mit all unseren bestehenden Produkten zu verbinden, ohne dass manuelle Schritte erforderlich waren.

Zum Glück haben wir alle an einem Strang gezogen und waren in der Lage, den Code zu schreiben und zu testen, um sicherzustellen, dass er gut und zuverlässig funktioniert und keine manuellen Eingriffe erfordert, um eine Linode GPU-Instanz zum Laufen zu bringen. Ein weiterer Nebeneffekt dieser Arbeit in diesem Stadium war, dass das Testen einfacher war. Wir mussten nur einen einzigen Button auf unserer Administrator-Schnittstelle anklicken, um eine Linode GPU-Instanz zum Laufen zu bringen.

Woche 4: Änderungen am öffentlichen API vornehmen, damit Kunden Linode-Instanzen einrichten können

Nachdem wir die Schaltfläche für die Administratoroberfläche zum Hochfahren einer Linode-GPU-Instanz erstellt hatten, fühlten wir uns richtig gut. Nun mussten wir daran arbeiten, dieselbe Funktionsweise für Kunden zugänglich zu machen. Das öffentliche API wird von Python unterstützt, was den Code extrem effizient machte. Wir waren in der Lage, die Änderungen sehr schnell umzusetzen und zu testen. Der knifflige Teil war, diese Funktion innerhalb des Unternehmens zum Testen zur Verfügung zu stellen, aber nicht extern verfügbar zu machen, bis wir die notwendigen Zuverlässigkeitstests durchgeführt hatten.

Woche 5: So stellen Sie eine öffentlich zugängliche Funktion hinter einem Feature Flag bereit

Früher und häufiger Einsatz.

Wir standen kurz vor dem Durchbruch, und so stellten wir uns die Frage: Wie fühlen wir uns dabei, dies der Öffentlichkeit vorzustellen und letztendlich Kunden dazu zu bringen, diesen neuen Dienst zu nutzen?

Die Antwort bestand darin, alle Unbekannten frühzeitig zu behandeln und zu berücksichtigen, indem wir sie früh und oft einsetzen. Während wir noch einige der Anwendungsfälle im Team testeten, stellten wir Linode GPU-Instanzen der Öffentlichkeit zur Verfügung, allerdings versteckt hinter einem Feature-Flag. Wir konnten die GPUs auf unseren Mitarbeiter-Accounts testen und somit sicherstellen, dass sich die Dinge genau so verhalten, wie wir es erwarten, wenn ein Kunde sie nutzen würde. Jedes Mal, wenn wir etwas Unerwartetes fanden, nahmen wir eine Korrektur und eine öffentliche Bereitstellung vorgenommen.

Langsam aber sicher, und mit der nahezu täglichen Bereitstellung von Code, haben wir alle auf unserer Liste stehenden Probleme gelöst. Wir hatten keine Änderungen mehr vorzunehmen und fühlten uns sicher genug, um diese Innovation für die Kunden bereitzustellen.

Woche 6: Test! Bereitstellen von GPUs für Linode-Mitarbeiter

Eines der schönsten Dinge daran, bei Linode zu arbeiten, ist, dass wir mit modernster Technologie spielen dürfen, bevor es jemand anderes tut. (P.S. wir stellen ein!) Jeder Mitarbeiter hat die Chance, ein neues Produkt auf Herz und Nieren zu prüfen, so dass jedes Stück Technik, welches wir auf den Markt bringen, ausgiebig getestet wurde. Jeder Mitarbeiter konnte sich anmelden, um eine Linode GPU-Instanz während der Arbeitszeit zu testen, sogar nach der Arbeit, wenn er unbedingt wollte, um die Linode GPU-Instanz aus Sicht der Kunden zu nutzen. Alles, was sie tun mussten, war, ihr Mitarbeiterkonto zu kennzeichnen und eine GPU zu starten.

Hier sind einige Beispiele, wie Linodians unsere neuen GPUs ausprobiert haben:

• Cloud-Gaming – wobei das Spiel auf der Linode-GPU-Instanz läuft und das Video und die Steuerung über Steam Link™ gesendet werden
• 3D-Rendering
• Video-Transcodierung
• Testen der Passwortstärke
• Ausführen von TensorFlow

Nach dieser Phase sammelten wir Leistungskennzahlen und entschieden uns, dass wir bereit sind, in die Produktion zu gehen und bei den Kunden zu starten.

Starten!

Wir sind gestartet! Wir haben gefeiert! Es gab Eis und Süßigkeiten! Kunden begannen, das Produkt auszuprobieren, welches sich noch vor wenigen Wochen in der Entwicklung befand. Das Beste daran war, dass am Tag der Markteinführung alles funktionierte. Wir mussten keine Änderungen in letzter Minute vornehmen, es gab keine Feuer zu löschen, die Kunden waren zufrieden und alles funktionierte zuverlässig.

Der eigentliche Code-Start war nicht schwierig. Aus Sicht des Codes und der Systemkonfiguration war alles, was es brauchte, um GPUs in Produktion zu bringen, das Entfernen eines Feature-Flags. Aber es gibt noch eine Menge anderer Dinge, welche in eine Produkteinführung bei Linode einfließen: technische Dokumentation, die Durchführung der UI-Änderungen im Linode-Cloud-Manager und all die lustigen Marketingmaterialien, welche helfen, unser neues Produkt zu präsentieren.

Nach dem Start: Sechs Monate lang keine Code-Änderungen

Einige Fragen gehen uns immer wieder durch den Kopf: Haben wir genug Tests durchgeführt? Waren sechs Wochen zu schnell?

In unserem Fall war es genau die richtige Geschwindigkeit: Ich musste den Code seit dem Launch nicht mehr anrühren. Und die Linode-GPUs wurden jeden Tag von Kunden genutzt. Es ist großartig, wenn man ein Produkt entwickelt und es funktioniert, dann weitermacht und andere großartige Produkte entwickelt und die Sache, welche man vor zwei Jahren entwickelt hat, läuft immer noch, ganz von selbst, mit minimaler Interaktion

Rückblickend gibt es einige Faktoren, welche uns diesen Erfolg ermöglichten:

1. Im Vorfeld recherchieren – Dies hat uns sehr geholfen, alles Unbekannte in Angriff zu nehmen, ohne tatsächlich Hardware in der Hand zu halten.
2. Einen Plan erstellen – Wir hatten einen sehr detaillierten Plan und jeder Schritt musste termingerecht ausgeführt werden, sonst hätten wir nicht starten können.
3. An den Plan halten – Sich auf die anstehende Aufgabe konzentrieren und die noch verbleibenden Aufgaben im Auge behalten.
4. Ein gutes Management-Team – Sicherstellen, dass alle Management-Ebenen verstanden haben, dass, wenn bei einem Projekt mit einem engen Zeitplan ein Schritt versäumt wird, der Starttermin nicht eingehalten werden kann. Das ist vielleicht der wichtigste Teil, der uns zum Erfolg verholfen hat. Etwas Druck ist durchaus gut, so wie es in unserem Fall war. Zu viel Druck hingegen führt zu Burnout und Misserfolg. Nachdem wir den Zeitplan mit dem Management abgestimmt hatten, waren sie vollständig an Bord.
5. Sich gegenseitig unterstützen – Das eine Team, das eine Chance hatte, hätte ohne die gesamte unterstützende Struktur des restlichen Unternehmens keine Chance gehabt. Wenn alle Ihre Mitarbeiter wollen, dass Sie Erfolg haben, werden sie alle einspringen und aushelfen, wenn sie gebraucht werden.
6. Testen – Testen, Testen, Testen, wenn ich es noch einmal schreiben könnte, würde ich immer noch schreiben: Testen. Sowohl automatisierte als auch manuelle Tests. Dies war bei weitem der Hauptgrund dafür, dass niemand in meinem Team den Code in über 6 Monaten anrühren musste.

Erfahren Sie mehr über Linode GPU-Instanzen, indem Sie sich unsere GPU-Dokumentation ansehen. Wir haben gerade die GPU-Verfügbarkeit in unseren Rechenzentren in Newark, Mumbai und Singapur erweitert.

Sind Sie daran interessiert, Linode GPUs für Ihre aktuellen Workloads zu testen? Sie können eine kostenlose, einwöchige Testversion anfordern, um zu sehen, wie unsere GPUs für Sie arbeiten. Erfahren Sie hier mehr.

(Und noch einmal, wenn Sie uns helfen wollen, Produkte wie Linode-GPUs herzustellen und zu testen, wir stellen ein!)