Teorema CAP jest fundamentem teorii systemów rozproszonych. Oczywiście, dyskusje na jej temat nie milkną: definicje w niej nie są kanoniczne, a dowód jest nieformalny… Niemniej jednak, twardo opierając się na zdrowym rozsądku™, intuicyjnie rozumiemy, że teorema jest prawdziwa.
Jedyną rzeczą, która nie jest oczywista, jest znaczenie litery „P”. Kiedy klaster się rozdziela, decyduje – czy nie odpowiadać, aż zostanie osiągnięta większość, czy też przekazać dostępne dane. W zależności od wyników tego wyboru, system klasyfikowany jest jako CP lub AP. Cassandra, na przykład, może działać w obu trybach, w zależności nie tylko od ustawień klastra, ale także od parametrów każdego konkretnego zapytania. Ale jeśli system nie jest „P”, a się rozdzieli, to co się dzieje?
Odpowiedź na to pytanie jest nieco zaskakująca: klaster CA nie może się rozdzielić.
Czym jest taki klaster, który nie może się rozdzielić?
Niezbędnym atrybutem takiego klastra jest wspólny system przechowywania danych. W przeważającej większości przypadków oznacza to podłączenie przez SAN, co ogranicza zastosowanie rozwiązań CA do dużych przedsiębiorstw, które mogą utrzymać infrastrukturę SAN. Aby kilka serwerów mogło pracować z tymi samymi danymi, potrzebny jest klastrowy system plików. Takie systemy plików są dostępne w portfolio HPE (CFS), Veritas (VxCFS) i IBM (GPFS).
Oracle RAC
Opcja Real Application Cluster pojawiła się po raz pierwszy w 2001 roku w wersji Oracle 9i. W takim klastrze kilka instancji serwera pracuje z tą samą bazą danych.
Oracle może działać zarówno z klastrowym systemem plików, jak i z własnym rozwiązaniem – ASM, Automatic Storage Management.
Każda instancja prowadzi swój dziennik. Transakcja jest wykonywana i rejestrowana przez jedną instancję. W przypadku awarii instancji, jeden z ocalałych węzłów klastra (instancji) odczytuje jej dziennik i przywraca utracone dane – dzięki temu zapewniana jest dostępność.
Wszystkie instancje mają własną pamięć podręczną, a te same strony (blokad) mogą znajdować się jednocześnie w pamięciach podręcznych wielu instancji. Co więcej, jeśli jakaś strona jest potrzebna jednej instancji i znajduje się w pamięci podręcznej innej instancji, może ona uzyskać ją od "sąsiada" dzięki mechanizmowi cache fusion, zamiast odczytywać dane z dysku.
Co się stanie, jeśli jeden z egzemplarzy będzie musiał zmienić dane?
Cechą Oracle jest to, że nie ma dedykowanej usługi blokad: jeśli serwer chce zablokować wiersz, to informacja o blokadzie jest umieszczana bezpośrednio na tej stronie pamięci, na której znajduje się blokowany wiersz. Dzięki temu podejściu Oracle jest mistrzem wydajności wśród monolitycznych baz: serwis blokad nigdy nie staje się wąskim gardłem. Jednak w konfiguracji klastrowej taka architektura może prowadzić do intensywnej wymiany danych w sieci i wzajemnych blokad.
Gdy tylko wiersz zostanie zablokowany, egzemplarz powiadamia wszystkie pozostałe egzemplarze, że strona, na której znajduje się ten wiersz, została zajęta w trybie monopolowym. Jeśli inny egzemplarz będzie chciał zmienić wiersz na tej samej stronie, musi czekać, aż zmiany na stronie zostaną zatwierdzone, tzn. informacja o zmianie zostanie zapisana w dzienniku na dysku (przy czym transakcja może trwać). Może się zdarzyć, że strona zostanie zmieniona kolejno przez kilka egzemplarzy, a wtedy przy zapisie strony na dysku trzeba będzie ustalić, u którego egzemplarza znajduje się aktualna wersja tej strony.
Przypadkowa aktualizacja tych samych stron przez różne węzły RAC prowadzi do znacznego spadku wydajności bazy danych – aż do tego, że wydajność klastra może być niższa niż wydajność pojedynczego egzemplarza.
Prawidłowe wykorzystanie Oracle RAC polega na fizycznym podziale danych (na przykład za pomocą mechanizmu tabel partycjonowanych) i odwoływaniu się do każdego zestawu partycji przez dedykowany węzeł. Głównym celem RAC stało się nie poziome skalowanie, ale zapewnienie odporności na awarie.
Jeśli węzeł przestaje odpowiadać na sygnały heartbeat, to ten węzeł, który jako pierwszy to zauważył, uruchamia procedurę głosowania na dysku. Jeśli i tu zaginiony węzeł się nie zaznaczy, to jeden z węzłów przejmuje obowiązki dotyczące przywracania danych:
- «zamraża» wszystkie strony, które znajdowały się w pamięci podręcznej zaginionego węzła;
- odczytuje dzienniki (redo) zaginionego węzła i ponownie stosuje zmiany zapisane w tych dziennikach, jednocześnie sprawdzając, czy inne węzły nie mają nowszych wersji zmienianych stron;
- cofa nieukończone transakcje.
Aby uprościć przełączanie między węzłami, w Oracle używa się pojęcia usługi – wirtualnego egzemplarza. Egzemplarz może obsługiwać wiele usług, a usługa może przechodzić między węzłami. Egzemplarz aplikacji, który obsługuje określoną część bazy (na przykład grupę klientów), współpracuje z jedną usługą, a usługa odpowiadająca za tę część bazy przechodzi na inny węzeł w przypadku awarii węzła.
IBM Pure Data Systems for Transactions
Klasterowe rozwiązanie dla systemów zarządzania bazą danych pojawiło się w portfolio Niebieskiego Giganta w 2009 roku. Ideologicznie jest wydaniem klastru Parallel Sysplex, zbudowanego na „zwykłym” sprzęcie. W 2009 roku zadebiutował produkt DB2 pureScale, stanowiący komplet oprogramowania, a w 2012 roku IBM oferuje zestaw programowo-sprzętowy (appliance) pod nazwą Pure Data Systems for Transactions. Nie należy mylić tego z Pure Data Systems for Analytics, które jest niczym innym jak przemianowanym Netezza.
Architektura pureScale na pierwszy rzut oka przypomina Oracle RAC: podobnie jak kilka węzłów jest podłączonych do wspólnego systemu magazynowania danych, a na każdym węźle działa swój egzemplarz systemu zarządzania bazą danych z własnymi obszarami pamięci i dziennikami transakcji. Ale w przeciwieństwie do Oracle, w DB2 istnieje dedykowana usługa blokad, reprezentowana przez zestaw procesów db2LLM*. W konfiguracji klastrowej ta usługa jest przenoszona na oddzielny węzeł, który w Parallel Sysplex nazywa się coupling facility (CF), a w Pure Data – PowerHA.
PowerHA zapewnia następujące usługi:
- menedżer blokad;
- globalna pamięć podręczna;
- obszar komunikacji międzyprocesowej.
Do przesyłania danych z PowerHA do węzłów baz danych i z powrotem wykorzystuje się zdalny dostęp do pamięci, dlatego klastrowy interkonekt musi obsługiwać protokół RDMA. PureScale może korzystać zarówno z Infiniband, jak i RDMA over Ethernet.
Jeśli węzeł potrzebuje strony, której nie ma w pamięci podręcznej, prosi o stronę w globalnej pamięci podręcznej, a tylko jeśli i tam jej nie ma, odczytuje ją z dysku. W przeciwieństwie do Oracle, żądanie kierowane jest tylko do PowerHA, a nie do sąsiednich węzłów.
Jeśli instancja ma zmienić wiersz, blokuje go w trybie ekskluzywnym, a stronę, na której znajduje się wiersz, – w trybie współdzielonym. Wszystkie blokady są rejestrowane w globalnym menedżerze blokad. Gdy transakcja zostaje zakończona, węzeł wysyła wiadomość do menedżera blokad, który kopiuje zmienioną stronę do globalnej pamięci podręcznej, znosi blokady i unieważnia zmienioną stronę w pamięciach podręcznych innych węzłów.
Jeśli strona, na której znajduje się zmieniany wiersz, jest już zablokowana, menedżer blokad odczyta zmienioną stronę z pamięci węzła, który dokonał zmian, zniesie blokadę, unieważni zmienioną stronę w pamięciach podręcznych innych węzłów i odda blokadę strony węzłowi, który ją zażądał.
„Brudne”, czyli zmienione, strony mogą być zapisywane na dysku zarówno z zwykłego węzła, jak i z PowerHA (castout).
W przypadku awarii jednego z węzłów pureScale, odzyskiwanie jest ograniczone tylko do tych transakcji, które w momencie awarii nie były jeszcze zakończone: strony, zmienione przez ten węzeł w zakończonych transakcjach, są w globalnej pamięci podręcznej na PowerHA. Węzeł jest ponownie uruchamiany w ograniczonej konfiguracji na jednym z serwerów klastra, cofa niezakończone transakcje i zwalnia blokady.
PowerHA działa na dwóch serwerach, a główny węzeł synchronizuje swoje stany. W przypadku awarii głównego węzła klaster PowerHA nadal działa z zapasowym węzłem.
Oczywiście, jeśli odwoływać się do zestawu danych przez jeden węzeł, ogólna wydajność klastra będzie wyższa. PureScale może nawet zauważyć, że pewien obszar danych jest przetwarzany przez jeden węzeł, a wtedy wszystkie blokady dotyczące tego obszaru będą przetwarzane lokalnie przez węzeł bez komunikacji z PowerHA. Ale gdy tylko aplikacja spróbuje uzyskać dostęp do tych danych przez inny węzeł, centralne przetwarzanie blokad zostanie wznowione.
Wewnętrzne testy IBM z obciążeniem składającym się z 90% odczytów i 10% zapisów, co bardzo przypomina rzeczywiste obciążenie przemysłowe, pokazują niemalże liniowe skalowanie do 128 węzłów. Warunki testowania niestety nie są ujawniane.
HPE NonStop SQL
Wysokodostępna platforma znajduje się także w portfolio Hewlett-Packard Enterprise. Jest to platforma NonStop, wprowadzona na rynek w 1976 roku przez firmę Tandem Computers. W 1997 roku firma została przejęta przez Compaq, który z kolei w 2002 roku połączył się z Hewlett-Packard.
NonStop jest wykorzystywana do budowy aplikacji krytycznych – na przykład HLR lub przetwarzania kart bankowych. Platforma dostarczana jest jako zintegrowany system sprzętowo-programowy, obejmujący jednostki obliczeniowe, system przechowywania danych oraz sprzęt komunikacyjny. Sieć ServerNet (w nowoczesnych systemach – Infiniband) służy zarówno do komunikacji między jednostkami, jak i do dostępu do systemu przechowywania danych.
W wcześniejszych wersjach systemu używano własnościowych procesorów, które były synchronizowane ze sobą: wszystkie operacje były wykonywane synchronnie przez kilka procesorów, a gdy jeden z procesorów napotkał błąd, był wyłączany, podczas gdy drugi kontynuował pracę. Później system przeszedł na standardowe procesory (najpierw MIPS, potem Itanium, a w końcu x86), a do synchronizacji zaczęto używać innych mechanizmów:
- wiadomości: każdy proces systemowy ma swojego bliźniaka-«cień», któremu aktywny proces okresowo wysyła wiadomości o swoim stanie; w przypadku awarii głównego procesu, proces cienia rozpoczyna pracę od momentu określonego w ostatniej wiadomości;
- głosowanie: system przechowywania danych ma specjalny komponent sprzętowy, który przyjmuje kilka identycznych żądań i wykonuje je tylko w przypadku, gdy żądania się pokrywają; zamiast fizycznej synchronizacji procesory pracują asynchronicznie, a wyniki ich działania są porównywane tylko w momentach wejścia/wyjścia.
Od 1987 roku na platformie NonStop działa relacyjna baza danych – najpierw SQL/MP, a później SQL/MX.
Cała baza danych dzieli się na części, a za każdą część odpowiada odpowiedni proces Data Access Manager (DAM). Zapewnia on zapis danych, cache'owanie oraz mechanizm blokad. Przetwarzaniem danych zajmują się procesy wykonawcze (Executor Server Process), działające na tych samych węzłach co odpowiadające menedżery danych. Planista SQL/MX dzieli zadania między wykonawcami i łączy wyniki. W razie potrzeby wprowadzenia spójnych zmian używany jest protokół dwuetapowego zatwierdzania, zapewniany przez bibliotekę TMF (Transaction Management Facility).
NonStop SQL potrafi priorytetyzować procesy tak, aby długie zapytania analityczne nie przeszkadzały w realizacji transakcji. Jej głównym celem jest jednak przetwarzanie krótkich transakcji, a nie analityka. Producent gwarantuje dostępność klastra NonStop na poziomie pięciu „dziewiątek”, co oznacza, że czas przestoju wynosi tylko 5 minut rocznie.
SAP HANA
Pierwsza stabilna wersja bazy danych HANA (1.0) została wydana w listopadzie 2010 roku, a pakiet SAP ERP przeszedł na HANA od maja 2013 roku. Platforma oparta jest na zakupionych technologiach: TREX Search Engine (do wyszukiwania w kolumnowej bazie danych), bazy danych P*TIME i MAX DB.
Samo słowo „HANA” jest akronimem od High performance ANalytical Appliance. Ta baza danych dostarczana jest w postaci kodu, który może działać na dowolnych serwerach x86, jednak przemysłowe instalacje są dozwolone tylko na sprzęcie, który przeszedł certyfikację. Dostępne są rozwiązania HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Niektóre konfiguracje Lenovo umożliwiają nawet użytkowanie bez SAN – rolę wspólnej pamięci masowej odgrywa klaster GPFS na lokalnych dyskach.
W przeciwieństwie do wymienionych wcześniej platform, HANA jest bazą danych w pamięci, tzn. pierwotny obraz danych przechowywany jest w pamięci operacyjnej, a na dysk zapisywane są jedynie dzienniki i okresowe zrzuty – w celu przywrócenia w przypadku awarii.
Każdy węzeł klastra HANA odpowiada za swoją część danych, a mapa danych przechowywana jest w specjalnym komponencie – Name Server, znajdującym się na węźle koordynującym. Dane nie są duplikowane między węzłami. Informacje o blokadach również przechowywane są na każdym węźle, ale w systemie istnieje globalny detektor blokad wzajemnych.
Klient HANA podczas łączenia z klastrem ładowany jego topologię i w późniejszym czasie może zwracać się bezpośrednio do dowolnego węzła w zależności od tego, jakie dane są mu potrzebne. Jeśli transakcja dotyczy danych jednego węzła, to może być wykonana lokalnie przez ten węzeł, ale jeśli zmieniają się dane kilku węzłów, to węzeł inicjujący zwraca się do węzła koordynatora, który otwiera i koordynuje rozproszoną transakcję, utrwalając ją za pomocą zoptymalizowanego protokołu dwuetapowego.
Węzeł koordynatora jest zduplikowany, dlatego w przypadku awarii koordynatora natychmiast włącza się węzeł zapasowy. Natomiast gdy awarii ulegnie węzeł z danymi, jedynym sposobem na uzyskanie dostępu do jego danych jest ponowne uruchomienie węzła. Zazwyczaj w klastrach HANA utrzymuje się serwer zapasowy (spare), aby jak najszybciej uruchomić utracony węzeł.
Źródło: habr.com
