InfiniBand- und Ethernet-Dualprotokollmigration für KI

InfiniBand- und Ethernet-Dualprotokollmigration für KI

Entwicklung von Dual-Protokoll-Geweben

Entwicklung von Dual-Protokoll-Geweben
  • KI- und HPC-Teams stehen unter Druck, GPU-Cluster auszubauen, Workloads zu konsolidieren und Netzwerke zu modernisieren, ohne bestehende InfiniBand-basierte Anwendungen zu beeinträchtigen. Gleichzeitig etablieren sich Ethernet-Spine-Leaf-Fabrics als Standard für die gemeinsame Anbindung von Rechenzentren und den Ost-West-Verkehr. Dies führt zu einem stark eingeschränkten Übergang, bei dem der Betrieb mit zwei Protokollen und eine schrittweise Migration oft die einzig praktikable Lösung darstellen.

    Dieser Abschnitt beschreibt die Entwicklung einer Dual-Protokoll-Fabric, die bestehende InfiniBand-Systeme mit neuen Ethernet-basierten KI- und HPC-Domänen verbindet. Dabei werden InfiniBand- und Ethernet-Switches schrittweise eingeführt. Die folgenden Abschnitte konzentrieren sich darauf, wo natives InfiniBand beibehalten, wo es durch leistungsstarkes Ethernet erweitert werden sollte und wie Migrationsphasen strukturiert werden, um Leistung, Risiko und Kosten in GPU-intensiven Umgebungen optimal auszubalancieren.

Konflikte im Dual-Protokoll-KI/HPC-Fabric-Design

Die Balance zwischen InfiniBand- und Ethernet-Koexistenz, KI/HPC-Leistung und Migrationsrisiko macht die Planung einer Dual-Protokoll-Fabric äußerst komplex.

Konflikte im Dual-Protokoll-KI/HPC-Fabric-Design
  • Aufrechterhaltung verlustfreier Leistung über verschiedene Stoffarten hinweg

    Die Koordination von Latenz-, Überlastungs- und Verlustdomänen über InfiniBand und Ethernet hinweg, ohne KI- oder MPI-Workloads zu beeinträchtigen, ist schwer zu modellieren.

  • Phasenweise Migration ohne ungenutzte Kapazitäten

    Die Bereitstellung von Spine-Leaf- und Direktoren-Komponenten über InfiniBand und Ethernet unter Vermeidung von ungenutzten GPUs, Ports und Überkapazitäten stellt eine planungstechnische Herausforderung dar.

  • Betriebliche Komplexität von Dual-Fabrics

    Der Betrieb von zwei Steuerungsebenen, Telemetrie-Stacks und Änderungsfenstern erhöht den Radius der Ausfallfolgen und erfordert eine einheitliche Transparenz und Steuerung.

Dual-Protokoll-KI-Fabric-Prioritäten

Wichtige Überlegungen für die Weiterentwicklung von InfiniBand AI-Clustern hin zu Ethernet-fähigen, gemischtprotokollfähigen Fabrics.

Phasenweise InfiniBand-Entwicklung

Modernisierung bestehender IB-Infrastrukturen ohne Beeinträchtigung von KI- und HPC-Schulungsarbeitsplätzen.

Einheitliches Zweistoffdesign

Entwerfen Sie eine Spine-Leaf-Architektur, bei der InfiniBand und Ethernet für KI-Cluster parallel skalieren.

Migrationsrisikokontrolle

Minimieren Sie das Umstellungsrisiko durch stufenweise Erweiterung, Verkehrstrennung und klare Rückfahrpfade.

InfiniBand vs. Dual-Protocol Fabric Vergleich

Klären Sie, wann InfiniBand-only-Cluster beibehalten werden sollten und wann Ethernet Spine-Leaf für eine schrittweise Migration auf Dual-Protokoll für KI und HPC eingeführt werden sollte.

Funktion InfiniBand-exklusives Gewebe
Dual-Protokoll InfiniBand + Ethernet (hot)
Ergebnis für Sie
Einsatzpassung Homogene InfiniBand-Spine-Leaf-Architektur mit MSB7560-E / MSB7880 / MSB7800 für eng gekoppelte HPC-Jobs. Gemischte Fabric mit bestehendem InfiniBand plus Ethernet Leaf/Spine (MSN4600, MSN3750, MSN2700, MSN2010) für Ost-West-KI-Verkehr. Wählen Sie einen Bereitstellungspfad, der die Stabilität des aktuellen HPC-Systems gewährleistet und gleichzeitig die Ethernet-Kapazität dort erweitert, wo das Wachstum von KI und Speicher am schnellsten erfolgt.
Arbeitslastfokus Optimiert für latenzempfindliche MPI- und traditionelle HPC-Simulationen mit vorhersagbaren Kommunikationsmustern. Unterstützt sowohl MPI/HPC als auch datenparallele KI, Microservices, Speicherdatenverkehr über Standard-Ethernet und RoCE. Richtet die Netzwerkentwicklung an Ihrem Workload-Mix aus, anstatt das Design ausschließlich auf klassische HPC-Muster zu beschränken.
Leistung und Latenz Konstant niedrige Latenz und hoher Durchsatz innerhalb von InfiniBand-Fabrics; begrenzte Flexibilität für Nicht-HPC-Datenströme. InfiniBand erhält die kritischen Pfade mit niedriger Latenz aufrecht, während das Ethernet-Fabric den sprunghaften Datenverkehr von KI-Systemen, Data Lakes und Backups aufnimmt. Gewährleistet die Leistungsfähigkeit eng gekoppelter Jobs und verhindert gleichzeitig, dass störende Nachbarprozesse KI und gemeinsam genutzte Dienste beeinträchtigen.
Skalierbarkeit und Erweiterung Für eine Skalierung werden mehr InfiniBand-Chassis/Leitungskarten benötigt; die Erweiterung ist tendenziell monolithisch und kapitalintensiv. Ethernet Spine-Leaf kann modular zusammen mit InfiniBand skaliert werden, wodurch die Kapazität pro KI-Cluster oder Rack erhöht wird. Ermöglicht schrittweises Wachstum und eine reibungslosere Budgetplanung anstelle von disruptiven, netzwerkweiten InfiniBand-Upgrades.
Integration und Interoperabilität Starke Leistung innerhalb von HPC-Inseln; komplexer in der Integration mit Cloud-Gateways, bestehendem DC-Ethernet und Observability-Tools. Native Kompatibilität mit Data Center Ethernet, Standardwerkzeugen und Hybrid Cloud-Konnektivität, während InfiniBand für den Kernbereich HPC erhalten bleibt. Vereinfacht die Integration in bestehende Rechenzentrumsnetzwerke und Cloud-Anbindungen und reduziert so Reibungsverluste bei KI- und Analyse-Pipelines.
Operative Komplexität Einheitlicher Protokoll-Stack und Toolchain, aber begrenzte Flexibilität für zukünftige KI-orientierte Architekturen. Zwei Frameworks, aber gemeinsames Mellanox-Ökosystem; ermöglicht die Abstimmung von Management, Automatisierung und Überwachung über IB und Ethernet hinweg. Es gleicht die erhöhte Protokollkomplexität mit besserer operativer Kontrolle und zukunftssicherer Architektur für das Wachstum von KI aus.
Kostenprofil Hohe Leistung, aber höhere Kosten pro Port und geringere Wiederverwendung von Standard-Ethernet-Komponenten und -Optiken. Nutzt Ethernet-Kenntnisse, Optiken und Werkzeuge wieder; ermöglicht gezielte InfiniBand-Investitionen dort, wo extrem niedrige Latenzzeiten erforderlich sind. Optimiert die Gesamtbetriebskosten, indem die Ausgaben für InfiniBand für kritische Pfade reserviert und gleichzeitig kosteneffektives Ethernet in großem Umfang genutzt wird.
Migrationspfad und Risiko Stabil für den Status quo; schwierig, neue KI- oder Speichertopologien ohne grundlegende Neugestaltung einzuführen. Unterstützt die schrittweise Migration: Beginnen Sie mit gemischten Fabrics und verlagern Sie dann nach und nach mehr Datenverkehr oder Racks auf Ethernet, je nach Bedarf. Reduziert Migrationsrisiken und Ausfallzeiten, indem es Ihnen ermöglicht, in einem kontrollierten, projektbezogenen Tempo in Richtung KI-fähiger Systeme zu wechseln.

Benötigen Sie Hilfe? Technische Experten stehen Ihnen jetzt zur Verfügung.

  • +1-626-655-0998 (USA)
    UTC 15:00-00:00
  • +852-2592-5389 (HK)
    UTC 00:00-09:00
  • +852-2592-5411 (HK)
    UTC 06:00-15:00
Benötigen Sie Hilfe? Technische Experten stehen Ihnen jetzt zur Verfügung.

Ideale Einsatzszenarien

Entwickelt für KI- und HPC-Betreiber, die von InfiniBand auf Dual-Protokoll-Architekturen umsteigen und gleichzeitig bestehende GPU- und Cluster-Investitionen schützen möchten.

KI-Supercomputing-Cluster erweitern sich von InfiniBand auf Ethernet

KI-Supercomputing-Cluster erweitern sich von InfiniBand auf Ethernet

  • Bestehende GPU-Trainingscluster können auf älteren InfiniBand-Plattformen betrieben werden, während gleichzeitig Ethernet-basierte Knoten zur Kapazitätserweiterung eingeführt werden, ohne laufende Aufträge zu unterbrechen.
  • Um Hotspots während der Modelliteration zu vermeiden, wird der Ost-West-KI-Trainingsverkehr über InfiniBand und die Nord-Süd-Datenerfassung über Ethernet segmentiert.
  • Nutzen Sie Spine-Leaf-Designs mit Dual-Protokoll, um neue Ethernet-Top-of-Rack-Switches mit InfiniBand-Fabrics zu verbinden und so eine nahtlose Skalierung von GPU-Pods zu ermöglichen.
HPC-Forschungszentren modernisieren Mischprotokoll-Architekturen

HPC-Forschungszentren modernisieren Mischprotokoll-Architekturen

  • Aufrechterhaltung latenzarmer InfiniBand-Verbindungen für MPI-Workloads bei gleichzeitiger Integration von Ethernet-basierten Speicher- und Visualisierungsclustern in dasselbe Fabric.
  • Isolierte Testumgebungen für neue Ethernet-basierte HPC-Scheduler und Container bei gleichzeitiger gemeinsamer Nutzung von InfiniBand-Backbones mit Produktions-Rechenwarteschlangen.
  • Führen Sie Ethernet-Spine-Switches zusammen mit InfiniBand-Direktoren ein, um einen schrittweisen Migrationspfad für HPC-Knoten und -Instrumente der nächsten Generation zu schaffen.
Unternehmensrechenzentren integrieren KI-Workloads in bestehende Infrastrukturen

Unternehmensrechenzentren integrieren KI-Workloads in bestehende Infrastrukturen

  • Verbinden Sie GPU-Trainingsracks über InfiniBand mit bestehenden Enterprise-Ethernet-Kernen unter Verwendung von Dual-Protokoll-Aggregation für einheitlichen Betrieb und Überwachung.
  • Führen Sie latenzsensitive Inferenzprozesse über InfiniBand durch, während Sie gleichzeitig Massenanalysen, Protokollierung und Backup-Datenverkehr über Ethernet leiten, um die Leistungsfähigkeit der KI-Infrastruktur aufrechtzuerhalten.
  • Setzen Sie Ethernet-Top-of-Rack-Switches für Allzweckserver zusammen mit InfiniBand-Leaf-Switches für KI-Knoten innerhalb des gleichen Rechenzentrumslayouts ein.
Cloud- und XaaS-Anbieter, die KI und HPC als Dienstleistung anbieten

Cloud- und XaaS-Anbieter, die KI und HPC als Dienstleistung anbieten

  • Bieten Sie Mietern InfiniBand-gestützte KI-Instanzen an und nutzen Sie gleichzeitig Ethernet-basierte Frontend- und Steuerungsnetzwerke für das Multi-Tenant-Onboarding.
  • Implementieren Sie Dual-Protokoll-Pods, bei denen InfiniBand die Bare-Metal-Knoten der GPUs und Ethernet die Kubernetes- oder VM-Infrastruktur in derselben Region verbindet.
  • Nutzen Sie Ethernet-Spine-Leaf-Fabrics, um die Kapazität in neuen Verfügbarkeitszonen zu erweitern und gleichzeitig Verbindungen zu älteren InfiniBand-Clustern für gemeinsam genutzte GPU-Pools herzustellen.
Vertikale Branchen, die Analysen und Simulationen mit niedriger Latenz durchführen

Vertikale Branchen, die Analysen und Simulationen mit niedriger Latenz durchführen

  • Behalten Sie Echtzeit-Risiko-, CFD- oder EDA-Simulationen auf InfiniBand bei, während Sie Datenspeicher und Berichtsplattformen auf Ethernet verlagern, ohne die Kernarchitektur zu ändern.
  • Verbinden Sie OT-Gateways und Sensoraggregationsknoten über Ethernet mit InfiniBand-basierten Rechenfarmen für nahezu Echtzeit-Analysen und digitale Zwillinge.
  • Nutzen Sie Dual-Protokoll-Fabrics, um regulierte Workloads auf InfiniBand von weniger sensiblen Analysen auf Ethernet innerhalb desselben Rechenzentrums zu trennen.

Häufig gestellte Fragen

Wie entscheide ich mich zwischen InfiniBand- und Ethernet-Switches für eine schrittweise Migration von KI- oder HPC-Systemen?

  • Für GPU-intensive KI-Trainings oder eng gekoppelte HPC-Workloads, die bereits auf InfiniBand aufgebaut sind, werden Modelle wie MLNX:MSB7560-E und MLNX:MSB7880-ES2R typischerweise als Kernstruktur positioniert, um niedrige Latenz und RDMA-Leistung während der ersten Migrationsphasen zu gewährleisten.
  • Wenn Sie den Ost-West-Verkehr für Speicher, Microservices oder Front-End-Zugriff erweitern und gleichzeitig Ihre bestehende InfiniBand-Fabric beibehalten möchten, sind Ethernet-Spine-Leaf-Switches wie MLNX:MSN4600-VS2RO und MLNX:MSN3750-VS2RSC besser geeignet, um IP-, Orchestrierungs- und zukünftige KI-over-Ethernet-Segmente zu übertragen.
  • Ein praktischer Ansatz besteht darin, latenzempfindliche GPU-Trainingsaufträge auf InfiniBand auszuführen und gleichzeitig weniger latenzkritische KI-Inferenz-, Datenerfassungs- und Managementebenen schrittweise auf Ethernet umzustellen, um so eine Dual-Protokoll-Architektur zu entwickeln, ohne bestehende Cluster zu beeinträchtigen.

Können diese InfiniBand- und Ethernet-Switches mit meinen aktuellen Servern und Adaptern zusammen betrieben werden?

  • In den meisten Dual-Protokoll-Designs werden InfiniBand-Switches wie MLNX:MSB7880-ES2F oder MLNX:MSB7800-ES2R direkt mit vorhandenen InfiniBand HCAs in GPU-Servern verbunden, während Ethernet-Switches wie MLNX:MSN2700-CS2FC und MLNX:MSN2010-CB2F IP-Netzwerke, Speicherdatenverkehr und die Northbound-Konnektivität verwalten.
  • Wichtige Prüfungen vor der Bestellung umfassen: unterstützte Verbindungsgeschwindigkeiten für Ihre Netzwerkkarten, Kabel- und Transceivertypen (DAC, AOC, Optik) und ob Ihr Betriebssystem und Ihre Treiber gegebenenfalls sowohl RoCE als auch natives InfiniBand unterstützen.
  • Wenn Sie sich bezüglich der Kompatibilität von Adapter, Firmware oder Betriebssystem unsicher sind, können Sie sich zur Designvalidierung und für Vorabprüfungen an unser technisches Team wenden über kostenloser CCIE-SupportBitte beachten Sie: Die genauen Garantiebedingungen und Supportleistungen können je nach Produkt und Region variieren. Genaue Informationen finden Sie in den offiziellen Produktinformationen. Bei weiteren Fragen wenden Sie sich bitte an: router-switch.com.

Worauf sollte ich beim Einsatz einer gemischten InfiniBand- und Ethernet-Fabric für KI-Cluster achten?

  • In Dual-Protokoll-Netzwerken sind die häufigsten Probleme Überbelegung und nicht aufeinander abgestimmte QoS-Richtlinien zwischen InfiniBand- und Ethernet-Domänen, was zu unvorhersehbarer Leistung bei GPU-Aufträgen führen kann, wenn der Datenverkehr Gateways oder konvergierte Knoten durchläuft.
  • Planen Sie eine klare Segmentierung der Verkehrstypen: Halten Sie den GPU-Trainingsverkehr in Ost-West-Richtung nach Möglichkeit über InfiniBand, während Sie Ethernet für den Speicherzugriff, die Orchestrierung und den Benutzerzugang verwenden. Stellen Sie außerdem sicher, dass die Puffer- und Staukontrolleinstellungen durchgängig optimiert sind, wenn RoCE aktiviert wird.
  • Wichtig ist es außerdem, für beide Protokolldomänen auf getestete Kabel- und Transceiverkombinationen zu standardisieren und den Umstieg mit einem Rücksetzplan zu gestalten, damit etwaige Interoperabilitätsprobleme zwischen bestehender Ausrüstung und neuen MLNX-Switches isoliert werden können, ohne die Produktionscluster zu beeinträchtigen.

Gibt es Leistungs- oder Funktionseinschränkungen beim Betrieb von Dual-Protokoll-Netzwerken während der Migration?

  • Bei einer schrittweisen Migration können Sie möglicherweise nicht alle erweiterten Funktionen auf beiden Fabrics gleichzeitig aktivieren; beispielsweise sind bestimmte Optionen für das Staumanagement oder die Telemetrie möglicherweise nur auf der InfiniBand-Seite oder nur auf neueren Ethernet-Plattformen wie MLNX:MSN4600-VS2RO verfügbar.
  • Der Datenverkehr, der über Gateways oder konvergierte Knoten von InfiniBand zu Ethernet geleitet werden muss, verursacht fast immer zusätzliche Latenz und weist möglicherweise nicht dasselbe Jitterprofil wie native InfiniBand-Pfade auf. Daher sollten leistungssensible Aufgaben nach Möglichkeit auf ein einziges Fabric beschränkt werden.
  • Sie sollten auch auf Firmware- und Softwarekonsistenz achten: Die Kombination älterer InfiniBand-Switches mit neuer MLNX-Spine-Hardware in derselben Steuerungsebene kann die Anzahl der Funktionen und Geschwindigkeiten, die Sie sicher aktivieren können, einschränken, insbesondere in großen KI- oder HPC-Clustern.

Was sollte ich über Kauf, Lieferzeit und Lebenszyklus dieser InfiniBand- und Ethernet-Switches wissen?

  • Lieferzeit und Verfügbarkeit für Modelle wie MLNX:MSB7560-E oder MLNX:MSN3750-VS2RSC können je nach Konfiguration, regionalem Lagerbestand und laufender Nachfrage aus KI-Projekten variieren. Daher ist jeder angegebene Zeitplan in der Regel von der Produktverfügbarkeit und Ihrem Lieferort abhängig.
  • Bei Projekten, die mit der Auslieferung von GPU-Servern abgestimmt sein müssen, überprüfen viele Kunden zunächst den Lebenszyklusstatus, die EOL/EOSL-Zeitpläne und empfohlene Ersatzprodukte für die Ziel-SKUs mithilfe unseres Systems. EOL-/EOSL-Prüfer um das Risiko von Aktualisierungen während des Projekts zu vermeiden.
  • Die Versandoptionen und typischen Logistikabläufe für verschiedene Regionen sind in unserem [Produktname/Ablaufbeschreibung] aufgeführt. Versandarten Die Richtlinien umfassen auch die Bedingungen, unter denen Express- oder Sammelsendungen arrangiert werden können, vorbehaltlich der Lager- und Speditionsbeschränkungen.

Wie werden Garantie, Rückgabe und Steuern bei diesen Dual-Protokoll-Netzwerklösungen gehandhabt?

  • Die Garantiebedingungen für InfiniBand- und Ethernet-Switches können je nach Modell und Region variieren. Bevor Sie Ihre Materialliste für die Migration von KI oder HPC abschließen, empfehlen wir Ihnen, unsere aktuellen Garantiebedingungen zu prüfen. Garantiebestimmungen und die Abdeckung für jede SKU in Ihrem Design zu bestätigen.
  • Wenn ein Gerät defekt ankommt oder während der Garantiezeit ausfällt, ist unser Rückgabeverfahren in der Dokumentation festgehalten. Rückgabeanweisungen, in denen erklärt wird, wie man eine RMA beantragt, Geräte verpackt und den Ersatz oder die Gutschriftabwicklung verfolgt.
  • Bei internationalen Einsätzen sollten Sie auch Importgebühren einplanen; unser Steuern und Zölle Dieser Leitfaden erläutert typische Vorgehensweisen, die endgültigen Beträge und Verantwortlichkeiten hängen jedoch stets von den Bestimmungen Ihres Landes und den gewählten Incoterms ab. Bitte beachten Sie: Die spezifischen Garantiebedingungen und Supportleistungen können je nach Produkt und Region variieren. Genaue Informationen finden Sie in den offiziellen Unterlagen. Bei weiteren Fragen wenden Sie sich bitte an: router-switch.com.

Weitere Lösungen

Ethernet vs InfiniBand for AI & HPC Networks

Ethernet vs. InfiniBand für KI- und HPC-Netzwerke

Ein fokussierter Vergleich von Ethernet und InfiniBand für KI/HPC-Fabrics – Latenz, Skalierung, RDMA und Kosten-Kompromisse.

KI- und HPC-Netzwerke
Lossless Ethernet for AI & HPC Networks

Verlustfreies Ethernet für KI- und HPC-Netzwerke

Entwickeln Sie verlustfreie Ethernet-Fabrics für KI und HPC mit RoCE-fähigem Design, Unterstützung bei der Staukontrolle und skalierbarer Netzwerkplanung mit niedriger Latenz.

Verlustfreies Ethernet
GPU Cluster Networking Solutions for AI Scale-Out

GPU-Cluster-Netzwerklösungen für die KI-Skalierung

Entwicklung von leistungsstarken Ethernet-Fabrics für KI-GPU-Cluster mit skalierbarer Topologieführung, latenzarmer Umschaltung und sofort einsatzbereiter Architektur.

KI-GPU-Cluster-Netzwerk