Jak hartowała się wirtualizacja

Popełniłem ostatnio kilka bardziej technicznych wpisów, a miały być przecież wynurzenia. ;-)

Jednym ze słów-kluczy, które padły we wpisie o meetBSD, jest wirtualizacja. Ta wspaniała wirtualizacja, dzięki której możemy skonsolidować wiele mielących wiatrakami powietrze serwerów w jedną fizyczną maszynę i uratować zasoby planety; dzięki której możemy powoływać i niszczyć środowiska systemowe (np. do testów) kilkoma kliknięciami myszki.

Pamiętam, że dawno dawno był taki numer PCkuriera, w którym po raz pierwszy ujrzałem VMware, jaskółkę zwiastującą ofensywę wirtualizacji. Przeczesałem dziś metry żółtych okładek na półkach i znalazłem: numer 18/99 z 2-go września 1999 r.

Strona 30, w kategorii Oprogramowanie/Emulatory czai się recenzja Artura Wyrzykowskiego "VMware 1.0. Windows pod Linuksem". Znamienne, że produkt był właśnie w wersji dla Linuksa - "dla Windows NT 4.0 i 2000 VMware przygotowało analogiczny emulator (obecnie jeszcze w wersji beta)". Było to de facto obecne Workstation i kosztowało 299 USD. Autor przeprowadził testy SYSmarkiem, środowisko bez wirtualizacji było o 70-100% szybsze. Zastosowania? Bardzo niszowe. :) Dla kogoś, kto z jakiegoś powodu pracuje tylko pod Linuksem, a musi uruchomić jednocześnie np. MS Windows dla jakiejś specyficznej aplikacji np. Płatnika...

Dziś do zabawy w wirtualizację na desktopie mamy za darmo choćby VMware Player czy Oracle Virtualbox. Prawdziwy biznes robi się na wirtualizacji datacenter, choć i tam coraz więcej można dostać w gratisie.

Dla oddania kontekstu historycznego, kilka smaczków z tego numeru:

• str. 6 - "koszt rejestracji nazwy w domenie .PL to obecnie 300 zł (...) co roku"
• str. 12 - "Usługi katalogowe dziś i jutro", czyli NDS vs. AD - dziś już chyba nie ma wątpliwości, kto wygrał ;)
• str. 18 - "Linux od Corela", pokaz przedpremierowy ś.p. Corel Linuksa oraz Inprise ;) Delphi 5, do tego "Amerykański Departament Handlu poszukuje technologii szyfrujących, z których wybierze jedną jako oficjalny standard AES"
• str. 37 - "TCH Components wprowadził do sprzedaży (...) dyski o pojemności 18GB"
• str. 38 - "Linia komputerów ZETAN, produkowanych przez grupę ZETO (...) wzbogaciła się o komputer wyposażony w procesor Pentium III 600MHz. Zastosowano w nim płytę główną z chipsetem BX, dysk o pojemności 8,4GB oraz 128MB RAM"
• str. 57 - test monitora LCD IBM T55A o przekątnej 15'', cena? jedyne 5700 zł + VAT
• str. 58-59 - zestawienie cen modemów i faksmodemów, ceny rzędu 300-500 zł, ale pojawiają się winmodemy za 149 zł ;)
• str. 60 - informacja o ICQ99b, "w tej chwili baza użytkowników tego pakietu (...) przekracza 40 mln"
• str. 68 - "Bankructwo Iridium. Kosmiczne długi", "Linux na giełdzie. Cena akcji RedHat (...) wzrosła pierwszego dnia notowań o 370%"

Pamiętam... że dawno dawno dawno temu był tak numer C&A, w którym był test emulatora PC na Amigę... ale nie, ta szafa jest zbyt zakurzona.

meetBSD 2010 Kraków

W dniach 2-3 lipca 2010 odbyła się w Krakowie konferencja meetBSD. Wśród prelegentów dominowali goście zagraniczni, w tym deweloperzy systemu FreeBSD. Poziom merytoryczny był wysoki, ale i momentami "ciężki" gatunkowo. Może właśnie dlatego na sali wykładowej było wiele pustych miejsc? Sama sala była zresztą świetna, podobnie jak cały budynek Wydziału Matematyki i Informatyki UJ.

 

Społeczność BSD jest wyraźnie mniejsza niż Linuksowa, także ta komercyjna. Zapewne dlatego Linux wyraźnie wyprzedza FreeBSD w niektórych obszarach. Są to m.in. sieciowa replikacja urządzeń blokowych (np. DRBD) oraz możliwości wirtualizacji. Na konferencji swoje prelekcje mieli autorzy rozwiązań adresujących te luki: HAST-a (Paweł Jakub Dawidek) i VImage (Marco Zec); są one w dość wczesnej fazie rozwoju, ale mają szansę na upowszechnienie wraz z kolejnymi wydaniami linii FreeBSD 8.x.

HAST
HAST odpowiada funkcjonalnie DRBD - replikuje dyskowe urządzenia blokowe (providerów GEOM). Na ten moment implementuje tylko tryb replikacji synchronicznej i nie wspiera pracy multimaster. Według autora jest już jednak w pełni funkcjonalny.

VImage
VImage to wirtualizacja stosu sieciowego. Pamiętam jeszcze patche do FreeBSD 4.x - wówczas było to rozwiązanie zaskakująco zaawansowane, ale chyba wyprzedziło zapotrzebowanie użytkowników. ;) Obecnie VImage zintegrowane jest z oficjanym jądrem (ale nie jest domyślnie wkompilowane) i wraz z jailami stanowi odpowiednik linuksowego OpenVZ. VImage nie wspiera jeszcze pf-a, ale wspiera ipfw i IPsec. Według autora możliwe są problemy ze stabilnością - feature ma status experimental.
Uwagę zwracało graficzne narzędzie do projektowania topologii wirtualnych maszyn z magicznym przyciskiem do aplikowania zaprojektowanych zmian na systemie. Widać, że autor używa tego do symulowania różnych topologii sieciowych i zabawy z protokołami rutingu (w puli jaili, każdy z osobnym stosem sieciowym, biegały Quaggi).

High-speed traffic
Szczególnie zainteresował mnie wykład dotyczący wysokowydajnego rutowania i policowania ruchu abonenckiego na FreeBSD. Nikolay Aleksandrov prezentował rozwiązanie wydewelopowane wewnętrznie dla potrzeb jednego z bułgarskich ISP (warto sprawdzić ofertę - jesteśmy 100 lat za Bułgarami;)):

• zmodyfikowali sterownik karty sieciowej Intela, stworzyli pewien odpowiednik Netgrapha
• zrównoleglili polling na wiele rdzeni CPU i kart

i w ten sposób praktycznie pominęli stos sieciowy systemu - przy pomocy specjalizowanych "węzłów" dopasowują i przekładają ramki pomiędzy VLAN-ami i portami kilku 4-portowych kart 1Gbit, przy okazji go kolejkując. Jako że przepuszczają przez tą maszynę także ruch między abonentami, mają naprawdę duże obciążenie - jeśli dobrze zapamiętałem (slajdów jeszcze nie ma) przy kilkunastu tysiącach abonentów jest to około 2Mpps, 2Gbps ruchu Internetowego i 20Gbps wewnętrznego. To wszystko przycinanie i równoważone w około 200 tys. kolejek (jeden z ich węzłów do procesowania pakietów) na dość zwyczajnej platformie serwerowej Intela z Xeonami przy stabilnym 50% obciążeniu. Aha, zrobili hook do BPF-a (por. wpis o ringmapie), przez co możliwa jest wydajna inspekcja ruchu. Zabawne, do jak ciekawych rzeczy można doprowadzić brak pieniędzy na "profesjonalne rozwiązania". Niestety... kod nie jest na razie publicznie dostępny. ;)

Wieczorny Social Event z koncertem był bardzo przyjemny, a darmowe piwo lało się strumieniami. :P

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. ;)