Twarde fluszowanie buforów

Dawno nie było "twardego" wpisu...

Gdy tworzymy aplikację i kod zapisujący do pliku, zwykle traktujemy operację zapisu jako wykonaną gdy sterowanie w kodzie przejdzie do kolejnych instrukcji. Zazwyczaj to fałszywe poczucie bezpieczeństwa w niczym nie przeszkadza. Do czasu, gdy pojawi się sytuacja awaryjna: aplikacja, system operacyjny, dyski lub zasilanie padną.

Odkrywamy jednak operację typu (f)flush() i czujemy się lepiej, bufory mamy opróżnione. Bardzo miło, ale nasza sytuacja w razie awarii systemu nie jest wiele lepsza. Jedyne co osiągnęliśmy, to wypchnięcie danych z jednych buforów do drugich (OS). Dane nadal nie są utrwalone. Jeśli oprogramowanie zapisuje krytyczne dane, realizuje jakąś transakcję, to kiepsko to wygląda.

Aby je utrwalić na nośnikach, musimy sięgnąć po fsync(). Bardzo ładnie jest to wyjaśnione tutaj.

Oczywiście, one nadal nie muszą być utrwalone. Jest jeszcze sterownik systemu plików, sterownik urządzenia blokowego, bufor w macierzy/kontrolerze dysków i w samym dysku! Ale jeśli sterowniki, kontroler dysków i firmware dysku są OK, no to w końcu czujemy się lepiej. Problem w tym, że nie zawsze są OK.

Poza tym, nawet jeśli są OK, awaria dysku/zasilania może przyjść w trakcie zapisywania danych na dysk i zapiszą się tylko częściowo i nie w tej kolejności, w której były zlecone. Implikacje mogą być bardzo daleko idące i dotyczą głównie implementacji: systemów plików, baz danych, systemów transakcyjnych, systemów kolejkowych czy nawet serwera pocztowego. Na pewno wszędzie, gdzie liczy się ACID.

Niektóre systemy udostępniają dodatkowe możliwość wpłynięcia na proces utrwalania, np. Mac OS X udostępnia w fnctl() opcję F_FULLFSYNC. Również Windows udostępnia funkcję FlushFileBuffers() do czyszczenia (całego) cache dysku oraz tryb otwarcia pliku FILE_FLAG_WRITE_THROUGH, których opis sugeruje, że załatwiają sprawę (głowy nie dam, ale wg tego porównania wypada nieźle).

Istnieją narzędzia, które świadomie korzystają z tego dobrodziejstwa, np.:

• SQLite (trop)
• patch do Erlanga (uwzględnione) przysłany przez CouchDB
• ActiveMQ (kod)
• H2 DB udostępnia, ale domyślnie świadomie rezygnuje (analiza)

Istnieją ponadto techniki radzenia sobie z częściowym utrwaleniem danych na podsystemie dyskowym w aplikacjach, które przepisują daną "w miejscu". Dla przykładu Websphere MQ zapisuje dziennik operacji (journal) w stronach i może się zdarzyć, że strona nie jest pełna. Wówczas zapisywana jest część strony, a reszta zostaje dopisana później. Ta druga operacja potencjalnie może skutkować utratą danych tego pierwszego zapisu. Aby to obejść, Websphere MQ domyślnie stosuje dla loga operacji metodę zapisu (LogWriteIntegrity) TripleWrite. Powoduje to dla niepełnych stron loga zapis pierwszej "połówki", na kolejnej stronie commit drugiej "połówki", a następnie (trzeci zapis) commit obu połówek razem do tej pierwszej strony.

To na ostateczne popsucie humoru:

• znacie programistów krytycznych aplikacji biznesowych ;) w Java, którzy świadomie robią coś więcej niż flush() by utrwalić dane?
• znacie kogoś, kto ma transakcyjną bazę danych SQL lub serwer SMTP na "oszukujących" dyskach SATA? (co lepsze, te low-endowe dyski mają duże 16-64MB cache)
• co się stanie z e-mailem, gdy serwer SMTP potwierdzi jego przyjęcie i nie zrobi fsync() na pliku w spoolu, po czym padnie zasilanie?
• znacie administratorów Linux, którzy świadomie wyłączają write cache na dyskach? (czasami robią to za nich same kontrolery macierzowe)
• zastanawialiście się co czeka system plików w wirtualnej maszynie po padzie hosta, zwłaszcza gdy ów filesystem gościa jest plikiem na systemie hosta? (hint)
• czy Wasz system plików księguje (journalling) dane, czy tylko metadane?
• ile lat temu pojawiło się wsparcie dla wiarygodnego utrwalania danych w Twoich krytycznych aplikacjach i systemach?

BSD Hypervisor

Zupełnie przypadkiem zauważyłem ostatnio, że pod skrzydłami FreeBSD rozwija się nowy twór ;) w postaci natywnego hypervisora: BHyVe. Projekt jest podarunkiem od NetApp i ma ambitne cele, m.in. wsparcie dla live migration. BHyVe można sklasyfikować jako hypervisor typu hosted, tj. pracujący w otoczeniu systemu operacyjnego (w odróżnieniu od bare metal).

Po co to komu, skoro jest już tyle innych i dojrzałych rozwiązań do wirtualizacji? Syndrom NIH? A może polityka i przykład strategicznego planowania? Czas pokaże. ;-)

NetBSD Rump

Znalazłem kolejny po NPF i Lunatiku powód, by kiedyś (czyli nigdy?) bliżej przyjrzeć się NetBSD: Rump Anykernel. Rump (Runnable Userspace Meta Program) umożliwia uruchamianie w przestrzeni użytkownika jądra lub jego elementów. Możliwe zastosowania to bezpieczeństwo, wirtualizacja lub łatwiejsze debugowanie. ;) Co więcej, dzięki rump sysproxy możliwe jest luźne wiązanie aplikacji (kernel clients) z takimi komponentami jądra (kernel servers). Tutorial demonstruje np. uruchamianie aplikacji w połączeniu z dedykowanym, zwirtualizowanym stosem TCP/IP.

Drżyj - nadciąga TRILL

Ivan Pepelnjak, posiadacz najwyższych stopni wtajemniczenia w sekcie siskoitów ;) silnie skupił się na krytyce promowanego ostatnimi czasy TRILL-a.

Czym jest TRILL? Bardzo upraszczając, to takie przełączanie ramek, gdzie poszczególne przełączniki wymieniają informacje o trasach podobnie jak rutery, czyli z użyciem protokołu rutingu. (Klasyczne przełączniki uczą się po prostu, na którym porcie jaki MAC jest osiągalny, a jak nie wiedzą, to ślą ramkę do wszystkich). Teoretycznie ma uprościć życie i np. pozwolić budować wielkie (tysiące hostów) domeny rozgłoszeniowe w środowisku datacenter. Bardzo modne w czasach wirtualizacji i chmur.

Dlaczego należy drżeć przed TRILL-em? Ivan zastanawia się nad tym w serii postów. W szczególności polecam:

• Dlaczego bridge w ogóle nie powinny zaistnieć? - Bridges: a kludge that shouldn't exist
• Jaka jest różnica między przełączaniem a rutowaniem? - Bridging and Routing: is there a difference? oraz Bridging and Routing, Part II
• O wysypie standardów - How many large-scale bridging standards do we need?

Ivan obawia się, że debugowanie problemów w takich sieciach stanie się prawdziwym koszmarem, ze względu na różnice leżące u podstaw działania warstwy drugiej i trzeciej. Znamienne dla L2 są m.in.:

• brak licznika hopów
• brak wsparcia dla fragmentacji
• brak sygnalizacji problemu do nadawcy
• powielanie ramek
• mobilność adresu

No cóż, sieci podobnie jak wszystko inne robią się nam coraz bardziej skomplikowane. ;)

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

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