Blaupause für das maßgeschneiderte Rechenzentrum Was ist der Compute Express Link?
Anbieter zum Thema
Rechenzentren sind im Zusammenspiel der Komponenten oft unflexibel und werden aus dieser Not heraus häufig überdimensioniert, sprich der ökologische und ökonomische Wirkungsgrad ist schlecht. Mit dem Compute Express Link 3.0 sollte sich das in naher Zukunft ändern.

Ob einzelne Rechner, Serverschränke oder ein ganzes Rechenzentrum: die schwächste Kette im Glied bestimmt auch hier die Gesamtleistung. Die superschnelle CPU verpufft in ihrer Leistung, wenn die Daten nicht schnell genug in den oder aus dem Speicher kommen oder wenn mehrere CPUs quasi-autistisch vor sich hin werkeln. Kommunikation ist nicht alles, aber ohne Kommunikation ist alles nichts.
Deshalb sind Bussysteme, die Zentrum und Peripherie breitbandig und ohne nennenswerte Verzögerung verbinden, in allen Anwendungsbereichen der IT ein zentrales Element. Was in der prozessnahen IT (auch OT genannt) der PCIe- und der COM-HPC-Bus sind, das ist im Rechenzentrumsbereich der Compute Express Link (CLX). Derartige Busstrukturen sind deshalb ein integraler Bestandteil heutiger Server in Form von Steckplätzen für entsprechende Karten und in einigen Superrechnern gibt es sogar eigene Verbindungen dafür ohne den Umweg separate CLX-Module.
Enge Symbiose zwischen PCIe und CLX
Nachdem einige Jahre lang mit Gen-Z, CCIX (Cache Coherent Interconnect for Accelerators), OpenCAPI (Coherent Accelerator Processor Interface) und eben CLX vier „Rechenzentrums-Bus“-Spezifikationen miteinander konkurrierten, jeweils unterstützt von verschiedenen Chip-, Server- und Peripherieherstellern, hat mittlerweile der Compute Express Link in seiner aktuellen Version 3.0 die Konkurrenten sowohl von den Features als auch von den unterstützenden Firmen her „aufgesogen“. Entsprechende Zusammenführungen sind rechtlich vereinbart.
Physikalisch basiert CLX auf dem aus der prozessnahen Datenverarbeitung bekannten Bus-System PCI Express (PCIe), wobei CLX 1.0 und CLX 2.0 auf PCIe 5.0 und die gerade vorgestellte Version CLX 3.0 auf der in Entwicklung befindlichen Spezifikation PCIe 6.0 aufsetzen. Man erwartet, dass sich CLX 3.0 und PCIe 6.0 wechselseitig in der Entwicklung und der praktischen Verwendung antreiben.
Die Version 3.0 ist im Übrigen abwärtskompatibel zu CXL 1.x und CXL 2.0.
PCIe 5.0 seinerseits ist vollduplexfähig und arbeitet mit 3938 MByte pro Sekunde, Lane und Richtung, PCIe 6.0 mit 7529 MByte/s. In puncto Geschwindigkeit und Switching-Fähigkeiten (siehe unten) setzt CXL voll auf die Weiterentwicklung des zugrunde liegenden Systembusses.
Ergänzung der Semantik der PCIe-Protokolls
Eine Eigenentwicklung des CXL-Konsortiums sind die drei Protokolle CXL.io, CXL.cache und CXL.memory. Sie sorgen dafür, dass sich die Kernkomponenten Eingabe-Ausgabe, Speicherkommunikation und Cache-Kohärenz mit nur äußerst geringen Verzögerungszeiten umsetzen lassen. Damit ergänzt CXL die I/O-Semantik des PCIe-Protokolls um Kohärenz und Speichersemantik.
Im Einzelnen werden drei primäre Gerätetypen von CXL adressiert, die in Rechenzentren eine immer größere Rolle spielen:
- Spezialisierte Beschleuniger für (Cloud-) Rechenzentren wie etwa SmartNICs. Diese Komponenten sind für einen kohärenten Zugriff auf den Speicher der Host-CPU ausgelegt und damit auf die Protokolle CXL.io und CXL.cache angewiesen.
- Allzweckbeschleuniger wie GPU, ASIC, FPGA oder Intels IPUs mit lokalem GDDR- oder HBM-Hochleistungsspeicher. Die Komponenten können kohärent auf den Speicher der Host-CPU zugreifen und/oder ermöglichen von der Host-CPU aus einen kohärenten oder nicht-kohärenten Zugriff auf den lokalen Gerätespeicher. Hierzu sind alle drei Protokolle, also CXL.io, CXL.cache und CXL.mem erforderlich.
- Speichererweiterungskarten und Hybrid-Speicher (Storage-Class Memory, SCM). Diese Komponenten bieten der Host-CPU einen Zugriff mit niedriger Latenz auf lokalen DRAM oder nichtflüchtigen Speicher. Hierzu werden die Protokolle CXL.io und CXL.mem benötigt.
Die „disaggregierte Datacenter-Architektur“
Vordergründig könnte man sagen, dass man auf der Basis von CLX bequem und kostengünstig über einen PCIe-Steckplatz (statt in teurer Weise über den DDR-Bus) zusätzlichen Speicherplatz für einen Server bereitstellen kann, doch tatsächlich handelt es sich (zumindest bei CLX 2.0 und 3.0) um weit mehr.
:quality(80)/p7i.vogel.de/wcms/8e/5e/8e5e8f820b67167bb685e09a87225c60/0106311703.jpeg)
Die dritte Spezifikation des Compute Express Link
CXL 3.0 verändert die Bauart von Computern, Clustern und von Rechenzentren
Mit CLX 3.0 kann nämlich die gesamte Rechenzentrumsarchitektur neu oder viel effizienter organisiert werden. Der etwas kryptisch wirkende Begriff „disaggregierte Datacenter-Architektur“ gibt hier die Richtung an. Disaggregierung will sagen, dass tendenziell jede Komponente mit jeder anderen Komponente kommunizieren kann und die jeweiligen Dienste (Rechenpower, Speicher, Cache, Beschleunigung) wechselseitig genutzt werden können.
Durch eine solche Architektur ist eine sehr feingranulare Auslastung der Komponenten möglich, was nicht nur ökologisch, sondern auch ökonomisch vorteilhaft ist. Ressourcen lassen sich von einem Knoten zu einem anderen verschieben, die Systeme können mit der Zeit und den Bedarfen wachsen.
Diese Möglichkeit eröffnet sich zum einen durch das seit CLX 2.0 mögliche Switching und zum anderen über das Pooling von Peripherie (nicht nur von Speicher!), so dass die einzelnen Peripherie-Komponenten von mehreren Servern angesprochen werden können. Hierzu werden mehrere CXL-Switches zu einer Fabric zusammengefügt, also zu einem „Gewebe von Netzwerk-Switches“, das in diesem Fall nicht über Ethernet, sondern über PCIe läuft.
Produkte für CLX 2.0 und 3.0 lassen noch auf sich warten
Die neue Compute Express Link-Version 3.0 ist seit August einsatzfähige Komponenten für diese Version aber noch nicht. Selbst für CLX 2.0 gibt es noch keine Produkte. Die CLX-fähigen neuen Server-Prozessoren Sapphire Rapids von Intel und Epyc Genoa von AMD, die demnächst ausgeliefert werden sollen, „sprechen“ gerade einmal CLX 1.1.
Auf CLX 2.0 und CLX 3.0-fähige Produkte wird man wohl noch ein paar Jahre warten müssen. Zwei bis vier Jahre – je nach Version – sind vermutlich realistisch. Man hat also Zeit, die Architektur-Revolution in den Rechenzentren gut vorzubereiten.
(ID:48551423)