Architektura chmur i wirtualizacja Wykład 6 Dane w chmurze
Zawartość Bazy NoSQL Skalowalne bazy relacyjne Chmurowe systemy plików Powiązane algorytmy 2
Dane w chmurze
Architektura równoległych baz danych D. DeWitt and J. Gray: Parallel Database Systems: The Future of High Performance Database Processing, CACM 36(6), 1992 4
Skalowalne bazy Aspekty skalowalności baz danych: Dużo (małych) transakcji, Dużo kopii danych, Duże zużycie procesora dla pojedynczego zapytania, Skrajnie duże zbiory danych dla jednego zapytania. Replikacja danych: Przenoszenie danych do miejsc, gdzie są potrzebne, Zarządzana replikacja dla zapewnienie dostępności i niezawodności. 5
Dlaczego chmury? Aplikacje zarządzające danymi są potencjalnymi kandydatami do wdrożenia w chmurze Przemysł bazy przedsiębiorstw charakteryzują się wysokimi kosztami, zarówno sprzętu jaki i oprogramowania, Środowisko akademickie zarządzanie, przetwarzanie i współdzielenie masowo produkowanych danych w chmurze. 6
Dlaczego chmury? Wiele niezwykle skutecznych aplikacji chmurowych (cloud killer apps) polega na intensywnym przetwarzaniu danych (data- intensive): Przetwarzanie wsadowe z map/reduce, OLTP (Online Transaction Processing) w zautomatyzowanych aplikacjach biznesowych, OLAP (Offline Analytical Processing) w eksploracji danych (data mining) lub uczeniu maszynowym (machine learning). 7
Charakterystyka chmur Dane są przechowywane na niezaufanych hostach Istnieje ryzyko dotyczące prywatności i bezpieczeństwa przechowywania danych na niezaufanym hoście, Szczególnie wrażliwe dane mogą być pominięte w analizie lub uczynione anonimowymi. Współdzielenie i umożliwianie dostępu jest częstym celem używania chmur dla naukowych zbiorów danych. Data Management in the Cloud: Limitations and Opportunities, IEEE, 2009. 8
Charakterystyka chmur Dane są replikowane, często na przestrzeni olbrzymich odległości geograficznych Ciężko utrzymać gwarancje ACID (atomicity, consistency, isolation, durability) w obecności replikacji na olbrzymią skalę, Pełne gwarancje ACID zazwyczaj nie są wymagana w aplikacjach analitycznych. Data Management in the Cloud: Limitations and Opportunities, IEEE, 2009. 9
Charakterystyka chmur Wirtualizacja dużych kolekcji danych stanowi wyzwanie Ładowanie zajmuje więcej czasu niż uruchamianie VM, Koszty składowania kontra koszty pasma, Replikacja online kontra replikacja offline. Data Management in the Cloud: Limitations and Opportunities, IEEE, 2009. 10
Wyzwania Ustępstwa (trade- off) funkcjonalność na rzecz kosztów operacyjnych Ograniczony interfejs, minimalistyczny język zapytać, ograniczone gwarancje spójności, Większy ciężar programistyczny dla deweloperów, Umożliwienie przewidywalnych usług i SLA (service level agreements). The Claremont Report on Database Research, 2008 11
Wyzwania Zarządzalność Ograniczony udział ludzki, duża wariancja obciążenia i różnorodność współdzielonych infrastruktur, Potrzeba samo- zarządzających i adaptacyjnych technik bazodanowych. The Claremont Report on Database Research, 2008 12
Wyzwania Skalowalność Dzisiejsze bazy SQLowe nie skalują się do tysięcy węzłów wdrażanych w kontekście chmury, Ciężko obsługiwać zwielokrotnione rozproszone aktualizacje tego samego zbioru danych, Ze względów pojemności (magazynowanie, pasmo sieciowe, itp.) ciężko replikować olbrzymie zbiory danych z zapewnieniem dostępności Magazynowanie różne techniki implementacji transakcyjności, różna semantyka, lub jedno i drugie, Przetwarzanie zapytań i optymalizacja wymagane ograniczenia przestrzeni planów lub samego wyszukiwania, Programowalność wyrażanie programów w chmurze. The Claremont Report on Database Research, 2008 13
Wyzwania Prywatność i bezpieczeństwo danych Ochrona przed innymi użytkownikami i dostawcami chmur, Pokusy dla dostawców i klientów. The Claremont Report on Database Research, 2008 14
Wyzwania Nowe aplikacje: mieszanki (mashups) interesujących zbiorów danych Używają usług z przygotowanym dużymi zbiorami danych, notowaniami giełdowymi, wynikami przeszukiwania sieci, danymi naukowymi, Zbiory danych pochodzą z prywatnych lub publicznych domen, Mogą stać się początkiem federacyjnych architektur chmurowych. The Claremont Report on Database Research, 2008 15
Skalowalne składy danych
Przegląd Nowe systemy pojawiły się w celu sprostania wymaganiom zarządzania danymi w chmurze Składy NoSQL, Skalowalne bazy SQL. Skalowanie poziome (horizontal scaling) Shared nothing, Replikowanie i partycjonowanie danych na tysiącach serwerów, Dystrybucja obciążenia prostej operacji na tysiące serwerów. Proste operacje to: Wyszukiwania po kluczu (key lookups), Odczyty i zapisy na jednym lub małej liczbie rekordów, Brak złożonych zapytań lub złączeń. 17
Sharding, partycjonowanie poziome i pionowe Partycjonowanie poziomie (horizontal partitioning) Partycjonowanie pionowe (vertical paritioning) SQL Azure Federation Introduction, http://geekswithblogs.net/shaunxu/archive/2012/01/07/sql- azure- federation- ndash- introduction.aspx 18
Sharding, partycjonowanie poziome i pionowe Partycjonowanie poziome dzieli jedną lub więcej tabel względem rekordu, zazwyczaj w ramach pojedynczej instancji schematu lub serwera bazy danych Może oferować korzyść z redukcji wielkości indeksu (i dlatego kosztu wyszukiwania) pod warunkiem, że istnieje jakiś oczywisty, solidny i jawny sposób identyfikacji, w jaki ten konkretny rekord może być znaleziony bez potrzeby wcześniejszego przeszukiwania indeksu Klasyczny przykład tabele z klientami dla każdej litery, gdzie nazwa klienta wskazuje od razu, gdzie dany rekord znaleźć. Wikipedia, http://en.wikipedia.org/wiki/sharding 19
Sharding, partycjonowanie poziome i pionowe Sharding idzie znacznie dalej partycjonuje problematyczne tabele w ten sam sposób, ale potencjalnie pomiędzy wieloma instancjami schematu Oczywistą zaletą jest to, że obciążenia wyszukiwania dla dużej spartycjonowanej tabeli może być rozłożone pomiędzy wiele serwerów (logicznych lub fizycznych), nie tylko wiele indeksów na jednym logicznym serwerze, Rozdzielanie odłamków (shards) pomiędzy liczne izolowane instancje wymaga więcej niż partycjonowania poziomego. Zakładane zyski wydajności zostałyby utracone, jeżeli odpytywanie bazy wymagałoby odpytania każdej instancji tylko w celu pobrania prostej tabeli. Dlatego sharding rozdziela wielkie spartycjonowane tabele pomiędzy serwery, podczas gdy mniejsze tabele są replikowane jako kompletne jednostki. Wikipedia, http://en.wikipedia.org/wiki/sharding 20
Sharding, partycjonowanie poziome i pionowe To także dlatego sharding jest związany z architekturą shared nothing po rozbiciu każdy shard może istnieć w całkowicie oddzielnym logicznym schemacie, instancji, fizycznym serwerze, centrum danych, czy kontynencie. Nie ma potrzeby zachowywania współdzielonego dostępu (spomiędzy shardów) to innych niespartycjonowanych tabel na innych shardach Czyni to replikację pomiędzy wieloma serwerami łatwą, w przeciwieństwie do prostego partycjonowania poziomego, Jest to także wygodne w przypadku rozproszenia aplikacji na skalę globalną, gdzie łącza komunikacyjne pomiędzy centrami danych stanowiłyby wąskie gardło. Wikipedia, http://en.wikipedia.org/wiki/sharding 21
Sharding, partycjonowanie poziome i pionowe Istnieje także wymaganie dotyczące mechanizmu powiadamiania i replikacji pomiędzy instancjami schematu, aby niespartycjonowane tabele pozostały zsynchronizowane tak blisko, jak aplikacja tego wymaga Stanowi to złożony wybór w odłamkowej (sharded) architekturze, Stosowane podejścia sięgają od ustawiania danych tylko do odczytu (aktualizacje są rzadkie i batchowane) po dynamicznie replikowane tabele (kosztem ograniczenia pewnych korzyści z rozproszenia i shardingu), przez wiele opcji pośrednich. Wikipedia, http://en.wikipedia.org/wiki/sharding 22
Sharding, partycjonowanie poziome i pionowe 5 ways to boost performance of your Rails applications, http://blog.sphereinc.com/2010/07/5- ways- to- boost- performance- of- your- rails- applications/ 23
Definicja NoSQL Zgodna definicja nie istnieje: not only SQL, not SQL/relational, 24
Definicja NoSQL Sześć cech kluczowych: Zdolność poziomego skalowania prostych operacji poprzez wiele serwerów, Zdolność replikacji i dystrybucji (partycjonowania) danych na wiele serwerów, Proste wołania poziomu interfejsu lub protokołu (w przeciwieństwie do wiązania SQL), Słabszy model współbieżności niż w transakcjach ACID większości systemów relacyjnych, Wydajne wykorzystanie rozproszonych indeksów i RAM dla magazynowania danych, Zdolność dynamicznego dodawania nowych atrybutów do rekordów (brak schematu). 25
Relacyjny model danych Dane przechowywane w relacjach (tabelach) krotek (rzędów, rekordów) skalarnych wartości Krotka (tuple) rząd w tabeli relacyjnej, gdzie nazwy i typy atrybutów są zdefiniowane w schemacie, a wartości są skalarne, Zapytania wyrażone względem dowolnych (kombinacji) atrybutów, Indeksy zdefiniowane względem dowolnych (kombinacji) atrybutów. 26
NoSQLowe modele danych Dokumentowy (document) obsługuje zarówno wartości skalarne, jak i zagnieżdżone dokumenty a atrybuty są dynamicznie definiowane dla każdego dokumentu. Rodzina kolumn (column family, key- value) grupuje pary klucz- wartość (kolumny) w rodziny aby je partycjonować i replikować. Jedna rodzina kolumn przypomina dokument, do której mogą być dodawane nowe (zagnieżdżone, listowe) atrybuty. Obiektowy (object) analogiczny do obiektów w językach programowania, ale bez metod proceduralnych, 27
Model klucz- wartość Składowanie danych Wartości (dane) są przechowywane w oparciu o klucze zdefiniowane przez programistę, System jest agnostyczny względem struktury (semantyki) wartości. Zapytania wyrażone względem kluczy. Indeksy główne są definiowane na kluczach wspieranych przez system, indeksy pomocnicze na wartościach lub częściach wartości. Interfejs: put(key, value) get(key): value 28
Model dokumentowy Składowanie danych Dokumenty (dane) są przechowywane w oparciu o klucze zdefiniowane przez programistę, System jest świadomy (dowolnej) struktury dokumentu, Obsługa list, wskaźników i zagnieżdżonych dokumentów. Zapytania wyrażone względem kluczy (lub atrybutu, jeżeli istnieje indeks). Obsługa indeksów opartych na kluczach i indeksów wtórnych. Interfejs: set(key, document) get(key): document set(key, name, value) get(key, name): value 29
Model rodziny kolumn Składowanie danych Trójki <name, value, timestamp> (tzw. kolumny) są przechowywane w oparciu o rodzinę kolumn i klucz. Rodzina kolumn przypomina dokument. System jest świadomy (dowolnej) struktury rodziny kolumn, System używa informacji rodziny kolumn dla replikacji i rozproszenia danych. Zapytania wyrażone w oparciu o klucz i rodzinę kolumn. Zazwyczaj wspierane są indeksy wtórna dna rodzinie kolumn. Interfejs: define(family) insert(family, key, columns) get(family, key): columns 30
Model grafowy (graph) Składowanie danych Dane są przechowywane w oparciu o węzły i (typowane) łuki. Zarówno węzły jak i łuki mogą przyjmować (dowolne) atrybuty. Zapytania wyrażone w oparciu o identyfikatory systemowe (jeżeli nie ma indeksów). Obsługiwane są indeksy pomocnicze dla węzłów i łuków. Pobieranie węzłów w oparciu o atrybuty i łuki po typie, węźle początkowym i/lub końcowym. Interfejs: create: id get(id) connect(id1, id2): id addattribute(id, name, value) getattribute(id, name): value 31
Model tablicowy (array) Zagnieżdżone wielowymiarowe tablice Komórki mogą być krotkami lub innymi tablicami, Mogą mieć wymiary niecałkowite. Dodatkowy wymiar historii na aktualizowalnych tablicach. Postrzępione (ragged) tablice pozwalają każdemu rzędowi lub kolumnie mieć inną długość. Wspiera wiele typów wartości zerowych (null) Komórki tablicy mogą być puste (empty), Definiowalne przez użytkownika podejście do wartości specjalnych. 32
Model obiektowy Składowanie danych Typowane obiekty języka programowania (plus obiekty referencyjne), Atrybuty mogą być kolekcjami, Baza jest świadoma typu (schematu) obiektów. Obiekty są pobierane za pomocą zapytań lub trawersowania od korzeni. Wyspecjalizowane indeksy mogą być wyrażone w oparciu o schemat. Interfejs: set(object) get(query): object 33
Skalowalna spójność i modele transakcyjne
Twierdzenie Brewera Brewer s conjecture Trzy właściwości, które są pożądane i oczekiwane od rzeczywistych systemów współdzielących dane: C spójność danych (data consistency), A dostępność (availability), P tolerancje na partycję sieci (tolerance of network partition). Na warsztatach PODC 2000 (Portland) Eric Brewer przedstawił przypuszczenie (conjecture), że tylko dwie z tych trzech właściwości mogą być spełnione przez system w dowolnym momencie. Przypuszczenie zostało sformalizowane i potwierdzone przez Setha Gilberta i Nancy Lynch z MIT w roku 2002. Obecnie jest znane jako twierdzenie CAP (CAP Theorem). 35
Spójność danych Systemy bazodanowe zazwyczaj implementują transakcje ACID: Atomowość (atomicity) wszystko albo nic, Spójność (consistency) transakcje nigdy nie widzą ani nie tworzą niespójnych danych, Izolacja (isolation) transakcje nie są świadome współbieżnych transakcji, Trwałość (durability) stan transakcji jest trwały po jej zatwierdzeniu (commit). 36
Spójność danych Jest użyteczna w zautomatyzowanych aplikacjach biznesowych. Bankowości z końcem transakcji suma pieniędzy na obydwu rachunkach jest taka sama jak przed transakcją, Aukcjach online ostatni licytujący wygrywa aukcję, Istnieją aplikacje, które mogą poradzić sobie z luźniejszymi gwarancjami spójności i okresami niespójności. 37
Dostępność Od usług oczekuje się wysokiej dostępności: Każde żądanie powinno uzyskać odpowiedź, Rzeczywiste problemy mogą pojawić się, kiedy usługa przestaje działać. Realistyczny cel: Usługa powinna być dostępna tak samo jak sieć, w której działa, Jeżeli dowolna usługa w danej sieci jest dostępna, rozważana usługa także powinna być dostępna. 38
Tolerancja na partycjonowanie Usługa powinna nadal działać zgodnie z oczekiwaniami Jeżeli jakiś węzeł ulega awarii, Jeżeli jakieś łącza komunikacyjne zawodzą. Jedną z pożądanych właściwości tolerancji na błędy (fault tolerance) jest elastyczność względem partycjonowania sieci na wiele komponentów. W cloud computing awarie węzła i komunikacji nie są wyjątkiem, ale codziennymi zdarzeniami. 39
Problemy z CAP Asymetria właściwości CAP: C jest ogólną właściwością systemu, A jest właściwością systemu jedynie w przypadku partycji. Nie istnieją trzy różne wybory: W praktyce CA i CP są nieodróżnialne, ponieważ A jest poświęcane jedynie w przypadku partycji. Używane jako wymówka, aby nie martwić się o spójność Dostępność jest naprawdę dla mnie ważna, więc CAP mówi, że będę musiał zrezygnować ze spójności. Daniel Abadi, Yale University 40
Inny problem do naprawienia Poza dostępnością w przypadku partycji, istnieją inne koszty spójności. Narzut synchronizacji schematów. Opóźnienia (latency) Jeżeli obciążenie może zostać spartycjonowane geograficznie, opóźnienia nie są takie złe, W przeciwnym wypadku, nie ma sposobu uniknięcia przynajmniej jednego dookólnego komunikatu. Daniel Abadi, Yale University 41
Wspólne rozwiązanie problemów PACELC W przypadku partycji (P), czy system wybiera dostępność (A), czy spójność (C)? W przeciwnym wypadku (Else), czy system wybiera opóźnienia (Latency) czy spójność (C)? PA/EL Dynamo, SimpleDB, Cassandra, Riptano, CouchDB, Cloudant. PC/EC Systemy zgodne z ACID. PA/EC GenieDB. PC/EL Istnienie jest dyskusyjne. Daniel Abadi, Yale University 42
Przypadek P*/EC Zwiększony nacisk na poziomo skalowalne transakcyjne systemy bazodanowe: Cloud computing, Aplikacje rozproszone, Chęć wdrażania aplikacji na tanim niewyspecjalizowanym sprzęcie. Ogromna większość obecnie dostępnych systemów skalowalnych poziomo reprezentuje P*/EL: Rozwijane przez inżynierów w Google, Facebook, Yahoo, Amazon, itp. Ci inżynierowe mogą poradzić sobie z ograniczoną spójnością, ale jest to naprawdę trudne, poza tym musie istnieć też opcja na reszty użytkowników. Ponadto: Rozproszona kontrola współbieżności i protokołów zatwierdzających jest kosztowna, Gdy spójność zanika, zazwyczaj za raz potem ginie też atomowość NoSQL. Daniel Abadi, Yale University 43
Problem do przezwyciężenia Wysoka dostępność jest krytyczna, replikacja jest celem pierwszej kategorii. Dzisiejsze systemy najpierw działają, potem się replikują Komplikacja semantyki wysyłania zapytań odczytujących do replik, Potrzeba potwierdzania od replik przed zatwierdzeniem (zwiększone opóźnienia) jeżeli chcemy mieć trwałość i wysoką dostępność. Trwające transakcje muszą być porzucone w momencie błędu głównej (master) bazy. Chcemy systemu, który najpierw się replikuje, później działa. Rozproszona kontrola współbieżności i zatwierdzanie są kosztowne, chcemy pozbyć się obydwu. Daniel Abadi, Yale University 44
Kluczowa idea Zamiast osłabiania ACID wzmocnijmy je. Wyzwania: Gwarantowanie równoważności względem pewnej seryjnej kolejności czyni replikację trudną, Przeprowadzenie tego samego zbioru transakcji na dwóch różnych replikach może spowodować ich rozbieżność. Zabronienie każdego niedeterministycznego zachowania. Zabronienie porzuceń (aborts) spowodowanych przez DBMS: Zabronienie zakleszczania (deadlock), Rozproszone zatwierdzanie jest znacznie prostsze, kiedy nie ma porzuceń. Daniel Abadi, Yale University 45
Konsekwencje determinizmu Repliki dają to samo wyjście, zakładając jednakowe wejście Ułatwia do aktywną replikację. Wystarczy logować jedynie początkowe wejście, stan awarii może zostać zrekonstruowany na podstawie tego logu (albo z repliki). Aktywne rozproszone transakcje nie są porzucane aż do momentu awarii węzła: Silna redukcja (lub eliminacja) kosztów rozproszonego zatwierdzania, Nie ma potrzeby martwienia się o węzły ulegające awarii podczas protokołu zatwierdzania, Nie ma potrzeby martwienia się o efekty transakcji i zapisywanie jej na dysku przed zapewnieniem jej zatwierdzenia, Wystarczy jeden komunikat z dowolnego węzła, które może deterministycznie porzucić transakcję, Ten komunikat może zostać wysłany w środku transakcji, kiedy tylko wie, że nastąpi zatwierdzanie. Daniel Abadi, Yale University 46
Silna i słaba spójność Silna spójność Po zatwierdzeniu aktualizacji, każdy kolejny dostęp będzie zwracał zaktualizowaną wartość. Słaba spójność System nie gwarantuje, że kolejne dostępny będą zwracały zaktualizowaną wartość, Może istnieć potrzeba spełnienia pewnych warunków zanim zaktualizowana wartość będzie zwrócona, Okno niespójności czas pomiędzy aktualizacją i punktem czasu, kiedy każdy dostęp ma zagwarantowane zwrócenie zaktualizowanej wartości. Eventual Consistency by W. Vogels, 2008 47
Spójność ostateczna (eventual) Specyficzna forma słabej spójności. Jeżeli nie ma nowych aktualizacji, w końcu wszystkie dostępy będą zwracać zaktualizowaną wartość. Przy braku błędów, maksymalny rozmiar okna niespójności może być określony w oparciu o: Opóźnienia komunikacyjne, Obciążenie systemu, Liczbę replik, To nie jest nowy pomysł: DNS używa spójności ostatecznej podczas aktualizacji, RDBMS używa spójności ostatecznej dla komunikacji asynchronicznej lub kopii zapasowych. Eventual Consistency by W. Vogels, 2008 48
Modele spójności ostatecznej Spójność przyczynowa (causal consistency) Jeżeli A zakomunikował B, że zaktualizował wartość, to kolejny dostęp od B zwróci zaktualizowaną wartość, a zapis nadpisze wcześniejszy zapis. Dostęp z C, który nie ma przyczynowego związku z A podlega normalnym regułom spójności ostatecznej. Spójność czytania swoich zasobów (read- your- writes consistency) Przypadek specjalny modelu spójności przyczynowej, Po zaktualizowanie wartości, proces będzie zawsze odczytywać zaktualizowaną wartość i nigdy nie zobaczy starczej wartości. Eventual Consistency by W. Vogels, 2008 49
Modele spójności ostatecznej Spójność sesji (session consistency) Praktyczny przypadek spójności czytania swoich zasobów, Dane są dostępowane w sesji, gdzie istnieje gwarancja czytania swoich zasobów, Gwarancja nie rozciąga się między sesjami. Monotoniczna spójność odczytu (monotonic read consistency) Jeżeli proces widział określoną wartość, każdy kolejny dostęp nigdy nie zwróci poprzedniej wartości. Monotoniczna spójność zapisu (monotonic write consistency) System gwarantuje serializację zapisów jednego procesu, Systemy, które nie gwarantują tego poziomu zapisu są trudne w oprogramowaniu. Eventual Consistency by W. Vogels, 2008 50
Modele spójności ostatecznej Właściwości mogą być łączone Np. monotoniczne odczyty plus spójność sesji, Np. monotoniczne odczyty plus czytanie własnych zapisów, Możliwa spora liczba scenariuszy, zależna od tego, czy aplikacja może sobie poradzić z konsekwencjami. Eventual Consistency by W. Vogels, 2008 51
Konfiguracje Definicje: N liczba węzłów przechowujących replikę, W liczba replik, które muszą potwierdzić operację zapisu, R liczba replik, które są dostępowane dla operacji zapisu. Eventual Consistency by W. Vogels, 2008 52
Konfiguracje W+R > N Np. replikacja synchroniczna (N=2, W=2, and R=1), Zbiory zapisów i odczytów zawsze się nakładają, Silna spójność może zostać zagwarantowana poprzez protokoły kworum (quorum protocols), Ryzyko zmniejszenia dostępności w podstawowym protokole kworum operacje nie powodzą się, jeżeli odpowie mniej niż wymagana liczba węzłów, co może być spowodowane awarią węzła. W+R = N Np. replikacja asynchroniczna (N=2, W=1, and R=1), Nie można zagwarantować silnej spójności. Eventual Consistency by W. Vogels, 2008 53
Konfiguracje R=1, W=N Zoptymalizowane dla odczytu pojedynczy odczyt zwróci wartość, Operacje zapisu dotyczą wszystkich węzłów i są zagrożone niepowodzeniem. R=N, W=1 Zoptymalizowane dla zapisu operacje zapisu dotyczą wyłącznie jednego węzła i opierają się na leniwej (epidemicznej) technice uaktualniania pozostałych replik, Operacje odczytu dotyczą wszystkich węzłów i zwracają najnowszą wartość, Nie ma gwarancji trwałości w przypadku awarii. W < (N+1)/2 ryzyko konfliktów zapisów. W+R <= N Słaba/ostateczna spójność. Eventual Consistency by W. Vogels, 2008 54
Base Basically Available, Soft state, Eventually Consistent Spójność jest ostatecznie osiągana, konflikty muszą być rozwiązane w pewnym momencie Naprawa odczytów, Naprawa zapisów, Naprawa asynchroniczna. Rozwiązywanie konfliktu jest zazwyczaj oparte na globalnym (częściowym) szeregowaniu operacji, co deterministycznie gwarantuje, że wszystkie repliki rozwiązują konflikty w ten sam sposób. Określone przez klienta timestampy, Zegary wektorowe. 55
Zegary wektorowe Generują częściowe szeregowanie zdarzeń w systemie rozproszonym i wykrywają zakłócenia przyczynowości. Zegar wektorowy systemu z n procesami jest wektorem n logicznych zegarów (jeden zegar na proces). Komunikaty zawierają stan logicznego zegara procesu wysyłającego, Lokalna kopia najmniejszych możliwych wartości globalnego zegara wektorowego jest utrzymywana w każdym procesie. Algorytm zegara wektorowego został opracowany niezależnie przez Colin Fidge a i Friedemann Matterna w 1988. 56
Reguły aktualizacji zagara Wszystkie zegary są inicjalizowane na zero. Proces inkrementuje swój własny zegar logiczny w wektorze o jeden za każdym razem kiedy: Doświadcza zdarzenia wewnętrznego, Proces przygotowuje się do wysłania komunikatu, Proces otrzymuje komunikat. wektorowego Za każdym razem, kiedy proces wysyła komunikat, przesyła cały zegar wektorowy wraz z wysyłanym komunikatem. Za każdym razem, kiedy proces otrzymuje komunikat, aktualizuje każdy element w sowim wektorze biorąc maksimum wartości we własnym zegarze wektorowym i wartości z wektora w otrzymanym komunikacie. 57
Przykład zegara wektorowego Wikipedia, http://en.wikipedia.org/wiki/vector_clock 58
Chmurowe systemy plików: Google File System (GFS)
Założenia projektowe System jest zbudowany z wielu niedrogich powszechnie dostępnych komponentów Awarie komponentów zdarzają się rutynowo, Monitoruje się, żeby wykrywać awarie, znosić je i się naprawiać. System przechowuje ogromną liczbę dużych plików Kilka milionów plików, zazwyczaj 100 MB lub większych, Wielogigabajtowe pliki są całkiem powszechne i muszą być sprawnie zarządzane, Małe pliki także są obsługiwane, ale system nie jest dla nich zoptymalizowany. Obciążenie systemu Duże odczyty strumieniowe kolejne odczyty z jednego klienta odczytują przyległe obszary, zazwyczaj 1 MB i więcej, Małe dowolne (random) odczyty zazwyczaj kilka kb w dowolnym offsecie, Duże sekwencyjne zapisy dowiązywanie danych do plików; operacja podobna do strumieniowych odczytów; małe przypadkowe zapisy są także obsługiwane, ale niewydajnie. 60
Założenia projektowe Wsparcie dla równoczesnych dowiązań do tego samego pliku Wydajna implementacja, Dobrze zdefiniowana semantyka, Przypadek użycia: Kolejki producent- konsument lub wielodrogowe scalanie z setkami procesów równolegle dowiązujących do pliku, Atomowość z minimalnym narzutem synchronizacji jest kluczowa, Plik może być odczytywany późnej lub jednocześnie. Zachowanie wysokiego pasma jest ważniejsze od niewielkich opóźnień. 61
Decyzje projektowe interfejs GFS nie implementuje standardowego API jak POSIX. Obsługuje zwykłe operacje na plikach: Utwórz/usuń, Otwórz/zamknij, Odczytaj/zapisz. Wspiera dodatkowe operacje: Snapshot niskim kosztem tworzy kopię pliku lub drzewa katalogów używając kopiowania przy zapisie, record append pozwala wielu klientom dowiązywać dane do tego samego pliku równocześnie, jednocześnie gwarantując atomowość każdego indywidualnego dowiązania klienta. 62
Decyzje projektowe architektura Klaster GFS: Pojedynczy master i wiele chunkserverów, Dostępowany przez wiele klientów, Komponenty to zazwyczaj powszechnie dostępne maszyny linuksowe, Procesy serwera GFS działają w trybie użytkownika. Kawałki (chunks): Pliki są podzielone na równe kawałki, Identyfikowane przez globalnie unikatowe 64- bitowe uchwyty (handles) przypisywane przez mastera, Kawałki są replikowane dla zwiększenia niezawodności, zazwyczaj czynnik replikacji wynosi 3. 63
Decyzje projektowe architektura Wiele chunkserverów: Przechowują kawałki na dysku lokalnym jako pliki linuksowe, Przyjmują i obsługują żądania danych, Brak specjalnego cache owania opiera się na linuksowym cache u bufora. Pojedynczy master upraszcza ogólny projekt: Umożliwia bardziej skomplikowane rozmieszczanie kawałków i replikację, zachowując pojedynczy punkt niepowodzenia, Utrzymuje metadane systemu plików przestrzeń nazw, informacje kontroli dostępu, mapowanie plik- kawałek, bieżącą lokalizację kawałka. Wykonuje czynności zarządcze dzierżawy kawałków, garbage collection, osierocone kawałki, migrację kawałków. heart beats okresowe komunikaty wysyłane do chunkserverów do wydawania instrukcji lub pobierania stanu, Nie przyjmuje ani nie akceptuje żądań danych. 64
Decyzje projektowe architektura The Google File System by S. Ghemawat, H. Gobioff, and S.- T. Leung, 2003 65
Jeden z kluczowych parametrów: Ustawiona duża wartość, tj. 64 MB, Dla uniknięcia fragmentacji chunkservery używają leniwej alokacji przestrzeni, tzn. pliki są rozszerzane tylko w miarę potrzeby. Zalety: Redukcja interakcji między klientem a masterem, Redukcja narzutu sieciowego przez użycie trwałego połączenia TCP dla wielu operacji na jednym kawałku, Redukcja wielkości metadanych przechowywanych na masterze. Wady: Decyzje projektowe wielkość kawałka Małe pliki składają się z nielicznych kawałków, Ryzyko hot spotów zwiększony czynnik replikacji dla małych plików. 66
Decyzje projektowe metadane Wszystkie metadane są trzymane w głównej pamięci mastera: Przestrzenie nazw pliku i kawałka tabela wyszukiwania (lookup table) z kompresją prefiksów, Mapowanie plik- kawałek, Lokalizacja replik kawałka nie przechowywana, ale odpytywana z chunkserverów. Dziennik operacji: Przechowywany na lokalnym dysku mastera i replikowany na zdalne maszyny, Używany do przywracania mastera w przypadku awarii. Dyskusja: Rozmiar głównej pamięci mastera ogranicza liczbę możliwych plików, Master utrzymuje poniżej 65 bajtów na kawałek. 67
Decyzje projektowe model spójności Rozluźniony model spójności: Przystosowany do wysoko- rozproszonych aplikacji Google, Prosty i wydajny w implementacji. Mutacje przestrzeni nazw pliku są atomowe: Obsługiwane wyłącznie przez mastera, Blokowanie przestrzeni nazw gwarantuje atomowość i poprawność, Dziennik operacji mastera definiuje globalną całkowita kolejność operacji. Stan regionu pliku po mutacji danych: Spójny wszystkie klienty zawsze widzą te same dane, bez względu ma replikę, z której je odczytały, Określony spójny plus wszystkie klienty widzą całą mutację danych, Nieokreślony ale spójny wynik współbieżnej skutecznej mutacji wszystkie klienty widzą te same dane, ale może nie odzwierciedlać jednej lub więcej mutacji, Niespójny wynik nieudanej mutacji. 68
Decyzje projektowe model Mutacja zapisu danych spójności Dane są zapisywane w zależnym od aplikacji offsecie pliku. Mutacja dowiązywanie rekordu danych Dane (rekord) są dowiązywane atomowo co najmniej raz, nawet w obecności konkurencyjnych mutacji, GFS wybiera offset i zwraca go klientowi, GFS może wstawić padding lub duplikaty rekordów pomiędzy. Zapis Dowiązywanie rekordu Szeregowy sukces Określony Określony przeplatany z niespójnym Konkurencyjny sukces Spójny ale nieokreślony Porażka Niespójny 69
Decyzje projektowe model współbieżności Implikacje dla aplikacji: Opieranie się na dowiązywaniu zamiast na nadpisywaniu, Checkpointing, Sumy kontrolne poziomu aplikacji, Samo- walidacja zapisu, samo- identyfikacja rekordów. Typowe przypadki użycia (lub hakowanie rozluźnionej spójności ): Zapis generuje plik od początku do końca i następnie atomowo zmienia jego nazwę na nazwę trwałą, pod którą można do niego uzyskać dostęp, Zapisywacz wstawia okresowe checkpointy, odczytywacze czytają tylko do checkpointu, Wiele zapisywaczy równocześnie dowiązuje do pliku w celu scalenia wyników, odczytywacz pomija sporadyczny padding i powtórzenia używając sum kontrolnych. 70
Operacje zapis plików Klient master (1, 2) Chunkserver z dzierżawą kawałka Chunkservery z replikami Klient chunkservery Przesłanie danych do chunkserverów (3) Zapisanie danych do głównej repliki (4) Główna wtórna Przekazanie (forward) żądania zapisu (5) Wtórna główna Status operacji (6) Główna klient Status operacji (7) The Google File System by S. Ghemawat, H. Gobioff, and S.- T. Leung, 2003 71