So wichtig sind PCIe-Fabrics für Composable Infrastructures

Durch Multi-Fabric-Ansätze statt der Beschränkung auf Ethernet oder PCI könnte Composable Infrastructure nach zehn Jahren doch noch zum Markterfolg werden.

Die IT strotzt vor vielversprechenden Ideen, die nie breit umgesetzt werden. Beispielsweise konnte sich Composable Infrastructure in den vergangenen fünf Jahren nicht durchsetzen. Man könnte die Disaggregation der Hardwareressourcen fast für einen Fehlschlag halten. Aber vielleicht sollte man das Konzept noch nicht aufgeben, obwohl die wenigen verfügbaren Nutzungsdaten eher desillusionierend sind.

Eine Umfrage unter IT-Verantwortlichen und Managern durch Statista ergab, dass nur 11 Prozent der Befragten Composable Infrastructure in der Produktion hatten. 52 Prozent waren nicht an der Technologie interessiert. Tatsächlich verzeichnete Composable Infrastructure den niedrigsten Grad an Interesse von zehn aufgeführten Technologien.

Nichtsdestotrotz gab es in den vergangenen Jahren einige signifikante Produktentwicklungen. Sie weckten die Hoffnung, dass das Konzept seinen Platz im Unternehmen finden würde, besonders bei Organisationen, die große Cluster für HPC- und KI-Workloads bauen.

Hardware-Composability: Hintergrund und Technologie

Die Idee hinter Composable Hardware reicht ein Jahrzehnt zurück: Damals baute Calxeda einen modularen Scale-Out-Server mit ARM-Prozessor und einer integrierten 10-Gbit/s-Ethernet-Fabric. Für seine Zeit war dieser Server sehr schnell und verband benachbarte Rechenknoten im Chassis.

Calxeda ist heute nicht mehr am Markt. Sein intellektuelles Eigentum wird heute durch Silver Lining Systems genutzt. Calxedas Technologie wurde zunächst von HP für seine Moonshot-Server angezapft. Man kann darüber streiten, ob dies der erste Versuch war, ein Hardware-/Softwaresystem mit Composable-Technologien zu bauen. Allerdings gab HP diesen Ansatz später auf und verwendete stattdessen Intels neue Atom-Prozessoren. Moonshot hat sich seitdem zu HPE Synergy weiterentwickelt.

Abbildung 1: Aufbau einer Composable-Architektur.
Abbildung 1: Aufbau einer Composable-Architektur.

Das Konzept entwickelte sich mit einem anderen Startup weiter. Liquid begann 2015 mit einer neuen Herangehensweise auf Basis von PCIe-Fabrics. Sie sind der Dreh- und Angelpunkt des Liquid-Systems. Zu ihnen gehören PCIe-Switches auf Basis von Broadcom-Komponenten. Ein Softwaremanagementsystem hilft, die Bare-Metal-Server zu konfigurieren und zu verbinden. Sie bestehen aus CPU, Memory, Netzwerkkarte (NIC), Storage, GPU und Field-Programmable Gate Arrays (FPGA). Diese Ressourcen werden in angebundenen Servern und Erweiterungschassis gepoolt.

Warum PCI?

Liquid baute ursprünglich einen intern entwickelten Switch mit Silicon von PLX ein. Später verwendete das Unternehmen Broadcoms PEX8700 und PEX9700 Gen3 Switch-Chips. Mitte 2020 arbeiteten Liquid und Broadcom gemeinsam an einem PCIe-Gen-4.0-Referenzdesign. Dafür wurde Broadcoms PEX88000-Switch verwendet, der doppelt so schnell ist wie der Vorläufer Gen 3.0. Die Bandbreite liegt bei 256 Gigatransfers pro Sekunde und Port. Die Switches gibt es in 24- und 48-Port-Konfigurationen. Jeder Port unterstützt vier PCI-Lanes, die für x8 oder x16 konfigurierbar sind. Die Latenz von Port zu Port liegt bei 100 Nanosekunden.

PCIe ist ein idealer Interconnect für Server-Cluster und Composable Infrastructure.

PCIe ist der ideale Interconnect für Servercluster und Composable Infrastructure. Denn die genutzten modernen Prozessoren sind allgegenwärtig. Die Bandbreite ist mit 64 Gbit/s pro Lane hoch, die Latenz gering. Verlustloser Transport und direkter Memory-Zugriff (Direct Memory Access, DMA) werden unterstützt.

Durch das nicht transparente Bridging kann der Prozessor die Switch-Ports als PCI-Endpunkte sehen. Gen 4.0-Switches wie der Broadcom PEX 88000 enthalten einen ARM-Prozessor für die Konfiguration, das Management und die Handhabung von Hot Plugs. Sie verbinden Non-blocking Leitungsgeschwindigkeit mit I/O-Sharing und DMA.

Zu den Nachteilen von PCIe gehören höhere Kosten pro Port als bei Ethernet und enge Grenzen der möglichen Kabellänge. Fabrics müssen sich derzeit deshalb innerhalb eines Racks befinden. Daher haben sich Ethernet und Infiniband zu Alternativen für Composable Infrastructure entwickelt. Beispielsweise kündigte Liquid Multi-Fabric-Support für alle Arten von Composable-Komponenten an: CPU, Memory, GPU, NIC, FPGA und Storage. Unterstützt werden alle wichtigen Fabric-Typen, angefangen bei PCIe Gen 3.0 über Gen 4.0 bis hin zu Ethernet und InfiniBand. Im Gegensatz dazu unterstützt HPE mit Synergy lediglich Ethernet und Fibre Channel für Storage.

Anwendungen für Composable Infrastructure

Composable Infrastructure wurde ursprünglich als Methode konzipiert, kostspielige GPUs in einer KI-Umgebung gemeinsam zu nutzen, insbesondere für das rechenintensive Modelltraining. Allerdings eignet sich Composable auch für HPC-Cluster und Bare-Metal-Cloud-Infrastrukturen, insbesondere für kleine Nischenanbieter. Die Technologie passt auch gut zu von mehreren Kunden verwendeten Edge Compute Clustern. Beispiele sind 5G-Basissationen oder Mikro-Cloud-Regionen. Composable Fabrics mit mehreren Knoten, die PCIe-zu-NVMe, NVMe-oF oder InfiniBand verwenden, sind eine beliebte Option für verteilte Scale-Out-Storage-Systeme. Dort teilen sich mehrere Server viele gepoolte NVMe-Disks.

Unabhängig von PCIe-Fabrics werden PCIe-NICs, GPU- und FPGA-Karten immer häufiger gemeinsam genutzt und virtuell zwischen mehreren VMs aufgeteilt, die Technologien wie virtualisierte Nvidia-GPUs, gemeinsam verwendete FPGAs, SmartNICs oder Data Processing Units (DPUs) verwenden. VMware beispielsweise gab kürzlich bekannt, dass sein Projekt Monterrey einige Funktionen von VMware Cloud Foundation auf DPUs wie Nvidias BlueField-2 ausdehnen soll. Mit der Software können mehrere ARM-Cores einer DPU eine ESXi-Instanz hosten, die Netzwerk- und Storage-Services für die Host-CPU übernimmt.

Langfristig, so meint Kit Colbert, Cloud-CTO bei VMware, soll Monterrey diverse Hosts und andere Hardwarebeschleuniger unterstützen.

„Durch das Projekt können wir Cluster-Architekturen neu konzipieren und Cluster bauen, die dynamischer, stärker durch APIs gesteuert und besser auf die Applikationen abgestimmt sind“, schreibt er in einem Blog-Eintrag. „Das ermöglichen wir durch Hardware Composability.“

Die Optionen, Hardware gemeinsam zu nutzen und dynamisch über mehrere Server hinweg zuzuweisen, nehmen stark zu. Sie eröffnen einen breiteren Zugriff auf Hardwarebeschleuniger und niedrigere Kosten durch bessere Hardwareauslastung.

Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.

Erfahren Sie mehr über Storage Management

ComputerWeekly.de
Close