- Blogübersetzung -
 |
| Quelle: SL Brand Center |
Eigentlich ist der Beitrag von Chris Linden nur etwas für Technik- und Netzwerk-Freaks und obwohl ich mich auch einigermaßen damit auskenne, sind die Schilderungen von Chris doch ziemlich spezifisch. Deshalb habe ich bei einigen seiner Abkürzungen auch den vollen Begriff ausgeschrieben, sonst wäre das noch größeres Technobabble.
Die Geschichte von der fehlenden Rückmeldung
Hier ist Chris Linden. Ich wollte kurz ein Beispiel mit euch teilen, zu einer der interessanten Herausforderungen, die wir mit dem Systemtechniker-Team hier bei Linden Lab zu bewältigen hatten. Wir haben kürzlich ein paar seltsame Ausfälle festgestellt, während wir einen neuen API-Endpunkt testeten, der von Amazon gehostet wird. Von 100 HTTPS-Anfragen, die von unserem Rechenzentrum an den Endpunkt gesendet wurden, blieben 1 oder 2 der Anfragen hängen und führten zu einem Timeout. Merkwürdig. Aber wir können nachvollziehen, dass Netzwerke unzuverlässig sind, und so änderten wir unsere Anwendungen, damit sie mit dem Fehler umgehen konnten und versuchten auch, diese zuverlässiger zu machen, so gut wir es konnten.
Wir begannen nachzuforschen. Passiert es bei anderen Hosts im Rechenzentrum? Ja. Gab es Fehler bei allen Hosts? Nein, und das war zum Verrücktwerden, um ehrlich zu sein. Passiert es auch von außerhalb des Rechenzentrums? Nein. Passiert es bei verschiedenen Netzwerksegmenten innerhalb unseres Rechenzentrums? Ja.
Leider blieben damit nur unsere Hauptrouter als einzige Hardware-Elemente übrig, die sich zwischen den Hosts mit den Fehlern und dem allgemeinen Internet befanden. Wir haben eine Reihe von Traceroutes durchgeführt, um eine Vorstellung von den verschiedenen Wegen durch das Netzwerk zu bekommen, sahen aber nichts Außergewöhnliches. Wir haben dann eine Reihe von Datenpaketen untersucht und bemerkten etwas seltsames auf der Sendeseite.
1521 9.753127 216.82.x.x -> 1.2.3.4 TCP 74 53819 > 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1400 SACK_PERM=1 TSval=2885304500 TSecr=0 WS=128
1525 9.773753 1.2.3.4 -> 216.82.x.x TCP 74 443 > 53819 [SYN, ACK] Seq=0 Ack=1 Win=26960 Len=0 MSS=1360 SACK_PERM=1 TSval=75379683 TSecr=2885304500 WS=128
1526 9.774010 216.82.x.x -> 1.2.3.4 TCP 66 53819 > 443 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=2885304505 TSecr=75379683
1527 9.774482 216.82.x.x -> 1.2.3.4 SSL 583 Client Hello
1528 10.008106 216.82.x.x -> 1.2.3.4 SSL 583 [TCP Retransmission] Client Hello
1529 10.292113 216.82.x.x -> 1.2.3.4 SSL 583 [TCP Retransmission] Client Hello
1530 10.860219 216.82.x.x -> 1.2.3.4 SSL 583 [TCP Retransmission] Client Hello
Wir sahen, dass der TCP-Handshake durchgeführt wurde, dann aber auf der anderen Seite das SSL-Signal einfach aufhört zu reagieren. Dies geschah jedes Mal, wenn ein Fehler aufgetreten ist. Der Verlust von Paketen ist normal. Aber der beständige Verlust beim Erreichen von Client Hello? Sehr eigenartig. Wir haben uns dann den Host im Rechenzentrum und die Amazon-Instanz genauer angesehen. Wir veränderten die MTU-Einstellungen, den Pfad für MTU Discovery, suchten Fehler beim Xen Hypervisor, in den TCP Segmentation Einstellungen und in der NIC-Verschiebung. Nichts hat das Problem behoben.
Wir entschieden uns für eine Untersuchung unserer Internet-Service-Provider in unserem Datenzentrum. Wir sind mehrfach mit dem Internet vernetzt, um redundant zu sein, und wie der größte Teil des Internet, nutzen wir Border Gateway Protokolle, um festzustellen, welchen Weg unser Datenverkehr nimmt, um ein Ziel zu erreichen. Obwohl wir den Weg beeinflussen können, den die Daten nehmen, müssen wir das in der Regel nicht tun.
Wir haben uns dann die Wege von unseren Routern zu Amazon angesehen und festgestellt, dass die meisten von ihnen es bevorzugen, den Weg über Internet Service Provider A zu nehmen. Wir fanden aber auch ein paar Routen zu Amazon, die es vorzogen, über Internet Service Provider B geschickt zu werden. Und so gruben wir uns durch die Bereiche in den Amazon Web Services, tauschten die Elastic IP Adressen, bis wir eine Adresse innerhalb der Route gefunden hatten, die es bevorzugte, über Internet Service Provider B zu laufen. Das war in Irland. Wir lenkten eine Instanz auf eu-west-1 und beaufschlagten diese mit unserem Test und...keine Fehler. Wir haben dann statische Routen auf unsere Router gelenkt, um Traffic auf den Amazon Web Service Instanzen zu erzwingen, bei denen zuvor Ausfälle zu sehen waren. Dies ermöglichte es uns, Anfragen zu diesen Test-Hosts zu senden, entweder über Internet Service Provider A oder Internet Service Provider B, basierend auf einer kleinen Konfigurationsänderung. Bei Internet Service Provider A gab es jedes mal Ausfälle, bei Internet Service Provider B keine.
Wir manipulierten die Routen, um ausgehenden Traffic von unserem Rechenzentrum zu den Amazon Netzwerken über Internet Service Provider B zu senden. Erfolg. Solange das nun aktiv war, ging der Datenverkehr über Internet Service Provider B (das Netzwerk, bei dem keine Fehler auftraten). Allerdings würde der Datenverkehr auf Internet Service Provider A zurückfallen, wenn aus irgendeinem Grund Internet Service Provider B ausfallen würde.
Nachdem wir uns mit Internet Service Provider A unterhalten haben, fanden sie ein Problem mit einer Hardware-Komponente in ihrem Netzwerk und ersetzten sie. Jetzt haben wir festgestellt, dass die gleichen Fehler aktuell nicht mehr auftreten und haben die Änderungen rückgängig gemacht, die den Traffic manipuliert hatten. Wir sehen dies heute als einen Gewinn und durch das Lösen der Verbindungsprobleme, konnten wir Second Life sehr viel zuverlässiger machen.
Quelle: Tale of the Missing ACK
Keine Kommentare:
Kommentar veröffentlichen