SDN-Dilemma: Linux-Kernel-Netzwerk vs. Kernel-Bypass

Sujal Das ist Chief Strategy und Marketing Officer bei Netronome, einem Anbieter von leistungsstarken x86-Co-Processing-Lösungen für Netzwerk, Sicherheit, Lastausgleich, Virtualisierung und SDN.

Wenn wir in den letzten 25 Jahren etwas im Technologiegeschäft gelernt haben, wäre es nicht zu unterschätzen, den Linux-Kernel zu unterschätzen. Warum waren dann so viele Netzwerkunternehmen so bemüht, den Linux-Kernel - oder genauer gesagt den Linux-Kernel-Netzwerkstapel - zu umgehen? Was könnte an den Netzwerkpaket-Arterien im Linux-Kernel so falsch sein, dass so viele von uns motiviert sind, sie zu umgehen?

Es gibt zwei Hauptgründe. Erstens ist der Kernel-Netzwerkstapel zu langsam - und das Problem wird nur noch schlimmer, wenn Server und Switches schneller vernetzt werden (10 GbE, 25 GbE und 40 GbE heute und in naher Zukunft 50 GbE und 100 GbE). . Zweitens ermöglicht die Handhabung von Netzwerken außerhalb des Kernels das Einstecken neuer Technologien, ohne dass der Kerncode des Linux-Kernels geändert werden muss.

Aus diesen beiden Gründen und mit dem zusätzlichen Vorteil, dass viele Kernel-Bypass-Technologien Open Source sind und / oder von Normungsgremien spezifiziert werden, drängen die Befürworter von Bypass-Lösungen die Betreiber von Rechenzentren weiterhin, diese zu übernehmen.

Kernel-Bypass-Lösungen

Wir haben in der Vergangenheit viele Kernel-Bypass-Lösungen gesehen, insbesondere RDMA (Remote Direct Memory Access), TOE (TCP Offload Engine) und OpenOnload. In jüngerer Zeit wurde DPDK (Data Plane Development Kit) in einigen Anwendungen verwendet, um den Kernel zu umgehen, und dann gibt es neue Initiativen wie FD.io (Fast Data Input Output), die auf VPP (Vector Packet Processing) basieren. Weitere werden wahrscheinlich in Zukunft entstehen.

Technologien wie RDMA und TOE erstellen einen parallelen Stapel im Kernel und lösen das erste Problem (nämlich "der Kernel ist zu langsam"), während OpenOnload, DPDK und FD.io (basierend auf VPP) das Netzwerk in den Linux-Benutzerbereich verschieben, um beide Probleme zu lösen Anforderungen an Geschwindigkeit und Technologie-Plug-Ins. Wenn Technologien im Linux-Benutzerbereich erstellt werden, werden Änderungen am Kernel vermieden, wodurch der zusätzliche Aufwand entfällt, der erforderlich ist, um die Linux-Kernel-Community von der Nützlichkeit der Bypass-Technologien und ihrer Übernahme durch Upstreaming in den Linux-Kernel zu überzeugen.

Netronom

Kernel-Bypass-Herausforderungen

Die Herausforderungen im Zusammenhang mit der Einführung paralleler Stapel außerhalb des Kernel-Netzwerkstapels sind für Rechenzentrumsbetreiber offensichtlich, die ihre Infrastruktur auf eine sehr große Anzahl von Servern skalieren müssen. Mit parallelen Netzwerkstapeln geht eine scheinbar endlose Liste von Problemen in Bezug auf Sicherheit, Verwaltbarkeit, Robustheit, Sperrung von Hardwareanbietern und Protokollkompatibilität einher.

Beispielsweise gibt es Implementierungen von Open vSwitch und OpenContrail, die DPDK als Kernel-Bypass-Ansatz verwenden. Die DPDK-Implementierungen sind auf zwei Arten eingeschränkt. Erstens ist es schwierig und manchmal unmöglich, Funktionen mit kernelbasierten Open-Source-Software-Innovationen schnell und im Gleichschritt zu entwickeln. Zweitens erfordert die Bereitstellung von Leistung und Sicherheit, die von VMs und Anwendungen benötigt werden, eine erhebliche Anzahl von x86-CPU-Kernen, wodurch die Gesamteffizienz der Rechenzentrumsinfrastruktur verringert wird.

Einige Rechenzentrumsbetreiber, die möglicherweise einige hundert Server verwalten müssen und eine einzelne Anwendung ausführen, wie z. B. High Performance Computing- oder High Frequency Trading-Cluster, finden es möglicherweise praktisch, solche parallelen Kernel-Bypass-Stapel zu verwenden. Gleiches gilt für dedizierte Speichercluster.

Aber kann die Verstopfung des Kernel-Netzwerkstapels behoben werden, ohne auf parallele Bypass-Stapel zurückzugreifen? Ja, kann es. Der richtige Weg, um die beiden oben genannten Probleme zu lösen, besteht darin, Wege zu finden, um die Leistung des Kernel-Netzwerkstapels transparent, mithilfe intelligenter Netzwerkhardware und ohne Herstellerbindung zu beschleunigen.

SmartNICs versuchen, diese Probleme zu lösen, ohne den Kernel zu umgehen. SmartNICs sind programmierbare NICS (Network Interface Cards), mit denen die Anbieter, die solche Produkte anbieten, Server-Netzwerkhardware mit Softwaregeschwindigkeit innovieren können - eine praktische Anforderung in einer modernen softwaredefinierten und NFV-fähigen Rechenzentrumsinfrastruktur.

Geben Sie SmartNICS ein

Netronome SmartNICs bieten sowohl grundlegende oder traditionelle NIC-Funktionen als auch erweiterte Funktionen, die von Cloud-Rechenzentren und Telekommunikationsdienstleistern benötigt werden. Zu diesen erweiterten Funktionen gehört die Möglichkeit, umfangreiche Netzwerkfunktionen auszulagern, z. B. virtuelle Switches und virtuelle Router, die in softwaredefinierten Netzwerkumgebungen und NFV-optimierten Computerservern verwendet werden. Die Möglichkeit, diese rechenintensiven Netzwerkfunktionen auf die SmartNIC zu verlagern, erhöht die Leistung und Sicherheit der VMs, erhöht die Anzahl der Anwendungen, die pro Server bereitgestellt werden können, und steigert die Effizienz des Rechenzentrums insgesamt. SmartNIC-Funktionen können sich mit Open Source-Netzwerkinnovationen wie Open vSwitch, OpenStack, OpenContrail und dem eBPF (Extended Berkeley Packet Filter) des IO Visor-Projekts schnell weiterentwickeln.

Die Vorteile der Bereitstellung von SmartNICs beschränken sich nicht nur auf eine höhere Leistung und einen umfassenderen Funktionsumfang. Es gibt auch erhebliche TCO-Einsparungen, da SmartNICs herkömmliche NICs ersetzen können, die in Servern verwendet werden. SmartNICs sind preislich wettbewerbsfähiger als herkömmliche NICs und bieten erhebliche Einsparungen, indem wertvolle Server-CPU-Ressourcen für VMs und Anwendungen freigesetzt und die Servereffizienz gesteigert werden. Angesichts der Tatsache, dass Server bis zu 60 Prozent der gesamten Infrastrukturkosten für Rechenzentren verbrauchen, verspricht die Möglichkeit, mithilfe von SmartNICs höhere Workloads pro Server zu unterstützen, erhebliche Einsparungen.

Befürworter der Kernel-Umgehung argumentieren gerne, dass die in SDN- und NFV-Anwendungen erforderliche Server-Netzwerkleistung mit leistungsstarken x86-CPU-Kernen erreicht werden kann. Daher sind nur herkömmliche Netzwerkkarten erforderlich. In praktischen Benchmarks und im realen Leben benötigen Kernel-Bypass-Mechanismen möglicherweise bis zu 24 CPU-Kerne, um die erforderliche Netzwerkleistung zu erzielen. Das verbraucht praktisch den gesamten Server nur für die Vernetzung.

SmartNIC-Anbieter sind sich einig, dass die Kernel-Netzwerkleistung ein echtes Problem darstellt, das sich nur verschlechtern wird, wenn Betreiber Rechenzentren bauen, um den Anforderungen einer immer größeren Anzahl von Mobil- und IoT-Geräten gerecht zu werden. Sie glauben jedoch nicht, dass die Umgehung des Betriebssystemkerns das Problem löst. Vielmehr müssen intensive Netzwerkverarbeitungsaufgaben im Linux-Kernel-Netzwerkstapel herstellerunabhängig auf SmartNICs ausgelagert werden, anstatt Implementierungen zu verwenden, die zu parallelen, redundanten Netzwerkstapeln führen.

SmartNICs adressieren diese Herausforderungen, indem sie die heute verfügbaren kernelbasierten Implementierungen von Netzwerkdatenpfaden auslagern und sich in der breiteren Linux-Open-Source-Community rasant weiterentwickeln. Linux-Kernel-Stack-Technologien wie eBPF und der Traffic Classifier versprechen SmartNIC-Anbietern wie Netronome, sich an den Linux-Kernel-Netzwerkstack zu halten und Rechenzentrumsbetreibern eine effiziente Skalierung zu ermöglichen.

Die durchschlagende Empfehlung der Linux-Community war immer, den Kernel-Bypass zu vermeiden. Wie alle grundlegenden und einfachen Ideen hat sich diese Idee in der Vergangenheit durchgesetzt, gilt heute und wird auch in Zukunft gelten.

Das New Tech Forum bietet einen Ort, an dem Sie neue Unternehmenstechnologien in beispielloser Tiefe und Breite erkunden und diskutieren können. Die Auswahl ist subjektiv, basierend auf unserer Auswahl der Technologien, die wir für wichtig und für die Leser von größtem Interesse halten. akzeptiert keine Marketingmaterialien zur Veröffentlichung und behält sich das Recht vor, alle eingebrachten Inhalte zu bearbeiten. Senden Sie alle Anfragen an [email protected]