📬 ISN 182: Zbuduj w chmurze laboratorium dla Data Center

Czemu Ansible działa wolno?

Ever Wondered Why Ansible Feels Slow?

The other day I was troubleshooting a simple Ansible connectivity issue and decided to peek under the hood. Using Border0 session recording feature i went down a bit of a rabbit hole.

LinkedInAndree Toonk

Podczas pracy z narzędziami do automatyzacji takich jak Ansible, jednym z głównych powodów frustracji może być powolne wykonywanie zadań i poleceń, Aby lepiej zrozumieć, co dzieje się w tle, przyjrzyjmy się przykładowemu poleceniu ansible:

ansible all -i my-server, -m command -a "uptime"

Naiwnie można by się spodziewać pojedynczego połączenia SSH, wykonania polecenia uptime i zakończenia operacji. Jednak w rzeczywistości proces jest znacznie bardziej złożony. Zobaczmy, co dzieje się krok po kroku:

1. Znalezienie katalogu domowego
   Ansible potrzebuje wiedzieć, gdzie umieścić pliki tymczasowe. Wykonuje więc pierwsze polecenie w celu ustalenia katalogu domowego użytkownika.
2. Utworzenie katalogu tymczasowego
   Następnie tworzy katalog tymczasowy, w którym będą przechowywane pliki pomocnicze i skrypty.
3. Odkrywanie wersji Pythona
   Ansible skanuje system w poszukiwaniu dostępnych wersji interpretera Pythona, aby móc skorzystać z najlepszej opcji.
4. Sprawdzenie poprawności Pythona
   Aby upewnić się, że wybrany interpreter działa prawidłowo, Ansible wykonuje testowe polecenie.
5. Przesłanie modułu przez SFTP
   W tym momencie Ansible przesyła plik AnsiballZ_command.py zawierający kod Pythona do wykonania żądanego polecenia.
6. Nadanie praw wykonywania
   Upewniając się, że właśnie przesłany skrypt będzie mógł zostać wykonany.
7. Wykonanie zadania
   Wreszcie, za pomocą polecenia python, Ansible uruchamia swój główny skrypt z żądanym poleceniem.
8. Sprzątanie
   Po wykonaniu zadania Ansible usuwa wszystkie utworzone wcześniej pliki tymczasowe.

Łatwo zauważyć, że ta pozornie prosta operacja wymaga dużej ilości przygotowań i dodatkowych czynności w tle. A wszystko to zanim Ansible w ogóle wykona właściwe polecenie.

Ansible został zaprojektowany z myślą o solidności, bezpieczeństwie i elastyczności. Zamiast wykonywać polecenia bezpośrednio na zdalnym systemie, pozwala przesyłać samodzielne moduły kodu Pythona, które są następnie wykonywane w kontrolowanym środowisku. Taka architektura daje większą kontrolę nad procesem i lepsze możliwości debugowania, ale niestety wiąże się z dodatkowymi czynnościami przygotowawczymi.

Choć wspomniane wcześniej kroki są dla Ansible normalne, nie zawsze jest to pożądane zachowanie. W przypadku prostych poleceń, takich jak uptime, cały ten proces może wydawać się zbyt rozbudowany. Na szczęście istnieje wyjście - tryb surowy (raw).

Tryb surowy pozwala ominąć większość kroków przygotowawczych i bezpośrednio wykonać żądane polecenie na zdalnym hoście. Zaoszczędzi to czas i zasoby, kosztem jednak mniejszej kontroli i możliwości debugowania. Aby uruchomić polecenie uptime w trybie surowym, użyj polecenia:

ansible all -i my-server, -m raw -a "uptime"

To polecenie wykona zadanie w pojedynczej sesji SSH, bez potrzeby przesyłania czy uruchamiania dodatkowych skryptów. Idealne rozwiązanie, gdy czas ma kluczowe znaczenie.

Wydajność TCP w sieci Starlink

A transport protocol’s view of Starlink

How TCP interacts with the characteristics of the Starlink service.

APNIC BlogGeoff Huston

W świecie nowoczesnych technologii komunikacyjnych, systemy satelitarne stanowią coraz ważniejszą alternatywę dla tradycyjnych łączy naziemnych. Szczególnie interesującym przypadkiem jest Starlink, system satelitarny niskiej orbity ziemskiej (LEO) firmy SpaceX, który oferuje unikalne możliwości, ale również stawia przed inżynierami sieciowymi nowe wyzwania. Jak protokół TCP, podstawowy filar transportu danych w Internecie, radzi sobie z tymi wyzwaniami?

Aby zrozumieć wyjątkowość Starlink, warto najpierw przyjrzeć się tradycyjnym systemom satelitarnym na orbicie geosynchronicznej. Te satelity, znajdujące się na wysokości około 35 786 km nad równikiem, pozostają "nieruchome" względem powierzchni Ziemi. Jednak ta stabilność ma swoją cenę:

• Opóźnienie sygnału (RTT) wynosi średnio około 660 ms
• Ograniczona liczba dostępnych "slotów" orbitalnych
• Konieczność stosowania dużych anten odbiorczych

Starlink wykorzystuje satelity na niskiej orbicie ziemskiej (LEO), na wysokości około 550 km. To fundamentalnie zmienia charakterystykę usługi:

• Minimalne opóźnienie propagacji sygnału to zaledwie 3,7 ms
• Satelity poruszają się z prędkością około 27 000 km/h względem powierzchni Ziemi
• Każdy satelita jest widoczny z danego punktu na Ziemi przez zaledwie kilka minut
• Konieczność współpracy setek satelitów tworzących konstelację

Analiza danych pomiarowych ujawnia kilka kluczowych cech łącza Starlink:

1. Zmienne opóźnienie - RTT zmienia się regularnie co około 15 sekund, co odpowiada przełączaniu między satelitami. Opóźnienie może skoczyć nagle z 30 ms do 80 ms podczas takiego przełączenia.
2. Wysoki jitter - średnia zmienność opóźnienia między kolejnymi pakietami wynosi około 6,7 ms, co jest relatywnie wysoką wartością.
3. Utrata pakietów - średnio około 1-2% pakietów jest traconych, przy czym straty te nie są związane z przeciążeniem sieci, a raczej z przełączaniem satelitów lub zakłóceniami radiowymi.
4. Zmienne przepustowości - testy wykazują, że przepustowość może wahać się od 10 Mbps do 370 Mbps dla pobierania i od 5 Mbps do 50 Mbps dla wysyłania, z medianą około 120 Mbps.

Protokół TCP został zaprojektowany z kilkoma założeniami dotyczącymi charakterystyki sieci:

• Stabilna maksymalna przepustowość ścieżki
• Niski jitter w porównaniu do RTT
• Niska średnia utrata pakietów, głównie związana z przepełnieniem buforów

Starlink łamie wszystkie te założenia, co powoduje, że standardowe implementacje TCP mogą działać nieefektywnie. W szczególności:

TCP CUBIC, najpopularniejszy obecnie algorytm kontroli przeciążeń, wykazuje następujące zachowanie na łączu Starlink:

• W godzinach szczytu osiąga średnią przepustowość znacznie poniżej potencjału łącza (około 45 Mbps przy rzeczywistej przepustowości 250 Mbps)
• Reaguje gwałtownie na straty pakietów, drastycznie zmniejszając okno wysyłania
• Powoli odbudowuje przepustowość po wystąpieniu straty pakietu
• Wykazuje znacznie lepszą wydajność w godzinach mniejszego obciążenia sieci

BBR (Bottleneck Bandwidth and Round-trip propagation time) to nowszy algorytm kontroli przeciążeń, który:

• Utrzymuje swoją szybkość wysyłania pomimo pojedynczych strat pakietów
• Próbuje oszacować iloczyn opóźnienia i przepustowości ścieżki
• Aktywnie testuje przepustowość przez regularne zwiększanie szybkości wysyłania
• Na łączu Starlink osiąga przepustowość znacznie bliższą rzeczywistemu potencjałowi łącza

Jak można zoptymalizować działanie TCP na łączach Starlink? Istnieje kilka obiecujących podejść:

1. Modyfikacja BBR - dostosowanie algorytmu BBR do brania pod uwagę regularnych 15-sekundowych przełączeń satelitów, opóźniając zwiększenie szybkości wysyłania jeśli zbliża się moment przełączenia.
2. Adaptacja CUBIC - modyfikacja CUBIC, aby wykorzystywał Selektywne Potwierdzenia (SACK) do naprawy utraconych pakietów bez zmniejszania okna wysyłania, jeśli strata nastąpiła podczas przełączania satelitów.
3. Wykorzystanie ECN - Explicit Congestion Notification pozwoliłoby protokołowi TCP na rozróżnienie między stratą pakietu spowodowaną przełączeniem satelity a stratą wynikającą z rzeczywistego przeciążenia sieci.

Starlink stanowi wyjątkowe środowisko dla protokołu TCP, charakteryzujące się wysokim jitterem, regularnie zmieniającym się opóźnieniem i stratami pakietów niezwiązanymi z przeciążeniem. Nowsze protokoły kontroli przeciążeń, takie jak BBR, radzą sobie z tymi wyzwaniami lepiej niż starsze implementacje.

Kluczowym elementem poprawiającym wydajność TCP na łączach Starlink jest wykorzystanie Selektywnych Potwierdzeń (SACK), które pozwalają algorytmowi kontroli przeciążeń na rozróżnienie między pojedynczymi stratami pakietów a stanem przeciążenia sieci.

EVPN/VXLAN od Nokia

https://documentation.nokia.com/cgi-bin/dbaccessfilename.cgi/3HE21632AAAATQZZA_V1_Nokia%20Validated%20Design:%203-stage%20EVPN%20VXLAN%20Fabric%20.pdf

Dokument wydany w ramach NVD (Nokia Validated Designs) koncentruje się na trójetapowym projekcie Clos EVPN VXLAN, obejmującym różne aspekty łączności fizycznej i logicznej w architekturze centrum danych, z EVPN jako płaszczyzną kontrolną i VXLAN jako płaszczyzną danych.

Automatyzacja bez linijki kodu

cli-automation

Network Automation from the Command Line

PyPI

cli-automation to aplikacja stworzona w języku Python, która automatyzuje proces zarządzania infrastrukturą sieciową bez konieczności pisania kodu. Jest dedykowana inżynierom sieciowym, którzy nie posiadają zaawansowanej wiedzy programistycznej, co umożliwia im łatwe wyciąganie konfiguracji oraz konfigurowanie urządzeń sieciowych. Użytkownicy mogą wprowadzać parametry połączenia za pomocą wiersza poleceń lub plików JSON.

Darmowe laboratorium w chmurze dla Twojego DC