Storage-Performance wird im Netz gewonnen oder verloren.

Nein. 25 GbE ist für viele Cluster ein sehr guter Einstieg, wenn Uplinks, Trennung, MTU, Queueing und Redundanz passen. 100 oder 200 GbE wird interessant bei vielen Hosts, hoher Ost-West-Last, NVMe-lastigen Workloads, GPU-Clustern oder sehr engen Latenzzielen.

Oft ja. Gebrauchte Mellanox- und NVIDIA-ConnectX-Adapter mit passenden Switches sind ein günstiger Weg zu RDMA-fähigen 56- oder 100-GbE-Fabrics für Storage- und Cluster-Netze. Entscheidend ist die Schnittstelle: RoCEv2 setzt mindestens einen ConnectX-3 Pro mit aktueller Firmware oder eine neuere Generation wie ConnectX-4 oder ConnectX-5 voraus, einfache ConnectX-3 können das nicht voll. Zu beachten ist außerdem, dass 56GbE ein Mellanox-eigenes Tempo ist und nur im reinen Mellanox-Verbund läuft; gegenüber Fremd-Switches fällt die Verbindung auf 40 GbE zurück. FDR-InfiniBand mit 56 Gbit/s ist davon zu unterscheiden. Wir prüfen Generation, Firmware, RoCE-Fähigkeit, End-of-Life und Verkabelung, bevor wir refurbished empfehlen.

Nein. RoCEv2 kann Latenz reduzieren und CPU entlasten, benötigt aber saubere PFC-/ECN-Konfiguration, passende Switches, NICs und Betriebserfahrung. Für viele iSCSI- oder NVMe/TCP-Setups ist ein gutes Ethernet-Design einfacher und robuster.

Im laufenden Datentransfer ja. RDMA verlagert die Transportverarbeitung in die Netzwerkkarte und überträgt direkt zwischen den Arbeitsspeichern beider Systeme, ohne TCP/IP-Stack, ohne Kernel-Eingriff und ohne CPU-Zyklen pro Paket; nur Verbindungsaufbau und Speicherregistrierung laufen einmalig über die CPU. In Hersteller-Benchmarks für NVMe-oF über RoCE sinkt die CPU-Last auf dem Storage-Server gegenüber iSCSI um grob 30 bis 45 Prozent, Microsoft nennt geringeren CPU-Verbrauch ausdrücklich als Vorteil von SMB Direct. Das bedeutet weniger CPU-Last bei gleichem Durchsatz oder mehr Durchsatz pro Kern; wo Software pro Kern lizenziert wird, etwa bei Datenbanken, wirkt das direkt auf die Kosten. Voraussetzung bleibt ein verlustfreies Fabric mit PFC und ECN. Wo das nicht gewünscht ist, ist iWARP über normales TCP eine einfachere, aber langsamere Alternative.

Ceph unterscheidet typischerweise Client/Public-Traffic und Cluster-/Replikationsverkehr. Je nach Größe und Last trennen wir diese Pfade logisch oder physisch, damit Rebalancing, Recovery oder Backfill nicht die VM- oder Client-Performance unkontrolliert beeinflussen.

Das hängt von Betrieb, Support, Budget und vorhandenen Standards ab. Wir betrachten unter anderem Cisco, Arista, HPE, H3C, Huawei, NVIDIA Networking, Dell und Edgecore sowie Open-Networking-Optionen wie das quelloffene SONiC oder das kommerzielle OcNOS, wenn das Betriebsteam dazu passt.

SONiC (Software for Open Networking in the Cloud) ist ein quelloffenes, Linux- und Debian-basiertes Netzwerk-Betriebssystem, bei dem jede Funktion als Container läuft. Über das Switch Abstraction Interface (SAI) arbeitet SONiC hardwareunabhängig auf Switches verschiedener Hersteller und ASICs: Hardware und Betriebssystem sind entkoppelt, kein Lock-in auf ein herstellereigenes NOS. Ursprünglich von Microsoft für Azure entwickelt, liegt SONiC seit 2022 bei der Linux Foundation; zum Ökosystem gehören unter anderem Microsoft, Google, Broadcom, NVIDIA, Dell, Arista und Cisco. Es läuft auf Whitebox- und Markenhardware von Edgecore, Dell oder NVIDIA auf Silizium von Broadcom, Marvell und NVIDIA. Die Stärken liegen genau dort, wo Datacenter-Fabrics sie brauchen: Spine-Leaf, BGP, ECMP, VXLAN/EVPN und hohe Portgeschwindigkeiten. OcNOS (IP Infusion) ist eine kommerzielle NOS-Alternative für offene, disaggregierte Hardware. Der Betrieb lebt von Automatisierung, etwa mit Ansible. Open Networking lohnt sich dann, wenn Sie eine herstellerunabhängige Fabric einheitlich automatisieren wollen und das Betriebsmodell dazu passt. Wir planen, integrieren und betreiben solche Setups, statt das Thema nur als Schlagwort zu führen.