W każdej chwili w Internecie gdzieś jest jakaś awaria.
Część tych awarii ma punktowych charakter i nie oddziaływuje na ruch na całym świecie. Czasem jednak, np. w wyniku zabaw z Bardzo Groźnym Protokołem, może pojawić się spore zamieszanie.
Jak już jesteśmy przy RIPE, warto w tym miejscu wspomnieć o jednym z ostatnich projektów RIPE Labs: Active Measurements. Pomysłodawcy wyszli z założenia, że nic tak dobrze nie będzie monitorować osiągalności kluczowych elementów sieci jak... rozproszona baza użytkowników końcowych.
Jest to zresztą naturalne rozwinięcie koncepcji innego projektu: DNSMON. O ile DNSMON używa sieci dedykowanych serwerów testowych (Test Traffic Measurements boxes), to aktywny monitoring zmierza w kierunku wykorzystania zminiaturyzowanych sond, które można tanio i łatwo instalować nawet u końcowego użytkownika. Poza rozmiarem, siłą tych sond jest ich docelowa liczebność - dziesiątki tysięcy lub więcej. Dzięki temu chwilowe problemy w pracy niektórych z sond będą tylko anomalią statystyczną.
Przy tak dużej liczbie, w każdej chwili gdzieś w Internecie będzie pracować jakaś sonda. ;)
Więcej informacji o projekcie:
Pokazywanie postów oznaczonych etykietą system zarządzania siecią. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą system zarządzania siecią. Pokaż wszystkie posty
wtorek, 28 września 2010
piątek, 13 sierpnia 2010
BSNMP
Pakiet Net-SNMP (dawniej UCD-SNMP) to bardzo popularna implementacja agenta SNMP. Dostarcza oprogramowanie użytkowe (sam agent jak i narzędzia) oraz biblioteki udostępniające API dla innych programów i języków programowania.
Każdy kto pracował chwilę z Net-SNMP wie, że prostota nie jest atutem tego pakietu... podobnie jak i samego protokołu (Simple Network Management Protocol), prostotę mającego chyba tylko w nazwie.
Harti Brandt, jeden z deweloperów FreeBSD, stworzył swego czasu uproszczoną implementację agenta, zwaną BSNMP: "It is intended to serve only the absolute basic MIBs and implement all other MIBs through loadable modules".
Wydaje się, że nie jest on jakoś powszechnie stosowany - ociężałego Net-SNMP ciężko się pozbyć. ;) Warto więc zauważyć, że BSNMP jest rozwijane i Shteryana Shopova otrzymała tegoroczny grant (o GSoC więcej pisałem tutaj) na implementację obsługi SNMPv3 i lepszą integrację ze statystykami sieci bezprzewodowych. Do wielu zastosowań, sprowadzających się do monitorowania wydajności narzędziami opartymi o RRDtool, BSNMP jest wystarczający.
Poza tym, w portach dostępne są dodatki: bsnmp-jails, bsnmp-regex, bsnmp-ucd, bsnmptools.
Każdy kto pracował chwilę z Net-SNMP wie, że prostota nie jest atutem tego pakietu... podobnie jak i samego protokołu (Simple Network Management Protocol), prostotę mającego chyba tylko w nazwie.
Harti Brandt, jeden z deweloperów FreeBSD, stworzył swego czasu uproszczoną implementację agenta, zwaną BSNMP: "It is intended to serve only the absolute basic MIBs and implement all other MIBs through loadable modules".
Wydaje się, że nie jest on jakoś powszechnie stosowany - ociężałego Net-SNMP ciężko się pozbyć. ;) Warto więc zauważyć, że BSNMP jest rozwijane i Shteryana Shopova otrzymała tegoroczny grant (o GSoC więcej pisałem tutaj) na implementację obsługi SNMPv3 i lepszą integrację ze statystykami sieci bezprzewodowych. Do wielu zastosowań, sprowadzających się do monitorowania wydajności narzędziami opartymi o RRDtool, BSNMP jest wystarczający.
Poza tym, w portach dostępne są dodatki: bsnmp-jails, bsnmp-regex, bsnmp-ucd, bsnmptools.
sobota, 19 czerwca 2010
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.
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:
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:
sobota, 12 czerwca 2010
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:
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:
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
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:
piątek, 11 czerwca 2010
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:
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. ;)
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
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. ;)
Subskrybuj:
Posty (Atom)