Ich habe ein Problem mit der Synchronisierung großer Datenmengen zwischen zwei Rechenzentren. Beide Rechner haben eine Gigabit-Verbindung und sind nicht voll ausgelastet, aber das Schnellste, was ich erreichen kann, liegt zwischen 6 und 10 Mbit => nicht akzeptabel!
Gestern habe ich einige Traceroute-Aufzeichnungen durchgeführt, die auf eine enorme Belastung eines LEVEL3-Routers schließen lassen, das Problem besteht jedoch nun schon seit Wochen und die hohe Reaktionszeit ist verschwunden (20 ms statt 300 ms).
Wie kann ich dies verfolgen, um den tatsächlich langsamen Knoten zu finden? Ich habe über ein Traceroute mit größeren Paketen nachgedacht, aber wird das funktionieren?
Außerdem muss dieses Problem nicht unbedingt mit einem unserer Server zusammenhängen, da die Übertragungsraten zu anderen Servern oder Clients viel höher sind.Büro => Serverist schneller alsServer <=> Server!
Jede Idee ist willkommen ;)
Aktualisieren
Wir verwenden eigentlich rsync über ssh, um die Dateien zu kopieren. Da es bei der Verschlüsselung tendenziell mehr Engpässe gibt, habe ich es mit einer HTTP-Anfrage versucht, aber leider ist diese genauso langsam.
Wir haben ein SLA mit einem der Rechenzentren. Sie sagten, sie hätten bereits versucht, das Routing zu ändern, weil dies angeblich mit einem Billignetz zusammenhängt, über das der Verkehr geleitet wird. Es stimmt, dass der Verkehr über ein „Billignetz“ geleitet wird, aber nur umgekehrt. Unsere Richtung geht über LEVEL3 und die andere über Lambdanet (von dem sie sagten, es sei kein gutes Netzwerk). Wenn ich es richtig verstanden habe (ich bin ein Netzwerk-Fortgeschrittener), haben sie einen längeren Pfad simuliert, um das Routing über LEVEL3 zu erzwingen, und sie kündigen LEVEL3 im AS-Pfad an.
Ich möchte im Grunde wissen, ob sie Recht haben oder ob sie nur versuchen, ihre Verantwortung abzuwälzen. Die Sache ist, dass das Problem in beide Richtungen (auf unterschiedlichen Routen) besteht, also denke ich, dass es in der Verantwortung unseres Hosters liegt. Und ehrlich gesagt glaube ich nicht, dass es eine DC2DC-Verbindung gibt, die wochenlang nur 600 kb/s - 1,5 MB/s bewältigen kann! Die Frage ist, wie man erkennt, WO dieser Engpass ist
Antwort1
Wenn Sie über eine langsame Verbindung im öffentlichen Internet umgeleitet werden, besteht Ihre einzige Möglichkeit darin, diese Verbindung zwangsweise zu umgehen. Der einfachste Weg, dies zu tun, besteht darin, eine Dateiübertragung zwischen zwei Endpunkten zu versuchen, von denen einer "Punkt A" (der Ursprung der Daten) und einZwischensiteder sich geografisch nicht am selben Ort wie Ihr Ziel, „Punkt B“, befindet.
Sobald Sie einen "Punkt C" gefunden haben, also einen Server, dernichtüber Ihren langsamen Internet-Router umgeleitet werden, können Sie zwischen Punkt A und Punkt C ein VPN einrichten, sodass der Datenverkehr um den langsamen Knoten „herumgeleitet“ wird.
Wenn Ihr Geschäftswert ($$$$$$) oder Ihr Einfluss beim ISP hoch ist, können Sie das Problem auch direkt mit Level 3 besprechen. Allerdings ist L3 ein Tier-1-ISP und reagiert möglicherweise nicht besonders offen auf Beschwerden über die Servicequalität oder die Netzsättigung, da er nur sehr wenig dagegen tun kann, wenn er seine Peering-Vereinbarungen mit den Downstream- oder anderen Tier-1-Anbietern, die die Konkurrenz auf seinem Knoten verursachen, nicht erweitern kann, will oder kann.
Da Sie sagten, dass die Verbindung „vom Büro zum Server“ schneller sei, könnten Sie versuchen, das VPN am „Büro“-Standort mit einem mäßig leistungsstarken Computer einzurichten (ein Dual-Core-Serversystem sollte genügen).
Oh, und außerdem!Wenn die Latenz (Ende zu Ende) zwischen "Punkt A" und "Punkt B" sehr hoch ist (mehr als 100 ms ist in der Serverwelt hoch), sollten Sie sicherstellen, dassSie verwenden kein gesprächiges NetzwerkprotokollSamba (auch bekannt als SMB oder Windows File Sharing) istäußerstgesprächig; andere „Sync“-Protokolle können auch gesprächig sein.
Chatty-Protokolle sind solche, die viele synchrone Hin- und Her-Rundreisen erfordern, um Daten zu übertragen. Wenn Ihr Protokoll zu chatty ist, kann allein die Latenz Ihre Übertragung behindern, unabhängig davon, wie schnell die Verbindung ist.
Um festzustellen, ob die Chattiness Ihren Durchsatz wirklich beeinträchtigt, können Sie einen bekanntenungesprächigProtokoll, wie HTTP, für eine Testübertragung. Versuchen Sie also normales altes HTTP von "Punkt A" zu "Punkt B" über den "langsamen" Level3-Router, und wenn die Latenz hoch ist, aber der Durchsatz immer noch gut ist, dannwissendass Ihre Übertragung deshalb so langsam ist, weil Ihr Protokoll zu gesprächig ist. Sie müssen das Protokoll also ändern.
Lassen Sie mich die Diskussion abrunden, indem ich kurz definiere und erkläredie drei Netzwerkbeeinträchtigungenund warumirgendjemanddavon können für dieses Problem verantwortlich sein:
Latenz-- Wie lange ein Datagramm braucht, um von Ihrem zum anderen Ende zu gelangen. In den meisten Fällen können Sie die Latenz nicht direkt verbessern, es sei denn, einer Ihrer Computer ist so überlastet, dass sein Netzwerkstapel, sein Kernel oder seine Anwendungen eine erhebliche zusätzliche Latenz erzeugen. Die meiste Latenz im öffentlichen Internet entsteht durch Internet-Router, nicht durch Ihren Computer oder den Endpunkt.
Bandbreite- Bandbreite ist der maximale Durchsatz der langsamsten Verbindung zwischen Ihrem Computer und dem Endpunkt. In den meisten modernen Netzwerken stellt die Bandbreite keine echte Einschränkung dar, da andere Netzwerkbeeinträchtigungen auftreten und das Netzwerk verlangsamen, lange bevor die Bandbreite zu einem echten Problem wird.
Paketverlust-- Paketverluste können zunehmenwahrgenommenLatenz für zuverlässige Datagramme (wie TCP) und ist oft das Ergebnis stark ausgelasteter Verbindungen, die Ihr Paket aus dem TCP-Sende- oder Empfangspuffer entfernen müssen, da der Puffer bereits zu voll ist. Paketverlust kann auch bei „zeitkritischen“ Paketen auftreten, wie dies bei fast allen TCP-Paketen der Fall ist, da das Paket verworfen wird, wenn es nach Ablauf der Frist ankommt. Dies tritt auf, wenn ein größeres TCP-Paket in mehrere IP-Datagramme fragmentiert wird und das TCP-Protokoll auf der Empfangsseite nur eine festgelegte Zeit warten kann, bis alle Fragmente angekommen sind, bevor es entscheidet, den Empfang des Pakets abzubrechen. Paketverlust ist also indirekt auf Sättigungsprobleme zurückzuführen (dieIstein Bandbreitenproblem) oder auch durch Hardwareprobleme oder -ausfälle verursacht werden.
Aus den grundlegenden Netzwerkbeeinträchtigungen ergeben sich Abhilfemaßnahmen, mit denen Sie die Zuverlässigkeit Ihrer Programme verbessern können, ohne die grundlegenden Beeinträchtigungen zu ändern, da Sie diese meist kaum oder gar nicht kontrollieren können:
Abhilfemaßnahme Nummer eins besteht darin, Ihr Protokoll weniger gesprächig zu machen (oder, aus Sicht der Systemintegration,verwendenein vorhandenes Protokoll, das weniger gesprächig ist als Ihre aktuelle Lösung). Je weniger „Roundtrips“ erforderlich sind, um Daten zwischen den Endpunkten zu synchronisieren, desto besser ist es – Punkt. Einige Protokolle können so entwickelt werden, dass sie eine variable Synchronisierungsfrequenz erfordern – wenn dies der Fall ist, sollten Sie die Synchronisierungsfrequenz dynamisch so weit wie möglich reduzieren, wenn Sie eine hohe Latenz oder einen Paketverlust feststellen. Die Reduzierung der Gesprächigkeit hilft, Latenz und Paketverlust zu verringern, aber nicht, Probleme mit der Bandbreitenobergrenze zu lösen.
Die zweite Abhilfemaßnahme besteht darin, alle Ihre Hops (diejenigen, die Sie direkt auf administrativer/Hardware-Ebene steuern) so zu konfigurieren, dass sie den besten verfügbaren Active Queue Management (AQM)-Algorithmus verwenden, der derzeit Fair Queue Controlled Delay AQM ist. Dieser ist im Linux-Kernel 3.5 oder höher als fq_codelqdisc-Implementierung verfügbar und bewirkt dynamischreduziertdie Größe der Sende- und Empfangspuffer, um die Latenz zu reduzieren, die diese Puffer unweigerlich erzeugen. Dies kann den Paketverlust reduzieren und dabei helfen, mit der Latenz mithilfe des TCP-Protokolls umzugehen, da Ihre fragmentierten Pakete weniger wahrscheinlich ablaufen, wenn Sie die Wartezeit minimieren, die das Paket durchlaufen muss, bevor es über die Verbindung gesendet wird. Beachten Sie, dass diese Abschwächung nur dann einen Unterschied macht, wenn der Knoten „gesättigt“ ist (d. h. wenn der TCP-Puffer leer ist, hat sie keine Wirkung). Ein Knoten ist gesättigt, wenn die Rate der in den Netzwerk-Socket geschriebenen Daten die Übertragungsrate des Uplinks überschreitet. Die typische Reaktion des TCP-Stacks auf diese Situation besteht darin, den Puffer zu vergrößern, was tatsächlich einen negativen Effekt hat, da es die Latenz erhöht und das alle möglichen Probleme verursacht – also hilft fq_codel, dies abzumildern.
Beide Maßnahmen helfen bei allen drei grundlegenden Netzwerkbeeinträchtigungen,ohneUmleitung des fehlerhaften Knotens undohneÄndern Sie die Hardware oder wenden Sie sich an den ISP.