In modernen Rechenzentren sind Hunderte von aktiven Geräten installiert, die durch verschiedene Arten der Überwachung abgedeckt werden. Aber selbst ein idealer Techniker mit perfekter Überwachung kann in nur wenigen Minuten richtig auf einen Netzwerkausfall reagieren. In einem Bericht auf der Next Hop 2020-Konferenz habe ich eine Netzwerkdesign-Methodik für Rechenzentren vorgestellt, die eine einzigartige Funktion aufweist: Das Rechenzentrum heilt sich in Millisekunden selbst. Genauer gesagt behebt der Ingenieur das Problem in aller Ruhe, während die Dienste es einfach nicht bemerken.
Für viele Netzwerktechniker beginnt ein Rechenzentrumsnetzwerk natürlich mit ToR, mit einem Switch im Rack. ToR hat normalerweise zwei Arten von Links. Die Kleinen gehen zu den Servern, andere – es gibt N-mal mehr davon – gehen zu den Spines der ersten Ebene, also zu ihren Uplinks. Uplinks werden normalerweise als gleich betrachtet und der Datenverkehr zwischen Uplinks wird basierend auf einem Hash aus 5-Tupel ausgeglichen, der proto, src_ip, dst_ip, src_port, dst_port umfasst. Hier gibt es keine Überraschungen.
Wie sieht als nächstes die Planarchitektur aus? Stacheln der ersten Ebene sind nicht miteinander verbunden, sondern durch Superspines. Der Buchstabe X wird für Superspines verantwortlich sein; es ist fast wie eine Querverbindung.
Und es ist klar, dass Tori andererseits mit allen Stacheln der ersten Ebene verbunden sind. Was ist in diesem Bild wichtig? Wenn wir innerhalb des Racks interagieren, erfolgt die Interaktion natürlich über ToR. Wenn die Interaktion innerhalb des Moduls stattfindet, erfolgt die Interaktion über die Spines der ersten Ebene. Wenn die Interaktion intermodular ist – wie hier ToR 1 und ToR 2 –, dann verläuft die Interaktion über Spines sowohl der ersten als auch der zweiten Ebene.
Theoretisch ist eine solche Architektur leicht skalierbar. Wenn wir über Portkapazität, freien Platz im Rechenzentrum und vorverlegte Glasfaser verfügen, kann die Anzahl der Lanes jederzeit erhöht werden, wodurch die Gesamtkapazität des Systems erhöht wird. Das geht ganz einfach auf Papier. So würde es im Leben sein. Aber darum geht es in der heutigen Geschichte nicht.
Ich möchte, dass die richtigen Schlussfolgerungen gezogen werden. Wir haben viele Wege innerhalb des Rechenzentrums. Sie sind bedingt unabhängig. Ein Pfad innerhalb des Rechenzentrums ist nur innerhalb von ToR möglich. Innerhalb des Moduls haben wir die Anzahl der Pfade, die der Anzahl der Fahrspuren entspricht. Die Anzahl der Pfade zwischen Modulen entspricht dem Produkt aus der Anzahl der Ebenen und der Anzahl der Superspines in jeder Ebene. Um es klarer zu machen und ein Gefühl für die Größenordnung zu bekommen, werde ich Zahlen angeben, die für eines der Yandex-Rechenzentren gültig sind.
Es gibt acht Ebenen, jede Ebene hat 32 Superspines. Als Ergebnis stellt sich heraus, dass es innerhalb des Moduls acht Pfade gibt, und bei intermodularer Interaktion sind es bereits 256 davon.
Das heißt, wenn wir Cookbook entwickeln und versuchen zu lernen, wie man fehlertolerante Rechenzentren baut, die sich selbst reparieren, dann ist die planare Architektur die richtige Wahl. Es löst das Skalierungsproblem und ist theoretisch einfach. Es gibt viele unabhängige Wege. Bleibt die Frage: Wie übersteht eine solche Architektur Ausfälle? Es gibt verschiedene Fehler. Und darüber werden wir jetzt diskutieren.
Lassen Sie einen unserer Superspines „krank“ werden. Hier bin ich zur Zwei-Ebenen-Architektur zurückgekehrt. Wir bleiben bei diesen Beispielen, da es mit weniger beweglichen Teilen einfach einfacher ist, zu erkennen, was vor sich geht. Lassen Sie X11 krank werden. Wie wird sich dies auf die Dienste auswirken, die in Rechenzentren ausgeführt werden? Viel hängt davon ab, wie der Fehler tatsächlich aussieht.
Wenn der Fehler gut ist, wird er auf der Automatisierungsebene desselben BFD abgefangen, die Automatisierung platziert problemlos die problematischen Verbindungen und isoliert das Problem, dann ist alles in Ordnung. Wir haben viele Wege, der Verkehr wird sofort auf alternative Routen umgeleitet und die Dienste merken davon nichts. Das ist ein gutes Drehbuch.
Ein schlechtes Szenario ist, wenn wir ständig Verluste haben und die Automatisierung das Problem nicht bemerkt. Um zu verstehen, wie sich dies auf eine Anwendung auswirkt, müssen wir uns ein wenig mit der Funktionsweise von TCP befassen.
Ich hoffe, ich schockiere niemanden mit dieser Information: TCP ist ein Übertragungsbestätigungsprotokoll. Das heißt, im einfachsten Fall sendet der Absender zwei Pakete und erhält darauf eine kumulative Bestätigung: „Ich habe zwei Pakete erhalten.“
Danach sendet er zwei weitere Pakete und die Situation wird sich wiederholen. Ich entschuldige mich im Voraus für die Vereinfachung. Dieses Szenario ist korrekt, wenn das Fenster (die Anzahl der Pakete im Flug) zwei beträgt. Im allgemeinen Fall ist dies natürlich nicht unbedingt der Fall. Die Fenstergröße hat jedoch keinen Einfluss auf den Paketweiterleitungskontext.
Was passiert, wenn wir Paket 3 verlieren? In diesem Fall erhält der Empfänger die Pakete 1, 2 und 4. Und er teilt dem Absender mit der SACK-Option explizit mit: „Wissen Sie, drei sind angekommen, aber das mittlere ging verloren.“ Er sagt: „Ack 2, SACK 4.“
In diesem Moment wiederholt der Absender problemlos genau das verlorene Paket.
Geht aber das letzte Paket im Fenster verloren, sieht die Situation ganz anders aus.
Der Empfänger erhält die ersten drei Pakete und beginnt zunächst zu warten. Dank einiger Optimierungen im TCP-Stack des Linux-Kernels wartet dieser auf ein gepaartes Paket, es sei denn, die Flags geben explizit an, dass es sich um das letzte Paket handelt oder etwas Ähnliches. Es wartet, bis das verzögerte ACK-Timeout abläuft, und sendet dann eine Bestätigung für die ersten drei Pakete. Aber jetzt wird der Absender warten. Er weiß nicht, ob das vierte Paket verloren gegangen ist oder gleich ankommt. Und um das Netzwerk nicht zu überlasten, wird versucht, auf einen expliziten Hinweis darauf zu warten, dass das Paket verloren gegangen ist, oder auf den Ablauf des RTO-Timeouts.
Was ist ein RTO-Timeout? Dies ist das Maximum der vom TCP-Stack berechneten RTT und eine Konstante. Was das für eine Konstante ist, wollen wir nun besprechen.
Aber wichtig ist: Wenn wir erneut Pech haben und das vierte Paket erneut verloren geht, verdoppelt sich der RTO. Das heißt, jeder erfolglose Versuch bedeutet eine Verdoppelung des Timeouts.
Sehen wir uns nun an, was diese Basis ist. Standardmäßig beträgt die minimale RTO 200 ms. Dies ist die minimale RTO für Datenpakete. Bei SYN-Paketen ist es anders, 1 Sekunde. Wie Sie sehen, dauert bereits der erste Versuch, Pakete erneut zu senden, 100-mal länger als die RTT im Rechenzentrum.
Kommen wir nun zurück zu unserem Szenario. Was ist mit dem Dienst los? Der Dienst beginnt, Pakete zu verlieren. Lassen Sie den Dienst zunächst bedingt Glück haben und in der Mitte des Fensters etwas verlieren, dann empfängt er einen SACK und sendet die verlorenen Pakete erneut.
Aber wenn sich das Pech wiederholt, dann haben wir eine RTO. Was ist hier wichtig? Ja, wir haben viele Wege in unserem Netzwerk. Der TCP-Verkehr einer bestimmten TCP-Verbindung wird jedoch weiterhin über denselben defekten Stapel geleitet. Paketverluste führen, sofern unser magisches X11 nicht von alleine ausgeht, nicht dazu, dass der Verkehr in unproblematische Bereiche fließt. Wir versuchen, das Paket über denselben kaputten Stapel zuzustellen. Dies führt zu einem kaskadierenden Ausfall: Ein Rechenzentrum besteht aus einer Reihe interagierender Anwendungen, und einige der TCP-Verbindungen all dieser Anwendungen beginnen sich zu verschlechtern – da Superspine alle Anwendungen betrifft, die im Rechenzentrum vorhanden sind. Wie das Sprichwort sagt: Wenn man ein Pferd nicht beschlagen hat, wurde das Pferd lahm; das Pferd lahmte – der Bericht wurde nicht übermittelt; Der Bericht wurde nicht zugestellt – wir haben den Krieg verloren. Nur hier erfolgt die Zählung in Sekunden ab dem Moment, in dem das Problem auftritt, bis zu dem Stadium der Verschlechterung, das die Dienste zu spüren beginnen. Dies bedeutet, dass Benutzer möglicherweise irgendwo etwas verpassen.
Es gibt zwei klassische Lösungen, die sich gegenseitig ergänzen. Das erste sind Dienste, die versuchen, Strohhalme einzubauen und das Problem wie folgt zu lösen: „Lassen Sie uns etwas im TCP-Stack optimieren.“ Lassen Sie uns Zeitüberschreitungen auf Anwendungsebene oder langlebige TCP-Sitzungen mit internen Gesundheitsprüfungen vornehmen.“ Das Problem besteht darin, dass solche Lösungen: a) überhaupt nicht skalierbar sind; b) werden sehr schlecht überprüft. Das heißt, selbst wenn der Dienst den TCP-Stack versehentlich so konfiguriert, dass er besser wird, ist es erstens unwahrscheinlich, dass er für alle Anwendungen und alle Rechenzentren anwendbar ist, und zweitens wird er höchstwahrscheinlich nicht verstehen, dass dies geschehen ist richtig, und was nicht. Das heißt, es funktioniert, aber es funktioniert schlecht und lässt sich nicht skalieren. Und wenn es ein Netzwerkproblem gibt, wer ist schuld? Natürlich, NOC. Was macht NOC?
Viele Dienste glauben, dass in der NOC-Arbeit so etwas passiert. Aber um ehrlich zu sein, nicht nur das.
NOC im klassischen Schema beschäftigt sich mit der Entwicklung vieler Überwachungssysteme. Dabei handelt es sich sowohl um Black-Box- als auch um White-Box-Überwachung. Über ein Beispiel einer Black-Box-Wirbelsäulenüberwachung Alexander Klimenko beim letzten Next Hop. Diese Überwachung funktioniert übrigens. Aber selbst eine ideale Überwachung wird zeitverzögert sein. Normalerweise dauert dies einige Minuten. Nach dem Auslösen benötigen die diensthabenden Ingenieure Zeit, um die Funktion noch einmal zu überprüfen, das Problem zu lokalisieren und dann den Problembereich zu löschen. Das heißt, die Problembehandlung dauert im besten Fall 5 Minuten, im schlechtesten Fall 20 Minuten, wenn nicht sofort ersichtlich ist, wo die Verluste entstehen. Es ist klar, dass unsere Dienste während dieser ganzen Zeit – 5 oder 20 Minuten – weiterhin leiden werden, was wahrscheinlich nicht gut ist.
Was möchten Sie wirklich erhalten? Wir haben so viele Möglichkeiten. Und genau deshalb entstehen Probleme, weil TCP-Flüsse, die kein Glück haben, weiterhin dieselbe Route verwenden. Wir brauchen etwas, das es uns ermöglicht, mehrere Routen innerhalb einer einzigen TCP-Verbindung zu verwenden. Es scheint, dass wir eine Lösung haben. Es gibt TCP, das als Multipath-TCP bezeichnet wird, also TCP für mehrere Pfade. Allerdings wurde es für eine ganz andere Aufgabe entwickelt – für Smartphones, die über mehrere Netzwerkgeräte verfügen. Um die Übertragung zu maximieren oder den Primär-/Backup-Modus festzulegen, wurde ein Mechanismus entwickelt, der mehrere Threads (Sitzungen) transparent für die Anwendung erstellt und es Ihnen ermöglicht, im Fehlerfall zwischen ihnen zu wechseln. Oder, wie gesagt, den Streak maximieren.
Aber hier gibt es eine Nuance. Um zu verstehen, was es ist, müssen wir uns ansehen, wie Threads erstellt werden.
Threads werden nacheinander installiert. Der erste Thread wird zuerst installiert. Nachfolgende Threads werden dann mithilfe des Cookies gesetzt, das bereits in diesem Thread vereinbart wurde. Und hier ist das Problem.
Das Problem besteht darin, dass der zweite und dritte Thread niemals entstehen, wenn sich der erste Thread nicht etabliert. Das heißt, Multipath-TCP löst den Verlust eines SYN-Pakets im ersten Fluss nicht. Und wenn die SYN verloren geht, wird Multipath-TCP zu regulärem TCP. Dies bedeutet, dass es uns in einer Rechenzentrumsumgebung nicht dabei hilft, das Problem der Verluste in der Fabrik zu lösen und zu lernen, im Falle eines Ausfalls mehrere Pfade zu verwenden.
Was kann uns helfen? Einige von Ihnen haben anhand des Titels bereits erraten, dass ein wichtiges Feld in unserer weiteren Geschichte das IPv6-Flow-Label-Header-Feld sein wird. Tatsächlich ist dies ein Feld, das in Version 6 vorkommt, in Version 4 jedoch nicht, es belegt 20 Bit, und über seine Verwendung gab es schon lange Kontroversen. Das ist sehr interessant – es gab Streitigkeiten, etwas wurde innerhalb des RFC behoben und gleichzeitig erschien eine Implementierung im Linux-Kernel, die nirgendwo dokumentiert wurde.
Ich lade Sie ein, mit mir eine kleine Untersuchung zu unternehmen. Werfen wir einen Blick darauf, was in den letzten Jahren im Linux-Kernel passiert ist.
Jahr 2014. Ein Ingenieur eines großen und angesehenen Unternehmens erweitert die Funktionalität des Linux-Kernels um die Abhängigkeit des Flow-Label-Werts vom Socket-Hash. Was wollten sie hier reparieren? Dies hängt mit RFC 6438 zusammen, in dem das folgende Problem behandelt wurde. Innerhalb des Rechenzentrums ist IPv4 häufig in IPv6-Paketen gekapselt, da die Fabrik selbst IPv6 ist, IPv4 jedoch irgendwie nach außen gegeben werden muss. Lange Zeit gab es Probleme mit Switches, die nicht unter zwei IP-Headern nach TCP oder UDP suchen und dort src_ports, dst_ports finden konnten. Es stellte sich heraus, dass der Hash, wenn man sich die ersten beiden IP-Header ansieht, fast fest war. Um dies zu vermeiden und den Ausgleich dieses gekapselten Datenverkehrs korrekt zu gewährleisten, wurde vorgeschlagen, den Hash des 5-Tupel-gekapselten Pakets zum Wert des Flow-Label-Felds hinzuzufügen. Ungefähr das Gleiche wurde für andere Kapselungsschemata gemacht, für UDP und für GRE, wobei letzteres das GRE-Schlüsselfeld verwendete. So oder so sind die Ziele hier klar. Und zumindest zu diesem Zeitpunkt waren sie nützlich.
Im Jahr 2015 kommt ein neuer Patch von demselben angesehenen Ingenieur. Er ist sehr interessant. Darin heißt es: Wir werden den Hash im Falle eines negativen Routing-Ereignisses randomisieren. Was ist ein negatives Routing-Ereignis? Dies ist der RTO, den wir zuvor besprochen haben, das heißt, der Verlust des Fensterendes ist ein wirklich negatives Ereignis. Es stimmt, es ist relativ schwer zu erraten, ob es das ist.
2016, ein weiteres seriöses Unternehmen, ebenfalls groß. Es zerlegt die letzten Krücken und sorgt dafür, dass sich der Hash, den wir zuvor zufällig erstellt haben, nun bei jeder SYN-Neuübertragung und nach jedem RTO-Timeout ändert. Und in diesem Brief wird zum ersten und letzten Mal das ultimative Ziel genannt – sicherzustellen, dass der Verkehr im Falle von Verlusten oder Kanalüberlastungen sanft umgeleitet werden kann und mehrere Pfade nutzt. Danach gab es natürlich viele Veröffentlichungen, die man leicht finden kann.
Nein, das ist nicht möglich, da es zu diesem Thema noch keine einzige Veröffentlichung gibt. Aber wir wissen es!
Und wenn Sie nicht ganz verstehen, was getan wurde, werde ich es Ihnen jetzt sagen.
Was wurde getan, welche Funktionalität wurde dem Linux-Kernel hinzugefügt? txhash ändert sich nach jedem RTO-Ereignis in einen zufälligen Wert. Dies ist das sehr negative Ergebnis des Routings. Der Hash hängt von diesem txhash ab und die Flussbezeichnung hängt vom skb-Hash ab. Hier gibt es einige Berechnungen zu Funktionen, alle Details lassen sich nicht auf einer Folie unterbringen. Wenn jemand neugierig ist, können Sie den Kernel-Code durchgehen und nachsehen.
Was ist hier wichtig? Der Wert des Flow-Label-Feldes ändert sich nach jedem RTO in eine Zufallszahl. Wie wirkt sich das auf unseren unglücklichen TCP-Stream aus?
Wenn ein SACK auftritt, ändert sich nichts, da wir versuchen, ein bekanntermaßen verlorenes Paket erneut zu senden. So weit, ist es gut.
Aber im Fall von RTO kann der Datenverkehr einen anderen Weg nehmen, sofern wir der Hash-Funktion auf ToR ein Flow-Label hinzugefügt haben. Und je mehr Lanes vorhanden sind, desto größer ist die Chance, dass ein Pfad gefunden wird, der nicht von einem Fehler auf einem bestimmten Gerät betroffen ist.
Ein Problem bleibt bestehen – RTO. Natürlich gibt es auch einen anderen Weg, aber dafür wird viel Zeit verschwendet. 200 ms sind viel. Eine Sekunde ist absolut wild. Zuvor habe ich über Zeitüberschreitungen bei der Konfiguration von Diensten gesprochen. Eine Sekunde ist also ein Timeout, das normalerweise vom Dienst auf Anwendungsebene konfiguriert wird, und in diesem Fall wird der Dienst sogar relativ recht haben. Darüber hinaus, ich wiederhole, beträgt die tatsächliche RTT in einem modernen Rechenzentrum etwa 1 Millisekunde.
Was können Sie mit RTO-Timeouts tun? Der Timeout, der für RTO bei Verlust von Datenpaketen verantwortlich ist, lässt sich relativ einfach aus dem Userspace konfigurieren: Es gibt ein IP-Utility und einer seiner Parameter enthält den gleichen rto_min. Wenn man bedenkt, dass RTO natürlich nicht global, sondern für bestimmte Präfixe angepasst werden muss, scheint ein solcher Mechanismus durchaus praktikabel zu sein.
Stimmt, mit SYN_RTO ist alles etwas schlimmer. Es ist natürlich festgenagelt. Der Kernel hat einen festen Wert von 1 Sekunde, und das war’s. Sie können vom Benutzerbereich aus nicht dorthin gelangen. Es gibt nur einen Weg.
eBPF kommt zur Rettung. Vereinfacht gesagt handelt es sich dabei um kleine C-Programme. Sie können an verschiedenen Stellen in der Ausführung des Kernel-Stacks und des TCP-Stacks in Hooks eingefügt werden, mit denen man sehr viele Einstellungen ändern kann. Im Allgemeinen ist eBPF ein langfristiger Trend. Anstatt Dutzende neuer Sysctl-Parameter zu streichen und das IP-Dienstprogramm zu erweitern, geht die Bewegung in Richtung eBPF und erweitert seine Funktionalität. Mit eBPF können Sie Überlastungskontrollen und verschiedene andere TCP-Einstellungen dynamisch ändern.
Für uns ist es aber wichtig, dass damit die SYN_RTO-Werte verändert werden können. Darüber hinaus gibt es ein öffentlich veröffentlichtes Beispiel: . Was wurde hier getan? Das Beispiel funktioniert, ist aber an sich sehr grob. Hier wird davon ausgegangen, dass wir innerhalb des Rechenzentrums die ersten 44 Bits vergleichen; wenn sie übereinstimmen, dann befinden wir uns im Rechenzentrum. Und in diesem Fall ändern wir den SYN_RTO-Timeout-Wert auf 4 ms. Die gleiche Aufgabe kann viel eleganter erledigt werden. Aber dieses einfache Beispiel zeigt, dass dies a) möglich ist; b) relativ einfach.
Was wissen wir bereits? Da die Ebenenarchitektur eine Skalierung ermöglicht, erweist es sich für uns als äußerst nützlich, wenn wir das Flow-Label auf ToR aktivieren und die Möglichkeit erhalten, Problembereiche zu umgehen. Der beste Weg, die RTO- und SYN-RTO-Werte zu reduzieren, ist die Verwendung von eBPF-Programmen. Es bleibt die Frage: Ist es sicher, ein Flow-Label für die Bilanzierung zu verwenden? Und hier gibt es eine Nuance.
Angenommen, Sie haben einen Dienst in Ihrem Netzwerk, der in Anycast läuft. Leider habe ich keine Zeit, näher darauf einzugehen, was Anycast ist, aber es handelt sich um einen verteilten Dienst mit verschiedenen physischen Servern, auf die über dieselbe IP-Adresse zugegriffen werden kann. Und hier liegt ein mögliches Problem: Das RTO-Ereignis kann nicht nur auftreten, wenn Datenverkehr durch die Fabric geleitet wird. Es kann auch auf ToR-Pufferebene auftreten: Wenn ein Incast-Ereignis auftritt, kann es sogar auf dem Host auftreten, wenn der Host etwas verschüttet. Wenn ein RTO-Ereignis auftritt und dadurch die Flussbezeichnung geändert wird. In diesem Fall kann der Datenverkehr an eine andere Anycast-Instanz weitergeleitet werden. Nehmen wir an, es handelt sich um einen zustandsbehafteten Anycast, der einen Verbindungsstatus enthält – es könnte sich um einen L3-Balancer oder einen anderen Dienst handeln. Dann entsteht ein Problem, denn nach RTO kommt die TCP-Verbindung beim Server an, der nichts über diese TCP-Verbindung weiß. Und wenn wir keine Statusfreigabe zwischen Anycast-Servern haben, wird dieser Datenverkehr verworfen und die TCP-Verbindung wird unterbrochen.
Was kann man hier machen? In Ihrer kontrollierten Umgebung, in der Sie den Flow-Label-Balancing aktivieren, müssen Sie den Wert des Flow-Labels aufzeichnen, wenn Sie auf Anycast-Server zugreifen. Der einfachste Weg besteht darin, dies über dasselbe eBPF-Programm zu tun. Aber hier ist ein sehr wichtiger Punkt: Was tun, wenn Sie kein Rechenzentrumsnetzwerk betreiben, sondern ein Telekommunikationsbetreiber sind? Das ist auch Ihr Problem: Ab bestimmten Versionen von Juniper und Arista enthalten sie standardmäßig ein Flow-Label in ihren Hash-Funktionen – ehrlich gesagt aus einem mir unklaren Grund. Dies kann dazu führen, dass Sie TCP-Verbindungen von Benutzern, die Ihr Netzwerk passieren, unterbrechen. Ich empfehle daher dringend, hier die Einstellungen Ihres Routers zu überprüfen.
Auf die eine oder andere Weise scheint es mir, dass wir bereit sind, zu Experimenten überzugehen.
Als wir das Flow-Label auf ToR aktivierten und den eBPF-Agenten vorbereiteten, der jetzt auf den Hosts lebt, beschlossen wir, nicht auf den nächsten großen Fehler zu warten, sondern kontrollierte Explosionen durchzuführen. Wir haben ToR genommen, das über vier Uplinks verfügt, und auf einem davon Drops eingerichtet. Sie stellten eine Regel auf und sagten: Jetzt verlieren Sie alle Pakete. Wie Sie links sehen können, haben wir eine Überwachung pro Paket, die auf 75 % gesunken ist, d. h. 25 % der Pakete gehen verloren. Auf der rechten Seite finden Sie Diagramme der Dienste, die hinter diesem ToR stehen. Im Wesentlichen handelt es sich hierbei um Verkehrsdiagramme der Schnittstellen mit Servern im Rack. Wie Sie sehen können, sanken sie noch tiefer. Warum sind sie tiefer gesunken – nicht um 25 %, sondern in manchen Fällen um das Drei- bis Vierfache? Wenn die TCP-Verbindung nicht erfolgreich ist, versucht sie weiterhin, über die defekte Verbindung eine Verbindung herzustellen. Dies wird durch das typische Verhalten des Dienstes innerhalb des DC noch verschärft: Für eine Benutzeranfrage werden N Anfragen an interne Dienste generiert, und die Antwort geht entweder an den Benutzer, wenn alle Datenquellen antworten oder wenn bei der Anwendung ein Timeout auftritt Ebene, die noch konfiguriert werden muss. Das heißt, alles ist sehr, sehr schlecht.
Jetzt das gleiche Experiment, aber mit aktiviertem Flow-Label-Wert. Wie Sie links sehen können, sank unsere Chargenüberwachung um die gleichen 25 %. Das ist absolut richtig, denn es weiß nichts über erneute Übertragungen, es sendet Pakete und zählt lediglich das Verhältnis der Anzahl der zugestellten und verlorenen Pakete.
Und rechts ist der Serviceplan. Die Wirkung eines problematischen Gelenks werden Sie hier nicht finden. In denselben Millisekunden floss der Datenverkehr vom Problembereich zu den drei verbleibenden Uplinks, die nicht von dem Problem betroffen waren. Wir haben ein Netzwerk, das sich selbst heilt.
Dies ist meine letzte Folie, Zeit für eine Zusammenfassung. Nun hoffe ich, dass Sie wissen, wie man ein selbstheilendes Rechenzentrumsnetzwerk aufbaut. Sie müssen nicht das Linux-Kernel-Archiv durchsuchen und dort nach speziellen Patches suchen; Sie wissen, dass das Flow-Label in diesem Fall das Problem löst, aber Sie müssen diesen Mechanismus sorgfältig angehen. Und ich betone noch einmal, dass Sie als Telekommunikationsbetreiber Flow Label nicht als Hash-Funktion verwenden sollten, da Sie sonst die Sitzungen Ihrer Benutzer unterbrechen.
Netzwerkingenieure müssen einen konzeptionellen Wandel vollziehen: Das Netzwerk beginnt nicht mit dem ToR, nicht mit dem Netzwerkgerät, sondern mit dem Host. Ein ziemlich eindrucksvolles Beispiel ist, wie wir eBPF sowohl zur Änderung des RTO als auch zur Festlegung des Flow-Labels für Anycast-Dienste verwenden.
Die Flow-Label-Mechanik eignet sich durchaus auch für andere Anwendungen im kontrollierten Verwaltungsbereich. Dabei kann es sich um Datenverkehr zwischen Rechenzentren handeln, oder Sie können solche Mechanismen auf besondere Weise nutzen, um den ausgehenden Datenverkehr zu verwalten. Aber davon erzähle ich euch hoffentlich beim nächsten Mal. Vielen Dank für eure Aufmerksamkeit.
Source: habr.com