Wzorce skalowania

Trafiłem niedawno na interesującego posta Scalability patterns and an interesting story... Autor wyróżnił pewne uniwersalne wzorce spotykane przy skalowaniu (rozumianym jako scale out, nie up) oprogramowania. Lubię porządek więc przytoczę. ;)

1. dystrybucja obciążenia
• równoważenie obciążenia
• partycjonowanie
• poziome
• pionowe
2. zrównoleglanie
3. luźne wiązanie
4. kolejkowanie i paczkowanie

RouteBricks

Rok po roku opensource podgryza kolejne przyczółki branży IT, okupowane dotąd przez rozwiązania komercyjne.

Są takie miejsca, w których ekspansja jest łatwa - dziś już chyba nikt nie wyobraża sobie płacenia za program do przeglądania zdjęć? Choć wiem, że niektórzy płacą np. za edytory tekstu ze wsparciem dla programowania ;) W innych przypadkach idzie nieco trudniej - choćby "ekspansja" Linuksa na desktopach... Są i takie, w których wejście na lukratywny rynek jest bardzo trudne - we wpisie z Open Source Day 2010 przytoczyłem przykład profesjonalnych baz danych.

Innym tego typu obszarem są urządzenia sieciowe. Widać postęp - od lat wiele urządzeń w segmencie SOHO (np. routery bezprzewodowe) to po prostu małe komputerki oparte np. o MIPS-a, z Linuksem w środku. Otwartość oprogramowania to tylko jeden z czynników, krytyczny jest jednak wzrost możliwości obliczeniowych architektury PC. Co by nie mówić o tym wzroście, przy wysokowydajnym przełączaniu pakietów IP, PC nie jest w stanie konkurować ze specjalizowanymi układami. Ale i tak kawałek tortu jest podgryzany, obsługa dziesiątek czy setek megabitów ruchu IP na pececie nie jest wielkim problemem. We wpisie z meetBSD 2010 pisałem o ekstremalnym rozwiązaniu pewnego bułgarskiego ISP, opartym o FreeBSD. ;) Elastyczność platformy PC w roli routera nie zawsze jest atutem, toteż powstają takie produkty jak Vyatta. Jest jednak poziom, z którym trudno się równać.


Trafiłem jednak w sieci na dający nadzieję artykuł: Software Router Smashes Speed Records. Ostateczne, jeśli procesor PC wciąż jest za słaby, można poszukać mocy w karcie graficznej. Można też zainstalować karty z układami FPGA. Oczywiście, wciąż ogranica nas magistrala. Istnieje równiez inicjatywa RouteBricks korzystająca z Clicka, gdzie wydajność routowania skaluje się... zrównoleglaniem, czyli zwiększając liczbę pecetów. Niestety, prototyp rozwiązania wciąż nie jest komercyjnie dostępny.

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

Gorzej, ale czasem szybciej

Natknąłem się niedawno na ciekawy, a do tego świeży (czerwiec 2010) artykuł "You're Doing It Wrong", który popełnił znany z asertywnych wypowiedzi deweloper FreeBSD i Varnisha, Poul-Henning Kamp.

Autor daje do pieca tekstami w rodzaju: my mind wandered, and it struck me that Knuth might be terribly misleading on the performance of the binary heap, possibly even by an order of magnitude.

Trąci "Faktem", niemniej PHK ilustruje istotny problem: programiści czasem zapominają, że algorytmy o niższej złożoności obliczeniowej mogą się zachowywać gorzej niż algorytmy o wyższej złożoności obliczeniowej, dlatego projektując rozwiązanie należy uwzględnić specyfikę architektury sprzętowej i rozmiar danych wejściowych. Teoretycznie gorszy algorytm może działać szybciej dla danych wejściowych o bardzo dużym rozmiarze (wystarczającym w projektowanym zastosowaniu) ze względu na unikanie np. kosztowego stronicowania.


Jako że mamy sezon ogórkowy, podlinkuję: - You are doing it wrong! - Says who? ;)

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