Strategischer Technologiewechsel für die Cloud-Plattform
Wir bei IONOS haben im Zuge der Inbetriebnahme eines neuen Rechenzentrums in Frankfurt die technische Grundlage des IONOS-Cloud-Netzwerks von InfiniBand auf Ethernet umgestellt. Ziel: höhere Flexibilität, einfacheres Skalieren und eine bessere Kosteneffizienz – bei gleichbleibend niedriger Latenz für speicherintensive Workloads. Diese Migration von InfiniBand zu Ethernet ist ein konsequenter Schritt, um die Plattform langfristig zu modernisieren und zu vereinheitlichen.
InfiniBand kurz erklärt – Stärken und Grenzen im Überblick
InfiniBand ist eine Verbindungstechnologie, die sich durch hohe Geschwindigkeiten und geringe Latenz auszeichnet. Sie wurde speziell für die Anforderungen von Hochleistungsrechnern (HPC) entwickelt. Die erste Spezifikation wurde im Jahr 2000 veröffentlicht. Architekturen mit RDMA (Remote Direct Memory Access) lieferten extrem geringe Latenzen und hohen Durchsatz bei geringem CPU-Overhead, weshalb InfiniBand lange eine bevorzugte Wahl für Supercomputing und Speichernetze ist – zuletzt verstärkt im Kontext verteilter GPU-Cluster für KI-Training.
InfiniBand ist als verlustfreie, eng kontrollierte Fabric konzipiert. InfiniBand erzwingt Verlustfreiheit über kreditbasierte Flusskontrolle und priorisierbare Traffic-Klassen, was Latenz und Jitter unter Last deterministischer macht. Das begünstigt eng gekoppelte Cluster-Workloads, verteilte Speichersysteme und KI/ML-Trainings-Jobs.
Im Cloud-Alltag zeigten sich jedoch strukturelle Grenzen:
- L3-Routing fehlt nativ, Nord-Süd-Verkehr benötigt Gateways
- Bandbreiten-Engpässe und zusätzliche Komplexität durch Protokoll-Übersetzung
- Hohe Hardware- und Betriebskosten
- Konzentration auf einen Hauptanbieter (Vendor Lock-in)
- Enger Talentpool für Planung, Betrieb und Fehleranalyse
IONOS Cloud auf InfiniBand – was bisher gut funktionierte
Wir nutzen InfiniBand seit den frühen 2010er-Jahren als Hochgeschwindigkeits-Fabric, besonders für Netzwerk-Speicher mit RDMA. Dafür wurden RNBD (RDMA Network Block Device) und die zugrunde liegende Transport-Bibliothek RTRS entwickelt. Beide Komponenten sind Teil des Linux-Kernels (GPL-2.0) und ermöglichen den Zugriff auf Remote-Block-Devices mit sehr niedriger I/O-Latenz – die Basis für performanten Cloud-Speicher in unseren Compute-Umgebungen. Die kreditbasierte Flusskontrolle der Fabric stellt dabei konsistente Latenzen für RDMA-Pfad und Netzwerk-Storage sicher.
Warum jetzt Ethernet – die wichtigsten Beweggründe
Ethernet hat in den letzten Jahren technologisch deutlich aufgeholt. Mit RoCEv2 (RDMA over Converged Ethernet) und Initiativen wie dem Ultra-Ethernet-Konsortium rückt Ethernet in Latenz und Durchsatz in Bereiche, die für Cloud-Speicher- und KI-Workloads attraktiv sind. Für allgemeine Cloud-Workloads überwiegen aus Sicht von Architektur und Betrieb die Vorteile:
- Routen statt tunneln: Ausgereifte Layer-3-Protokolle vereinfachen Nord-Süd-Verkehr und Interkonnektivität
- Hyperscale-Skalierbarkeit: Leaf/Spine-Topologien wachsen modular in klaren Schritten
- Ökosystem und Kosten: Breite Anbieterbasis reduziert TCO und senkt Beschaffungsrisiken – im Gegensatz zu InfiniBand, das historisch stark von Mellanox/NVIDIA dominiert wird
- Know-how und Tools: Größerer Talentpool, etablierte Observability-Stacks, offene Automations-Werkzeuge
- RDMA auf Ethernet: Mit RoCEv2 und Lossless-Ethernet-Konfigurationen lässt sich die RDMA-Performance der InfiniBand-Welt erreichen
Unser neues Netzwerk-Design auf Ethernet
Wir bei IONOS haben den Cloud-Stack für Ethernet neu gedacht und RoCEv2 als gleichwertigen RDMA-Pfad etabliert. Die Ergebnisse aus umfangreichen Tests mit RNBD/RTRS bestätigen die Zielmarke: niedrige Latenzen und hohe IOPS auch über Ethernet.
Architekturelle Eckpfeiler:
- EVPN-VXLAN Leaf/Spine mit 400G Ethernet als robustes Underlay für unseren Cloud-SDN-Stack
- RoCEv2 mit strikter Fabric-Disziplin (PFC/ECN, Traffic-Class-Design) für verlässliche RDMA-Performance
- Disaggregation mit SONiC als offenes, containerisiertes Netzwerk-Betriebssystem – mehr Kontrolle über Features, Upgrades und Innovationstempo
- Konsequente Automatisierung für Provisionierung, Telemetrie und Validierung (CI-ähnliche Netzwerktests, globale Policy-Checks)
Das Ergebnis ist ein hochperformantes, modular skalierbares Design mit Hyperscale-Potenzial – von der ersten Rack-Unit bis zum großflächigen Multi-Pod-Ausbau.
Performance ohne Kompromisse: RNBD/RTRS über RoCEv2
Die priorisierte Anforderung an das neue Backbone lautete: keine Einbußen bei Latenz und Durchsatz für Netzwerk-Speicher. Unsere Storage-Teams haben RNBD/RTRS über RoCEv2 validiert und die Ziele bestätigt. Damit bleiben die etablierten Speicher-Pfade für Virtual Machines (VMs) und Block-Storage (inklusive virtueller HDD-Volumes) konsistent – nur das Transport-Medium ändert sich.
Komplexität raus, Wachstum rein – operative Vorteile im Betrieb
Die Umstellung reduziert technische und organisatorische Reibung:
- Weniger Gateways, weniger Engpässe: Internet-Anbindung ist nativ, Nord-Süd-Wege werden kürzer
- Besseres Kapazitäts- und Fehlermanagement: Einheitlicher Telemetrie-Stack über die gesamte Fabric
- Flexiblere Beschaffung: Mehr Hardware-Optionen, unabhängigere Roadmaps
- Schnellere Iterationen: SONiC und Disaggregation erhöhen die Änderungs- und Release-Geschwindigkeit
Frankfurt als Blaupause – und was als Nächstes folgt
Die erste großflächige Implementierung des neuen Designs ist im Rechenzentrum in Frankfurt produktiv. Der Blueprint dient künftig als Standard für neue Standorte – inklusive Ethernet-Fabric, RoCEv2-Validierung und SONiC-basiertem Betriebsmodell. Der Wechsel markiert eine nächste Entwicklungsstufe für das Rechenzentrums-Networking der IONOS Cloud.
Learnings aus dem Migrationsprojekt
- Architektur entscheidet: Ein sauberer, wiederholbarer Blueprint beschleunigt Rollouts und senkt das Risiko
- RDMA ist kein Alleinstellungsmerkmal von InfiniBand mehr: Mit RoCEv2 lässt sich RDMA-Performance auf Ethernet zuverlässig erreichen
- Disaggregation zahlt Dividenden: Offene NOS-Bausteine und ein breiter Hardware-Pool verringern Vendor Lock-in und TCO
- Automatisierung als Pflicht: Skalierbare Network Fabrics entstehen nicht manuell – Policies, Tests und Telemetrie sind integraler Bestandteil
Ausblick: Offenes Netzwerk, offenes Ökosystem
Wir bei IONOS setzen auf ein offenes, disaggregiertes Netzwerk-Ökosystem. Das erhöht die Innovationsgeschwindigkeit und macht die Plattform zukunftssicher – für klassische Cloud-Workloads ebenso wie für daten- und KI-getriebene Szenarien. Ethernet statt InfiniBand ist dabei ein zentraler Schritt auf dem Weg zu mehr Standardisierung und Skalierbarkeit.