100GbE-Netzwerkkarten: Fehlkäufe bei Server-NICs vermeiden

Der Engpass liegt nicht im Treiber, lässt sich nicht per Firmware-Update beseitigen und verschwindet auch nicht, wenn der Switch am anderen Ende 100 Gbit/s unterstützt.

Wer eine 100GbE-Netzwerkkarte für den Server auswählt, muss daher mehr betrachten als Portanzahl und maximale Linkrate. PCIe-Generation und Lane-Breite, die elektrische Anbindung des Steckplatzes, der Formfaktor, das thermische Design, Hardware-Offloading und die geplanten Transceiver bilden eine zusammenhängende Kette. Schon ein unpassendes Glied kann dafür sorgen, dass eine teure NIC im Rack deutlich unter ihren Möglichkeiten bleibt.

Das ist der Kern vieler Fehlkäufe bei Server-NICs: Die Karte funktioniert, der Link wird aufgebaut, und trotzdem steht die erwartete Leistung im produktiven Betrieb nicht zur Verfügung.

Die PCIe-Falle: Warum Bandbreite nicht gleich Durchsatz ist

Der verbreitetste Planungsfehler bei 100GbE-NICs liegt in der Unterschätzung der PCIe-Anbindung. Auf dem Datenblatt des Servers steht oft nur „PCIe x16“. Das sagt jedoch noch nicht, wie viele Lanes elektrisch tatsächlich angebunden sind. Ein mechanischer x16-Steckplatz kann mit x16, x8 oder in bestimmten Plattformen sogar mit weniger Lanes arbeiten.

Für die Beurteilung einer Server-Netzwerkkarte ist außerdem die Bandbreite pro Richtung entscheidend. Ethernet wird bei einer Vollduplex-Verbindung in beide Richtungen übertragen, während PCIe ebenfalls bidirektional arbeitet. Die Werte dürfen deshalb nicht einfach addiert oder mit der Gesamtbandbreite des Steckplatzes verwechselt werden.

Die nutzbare Bandbreite liegt unter dem theoretischen PCIe-Link-Wert, weil Protokoll- und Transaktions-Overhead berücksichtigt werden müssen. PCIe Gen3, Gen4 und Gen5 verwenden zwar jeweils 128b/130b-Encoding, unterscheiden sich aber deutlich bei der Transferrate pro Lane. Für die Praxis zählt nicht die Marketingangabe „PCIe x16“, sondern das Ergebnis aus Generation, Lane-Anzahl und tatsächlicher elektrischer Anbindung.

Für einen einzelnen 100GbE-Port ist PCIe Gen3 x16 die untere sinnvolle Grenze. PCIe Gen4 x8 bietet ebenfalls ausreichend Spielraum. Eine Karte mit zwei 100GbE-Ports stellt dagegen deutlich höhere Anforderungen. Wenn beide Ports gleichzeitig annähernd mit Leitungsgeschwindigkeit arbeiten sollen, muss die PCIe-Anbindung die kombinierte Datenmenge einschließlich Protokolloverhead bewältigen. PCIe Gen4 x16 oder PCIe Gen5 x8 sind dafür typische Ausgangspunkte.

Dabei geht es nicht nur um klassische Dateiübertragungen. In virtualisierten Umgebungen laufen gleichzeitig VM-Datenverkehr, Storage-over-Ethernet, Management, Replikation und möglicherweise Overlay-Netze über dieselbe Karte. Zwei Ports mit nominell jeweils 100 Gbit/s werden dann nicht automatisch zu einer nutzbaren Übertragungsleistung von 200 Gbit/s. Der PCIe-Bus, der Prozessor, der Arbeitsspeicher und die Konfiguration der Datenpfade müssen den Durchsatz ebenfalls tragen können.

Der Steckplatz muss elektrisch geprüft werden

In älteren Servergenerationen sind x16-Steckplätze häufig mechanisch voll ausgeführt, aber elektrisch nur mit x8-Lanes angebunden. Auch die Bestückung anderer Slots kann die Lane-Verteilung verändern. Manche Plattformen teilen die Anbindung zwischen mehreren Steckplätzen oder deaktivieren bestimmte Slots, wenn ein zusätzlicher Prozessor nicht installiert ist.

Vor der Bestellung gehören deshalb mindestens diese Punkte in die technische Prüfung:

• Ist der vorgesehene Steckplatz mechanisch und elektrisch x16 oder nur elektrisch x8?
• Welche PCIe-Generation unterstützt der Slot tatsächlich?
• Verändert sich die Lane-Verteilung, wenn GPUs, NVMe-Adapter oder RAID-Controller installiert sind?
• Ist der Slot an die CPU angebunden, die auch den vorgesehenen Workload verarbeitet?
• Unterstützt das Server-BIOS die konkrete Karte und ihren Boot- oder Management-Modus?

Gerade der letzte Punkt wird oft erst bei der Inbetriebnahme sichtbar. Ein Server kann die Karte im Betriebssystem erkennen, aber trotzdem kein PXE-Boot über diesen Port erlauben. Für Cluster- oder Bare-Metal-Umgebungen ist das keine Nebensache.

Eine 100GbE-NIC in einem PCIe-Gen3-x8-Slot ist nicht „etwas langsamer“. Sie ist an einer Schnittstelle angeschlossen, die den Port schon auf Protokollebene ausbremst.

Hardware-Offloading und CPU-Last bei 148,8 Mpps

100 Gbit/s klingen zunächst nach einer Frage der Leitungskapazität. Bei kleinen Paketen wird daraus jedoch vor allem eine Frage der Paketverarbeitung. Bei 64-Byte-Paketen kann ein 100GbE-Link bis zu 148,8 Millionen Pakete pro Sekunde erzeugen. Diese Paketrate muss nicht zwangsläufig vollständig von einem allgemeinen CPU-Kern verarbeitet werden – aber ohne geeignete Hardwarefunktionen und eine passende Treiberkonfiguration wird sie sehr schnell zum Problem.

Jedes Paket bringt Verwaltungsarbeit mit: Empfang, Zuordnung zu einer Warteschlange, Prüfung von Checksummen, Verarbeitung von Headern, Übergabe an den Netzwerkstack und gegebenenfalls Weiterleitung an eine virtuelle Maschine oder einen Storage-Dienst. Bei großen Datenblöcken fällt diese Arbeit pro übertragenem Byte weniger ins Gewicht. Bei Kleinpaketen dominiert sie.

Moderne 100GbE-Controller wie der Intel E810 oder der Broadcom BCM57508 bieten deshalb mehrere Offloading- und Skalierungsfunktionen:

• RSS (Receive Side Scaling): Eingehende Datenströme werden anhand von Flow-Informationen auf mehrere Empfangswarteschlangen und CPU-Kerne verteilt. Ohne eine funktionierende Verteilung kann ein einzelner Kern zum Flaschenhals werden, während weitere Kerne kaum ausgelastet sind.
• TSO (TCP Segmentation Offload): Die CPU übergibt größere Datenblöcke an die NIC. Die Netzwerkkarte übernimmt anschließend die Aufteilung in kleinere TCP-Segmente. Das reduziert die Zahl der notwendigen CPU-Operationen bei großen Transfers.
• LRO (Large Receive Offload): Mehrere eingehende Pakete werden, sofern der Datenpfad dies zulässt, zu größeren Einheiten zusammengefasst, bevor sie den Netzwerkstack erreichen.
• Checksum-Offloading: Die Berechnung und Prüfung von IPv4-, IPv6-, TCP- und UDP-Prüfsummen kann teilweise auf den Controller verlagert werden.
• Flow Director und Queue-Steuerung: Bestimmte Datenströme lassen sich gezielt Empfangswarteschlangen oder Prozessorkernen zuordnen. Das ist in Umgebungen mit vielen VMs und klar getrennten Datenpfaden besonders relevant.
• SR-IOV-Unterstützung: Virtuelle Funktionen können direkt virtuellen Maschinen zugewiesen werden. Dadurch sinkt der Umweg über den Hypervisor, allerdings steigen die Anforderungen an Planung, Monitoring und Sicherheitskonfiguration.

Offloading ist jedoch kein Schalter, der jede CPU-Last verschwinden lässt. Die tatsächliche Wirkung hängt vom Betriebssystem, vom Treiber, vom Hypervisor, von der Paketgröße und vom verwendeten Protokoll ab. Auch Netzwerkfunktionen wie Verschlüsselung, Paketfilter, virtuelle Switches oder Container-Netzwerke können den Datenpfad wieder stärker an die CPU binden.

Controller im Vergleich: Datenblattwerte reichen nicht

Ein reiner Vergleich der maximalen Mpps-Zahl sagt wenig über die Eignung einer Karte aus. Ein Controller kann bei großen TCP-Transfers hervorragend arbeiten, während ein anderer bei vielen kurzen Flows, virtuellen Funktionen oder bestimmten Storage-Protokollen Vorteile bietet. Entscheidend ist, wo die Pakete verarbeitet werden und wie gut sich die Queues an die CPU-Topologie des Servers anpassen lassen.

Der Intel E810 bietet unter anderem eine umfangreiche Steuerung von Flows und Warteschlangen. Broadcom-Controller verfolgen je nach Modell und Treiber einen teilweise anderen Ansatz bei Protokollprofilen und Beschleunigungsfunktionen. Daraus lässt sich nicht pauschal ableiten, dass eine Plattform grundsätzlich schneller ist. Für die Auswahl einer 100GbE-NIC sollten deshalb die konkreten Szenarien betrachtet werden:

1. Große sequentielle Transfers: Hier stehen Durchsatz, DMA-Verhalten und eine effiziente Segmentierung im Vordergrund.

2. Viele kleine Pakete: Die Anzahl der Queues, RSS, Interrupt-Steuerung und die Verteilung auf CPU-Kerne werden wichtiger.

3. Virtualisierung: SR-IOV, virtuelle Funktionen, Hypervisor-Unterstützung und die Begrenzung pro VM müssen zusammenpassen.

4. Storage-Verkehr: Latenz, determinierbares Verhalten und die Unterstützung des vorgesehenen Protokolls sind mindestens so relevant wie die maximale Linkrate.

5. Paketverarbeitung im Host: Firewalls, Load-Balancer und DPDK-Anwendungen benötigen einen anderen Datenpfad als ein einfacher Fileserver.

Bei DPDK-basierten Anwendungen wird der Netzwerkverkehr teilweise im User Space verarbeitet. Das kann die Latenz und den Durchsatz verbessern, bindet aber häufig dedizierte CPU-Kerne und verlangt eine sorgfältige Speicher- und NUMA-Planung. SR-IOV reduziert den Overhead des virtuellen Switches, nimmt dem Administrator aber nicht die Aufgabe ab, Ressourcen wie Queues, Interrupts und Bandbreite sinnvoll zu verteilen.

Für einen belastbaren Controllervergleich gehört deshalb nicht nur die Frage „Wie viele Mpps schafft die Karte?“ auf den Tisch. Ebenso wichtig ist, wie sich die Leistung bei unterschiedlichen Paketgrößen, mit aktivierter Virtualisierung und unter gemischter Last verhält.

Thermische Herausforderungen und Leistungsaufnahme moderner NICs

100GbE-Netzwerkkarten sind keine Low-Power-Komponenten. Der Intel E810-CQDA2, eine verbreitete Dual-Port-Karte, liegt im Testbetrieb mit DAC-Kabeln oder Kurzstrecken-Optiken bei ungefähr 16,6 bis 20,7 W. Bei Langstrecken-Transceivern kann die Leistungsaufnahme weiter steigen. Der genaue Wert hängt vom Transceiver, der Link-Auslastung, der Umgebungstemperatur und der Kühlung des Servers ab.

Die Verlustleistung entsteht nicht nur im Controller. Auch PHY-Bausteine, Speicher, Spannungswandler und die eingesetzten optischen Module tragen zur Wärmeentwicklung bei. In einem 1U- oder 2U-Gehäuse sitzt die NIC zudem in einem eng begrenzten Luftstrom. Eine Karte, die auf einem offenen Teststand unauffällig bleibt, kann in einem dicht bestückten Server deutlich höhere Temperaturen erreichen.

Thermisches Throttling muss nicht sofort als vollständiger Ausfall sichtbar werden. Möglich sind zunächst reduzierte Taktraten, schwankende Latenzen, Paketverluste unter Spitzenlast oder ein Link, der nach längerer Betriebszeit neu ausgehandelt wird. Im ungünstigsten Fall fällt die Verbindung nur bei hoher Umgebungstemperatur aus – also genau dann, wenn die Kühlreserven des Rechenzentrums ohnehin knapp sind.

Nicht jede 100GbE-Karte passt zu jedem Airflow

Die thermische Planung beginnt mit der Luftstromrichtung. Viele Server sind auf einen Luftstrom von vorne nach hinten ausgelegt. Eine NIC mit eigenem Lüfter oder definierter Kühlkanalführung muss zu diesem Konzept passen. In Plattformen mit umgekehrtem Airflow, ungewöhnlicher Rack-Montage oder rückseitiger Ansaugung ist die Standardkarte nicht automatisch geeignet.

Zu prüfen sind insbesondere:

1. Luftstromrichtung im Server: Die Kühlkonstruktion der Karte muss zur Plattform passen. Ein Lüfter, der gegen den vorgesehenen Luftstrom arbeitet, kann die Kühlung verschlechtern statt verbessern.

2. Position im Gehäuse: Karten in der Nähe von GPUs, RAID-Controllern oder NVMe-Adaptern werden durch die Abwärme benachbarter Komponenten zusätzlich belastet.

3. Abstand zwischen Hochleistungskarten: Ein freier Slot zwischen zwei besonders warmen Karten kann den Luftstrom verbessern. Ob dies möglich ist, hängt allerdings von der Lane-Verteilung des Servers ab.

4. Zulufttemperatur: Eine Umgebung mit dauerhaft hoher Zulufttemperatur lässt weniger thermische Reserve. Die zulässige Umgebungstemperatur der NIC darf nicht isoliert von der Serverplattform betrachtet werden.

5. Kühlungsart: Passive Karten benötigen einen ausreichend starken Gehäuseluftstrom. Aktive Varianten bringen mehr Eigenständigkeit bei der Kühlung, erzeugen aber zusätzliche Geräusche und benötigen selbst elektrische Leistung.

6. Transceiver-Bestückung: Vier optische Module können thermisch anders zu bewerten sein als ein kurzes DAC-Kabel. Der Steckertyp ist deshalb auch ein Kühlungsparameter.

Die Leistungsaufnahme der Karte muss außerdem in die Gesamtbilanz des Racks eingehen. Eine einzelne NIC mit rund 20 W wirkt zunächst unkritisch. In einem 2U-Server mit mehreren GPUs, schnellen NVMe-Laufwerken und zwei Dual-Port-NICs verändert sich die Situation jedoch deutlich. Dann geht es nicht mehr nur um die Nennleistung des Netzteils, sondern um die Fähigkeit der Lüfter und Luftkanäle, diese Leistung dauerhaft aus dem Gehäuse zu transportieren.

20 W an einer einzelnen NIC sind kein thermisches Detail. In einem dicht bestückten Server können sie den Unterschied zwischen stabiler Volllast und sporadischen Fehlern unter Dauerlast ausmachen.

Ein weiterer Punkt ist die Geräuschentwicklung. Aktive 100GbE-Karten können in einem leisen Entwicklungsserver störender sein als in einem Rechenzentrum mit ohnehin hoher Grundlautstärke. Für Edge-Installationen, kleine Technikräume oder Testumgebungen sollte der zusätzliche Lüfter deshalb in die Auswahl einfließen.

OCP 3.0 vs. PCIe: Strategische Slot-Planung im Server-Rack

Das Open Compute Project definiert mit OCP 3.0 einen dedizierten Steckplatz für Netzwerkkarten. Anders als eine klassische PCIe-NIC wird die Karte nicht in einen der Standardsteckplätze eingesetzt. Dadurch bleiben diese Slots für GPUs, NVMe-Adapter, RAID-Controller oder andere Beschleuniger frei.

In dicht bestückten Servern ist das ein praktischer Vorteil. Die Netzwerkanbindung konkurriert nicht automatisch mit jeder zusätzlichen PCIe-Karte um die verfügbaren Slots. Auch die mechanische Integration kann günstiger ausfallen, weil der Serverhersteller den OCP-Bereich von Anfang an in die Kühlungs- und Serviceplanung einbezieht.

OCP 3.0 ist allerdings kein universelles Versprechen auf Plug-and-play. Der gemeinsame Formfaktor bedeutet nicht, dass jede OCP-Karte in jedem Server vollständig unterstützt wird. Steckverbinder, Firmware, Managementfunktionen, Boot-Unterstützung und thermische Parameter müssen zusammenpassen.

OCP 3.0 und PCIe im direkten Vergleich

Die Formulierung „hot-swap-fähig“ sollte bei OCP 3.0 nicht pauschal verwendet werden. Ob sich eine Netzwerkkarte im laufenden Betrieb austauschen lässt, hängt von der konkreten Serverplattform, dem Management-Controller und den dafür vorgesehenen Servicefunktionen ab. Der Standard allein ersetzt nicht die Freigabe des Herstellers.

Wo OCP 3.0 sinnvoll ist

OCP 3.0 spielt seine Stärken vor allem in standardisierten Serverflotten aus. Wenn viele identische Systeme betrieben werden, kann die Integration in BIOS, Management und Ersatzteilstrategie den Betrieb vereinfachen. Auch in GPU-Servern oder Storage-Knoten mit knappem PCIe-Budget ist der dedizierte Netzwerksteckplatz wertvoll.

Typische Einsatzszenarien sind:

• Server mit mehreren GPUs, FPGAs oder Beschleunigerkarten
• Rechenzentren mit einer einheitlichen Plattform eines Herstellers
• Umgebungen, in denen der Austausch der Netzwerkkarte über den vorgesehenen Serviceweg erfolgen soll
• Systeme, bei denen die Standard-PCIe-Slots bereits für Storage oder Beschleunigung reserviert sind

Standard-PCIe-NICs bleiben dagegen die flexiblere Wahl, wenn unterschiedliche Servergenerationen, Hersteller und Betriebssysteme berücksichtigt werden müssen. Sie lassen sich leichter in bestehende Hardwareflotten integrieren und bieten eine größere Auswahl bei Controller, Portlayout und Kühlungsvariante.

Die Entscheidung sollte deshalb nicht allein nach dem Steckertyp fallen. Relevant ist, ob die Karte über die gesamte Lebensdauer des Servers in die Slot-, Firmware- und Ersatzteilstrategie passt.

Transceiver-Kompatibilität und die Tücke proprietärer Firmware

Bei 100GbE ist die Wahl des Transceivers ein eigenständiges Risikofeld. Viele Verbindungsprobleme entstehen nicht durch einen defekten Controller, sondern durch eine Kombination aus inkompatiblem Modul, ungeeigneter Faser, falscher Codierung oder einer Firmware, die bestimmte Herstellerkennungen ablehnt.

NICs und Switches lesen Informationen aus dem EEPROM des Transceivers aus. Dazu gehören unter anderem Herstellerkennung, Modulvariante und unterstützte Übertragungsparameter. Manche Plattformen akzeptieren Module verschiedener Anbieter, andere prüfen diese Angaben gegen eine interne Whitelist. Ein optisches Modul kann technisch zum Standard passen und trotzdem vom Gerät abgelehnt werden.

Das betrifft nicht nur billige Drittanbieterprodukte. Auch ein Modul, das in einer Switch-Plattform problemlos arbeitet, muss nicht automatisch mit der vorgesehenen Server-NIC funktionieren. Bei einer B2B-Beschaffung ist daher die Kombination aus Karte, Firmware, Switch und Verkabelung entscheidend – nicht die isolierte Typenbezeichnung des Transceivers.

Die wichtigsten Kompatibilitätsrisiken

• Whitelist-Abgleich: Vor dem Kauf muss geprüft werden, welche Transceiver der NIC- und Switch-Hersteller freigeben. Die Liste kann sich mit Firmware-Versionen ändern.
• Firmware-Lock-in: Ein Update kann die Erkennung zuvor verwendeter Drittanbieter-Module beeinflussen. Das sollte in Wartungs- und Rollback-Planungen berücksichtigt werden.
• Fasertyp: Ein 100G-LR4-Modul wird über Singlemode-Faser betrieben. Eine vorhandene Multimode-Verkabelung ist dafür nicht automatisch geeignet.
• Stecker und Paralleloptik: SR4- und ähnliche Varianten verwenden mehrere parallele Fasern. Die Patchfelder, MPO-Komponenten und Polarity müssen dazu passen.
• Breakout-Szenarien: Ein 100GbE-Port kann je nach NIC, Switch und Kabel in mehrere niedrigere Links aufgeteilt werden. Dafür müssen beide Endpunkte den vorgesehenen Modus unterstützen.
• DAC- und AOC-Kabel: Bei kurzen Strecken sind Direct-Attach- oder Active-Optical-Cables oft einfacher zu betreiben. Auch sie können jedoch codiert oder herstellerspezifisch freigeschaltet sein.
• Diagnosemöglichkeiten: DOM- oder DDM-Werte, Temperatur- und Laserdaten helfen bei der Fehlersuche. Die Anzeige dieser Werte ist aber nicht bei jeder Kombination vollständig verfügbar.

Die Reichweitenangaben sind dabei keine Planungsgarantie. Dämpfung, Patchfelder, Steckverbindungen, Biegeradien und die Qualität der Faserstrecke können die tatsächliche Reserve reduzieren. Bei älteren Verkabelungen sollte vor dem Umstieg auf 100GbE eine Messung oder zumindest eine belastbare Dokumentation der Strecke vorliegen.

Proprietäre Firmware als Beschaffungsrisiko

Ein Firmware-Lock-in wird besonders problematisch, wenn Server und Switch von unterschiedlichen Herstellern stammen. Die Karte kann den Link zum Switch zunächst aufbauen, aber nach einem Firmware-Update ein anderes Verhalten zeigen. Umgekehrt kann ein Switch ein Modul akzeptieren, das die NIC auf der Serverseite blockiert.

Für eine professionelle Beschaffung empfiehlt es sich, die Zielkombination vor dem Rollout mit genau den vorgesehenen Komponenten zu testen. Dazu gehören nicht nur Link-Up und Ping, sondern auch:

• Aushandlung der erwarteten Geschwindigkeit,
• Fehlerzähler auf beiden Seiten,
• Verhalten unter Dauerlast,
• Temperatur der NIC und Transceiver,
• Reaktion auf Reboots und Firmware-Updates,
• Nutzung von Breakout- oder FEC-Modi,
• Failover und Wiederaufbau des Links.

So wird aus einer vermeintlichen Kompatibilitätsfrage eine reproduzierbare technische Prüfung. Das ist insbesondere dann wichtig, wenn mehrere hundert Meter Faser, viele Patchpunkte oder eine heterogene Switch-Landschaft im Spiel sind.

Was bei der Auswahl einer 100GbE-NIC zusammengehört

Die fünf Themenbereiche lassen sich nicht unabhängig voneinander bewerten. Eine Karte mit passender PCIe-Anbindung kann thermisch ungeeignet sein. Eine gut gekühlte OCP-Karte kann an der Firmware des Servers scheitern. Und ein kompatibler Transceiver hilft nicht weiter, wenn die Karte in einem elektrisch zu knapp angebundenen Slot steckt.

Für die Vorauswahl einer 100GbE-Netzwerkkarte für B2B-Hardware sollten deshalb mehrere Angaben gemeinsam dokumentiert werden:

Die Tabelle ist kein Ersatz für die Kompatibilitätsprüfung. Sie zeigt aber, warum die Frage „Welche 100GbE-NIC ist die schnellste?“ zu kurz greift. In einem Server mit PCIe Gen4 x8 kann eine passende Einzelportkarte sinnvoller sein als eine theoretisch leistungsfähigere Dual-Port-Karte, deren beide Ports in der vorgesehenen Plattform nicht gleichzeitig ausgelastet werden können.

Auch der geplante Betrieb muss einbezogen werden. Für ein Storage-Netz mit großen Blöcken gelten andere Prioritäten als für eine Virtualisierungsplattform mit vielen kleinen Flows. Bei einer Firewall oder einem Load-Balancer sind Paketverarbeitung und Latenz entscheidender als ein maximaler Durchsatz im synthetischen Test. Und bei GPU-Servern kann die Frage der NUMA-Nähe wichtiger sein als ein zusätzlicher Port.

Die Beschaffung beginnt beim Server, nicht beim Produktkatalog

Eine belastbare 100GbE-NIC-Auswahl startet mit dem Zielserver. Zuerst werden Slot, PCIe-Generation und Lane-Verteilung geprüft. Danach folgen CPU- und NUMA-Topologie, verfügbare Kühlreserve, Netzteilbudget und der gewünschte Datenpfad. Erst dann ist klar, ob Standard-PCIe oder OCP 3.0 sinnvoll ist und ob eine Einzel- oder Dual-Port-Karte die richtige Größenordnung darstellt.

Bei der Verkabelung muss die Strecke vom Server bis zum Switch als Gesamtsystem betrachtet werden. Transceiver, Faser, Patchfelder, Breakout-Kabel und Firmware bilden eine Kompatibilitätskette. Eine günstige Einzelkomponente kann die Beschaffung verteuern, wenn sie später durch freigegebene Module ersetzt werden muss oder bei hoher Last sporadische Fehler verursacht.

Die wichtigste Prüfung vor dem Kauf lässt sich in fünf praktische Fragen übersetzen:

1. Kann der vorgesehene Slot die Datenrate tatsächlich transportieren?

2. Ist der Controller für Paketgröße, Virtualisierung und Protokolle des Workloads geeignet?

3. Kann der Server die zusätzliche Wärme dauerhaft abführen?

4. Passt der Formfaktor in die Plattform, inklusive BIOS- und Management-Unterstützung?

5. Sind Transceiver, Faser und Firmware an beiden Enden des Links kompatibel?

Wenn eine dieser Fragen offenbleibt, ist die Produktnummer allein keine belastbare Entscheidungsgrundlage. Eine Server-Netzwerkkarte mit 100 Gbit/s Linkrate ist erst dann richtig dimensioniert, wenn PCIe-Bus, CPU-Datenpfad, Kühlung und physische Verbindung gemeinsam funktionieren. Genau dort entscheidet sich, ob die Investition im Rack ankommt – oder nur auf dem Datenblatt.