SRD: Parallele Zustellung von Paketen und Latenz-Reduktion Performance-Schub in der EC2-Vernetzung
Anbieter zum Thema
Das Protokoll Scalable Reliable Datagram (SRD) wird wahlweise als alternatives Transportprotokoll zwischen EC2-Instanzen genutzt. Es bietet Loadbalancing über mehrere Pfade hinweg und arbeitet mit TCP und UDP zusammen – kann durch zwei Eigenschaften aber einen viel höheren Datendurchsatz erzielen.

SRD, Scalable Reliable Datagram, existiert als IEEE-Papier bereits seit 2020, doch seit Ende November 2022 ist es in einem Produkt allgemein und kostenlos verfügbar: in Amazon Elastic Network Adapter (ENA) Express. AWS hat bereits 2016 seinen Elastic Network Adapter (ENA) vorgestellt. Der ENA brachte Vorteile wie Checksummen-Erzeugung, empfängerseitige Steuerung und schließlich das Multi-Queue Device Interface.
Mit ENA Express erweitert AWS seit November 2022 diese Funktionen um die Vorteile des Scalable Reliable Datagram (SRD). Voraussetzung ist die Nutzung des AWS-Nitro-Stacks in der Nitro-Netzwerkkarte. Nutznießer sind also in erster Linie AWS-Kunden.
ENA Express soll mit dem SRD-Protokoll die Bandbreite vergrößern und die Tail-Latenz von TCP-Paketen erheblich verringern. Auf einem Single-Flow-TCP-Datenfluss soll SRD den Durchsatz von 5 Gbps auf 25 Gbps steigern und die Tail-Latenz von TCP-Paketen für Workloads mit hohem Datendurchsatz (sprich: High Performance Computing, HPC) um 85 Prozent senken. Klingt nach Hexenwerk, ist es aber nicht.
Funktionsweise von SRD
Das Geheimnis des erhöhten Datendurchsatzes liegt in der Möglichkeit, die Zustellung von UDP- und TCP-Paketen (Datagrams) zu parallelisieren. Wie UDP dient SRD dem Datentransfer, doch anders als UDP ist die SRD-Zustellung stets zuverlässig. Neben UDP ist TCP ein weiteres unterstütztes Transferprotokoll. Doch anders als TCP kann SRD Pakete, die sich auf dem Transferweg befinden, umsortieren und sie außer der Reihe zustellen. Das kann also auch parallel erfolgen und hilft so, den potenziellen Stau bei einem Single-Link-Zustellpunkt (Port) zu vermeiden. Stattdessen können die auf andere Bahnen umgeleiteten Datenpakete an verschiedenen Ports in nicht-sequenziellen Paketbündeln eintreffen. Das kann allerdings für manche Systeme eine Herausforderung darstellen.
Im nächsten Schritt nutzt ENA Express das SRD-Protokoll anstelle von GRE bzw. Vxlan usw., um Datenpakete zwischen Nitro-Hypervisor-Hosts zu übertragen. Das soll zu einer schnelleren, zuverlässigen Zustellung von potenziell umsortierten Datenpaketen verhelfen.
Dieses Verfahren hält sich noch im Rahmen des bekannten Konzepts des Equal-cost Multi-path Routing (ECMP) und ist an sich nichts Neues. Koppelt der Kunde jedoch zwei ENA Express Adapter in unterstützten Instanz-Typen miteinander, lassen sich nach AWS-Angaben für eng gekoppelte HPC-Workloads hohe Datendurchsätze und Leistungsraten erzielen.
AWS-Blogger Jeff Bar beschreibt einen Praxistest für den SRD-Einsatz auf EC2-Instanzen. Über die Anforderungen und Caveats haben Barrs Kollegen in der Ausgabe 40 des IEEE-Magazins geschrieben. Ihre Definition lautet klipp und klar: „SRD ist für Hyper-Scale-Rechenzentren optimiert. Es bietet Loadbalancing über mehrere Pfade hinweg und eine schnelle ‚Erholung‘, falls es zu Paketverlusten oder gescheiterten Link-Verbindungen kommen sollte.“ Dieser IEEE-Artikel geht auch näher auf Tail-End-Latenz ein.
Vermeidung der Tail-End-Latenz
Verringerte Tail-End-Latenz ist der zweite große Vorteil des SRD-Protokolls. Doch worum handelt es sich dabei? Der wichtige Punkt hier ist, dass die Tail-Latenz, also die höchste Latenz in einer Gruppe von Paketen über die Gesamtperformance entscheidet, ähnlich dem schwächsten Glied einer Kette. Dabei ist die durchschnittliche Latenz weniger wichtig. Wenn ich 10 Pakete parallel verschicke und mein HPC-Cluster erst dann weiter machen kann, wenn alle Pakete angekommen sind, dann hilft mir eine durchschnittliche Latenz von 1,9 Mikrosekunden nicht, wenn 9 Pakete in 1 Mikrosekunde ankommen, aber ein Paket 10 Mikrosekunden (das ist der Tail) braucht. Denn mein HPC-Cluster muss in diesem Fall dennoch 10 Mikrosekunden warten, bis er weiter rechnen kann.
Mit Tail-End-Latency ist die Latenz-Teit der „Nachzügler“-Pakete gemeint. Das können ein oder mehrere sein und diese sind unabhängig von der Reihenfolge. Das Tail-End ist also die Menge der Datenpakete, die am längsten brauchen, beispielsweise weil sie aufgrund von Störungen verloren gegangen sind und daher, wie bei TCP üblich, nach einem Timeout erneut verschickt werden mussten.
Und da liegt der Hase im Pfeffer: Der Mindest-Time-out liegt in den meisten Betriebssystemen bei wenigen Millisekunden, wohingegen die Fabric-Übertragungszeiten in wenigen Mikrosekunden, also einem Tausendstel, gemessen werden. Wird also dieser Time-out umgangen oder vermieden, erfolgt die Übertragung in Mikro- statt Millisekunden. Voilà, so lassen sich die oben genannten 85 Prozent der Tail-End-Latenz reduzieren, bei stets zuverlässiger Zustellung der Datenpakete.
Nachteile und Einschränkungen
Wie erwähnt, gibt es SRD derzeit nur bei AWS. Der Launch Ende November 2022 erfolgte laut Jeff Barr auf der 16xlarge-size-Variante der C6gn-Instanzen. Weitere Instanzen und Größen sollen folgen. ENA Express ist kostenlos und in allen kommerziellen AWS-Regionen verfügbar.
Voraussetzung ist die Nutzung des AWS-Nitro-Stacks in der Nitro-Netzwerkkarte. Nutznießer sind also in erster Linie AWS-Kunden. ENA Express braucht bestimmte Ressourcen einer Nitro-Netzwerkkarte, um Pakete zu verarbeiten. Diese Verarbeitung erhöht die Latenz pro Paket um ein paar Mikrosekunden und hat einen minimalen Effekt auf die maximale Anzahl der von einer Instanz verarbeitbaren Pakete pro Sekunde.
„Werden einmal hohe Paketraten mit einer niedrigen Paketgröße gekoppelt, könnte ENA Express daher nicht das Mittel der Wahl sein“, erläutert Jeff Barr. „In allen anderen Fällen kann man einfach SRD in der AWS Management Konsole einschalten, um konsistente Latenz und eine höhere Bandbreite pro Datenfluss zu genießen.“
(ID:49249175)