Nitro, Corsica, TPU: Spezial-Hardware für die Cloud

Inhaltsverzeichnis

100 Prozent der CPU-Kerne eines Servers den virtuellen Maschinen der Kunden bereitstellen, ohne davon Ressourcen für den Hypervisor abzuzwacken? Was nach einem akademischen Wunschgedanken klingt, ist für Amazon Rechenzentrumssparte AWS inzwischen Realität. Damit das klappt, nutzt AWS die selbst entwickelte Plattform Nitro.

Angefangen hat alles mit der EC2-Generation C3, die Ende 2013 erschienen ist. Während sie wie noch ältere Version hauptsächlich auf Xen-Paravirtualisierung setzte, kam dort erstmals eine zusätzliche Netzwerkkarte zum Einsatz, die vom israelischen Startup Annapurna Labs entworfen wurden. Wobei "Netzwerkkarte" eigentlich nicht ganz stimmt: Als Smart-NIC kümmerte sie sich schon damals um mehr als nur stumpf Netzwerkpakete zu transportieren. Dennoch waren hier noch 20 Prozent der CPU-Kerne für den Xen-Hypervisor und andere Managementaufgaben fest reserviert.

In der Anfang 2015 erschienenen C4-Generation wurden die Zusatzaufgaben deutlich ausgebaut, sodass nun auch das gesamte Storage-Interface über die Smart-NIC lief. Dass AWS noch viel mehr vorhatte – und davon wenig der Konkurrenz überlassen wollte –, hat man zu dem Zeitpunkt schon erahnen können: Zum selben Zeitpunkt hat AWS Annapurna Labs kurzerhand übernommen.

Nitro für alles

Als Anfang 2017 dann die I3-Generation publik wurde, war auch klar, woran die neue Tochter gearbeitet hat: Zusätzlich zu den Smart-NICs agieren Annapurnas Nitro-Prozessoren als NVMe-Controller, die unter anderem SSD-Daten on the fly verschlüsseln. Die für Hypervisor & Co. reservierte CPU-Kapazität sank auf 10 Prozent aller Kerne. Das war aber immer noch mehr Reserve als man eigentlich benötigte, denn Annapurna-Chips sorgten sich mittlerweile ja um das Netzwerk, den lokalen und den entfernten Speicher – und zwar inklusive sämtlicher zugehöriger Virtualisierung.

Schon Ende 2017 folgte deshalb der nächste Schritt: Mit der Generation C5 stehen 100 Prozent der CPU-Kerne für Kundeninstanzen bereit. Der Xen-Hypervisor und das AWS-eigene Host-Linux wurden durch einen eigenen, extrem schlanken Nitro-Hypervisor ersetzt, der sich hauptsächlich noch mit niedrigen Aufgaben wie der Partitionierung der Ressourcen kümmert. Alles andere läuft auf Nitro-Spezialhardware.

Zu letzterer gehört übrigens auch ein Sicherheitschip, der fester Bestandteil aller Server-Mainboards von Amazon ist. Dieser kümmert sich unter anderem darum, dass die Server ohne Kompromittierung booten: Solange nach dem Einschalten nicht ein anderer Annapurna-Chip auf einer Smart-NIC einsatzbereit ist, der den Bootvorgang überwachen könnte, hält der Sicherheitschip den Prozessor im Reset und lässt keinerlei Schreibzugriffe von diesem zu.

Damit umgeht Amazon das bei normalen PCs und Servern aufwändig umschiffte Problem, dass CPUs dort grundsätzlich erst einmal unsicher starten. UEFI Secure Boot verifiziert dann erst nachträglich in vielen kleinen Schritten, dass der Bootvorgang nicht kompromittiert war. Hardware-Sicherheitsprozessoren gibt es übrigens nicht nur von Amazon: Auch Google (Titan) und Microsoft (Cerberus) setzen auf selbstentwickelte Security-ICs; Apples T2 findet man sogar in Consumer-Hardware.

Zum Abschluss hat AWS dann auch noch die nahe Zukunft skizziert: Wenn alles glatt läuft, dann könnte man künftig wohl ganz ohne Hypervisor auskommen. Und wenn dieser wegfällt oder wie im aktuellen Fall nur noch sehr schlank ausfällt, ist es dann auch egal, welchen Befehlssatz die eigentlichen CPUs haben. Nicht von ungefähr ist in der A1-Generation mittlerweile ja auch schon Server mit Amazons hauseigenem 64-Bit-ARM-Chip Graviton statt Intel Xeon oder AMDs Epyc erhältlich.

Corsica

Microsoft schilderte auf der Hot Chips die Hintergründe, die zur Entwicklung des hauseigenen Spezialchips Corsica geführt haben: Sämtliche Nutzerdaten eines Cloud-Servers müssen vor dem Speichern komprimiert und individuell verschlüsselt werden. Sollen Daten von Storage-System geholt werden, fallen die rechenintensiven Schritte in umgekehrter Reichenfolge an. Der Bedarf für einen Beschleuniger besteht in allen Azure-Servern, und die Anforderungen an die Hardware sind relativ gering – beste Voraussetzungen für die Entwicklung eines genau dafür bestimmten ASICs.

Corsica macht denn auch nichts anderes als die eben genannten Schritte. Der Chip wird per NVMe angesprochen und kommt ohne lokalen Speicher aus: Sämtliche Nutzdaten werden als Stream durchgeschoben. Neben einem hohen Datendurchsatz und einer geringen Latenz stand eine gleichzeitig extrem geringe Fehlerrate im Pflichtenheft.

Um auch bei einer Datenrate von 100 GBit/s etwa von Alpha-Teilchen ausgelöste Bit-Flips zu erkennen, wurden zwei Sicherungen integriert. So werden die Daten nach Kompression und Verschlüsselung beiseitegelegt und gleich wieder on-chip entschlüsselt und entpackt. Nur wenn eine dann generierte Checksumme mit der übereinstimmt, die beim Eingang der Daten erstellt wurde, werden die verschlüsselten, komprimierten Daten ausgegeben.

Zusätzlich sind zwei baugleiche Schlüsselgeneratoren involviert, die mit demselben Input gefüttert werden. Zur Verschlüsselung wird der Schlüssel von einem Generator verwendet, zur on-chip-Entschlüsselung für die Checksummenprüfung kommt der – im Regelfall identische – Schlüssel des anderen Generators zum Einsatz. Damit stellt Microsoft sicher, dass die Daten nicht versehentlich mit einem Bitfehler-behafteten Schlüssel gesichert wurden und später auch garantiert wieder korrekt entschlüsselt werden können.

TPU v3

Googles Vortrag zum hauseigenen KI-Beschleuniger TPU v3 predigte die Prämisse, dass Hardware-Designer sich doch möglichst mit involvierten Parteien wie KI-Spezialisten oder Server-Integratoren zusammensetzen sollten, um einen möglichst optimalen Spezialchip zu entwickeln. Im Laufe der Präsentation wurde indirekt klar, dass dies Google-intern bei der allerersten TPU wohl anders gelaufen sein muss: TPU v1 und TPU v2 unterscheiden sich recht deutlich.

So schrumpfte bei dem Generationswechsel der Matrix-Multiplizierer recht deutlich von 256 × 256 auf 128 × 128 – bei der ersten Version waren die praktischen Einschränkungen hinsichtlich Stromverbrauch, Latenz, Datendurchsatz etc. wohl größer als der Nutzwert des riesigen Arrays. Die aktuelle TPU v3 ist vom Chipdesign her denn auch eher ein TPU v2.5: Abgesehen von größeren Speicher wurde pro Kern lediglich ein zweiter Matrix-Multiplizierer integriert.

Alle anderen Veränderungen haben mit dem Gesamtsystem zu tun. So gibt es eine Wasserkühlung, um eine höhere Packdichte im Serverrack zu erreichen. Zudem wurde an der Vernetzung der einzelnen TPUs über Mainboardgrenzen hinaus gearbeitet: Es sind sowohl größere Verbände möglich als auch eine granularere Partitionierung. Der Latenz zuliebe ist der Netzwerkchip auch nicht mehr separat, sondern ebenfalls Teil der TPU geworden.

Zu einer möglichen TPU v4 wollten beziehungsweise durften die anwesenden Google-Mitarbeiter nichts sagen. Sie ließen einzig und allein durchblicken, dass sie derzeit bei allen verwendeten KI-Modellen sehr gut mit der 128-×-128-Matrixeinheit zurechtkommen und es somit keinen Bedarf gäbe, daran etwas zu ändern. (mue)