Monitorowanie utraty pakietów sieciowych i opóźnień w chmurze Roblox

Zespół inżynierów sieci Roblox zarządza rozległą, szybko rozwijającą się siecią z centrami danych i punktami obecności (POP) rozmieszczonymi na całym świecie. Zapewnienie doskonałych wrażeń użytkownikom platformy Roblox zależy od wydajności i niezawodności tej sieci. Dla operatorów sieci kluczowa jest możliwość wykrywania i rozwiązywania problemów w sieci oraz wgląd w jej wydajność. Monitorowanie sieci odbywa się zazwyczaj poprzez okresowe gromadzenie statystyk urządzeń, wskaźników błędów i dzienników systemowych oraz przechowywanie ich w bazie danych szeregów czasowych lub dzienników. Dane są gromadzone w modelu push lub pull przy użyciu standardowych protokołów, takich jak SNMP, Netconf, Rest API lub Streaming Telemetry.

Wykrywanie awarii sieci wyłącznie za pomocą telemetrii urządzeń ma kilka wad, ponieważ jest to technika monitorowania pasywnego. Zależy ona od zdolności węzłów sieciowych do identyfikowania i zgłaszania nietypowych sytuacji natychmiast po ich wystąpieniu. Urządzenie nie zawsze może zgłaszać dane lub, w niektórych przypadkach, może nie udostępniać wszystkich statystyk dotyczących stanu technicznego za pomocą standardowych metod gromadzenia danych telemetrycznych. Ponadto urządzenia sieciowe mogą czasami dostarczać błędne dane lub w sposób niewidoczny blokować ruch. Głównym ograniczeniem telemetrii urządzeń jest to, że zapewnia ona bardzo niewielki wgląd w statystyki dotyczące dostępności sieci od początku do końca, utraty pakietów i opóźnień.

Świetnym sposobem na aktywne monitorowanie sieci jest regularne przesyłanie syntetycznych sond przez sieć typu mesh, jak pokazano na poniższych rysunkach.

Podczas rozwiązywania problemów związanych z przestojami w produkcji operatorzy sieci często słyszą pytania typu: „Czy sieć gubi pakiety?” lub „Czy występuje obecnie awaria sieci wpływająca na łączność usług?”. Aby odpowiedzieć na tego typu pytania bez dostępu do historycznych danych dotyczących utraty pakietów i opóźnień, musieliby zbadać duży zbiór łączy i węzłów w sieci.

Projektowanie niezawodnego i skalowalnego systemu monitorowania sieci typu mesh

Aby system monitorowania sieci typu „czarna skrzynka” skutecznie wykrywał utratę pakietów lub skoki opóźnień, wymaga on ciągłego sondowania różnych części sieci. Sieci centrów danych wykorzystują wszystkie łącza między węzłami do obsługi ruchu użytkowników. Urządzenia sieci produkcyjnej obsługują protokół BGP i równoważą obciążenie ruchem na wielu ścieżkach o równych kosztach. W normalnych warunkach zmiany w topologii sieci są zazwyczaj odzwierciedlane w ciągu kilku sekund poprzez aktualizacje tablic routingu. Aby uzyskać dokładny pomiar utraty pakietów sieciowych, sondy testowe powinny przemieszczać się po jak największej liczbie ścieżek, obejmujących wszystkie węzły i łącza sieciowe. W przypadku dużej sieci, takiej jak nasza, obejmującej wiele lokalizacji na całym świecie, badanie każdej pary węzłów lub szaf nie jest skalowalne. Bardziej zrównoważonym rozwiązaniem, które wybraliśmy, nie obniżającym poziomu widoczności, jest badanie siatki N² w obrębie szaf w każdej lokalizacji wraz z kolejną siatką N² obejmującą wszystkie lokalizacje.

Czym badamy sieć?

Sondy testowe powinny emulować rzeczywisty ruch przechodzący przez sieć produkcyjną. Większość ruchu w naszej sieci to protokoły TCP, UDP lub HTTP, a każdy z nich może potencjalnie służyć do sondowania. Jednym z problemów związanych z sondowaniem TCP jest to, że nie jest ono wystarczająco lekkie, aby skalować się do liczby połączeń potrzebnych do monitorowania dużej sieci. Kolejną wadą protokołu TCP jest wbudowana kontrola przepływu i transmisja oparta na oknie przesuwnym, co skutkuje zmienną szybkością transmisji sondy, co nie jest idealne do kwantyfikacji lub wykrywania chwilowych utraty pakietów. Protokół ICMP, używany przez ping i traceroute, jest zazwyczaj ograniczony szybkością na serwerach lub węzłach sieciowych. Ogranicza to łączną szybkość sond ICMP, które mogą być używane. Żądania HTTP znajdują się wyżej w warstwie aplikacji i zależą od niektórych czynników spoza sieci, takich jak wydajność serwera lub aplikacji. Protokół HTTP dodaje do wyników dodatkowy zmienny czynnik, który trudno jest wyodrębnić. Celem tego systemu jest monitorowanie wydajności podstawowej infrastruktury sieciowej, która działa głównie w warstwach OSI 4 i niższych. Z tych powodów wybraliśmy sondy UDP, a także dlatego, że jest to główny protokół warstwy transportowej w naszej sieci.

Skąd wysyłamy sondy?

Jednym ze sposobów na osiągnięcie dużej łącznej częstotliwości sondowania, a także pokrycie dużej liczby ścieżek sieciowych, jest wykorzystanie jak największej liczby węzłów obliczeniowych do przesyłania sond. Ma to dwie zalety: pomaga rozłożyć obciążenie na systemy generujące sondy oraz zwiększa liczbę portów sieciowych, które je przenoszą. Wymaga to jednak agenta, który jest bardzo stabilny i jak najmniej obciąża zasoby systemu hosta. Jednocześnie agent powinien być w stanie dokładnie mierzyć utratę pakietów i opóźnienia na wielu ścieżkach bez wpływu wahań wykorzystania procesora, pamięci lub wejścia/wyjścia w systemie hosta. Agent musi stale utrzymywać tę delikatną równowagę między lekkością a wysoką wydajnością.

Jak mierzymy straty sieciowe i opóźnienia?

Może się to wydawać trywialnym obliczeniem w przypadku pojedynczego strumienia sond, jednak w skali pojawiają się pewne wyzwania, które nie są od razu oczywiste. Aby skalować się do tak dużej sieci, agent musi szybko i dokładnie obliczać liczbę pakietów wysyłanych (Tx) i odbieranych (Rx) wraz z sygnaturami czasowymi w wielu strumieniach jednocześnie. Ważne jest, aby wskaźniki strat sieciowych nie obejmowały pakietów utraconych na hoście, na którym działa agent, gdy jego procesor jest zajęty lub bufory sieciowe są przepełnione. Opóźnienie sieciowe należy obliczać na podstawie całkowitego czasu, przez jaki sondy znajdowały się w sieci lub w pośrednich węzłach sieciowych, z wyłączeniem czasu spędzonego na oczekiwaniu w buforach wejścia/wyjścia oraz na oczekiwaniu na harmonogramowanie przez system operacyjny procesu agenta.

System Ping Mesh firmy Roblox

Potrzeba monitorowania utraty danych i opóźnień w sieci typu „czarna skrzynka” istnieje od czasu rozwoju infrastruktury chmury publicznej i prywatnej. Trudno było znaleźć gotowe rozwiązanie, które można by skalować do naszej dużej sieci. Kilku dużych operatorów chmury i dostawców narzędzi sieciowych zaprojektowało własne rozwiązania do monitorowania utraty danych i opóźnień w sieci. Wypróbowaliśmy kilka ogólnodostępnych narzędzi, ale napotkaliśmy problemy ze stabilnością i skalowalnością, uzyskując jednocześnie jedynie ograniczony wgląd w wydajność sieci. To skłoniło nas do stworzenia własnego systemu monitorowania sieci typu mesh, który zapewnia lepsze wykrywanie błędów o niskiej częstotliwości przy niewielkim obciążeniu. Oto niektóre z najważniejszych cech naszego systemu:

• Do wdrożenia wszystkich komponentów naszego systemu wybraliśmy język Go, co pomogło osiągnąć wysoki poziom wydajności przy minimalnym zużyciu zasobów systemowych.
• Nasze agenty są bardzo stabilne i mogą działać na wielu różnych hostach produkcyjnych, w tym na tych, które obsługują kluczowe usługi na platformie Roblox, takie jak serwery ruchu, buforowania i aplikacji.
• Agent jest zoptymalizowany pod kątem operacji wejścia/wyjścia pakietów w trybie wsadowym za pomocą funkcji opakowujących Go nad wywołaniami systemowymi Linux sendmmsg() i recvmmsg(), co pozwala mu przesyłać sondy z dużą częstotliwością przy niskim obciążeniu. Każdy agent w naszym wdrożeniu jednocześnie przesyła sondy do maksymalnie 100 innych hostów z prędkością 100 pakietów na sekundę (PPS). Agent wysyła serie pakietów co sekundę do każdego miejsca docelowego.
• Sondy przenoszą różne wartości pola typu usługi (TOS) w nagłówku IP do każdego miejsca docelowego i są rozliczane oddzielnie pod kątem utraty pakietów i opóźnień w sieci. Każda seria pakietów zawiera mieszankę wielu wartości TOS do każdego innego miejsca docelowego. Pomaga to monitorować wydajność sieci dla różnych klas jakości usług (QoS).
• Agent może wykrywać utratę pakietów na poziomie nawet 1 na 6000 pakietów na minutę na każdej ścieżce sondy. Możliwe jest wykrycie utraty pakietów w rdzeniu lub na obrzeżach sieci trwającej krócej niż 1 sekundę, np. podczas flapu BGP.
• Wykresy utraty pakietów sondy odzwierciedlają wskaźniki błędów interfejsów urządzeń sieciowych, gdy to właśnie te błędy są przyczyną utraty pakietów. Udało nam się wykryć w sieci trudne do wykrycia błędy związane z „czarnymi dziurami” ruchu.
• Agenci wykorzystują znaczniki czasu odczytu jądra karty sieciowej (NIC), aby uzyskać wysoką dokładność pomiarów opóźnień sieciowych. Można zmierzyć stałe opóźnienie w obie strony w obrębie lokalizacji wynoszące 50–100 mikrosekund, wykluczając opóźnienia związane z planowaniem systemu operacyjnego hosta oraz dryft zegara sieciowego.
• Niskie wykorzystanie procesora i pamięci. Agent wykorzystuje mniej niż 25% jednego rdzenia przy szczytowych szybkościach transmisji i odbioru (po 5 kpps). Większość wdrożonych agentów wykorzystuje tylko około 5% rdzenia. Do zarządzania buforami pakietów Tx i Rx oraz licznikami agenta potrzeba tylko 10 MB pamięci sterty. Gdy sieć się rozrasta, możemy skalować się pionowo lub poziomo, dostosowując limity lub dodając dodatkowe agenty.
• Agent rzadko odczuwa wpływ obciążenia systemu hosta. Uzyskaliśmy dokładne wyniki nawet wtedy, gdy obciążenie procesora hosta kilkakrotnie zbliżało się do 99%.
• Dane telemetryczne są zbierane z każdego agenta w celu monitorowania jego stanu. Agenci potrafią zidentyfikować problematyczne sytuacje, takie jak ponowne uruchomienie systemu hosta, ponowne uruchomienie procesu agenta lub utratę pakietów spowodowaną przepełnieniem buforów gniazd.

Agenci są wdrażani za pomocą Chef na szerokim zestawie klastrów serwerów, aby utrzymać dużą liczbę węzłów uczestniczących w sondowaniu sieci. Plik binarny agenta jest uruchamiany i zarządzany za pomocą systemd w systemie Linux, dzięki czemu jest on automatycznie restartowany po ponownym uruchomieniu hosta lub aktualizacji agenta. Harmonogram sieci dynamicznie wykrywa i dostosowuje strumienie w razie potrzeby, gdy którykolwiek z agentów ulegnie awarii lub pojawią się nowe. Nasza aplikacja harmonogramująca okresowo sprawdza spis urządzeń i system wykrywania usług w celu wykrycia nowych agentów i stanu zdrowia serwerów przed przypisaniem celów do sondowania wewnątrz-podowego, wewnątrz-witrynowego i między-witrynowego. Magistrala komunikacyjna służy do przekazywania listy hostów docelowych do każdego agenta, który wysyła sondy testowe. Poszczególne strumienie, które mają swój początek lub koniec w konkretnej szafie, są rozdzielane między wszystkich dostępnych agentów w tej szafie. Pomaga nam to wykorzystać dużą liczbę ścieżek o równym koszcie w naszej strukturze sieciowej, jak pokazano na poniższych rysunkach.

Zaczęliśmy od 150 agentów w naszym pierwszym wdrożeniu, a obecnie udało nam się zwiększyć ich liczbę dziesięciokrotnie. Sieć typu mesh obejmuje naszą sieć szkieletową, łączącą 25 lokalizacji rozsianych po całym świecie. W jednym z naszych głównych centrów danych mamy sieć wewnątrzlokacyjną obejmującą ponad 200 szaf z około 33 000 strumieni, co daje łączną częstotliwość sondowania wynoszącą 1,65 Mpps. Każda szafa odbiera 5–10 kpps sond z innych szaf. Aplikacja planująca oblicza i równomiernie rozdziela ponad 35 000 celów między wszystkie nasze agenty w różnych lokalizacjach.

Gromadzenie i wizualizacja danych

Używamy osobnej aplikacji zbierającej dane, która co jakiś czas sprawdza wszystkie agenty Ping Mesh pod kątem utraty pakietów i opóźnień. Dane te są automatycznie filtrowane, żeby wykluczyć nieprawidłowe wyniki na podstawie stanów zdrowia zapisanych lokalnie w aplikacji zbierającej. Na przykład wykluczamy wyniki z agenta działającego na serwerze, który nie odpowiedział na testy sprawdzające stan zdrowia, albo z serwera, który właśnie się zrestartował. Nasz kolektor może synchronicznie odpytywać i filtrować wyniki z ponad 1500 węzłów, a następnie wprowadzać dane do bazy danych szeregów czasowych w ciągu 2 sekund.

Zarówno wyniki zagregowane, jak i wyniki dla poszczególnych strumieni są wizualizowane za pomocą pulpitów nawigacyjnych Grafana. Siatki map cieplnych mogą być trudne w użyciu w przypadku dużych zbiorów danych, szczególnie w przypadku naszego dużego centrum danych. Wykorzystujemy zapytanie Prometheus topk(), aby wyświetlić ścieżki o największej indywidualnej utracie pakietów spośród tysięcy wyników, których zazwyczaj jest tylko kilka. Wyniki są dokładnie weryfikowane w oparciu o statystyki kondycji agentów i systemów hostów, które są często zbierane przez kolektor. Daje nam to wysoki poziom pewności co do każdego pojedynczego wyniku, niezależnie od tego, jak duże są wahania utraty pakietów. Poszczególne wyniki, gdy są oglądane razem, mogą dać nam wskazówki, gdzie wystąpiła awaria sieci. Poniżej przedstawiono kilka przykładów utraty pakietów, które zostały wykryte przez nasz system monitorowania sieci kratowej.

Podsumowanie i kolejne kroki

Nasz system Ping Mesh stanowi potężne narzędzie dla zespołu inżynierów sieciowych do monitorowania utraty pakietów i opóźnień w całym łańcuchu. Dane te pozwalają natychmiast odpowiedzieć na pytanie: „Czy sieć traci pakiety?”. Z naszego doświadczenia wynika, że poważne incydenty sieciowe mające wpływ na klientów są zazwyczaj wykrywane i sygnalizowane przez system monitorowania telemetrycznego urządzeń. Dzięki temu systemowi ujawniane są również problemy o niewielkim wpływie, ale potencjalnie problematyczne, związane z buforowaniem sieci lub izolowanymi przypadkami „czarnej dziury” w ruchu.

Nasz system może również dostarczyć informacji na temat ogólnej niezawodności sieci Roblox Cloud Network. W jednym z naszych głównych centrów danych mamy ponad 100 milionów sond na minutę monitorujących stan sieci i rzadko odnotowujemy liczbę utraconych pakietów większą niż 50 na minutę. Wskazuje to na niezawodność na poziomie około 6 dziewiątek (99,9999%) w naszej sieci centrum danych. Dość często wśród 100 milionów pakietów nie odnotowuje się żadnej utraty. Gdy dochodzi do utraty znacznej liczby pakietów, system ten dostarcza informacji o tym, gdzie i jak długo trwała utrata. Silnik automatycznej naprawy samoczynnie naprawia sieć i zapobiega dalszym utratom ruchu użytkowników, przekierowując go inną ścieżką w sieci. Zespół ds. sieci w Roblox zbudował niezwykle niezawodną sieć chmurową.

W przyszłości zamierzamy wykorzystać silnik analityczny do korelacji danych z telemetrii urządzeń, dzienników systemowych i innych zestawów danych. Następnie planujemy porównać je z danymi Ping Mesh, aby pomóc w zlokalizowaniu miejsca wystąpienia awarii sieci. W miarę rozbudowy i ewolucji sieci chmurowej Roblox planujemy ulepszyć nasze mechanizmy sondowania, aby uwzględnić IPv6 i ramki jumbo, jednocześnie dodając więcej agentów w celu zwiększenia zasięgu między lokalizacjami.