Ringmap - wydajne przechwytywanie ruchu sieciowego na FreeBSD

Jak co roku Google uruchomiło program Summer of Code. GSoC to niezwykle wartościowa inicjatywa, katalizująca zmiany w różnych projektach open source, wykonywane rękoma pełnych zapału (i głodnych dolarów) studentów nadzorowanych przez doświadczonych mentorów. Program ten ma sens biznesowy dla Googla - pomijając kwestie wizerunkowe, polepszanie jakości ogólnodostępnego oprogramowania sprzyja tworzeniu przeciwwagi dla Microsoftu.

Jednym z wspieranych projektów jest oczywiście FreeBSD. Na liście wspartych w tym roku projektów możemy znaleźć m.in. Ringmap Capturing Stack for High Performance Packet Capturing. Projekt stara się zaadresować problemy wydajnościowe napotykane podczas przechwytywania (sniffing) ruchu sieciowego z użyciem klasycznego Berkeley Packet Filter, kojarzonego bardziej z narzędziem tcpdump (i innymi korzystającymi z biblioteki pcap).

Aplikacja korzysta z wywołań biblioteki pcap aby instrumentować jądro (BPF) do przechwytywania (w warstwie łącza danych) pakietów spełniających określone kryteria. Kryteria zadajemy wyrażeniem filtrującym, np.:

tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)

Fragmenty pakietów spełniających kryteria kopiowane są następnie z przestrzeni jądra do przestrzeni użytkownika, do aplikacji (np. sniffera wydobywającego hasła).

Ten model przetwarzana słabo skaluje się w świecie powszechnych w serwerach interfejsów sieciowych 1Gbit i coraz śmielej wkraczających 10Gbit. Szczególnie kosztowne jest kopiowanie danych (raz - wewnątrz jądra, drugi - do przestrzeni użytkownika), którego częściowo uniknięto wprowadzając we FreeBSD 8 mechanizm Zero-Copy BPF Buffers.

Ringmap ma na celu wprowadzenie prawdziwego zero-copy ;) poprzez mapowanie pamięci DMA karty sieciowej bezpośrednio do przestrzeni użytkownika. Wymaga to oczywiście szczególnego wsparcia po stronie sterownika karty sieciowej - projekt koncentruje się na 10Gbitowych Intelach (ixgbe).

Istnieją również inne pomysły na usprawnienia i rozszerzenia w podsystemie BPF: multiqueue BPF support and other BPF features. Jedno z rozszerzeń (wspomniane pod koniec prezentacji Zero-Copy BPF Buffers) to Direct-to-disk BPF - mechanizm bezpośredniego zapisu ruchu sieciowego na urządzenie dyskowe (zachodzący w całości w przestrzeni jądra). Z pewnością zafrapuje to niektórych subskrybentów POLIP-a, gdzie od czasu do czasu powraca zagadnienie logowania danych u ISP, jego zakresu i możliwości technicznych realizacji na szybkich łączach. ;) Jednym z ograniczeń jest z pewnością konieczność stosowania specjalizowanego podsystemu dyskowego - wysycone obustronnie łącze 10Gbit to przeszło 2.5GB danych na sekundę.

Poza BPF istnieją również inne, nieco mniej standardowe mechanizmy kopiowania ruchu sieciowego do przestrzeni użytkownika, zarówno we FreeBSD jak i w Linuksie. Ale o tym może... innym razem?


Zobacz także:

• bpf(4)
• tcpdump(1) 
• http://www.tcpdump.org/

rrdcached

Dawno, dawno temu, ciekawscy administratorzy wizualizowali sobie obciążenie różnorakich parametrów (np. wykorzystania łączy) przy pomocy MRTG - bo też i nie było nic lepszego. Z kolei co mniej dociekliwi administratorzy u operatorów telekomunikacyjnych odpalali agenta SNMP na ruterach szkieletowych z domyślnym community więc było co wizualizować. ;)

W starym MRTG dane gromadzone były w zwykłych plikach, pliki graficzne odświeżane były dla wszystkich przypadków - nawet jesli nikt danego wykresu nie oglądał. Nie było to dobre i słabo się skalowało. Aż w końcu Tobi zesłał nam RRDtool - cudowne narzędzie do gromadzenia, agregacji i wizualizacji serii danych. Zostało ono użyte nie tylko w MRTG, ale i powstało wiele lepszych narzędzi zauroczonych potęgą RRDtoola.

Specjalizowany backend plikowy jest bardzo wydajny w obsłudze, ale również napotyka problemy w skalowaniu. Wynikają one z faktu, że aktualizowanie dużej liczby serii danych przekłada się na dużą liczbę operacji na plikach:

• otwarcie pliku
• odczyt nagłówka
• aktualizację kilku fragmentów pliku
• zamknięcie pliku

Szczególną uwagę należy poświęcić odczytowi. Podsystem dyskowy jest zwykle tak skonstruowany, że stara się odczytywać dane z pewnym wyprzedzeniem. W większości przypadków taka strategia znakomicie się sprawdza, ale nie w przypadku plików RRD. Otwieranie grupy plików do stosunkowo małej liczby zapisów powoduje jednocześnie w tle potężną liczbę odczytów i wciąganie tych plików do pamięci podręcznej. Wystarczy popatrzeć na systemowe statystyki I/O. Pół biedy, jeśli się one w tej pamięci zmieszczą. Ale jeśli masz więcej niż kilkadziesiąt GB plików RRD, raczej się na typowych serwerach nie zmieszczą. ;)

Na niektórych systemach można ten problem rozwiązać - od wersji 1.3 RRDtool korzysta z funkcji posix_fadvise(), którą można poinformować system, że otwierając plik wcale nie chcemy wczytywać go z wyprzedzeniem (read ahead).

Można też wyłączyć czytanie z wyprzedzeniem na dyskowym urządzeniu blokowym, na którym leży system plików z RRD-kami. Pod Linuksem robi to komenda blockdev --setra 0 /dev/sda (zamiast sda wstaw swój dysk). Ale jeśli na tym samym urządzeniu dyskowym mamy innego rodzaju zasoby niż pliki RRD, to ustawienie może nas zaboleć. ;)

Innym ograniczeniem może być liczba jednoczesnych operacji aktualizacji i wynikający z niej wycisk dla głowic dysków. ;) Problem znika na dyskach SSD - pisałem poprzednio o tego typu instalacji w GG.

Począwszy od wersji 1.4 RRDtool dostarcza rrdcached - mechanizm asynchronicznej aktualizacji plików. Od tej pory możliwe jest natychmiastowe wykonywanie operacji update - zapis trafia do gniazda (lokalnego lub zdalnego) demona rrdcached, który wykonuje faktyczne zapisy większymi paczkami, zgodnie z przyjętą strategią, w zdefiniowanej liczbie wątków. Różnica w wydajności jest dramatyczna. Dane przed zapisem składowane są w pamięci lub w pliku kroniki.

Niestety, jest pewne ograniczenie - rrdcached nie wspiera aktualizacji z użyciem szablonu (template). Niektóre aplikacje oparte o RRD, jak np. Cacti, korzystają z szablonów.

Materiały dla dociekliwych:

• RRDtool Scalability
• Tuning RRD
• Running the World's Largest MRTG

OSEC Barcamp - czerwiec 2010

Kilka dni temu odwiedziłem klub studencki "Dziekanat 161" na SGGW, gdzie odbywał się Barcamp - kameralna impreza o smaku open source, w cieniu której promuje się jej organizator czyli OSEC. ;)

Gwiazdą wieczoru był Michał Gruchała z GG Network S.A., opowiadający o zastosowaniach open source w zarządzaniu infrastrukturą dla znanego komunikatora i innych projektów tej spółki.

Jeśli mam być szczery, rozwiązania wypracowane przez Allegro lub naszą-klasę, prezentowane na różnych konferencjach np. PLNOG, wydają się ciekawsze.

Audytorium było wyraźnie zaskoczone:

• brakiem redundancji geograficznej - tylko jedno datacenter (i tylko 300 fizycznych serwerów)
• polityką aktualizacji systemów - zgodne z zasadą "działa, to nie ruszaj" (delikatna sugestia, że na serwerach backendowych pomija się nawet poprawki bezpieczeństwa), a jak nie działa - to zaoraj od nowa
• brakiem uzasadnienia dla strategicznych wyborów oprogramowania np. wybór Xen-a jako rozwiązania do wirtualizacji podyktowany faktem, że "był w Debianie"
• wyborem leciwego już Nagiosa jako rozwiąznia fault management

Moją uwagę zwrócił także rozmiar opartej o collectd instalacji performance management - aż 300 tys. plików RRD. Obciążenie podsystemu dyskowego było tak wielkie, że wykorzystano w tym miejscu dyski SSD. Postaram się w jednym z kolejnych wpisów poświęcić nieco uwagi dużym instalacjom RRDtoola.

W drugiej części spotkania Łukasz Podkalicki prezentował swój projekt fstorage - będące w początkowym stadium rozwoju rozproszone repozytorium plików i danych strumieniowych np. do zastosowań webowych, mające zaadresować słabości innych rozwiązań (autor często odnosił się do MogileFS).

Audytorium zwrociło uwagę, że autor skupiając się na deweloperce wyraźnie zaniedbał otoczenie projektu warunkujące o być albo nie być - stronę, dokumentację instalacyjną, forum użytkowników, narzędzie śledzenia błędów.


Całość okraszona była browarami i ciepłą strawą, a od czasu do czasu prelekcje przerywał barman z głośnym shakerem i zbłąkane studentki uciekające na widok sali geeków. ;)