Überwachung von Paketverlusten und Latenzzeiten im Netzwerk auf Roblox Cloud

Das Roblox Network Engineering Team unterhält ein großes, schnell wachsendes Netzwerk mit Rechenzentren und Point-of-Presence-Standorten (POP), die über den ganzen Globus verteilt sind. Die Bereitstellung einer hervorragenden Benutzererfahrung auf der Roblox-Plattform hängt von der Leistung und Zuverlässigkeit dieses Netzwerks ab. Für Netzwerkbetreiber ist es entscheidend, Probleme im Netzwerk erkennen und beheben zu können sowie Einblick in die Netzwerkleistung zu haben. Die Netzwerküberwachung erfolgt in der Regel durch die regelmäßige Erfassung von Gerätestatistiken, Fehlermetriken und Syslogs sowie deren Speicherung in einer Zeitreihen- oder Log-Datenbank. Die Daten werden entweder über ein Push- oder ein Pull-Modell unter Verwendung von Standardprotokollen wie SNMP, Netconf, REST-APIs oder Streaming Telemetry erfasst.

Die Erkennung von Netzwerkfehlern ausschließlich über Gerätetelemetrie weist mehrere Mängel auf, da es sich um eine passive Überwachungstechnik handelt. Sie ist davon abhängig, dass die Netzwerkknoten anomale Situationen erkennen und melden können, sobald sie auftreten. Das Gerät meldet die Daten möglicherweise nicht immer zurück oder stellt in einigen Fällen möglicherweise nicht alle seine Zustandsdaten für die üblichen Telemetrie-Erfassungsmethoden bereit. Darüber hinaus liefern Netzwerkgeräte manchmal fehlerhafte Daten oder leiten Datenverkehr stillschweigend in ein „Black Hole“. Eine wesentliche Einschränkung der Gerätetelemetrie besteht darin, dass sie nur sehr wenig Einblick in die End-to-End-Erreichbarkeit, Paketverluste und Latenzstatistiken des Netzwerks bietet.

Eine hervorragende Möglichkeit zur aktiven Netzwerküberwachung ist die regelmäßige Übertragung synthetischer Probes über ein Mesh-Netzwerk, wie in den folgenden Abbildungen dargestellt.

Bei der Fehlerbehebung bei Produktionsausfällen werden Netzwerkbetreiber häufig gefragt: „Verliert das Netzwerk Pakete?“ oder „Gibt es einen laufenden Netzwerkfehler, der die Konnektivität beeinträchtigt?“ Um diese Art von Fragen ohne Zugriff auf historische Daten zu Paketverlusten und Latenzzeiten zu beantworten, müssten sie eine große Anzahl von Verbindungen und Knoten innerhalb des Netzwerks untersuchen.

Entwicklung eines zuverlässigen und skalierbaren Netzwerk-Mesh-Überwachungssystems

Damit ein Black-Box-Netzwerküberwachungssystem Paketverluste oder Latenzspitzen effektiv erkennen kann, ist eine kontinuierliche Abfrage verschiedener Teile des Netzwerks erforderlich. Rechenzentrumsnetzwerke nutzen alle Verbindungen zwischen Knoten für den Benutzerdatenverkehr. Produktionsnetzwerkgeräte führen BGP aus und verteilen den Datenverkehr über mehrere Pfade mit gleichen Kosten. Änderungen der Netzwerktopologie werden unter normalen Umständen in der Regel innerhalb von Sekunden durch Aktualisierungen der Routing-Tabelle widergespiegelt. Um eine genaue Messung des Netzwerkpaketverlusts zu erhalten, sollten die Testproben so viele Pfade wie möglich durchlaufen und dabei alle Netzwerkknoten und Verbindungen abdecken. Bei einem großen Netzwerk wie dem unseren, das sich über mehrere Standorte weltweit erstreckt, ist es nicht skalierbar, zwischen jedem Knoten- oder Rackpaar zu prüfen. Die nachhaltigere Lösung, für die wir uns entschieden haben und die keine Kompromisse bei der Transparenz eingeht, besteht darin, ein N²-Netzwerk über die Racks innerhalb jedes Standorts sowie ein weiteres N²-Netzwerk über alle Standorte hinweg zu prüfen.

Womit testen wir das Netzwerk?

Die Testproben sollten den Live-Datenverkehr in einem Produktionsnetzwerk nachbilden. Der Großteil des Datenverkehrs in unserem Netzwerk besteht entweder aus TCP, UDP oder HTTP, und jedes dieser Protokolle könnte potenziell für Proben verwendet werden. Eines der Probleme bei TCP-Proben ist, dass sie nicht leichtgewichtig genug sind, um auf die Anzahl der Verbindungen skaliert zu werden, die zur Überwachung eines großen Netzwerks erforderlich sind. Ein weiterer Nachteil von TCP ist, dass die integrierte Flusskontrolle und die auf gleitenden Fenstern basierenden Übertragungen zu einer variablen Sende-Rate der Probes führen, was für die Quantifizierung oder Erkennung momentaner Paketverluste nicht ideal ist. ICMP, das von Ping und Traceroute verwendet wird, unterliegt typischerweise einer Ratenbegrenzung auf den Servern oder Netzwerkknoten. Dies begrenzt die Gesamt-Rate der ICMP-Probes, die verwendet werden können. HTTP-Anfragen liegen höher in der Anwendungsschicht und hängen von einigen Faktoren außerhalb des Netzwerks ab, wie z. B. der Server- oder Anwendungsleistung. HTTP fügt den Ergebnissen einen zusätzlichen variablen Faktor hinzu, der schwer herauszufiltern ist. Das Ziel dieses Systems ist es, die Leistung der zugrunde liegenden Netzwerkinfrastruktur zu überwachen, die hauptsächlich auf den OSI-Schichten 4 und darunter arbeitet. Aus diesen Gründen haben wir uns für UDP-Probes entschieden, zusätzlich dazu, dass es das primäre Transportschichtprotokoll in unserem Netzwerk ist.

Von wo aus führen wir die Probes durch?

Eine Möglichkeit, eine hohe aggregierte Abfragefrequenz zu erreichen und gleichzeitig eine große Anzahl von Netzwerkpfaden abzudecken, besteht darin, so viele Rechenknoten wie möglich für die Übertragung der Abfragen zu nutzen. Dies hat zwei Vorteile: Es hilft, die Last auf die Systeme zu verteilen, die die Abfragen generieren, und es erhöht die Anzahl der Netzwerkports, über die sie übertragen werden. Dies erfordert jedoch einen Agenten, der sehr stabil ist und die Ressourcen des Hostsystems so wenig wie möglich beansprucht. Gleichzeitig sollte der Agent in der Lage sein, Paketverluste und Latenzzeiten auf mehreren Pfaden genau zu messen, ohne durch Schwankungen bei der CPU-, Speicher- oder E/A-Auslastung auf dem Hostsystem beeinträchtigt zu werden. Der Agent muss ständig dieses empfindliche Gleichgewicht zwischen geringem Ressourcenbedarf und hoher Leistungsfähigkeit aufrechterhalten.

Wie messen wir Netzwerkverluste und Latenz?

Dies mag bei einem einzelnen Proben-Stream als triviale Berechnung erscheinen, doch bei Skalierung ergeben sich einige Herausforderungen, die nicht sofort offensichtlich sind. Um auf ein derart großes Netz skalieren zu können, muss der Agent schnell und genau die Anzahl der gesendeten (Tx) und empfangenen (Rx) Pakete mit Zeitstempeln über zahlreiche Streams gleichzeitig berechnen. Es ist wichtig, dass die Metriken für Netzwerkverluste keine Pakete enthalten, die auf dem Host verloren gehen, auf dem der Agent läuft, wenn dessen CPU ausgelastet ist oder seine Netzwerkpuffer überlaufen. Die Netzwerklatenz muss anhand der Gesamtzeit berechnet werden, die die Probes auf der Leitung oder in zwischengeschalteten Netzwerkknoten verbracht haben, wobei die Zeit, die in E/A-Puffern verbracht wurde, sowie die Wartezeit des Agentenprozesses auf die OS-Scheduling-Zuweisung ausgeschlossen werden müssen.

Das Ping-Mesh-System von Roblox

Der Bedarf an einer Black-Box-Überwachung von Netzwerkausfällen und Latenzzeiten besteht seit dem Wachstum der öffentlichen und privaten Cloud-Infrastruktur. Es hat sich als schwierig erwiesen, eine Standardlösung zu finden, die sich an unser großes Netzwerk anpassen lässt. Mehrere große Cloud-Betreiber und Anbieter von Netzwerktools haben ihre eigenen Lösungen zur Überwachung von Netzwerkausfällen und Latenzzeiten entwickelt. Wir haben einige frei verfügbare Tools ausprobiert, stießen jedoch auf Probleme hinsichtlich Stabilität und Skalierbarkeit und erhielten zudem nur begrenzte Einblicke in die Netzwerkleistung. Dies veranlasste uns, unser eigenes Mesh-Überwachungssystem zu entwickeln, das eine bessere Erkennung von selten auftretenden Fehlern bei geringem Overhead ermöglicht. Einige der Highlights unseres Systems sind:

• Wir haben uns für Go entschieden, um alle Komponenten unseres Systems zu implementieren, was uns half, ein hohes Leistungsniveau bei minimalem Ressourcenverbrauch zu erreichen.
• Unsere Agenten sind äußerst stabil und können auf einer Vielzahl von Produktionshosts ausgeführt werden, einschließlich solcher, die kritische Dienste auf der Roblox-Plattform ausführen, wie Traffic-, Caching- und Anwendungsserver.
• Der Agent ist darauf optimiert, Paket-I/O-Operationen mit Go-Wrapper-Funktionen über die Linux-Systemaufrufe sendmmsg() und recvmmsg() zu bündeln, wodurch er eine hohe Rate an Probes mit geringem Overhead übertragen kann. Jeder Agent in unserer Bereitstellung sendet gleichzeitig Probes an bis zu 100 andere Hosts mit einer Rate von 100 Paketen pro Sekunde (PPS). Der Agent sendet jede Sekunde Paketbursts an jedes Ziel.
• Die Probes enthalten unterschiedliche TOS-Feldwerte (Type of Service) im IP-Header für jedes Ziel und werden hinsichtlich Paketverlust und Latenz im Netzwerk separat erfasst. Jeder Paketburst enthält eine Mischung aus mehreren TOS-Werten für jedes andere Ziel. Dies hilft bei der Überwachung der Netzwerkleistung für verschiedene QoS-Klassen (Quality of Service).
• Der Agent kann Netzwerkausfälle von nur 1 von 6000 Paketen pro Minute auf jedem Probe-Pfad erkennen. Paketverluste innerhalb des Kerns oder am Rand des Netzwerks, die weniger als 1 Sekunde dauern, können erkannt werden, beispielsweise solche während eines BGP-Flap.
• Die Diagramme zu den Paketverlusten der Probes ähneln denen der Fehlerraten von Netzwerkschnittstellen, wenn diese Fehler für die Verluste verantwortlich sind. Wir konnten damit schwer zu erkennende „Traffic Black-Hole“-Fehler im Netzwerk aufdecken.
• Die Agenten nutzen die Lesezeitstempel des NIC-Kernels, um eine hohe Genauigkeit bei der Messung der Netzwerklatenz zu erreichen. Es kann eine konsistente Round-Trip-Latenz innerhalb eines Standorts von 50–100 Mikrosekunden gemessen werden, wobei die Scheduling-Latenz des Host-Betriebssystems und die Netzwerkuhr-Abweichung ausgeschlossen werden.
• Geringe CPU-Auslastung und geringer Speicherbedarf. Der Agent beansprucht bei Spitzenübertragungs- und Empfangsraten (jeweils 5 kpps) weniger als 25 % eines einzelnen Kerns. Die meisten der eingesetzten Agenten beanspruchen nur etwa 5 % eines Kerns. Zur Verwaltung der Tx- und Rx-Paketpuffer und Zähler des Agenten sind lediglich 10 MB Heap-Speicher erforderlich. Wenn das Netzwerk wächst, können wir vertikal oder horizontal skalieren, indem wir die Grenzwerte anpassen oder zusätzliche Agenten hinzufügen.
• Der Agent wird selten beeinträchtigt, wenn das Host-System unter Last steht. Wir haben selbst dann genaue Ergebnisse erhalten, als die CPU-Auslastung des Hosts mehrfach fast 99 % erreichte.
• Von jedem Agenten werden Telemetriedaten erfasst, um dessen Zustand zu überwachen. Die Agenten können problematische Situationen erkennen, beispielsweise wenn das Host-System neu startet, wenn der Agentenprozess neu gestartet wird oder wenn Pakete aufgrund eines Überlaufs der Socket-Puffer verloren gehen.

Die Agenten werden mit Chef auf einer Vielzahl von Serverclustern bereitgestellt, um eine hohe Anzahl von Knoten zu gewährleisten, die an der Netzwerküberwachung teilnehmen. Die Agent-Binärdatei wird unter Linux mit systemd ausgeführt und verwaltet, sodass sie nach einem Neustart des Hosts oder einem Agent-Upgrade automatisch neu gestartet wird. Der Mesh-Scheduler erkennt und passt die Streams dynamisch nach Bedarf an, wenn einer der Agenten ausfällt oder neue hinzukommen. Unsere Scheduler-Anwendung fragt regelmäßig das Geräteinventar und ein Service-Discovery-System ab, um neue Agenten und den Serverstatus zu erkennen, bevor Ziele für Intra-Pod-, Intra-Site- und Inter-Site-Prüfungen zugewiesen werden. Ein Nachrichtenbus wird verwendet, um die Liste der Zielhosts an jeden Agenten zu übermitteln, der Testproben sendet. Einzelne Streams, die an einem bestimmten Rack beginnen oder enden, werden auf alle verfügbaren Agenten innerhalb dieses Racks verteilt. Dies hilft uns, eine große Anzahl von Pfaden mit gleichen Kosten innerhalb unserer Netzwerkstruktur zu nutzen, wie in den folgenden Abbildungen dargestellt.

Wir haben bei unserer ersten Bereitstellung mit 150 Agenten begonnen und konnten diese Zahl inzwischen erfolgreich verzehnfachen. Das Mesh-Netzwerk deckt unser Backbone ab und verbindet 25 Standorte, die über den ganzen Globus verteilt sind. An einem unserer primären Rechenzentrumsstandorte verfügen wir über ein standortinternes Netz, das mehr als 200 Racks mit etwa 33.000 Streams abdeckt und eine Proberate von 1,65 Mpps erreicht. Jedes Rack empfängt 5–10 kpps an Proben von anderen Racks. Die Scheduler-Anwendung berechnet und verteilt über 35.000 Ziele gleichmäßig auf alle unsere Agenten an verschiedenen Standorten.

Datenerfassung und Visualisierung

Wir betreiben eine separate Collector-Anwendung, die regelmäßig alle Ping-Mesh-Agenten auf Paketverluste und Latenzwerte abfragt. Diese Daten werden automatisch gefiltert, um ungültige Ergebnisse auf der Grundlage der lokal im Collector zwischengespeicherten Zustandsdaten auszuschließen. So schließen wir beispielsweise Ergebnisse von einem Agenten aus, der auf einem Server läuft, der nicht auf Zustandsprüfungen reagiert hat, oder von einem Server, der gerade neu gestartet wurde. Unser Collector kann Ergebnisse von über 1.500 Knoten synchron abfragen und filtern und die Daten dann innerhalb von 2 Sekunden in eine Zeitreihendatenbank einspeisen.

Sowohl aggregierte als auch streamspezifische Ergebnisse werden mithilfe von Grafana-Dashboards visualisiert. Heatmap-Raster können bei großen Datensätzen schwierig zu handhaben sein, insbesondere für unseren großen Rechenzentrumsstandort. Wir verwenden eine Prometheus-topk()-Abfrage, um die Pfade mit dem höchsten individuellen Paketverlust unter Tausenden von Ergebnissen anzuzeigen, von denen es in der Regel nur eine Handvoll gibt. Die Ergebnisse werden umfassend mit den Gesundheitsstatistiken der Agenten und Hostsysteme abgeglichen, die regelmäßig vom Collector abgefragt werden. Dies gibt uns ein hohes Maß an Vertrauen in jedes einzelne Ergebnis, unabhängig davon, wie groß die Schwankungen beim Paketverlust sind. Die einzelnen Ergebnisse können uns, wenn sie zusammen betrachtet werden, Hinweise darauf geben, wo der Netzwerkfehler aufgetreten ist. Nachfolgend sind einige Beispiele für Paketverluste aufgeführt, die von unserem Mesh-Überwachungssystem erfasst wurden.

Zusammenfassung und nächste Schritte

Unser Ping-Mesh-System ist für das Netzwerk-Engineering-Team ein leistungsstarkes Werkzeug zur Überwachung von End-to-End-Paketverlusten und Latenzzeiten. Anhand dieser Daten lässt sich die Frage „Verliert das Netzwerk Pakete?“ sofort beantworten. Nach unserer Erfahrung werden größere Netzwerkvorfälle, die Auswirkungen auf Kunden haben, in der Regel vom Gerätetelemetrie-Überwachungssystem erkannt und gemeldet. Probleme mit geringer Auswirkung, aber potenziellem Potenzial für Störungen, wie Netzwerkpufferung oder isolierte Traffic-Black-Holes, werden durch dieses System aufgedeckt.

Unser System liefert zudem Einblicke in die allgemeine Zuverlässigkeit des Roblox Cloud-Netzwerks. An einem unserer großen Rechenzentrumsstandorte überwachen über 100 Millionen Probes pro Minute den Zustand des Netzwerks, und wir verzeichnen selten mehr als 50 Paketverluste pro Minute. Dies entspricht einer Zuverlässigkeit von etwa 6 Neunen (99,9999 %) in unserem Rechenzentrumsnetzwerk. Häufig wird unter den 100 Millionen Paketen kein Paketverlust festgestellt. Wenn eine erhebliche Anzahl von Paketen verloren geht, liefert dieses System Erkenntnisse darüber, wo und wie lange der Paketverlust aufgetreten ist. Eine Engine zur automatischen Fehlerbehebung repariert das Netzwerk selbstständig und verhindert, dass der Benutzerdatenverkehr weitere Verluste erleidet, indem sie ihn über einen anderen Pfad im Netzwerk umleitet. Das Netzwerkteam bei Roblox hat ein äußerst zuverlässiges Cloud-Netzwerk aufgebaut.

In Zukunft beabsichtigen wir, eine Analyse-Engine einzusetzen, um Daten aus Gerätetelemetrie, Syslogs und anderen Datensätzen zu korrelieren. Anschließend planen wir, diese mit Ping-Mesh-Daten zu vergleichen, um die Stelle des Netzwerkfehlers einzugrenzen. Da das Cloud-Netzwerk von Roblox weiter wächst und sich weiterentwickelt, planen wir, unsere Überwachungsmechanismen um IPv6 und Jumbo-Frames zu erweitern und gleichzeitig weitere Agenten hinzuzufügen, um die Abdeckung zwischen den Standorten zu erhöhen.