Twierdzenie CAP jest kamieniem węgielnym teorii systemów rozproszonych. Oczywiście kontrowersje wokół niego nie słabną: zawarte w nim definicje nie są kanoniczne i nie ma ścisłego dowodu... Niemniej jednak twardo stojąc przy stanowiskach codziennego zdrowego rozsądku™, intuicyjnie rozumiemy, że twierdzenie jest prawdziwe.
Jedyne, co nie jest oczywiste, to znaczenie litery „P”. Kiedy klaster jest podzielony, decyduje, czy nie udzielać odpowiedzi do czasu osiągnięcia kworum, czy też oddać dostępne dane. W zależności od wyników tego wyboru, system jest klasyfikowany jako CP lub AP. Na przykład Cassandra może zachować się w dowolny sposób, w zależności nawet nie od ustawień klastra, ale od parametrów każdego konkretnego żądania. Ale jeśli system nie jest "P" i się rozłącza, to co?
Odpowiedź na to pytanie jest nieco nieoczekiwana: klastra urzędu certyfikacji nie można podzielić.
Co to za skupisko, którego nie można podzielić?
Niezbędnym atrybutem takiego klastra jest współdzielony system przechowywania danych. W zdecydowanej większości przypadków oznacza to połączenie poprzez sieć SAN, co ogranicza wykorzystanie rozwiązań CA do dużych przedsiębiorstw, które są w stanie utrzymać infrastrukturę SAN. Aby wiele serwerów mogło pracować z tymi samymi danymi, wymagany jest klastrowy system plików. Takie systemy plików są dostępne w portfolio HPE (CFS), Veritas (VxCFS) i IBM (GPFS).
OracleRAC
Opcja Real Application Cluster pojawiła się po raz pierwszy w 2001 roku wraz z wydaniem Oracle 9i. W takim klastrze kilka instancji serwerów pracuje z tą samą bazą danych.
Oracle może współpracować zarówno z klastrowym systemem plików, jak i z własnym rozwiązaniem - ASM, Automatic Storage Management.
Każdy egzemplarz prowadzi swój własny dziennik. Transakcja jest wykonywana i zatwierdzana przez jedną instancję. Jeśli instancja ulegnie awarii, jeden z pozostałych węzłów klastra (instancji) odczytuje swój dziennik i przywraca utracone dane, zapewniając w ten sposób dostępność.
Wszystkie instancje utrzymują własną pamięć podręczną, a te same strony (bloki) mogą znajdować się w pamięci podręcznej wielu instancji jednocześnie. Co więcej, jeśli jedna instancja potrzebuje strony i znajduje się ona w pamięci podręcznej innej instancji, może pobrać ją od sąsiada, korzystając z mechanizmu łączenia pamięci podręcznej, zamiast czytać z dysku.
Ale co się stanie, jeśli jedna z instancji będzie musiała zmienić dane?
Osobliwością Oracle jest to, że nie ma dedykowanej usługi blokowania: jeśli serwer chce zablokować wiersz, wówczas rekord blokady jest umieszczany bezpośrednio na stronie pamięci, na której znajduje się zablokowany wiersz. Dzięki takiemu podejściu Oracle jest mistrzem wydajności wśród monolitycznych baz danych: usługa blokowania nigdy nie staje się wąskim gardłem. Jednak w konfiguracji klastra taka architektura może prowadzić do intensywnego ruchu sieciowego i zakleszczeń.
Po zablokowaniu rekordu instancja powiadamia wszystkie inne instancje, że strona przechowująca ten rekord ma wyłączną blokadę. Jeśli inna instancja musi zmienić rekord na tej samej stronie, musi poczekać, aż zmiany na stronie zostaną zatwierdzone, to znaczy, że informacje o zmianie zostaną zapisane w dzienniku na dysku (i transakcja może być kontynuowana). Może się też zdarzyć, że strona będzie zmieniana sekwencyjnie przez kilka kopii i wówczas przy zapisie strony na dysk trzeba będzie dowiedzieć się, kto przechowuje aktualną wersję tej strony.
Losowe aktualizowanie tych samych stron w różnych węzłach RAC powoduje dramatyczny spadek wydajności bazy danych do punktu, w którym wydajność klastra może być niższa niż w przypadku pojedynczej instancji.
Prawidłowe użycie Oracle RAC polega na fizycznym partycjonowaniu danych (na przykład przy użyciu mechanizmu partycjonowanej tabeli) i uzyskiwaniu dostępu do każdego zestawu partycji za pośrednictwem dedykowanego węzła. Głównym celem RAC nie było skalowanie poziome, ale zapewnienie odporności na błędy.
Jeśli węzeł przestanie odpowiadać na puls, wówczas węzeł, który go wykrył, jako pierwszy rozpoczyna procedurę głosowania na dysku. Jeśli brakujący węzeł nie zostanie tutaj odnotowany, wówczas jeden z węzłów przejmuje odpowiedzialność za odzyskanie danych:
- „zamraża” wszystkie strony, które znajdowały się w pamięci podręcznej brakującego węzła;
- odczytuje logi (ponawia) brakującego węzła i ponownie stosuje zmiany zapisane w tych logach, jednocześnie sprawdzając, czy inne węzły mają nowsze wersje zmienianych stron;
- wycofuje oczekujące transakcje.
Aby uprościć przełączanie między węzłami, Oracle opracowało koncepcję usługi – instancji wirtualnej. Instancja może obsługiwać wiele usług, a usługa może przemieszczać się między węzłami. Instancja aplikacji obsługująca określoną część bazy danych (na przykład grupę klientów) współpracuje z jedną usługą, a usługa odpowiedzialna za tę część bazy danych przenosi się do innego węzła w przypadku awarii węzła.
Systemy IBM Pure Data dla transakcji
Rozwiązanie klastrowe dla DBMS pojawiło się w portfolio Blue Giant w 2009 roku. Ideologicznie jest następcą klastra Parallel Sysplex, zbudowanego na „zwykłym” sprzęcie. W 2009 roku wypuszczono pakiet oprogramowania DB2 pureScale, a w 2012 roku IBM zaoferował urządzenie o nazwie Pure Data Systems for Transactions. Nie należy go mylić z Pure Data Systems for Analytics, które jest niczym innym jak zmienioną nazwą Netezza.
Na pierwszy rzut oka architektura pureScale jest podobna do Oracle RAC: w ten sam sposób kilka węzłów jest podłączonych do wspólnego systemu przechowywania danych, a każdy węzeł uruchamia własną instancję DBMS z własnymi obszarami pamięci i dziennikami transakcji. Jednak w przeciwieństwie do Oracle, DB2 ma dedykowaną usługę blokowania reprezentowaną przez zestaw procesów db2LLM*. W konfiguracji klastrowej usługa ta jest umieszczona w oddzielnym węźle, który w przypadku Parallel Sysplex nosi nazwę obiektu sprzęgającego (CF), a w przypadku Pure Data PowerHA.
PowerHA świadczy następujące usługi:
- menedżer zamków;
- globalna pamięć podręczna bufora;
- obszar komunikacji międzyprocesowej.
Do przesyłania danych z PowerHA do węzłów bazy danych i z powrotem używany jest zdalny dostęp do pamięci, dlatego połączenie klastra musi obsługiwać protokół RDMA. PureScale może korzystać zarówno z Infiniband, jak i RDMA przez Ethernet.
Jeśli węzeł potrzebuje strony, a tej strony nie ma w pamięci podręcznej, to węzeł żąda strony w globalnej pamięci podręcznej i dopiero jeśli jej tam nie ma, odczytuje ją z dysku. W przeciwieństwie do Oracle żądanie trafia tylko do PowerHA, a nie do sąsiednich węzłów.
Jeśli instancja zamierza zmienić wiersz, blokuje go w trybie wyłącznym, a strona, na której znajduje się wiersz, w trybie współdzielonym. Wszystkie blokady są rejestrowane w globalnym menedżerze zamków. Po zakończeniu transakcji węzeł wysyła wiadomość do menedżera blokad, który kopiuje zmodyfikowaną stronę do globalnej pamięci podręcznej, zwalnia blokady i unieważnia zmodyfikowaną stronę w pamięci podręcznej innych węzłów.
Jeżeli strona, na której znajduje się zmodyfikowany wiersz, jest już zablokowana, menedżer blokad odczyta zmodyfikowaną stronę z pamięci węzła, który dokonał zmiany, zwolni blokadę, unieważni zmodyfikowaną stronę w pamięci podręcznej innych węzłów i daj blokadę strony węzłowi, który o to poprosił.
„Brudne”, czyli zmienione, strony można zapisywać na dysk zarówno ze zwykłego węzła, jak i z PowerHA (castout).
Jeśli jeden z węzłów pureScale ulegnie awarii, odzyskiwanie ogranicza się tylko do tych transakcji, które nie zostały jeszcze zakończone w momencie awarii: strony zmodyfikowane przez ten węzeł w ukończonych transakcjach znajdują się w globalnej pamięci podręcznej PowerHA. Węzeł uruchamia się ponownie w zredukowanej konfiguracji na jednym z serwerów w klastrze, wycofuje oczekujące transakcje i zwalnia blokady.
PowerHA działa na dwóch serwerach, a węzeł główny synchronicznie replikuje swój stan. Jeśli podstawowy węzeł PowerHA ulegnie awarii, klaster będzie nadal współpracować z węzłem zapasowym.
Oczywiście, jeśli uzyskasz dostęp do zbioru danych za pośrednictwem pojedynczego węzła, ogólna wydajność klastra będzie wyższa. PureScale potrafi nawet zauważyć, że pewien obszar danych jest przetwarzany przez jeden węzeł, a wtedy wszystkie blokady związane z tym obszarem będą przetwarzane lokalnie przez węzeł bez konieczności komunikowania się z PowerHA. Jednak gdy tylko aplikacja spróbuje uzyskać dostęp do tych danych za pośrednictwem innego węzła, przetwarzanie scentralizowanej blokady zostanie wznowione.
Wewnętrzne testy IBM przy obciążeniu wynoszącym 90% odczytu i 10% zapisu, które jest bardzo podobne do rzeczywistych obciążeń produkcyjnych, wykazały niemal liniowe skalowanie do 128 węzłów. Warunki testów niestety nie zostały ujawnione.
HPE NonStop SQL
Oferta Hewlett-Packard Enterprise obejmuje również własną platformę o wysokiej dostępności. 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-Packardem.
NonStop służy do tworzenia krytycznych aplikacji - na przykład HLR lub przetwarzania kart bankowych. Platforma dostarczana jest w postaci kompleksu programowo-sprzętowego (urządzenia), w skład którego wchodzą węzły obliczeniowe, system przechowywania danych oraz sprzęt komunikacyjny. Sieć ServerNet (w nowoczesnych systemach Infiniband) służy zarówno do wymiany pomiędzy węzłami, jak i dostępu do systemu przechowywania danych.
Wczesne wersje systemu wykorzystywały autorskie procesory, które były ze sobą zsynchronizowane: wszystkie operacje były wykonywane synchronicznie przez kilka procesorów, a gdy tylko jeden z procesorów popełnił błąd, wyłączał się, a drugi nadal działał. Później system przeszedł na konwencjonalne procesory (najpierw MIPS, potem Itanium, a na końcu x86), a do synchronizacji zaczęto wykorzystywać inne mechanizmy:
- komunikaty: każdy proces systemowy ma bliźniaka „cienia”, do którego aktywny proces okresowo wysyła komunikaty o swoim statusie; jeśli proces główny zawiedzie, proces cienia rozpoczyna działanie od momentu określonego przez ostatni komunikat;
- głosowanie: system pamięci ma specjalny komponent sprzętowy, który akceptuje wielokrotne identyczne dostępy i wykonuje je tylko wtedy, gdy dostępy są zgodne; Zamiast fizycznej synchronizacji, procesory działają asynchronicznie, a wyniki ich pracy porównywane są jedynie w momentach wejścia/wyjścia.
Od 1987 roku na platformie NonStop działa relacyjny system DBMS – najpierw SQL/MP, później SQL/MX.
Cała baza danych jest podzielona na części, a każda część odpowiada za własny proces Data Access Manager (DAM). Zapewnia mechanizmy rejestrowania, buforowania i blokowania danych. Przetwarzanie danych odbywa się za pomocą procesów serwera Executor działających w tych samych węzłach, co odpowiednie menedżery danych. Harmonogram SQL/MX dzieli zadania pomiędzy wykonawcami i agreguje wyniki. W przypadku konieczności wprowadzenia uzgodnionych zmian stosowany jest protokół zatwierdzania dwufazowego udostępniany przez bibliotekę TMF (Transaction Management Facility).
NonStop SQL może nadawać priorytety procesom, dzięki czemu długie zapytania analityczne nie zakłócają realizacji transakcji. Jednak jego celem jest właśnie przetwarzanie krótkich transakcji, a nie analityka. Deweloper gwarantuje dostępność klastra NonStop na poziomie pięciu „dziewiątek”, czyli przestój wynosi zaledwie 5 minut rocznie.
SAP HANA
Pierwsza stabilna wersja HANA DBMS (1.0) miała miejsce w listopadzie 2010 r., a pakiet SAP ERP przeszedł na HANA w maju 2013 r. Platforma bazuje na zakupionych technologiach: TREX Search Engine (wyszukiwanie w pamięci kolumnowej), P*TIME DBMS i MAX DB.
Samo słowo „HANA” jest akronimem, wysokowydajne urządzenie analityczne. Ten system zarządzania bazą danych jest dostarczany w postaci kodu, który może działać na dowolnym serwerze x86, jednak instalacje przemysłowe są dozwolone tylko na certyfikowanym sprzęcie. Rozwiązania dostępne od HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Niektóre konfiguracje Lenovo pozwalają nawet na pracę bez sieci SAN – rolę wspólnego systemu przechowywania danych pełni klaster GPFS na dyskach lokalnych.
W przeciwieństwie do platform wymienionych powyżej, HANA jest systemem DBMS in-memory, tj. podstawowy obraz danych jest przechowywany w pamięci RAM, a na dysku zapisywane są jedynie dzienniki i okresowe migawki w celu odzyskania w przypadku awarii.
Każdy węzeł klastra HANA odpowiada za własną część danych, a mapa danych przechowywana jest w specjalnym komponencie – Serwerze Nazw, zlokalizowanym na węźle koordynatora. Dane nie są duplikowane pomiędzy węzłami. Informacje o blokowaniu są również przechowywane w każdym węźle, ale system posiada globalny detektor zakleszczenia.
Gdy klient HANA łączy się z klastrem, pobiera jego topologię, a następnie może uzyskać bezpośredni dostęp do dowolnego węzła, w zależności od potrzebnych danych. Jeżeli transakcja wpływa na dane pojedynczego węzła, to może zostać wykonana lokalnie przez ten węzeł, natomiast w przypadku zmiany danych kilku węzłów węzeł inicjujący kontaktuje się z węzłem koordynującym, który otwiera i koordynuje rozproszoną transakcję, zatwierdzając ją za pomocą zoptymalizowany protokół zatwierdzania dwufazowego.
Węzeł koordynujący jest zduplikowany, zatem w przypadku awarii koordynatora jego rolę natychmiast przejmuje węzeł zapasowy. Jeśli jednak węzeł z danymi ulegnie awarii, jedynym sposobem uzyskania dostępu do jego danych jest ponowne uruchomienie węzła. Z reguły klastry HANA utrzymują zapasowy serwer, aby jak najszybciej zrestartować na nim utracony węzeł.
Źródło: www.habr.com