Twierdzenie CAP jest kamieniem węgielnym teorii systemów rozproszonych. Oczywiście, toczy się na ten temat wiele dyskusji: jego definicje nie są kanoniczne i nie ma ścisłego dowodu… Niemniej jednak, mocno stojąc na stanowiskach zdrowego rozsądku™, intuicyjnie rozumiemy, że twierdzenie jest prawdziwe.
Jedyne, co nie jest oczywiste, to znaczenie litery „P”. Kiedy klaster się dzieli, decyduje, czy nie odpowiadać, dopóki nie zostanie osiągnięte kworum, czy przekazać posiadane dane. W zależności od wyników tego wyboru system jest klasyfikowany jako CP lub AP. Cassandra na przykład może zachowywać się na oba sposoby, w zależności nie od ustawień klastra, ale od parametrów każdego konkretnego żądania. Ale jeśli system nie jest „P” i się dzieli, to co wtedy?
Odpowiedź na to pytanie jest dość nieoczekiwana: klaster CA nie może się podzielić.
Co to za klaster, który nie może się podzielić?
Istotnym atrybutem takiego klastra jest współdzielony system przechowywania danych. W zdecydowanej większości przypadków oznacza to połączenie przez sieć SAN, co ogranicza wykorzystanie rozwiązań CA do dużych przedsiębiorstw zdolnych do utrzymania infrastruktury SAN. Aby zapewnić kilka serwery Do pracy 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 wiele instancji serwer pracować z tą samą bazą danych.
Oracle może pracować zarówno z systemem plików klastra, jak i z własnym rozwiązaniem – ASM (Automatic Storage Management).
Każda instancja utrzymuje 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 – zapewnia to dostępność.
Wszystkie instancje utrzymują własną pamięć podręczną, a te same strony (bloki) mogą znajdować się w pamięciach podręcznych kilku instancji w tym samym czasie. Ponadto, jeśli strona jest potrzebna jednej instancji i znajduje się w pamięci podręcznej innej instancji, może ona uzyskać ją od swojego „sąsiada” za pomocą mechanizmu łączenia pamięci podręcznej zamiast odczytywania jej 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, rekord blokady jest umieszczany bezpośrednio na stronie pamięci, na której znajduje się zablokowany wiersz. Dzięki temu 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 intensywnej wymiany sieciowej i wzajemnych blokad.
Po zablokowaniu rekordu instancja powiadamia wszystkie inne instancje, że strona, która zawiera rekord, została zablokowana na wyłączność. Jeśli inna instancja musi zmienić rekord na tej samej stronie, musi czekać, aż zmiany na stronie zostaną zatwierdzone, tj. zmiana zostanie zapisana w dzienniku na dysku (podczas gdy transakcja może być kontynuowana). Może się również zdarzyć, że strona zostanie zmieniona przez kilka instancji z rzędu, a następnie, gdy strona zostanie zapisana na dysku, musi ustalić, kto przechowuje bieżącą wersję strony.
Losowa aktualizacja tych samych stron na różnych węzłach RAC powoduje drastyczne pogorszenie wydajności bazy danych, do tego stopnia, że wydajność klastra może być niższa niż wydajność pojedynczej instancji.
Prawidłowe użycie Oracle RAC polega na fizycznym podziale danych (na przykład przy użyciu mechanizmu partycjonowanej tabeli) i dostępie do każdego zestawu partycji za pośrednictwem dedykowanego węzła. Głównym celem RAC stało się nie skalowanie poziome, ale tolerancja błędów.
Jeśli węzeł przestaje odpowiadać na bicie serca, węzeł, który wykrył to jako pierwszy, rozpoczyna procedurę głosowania na dysku. Jeśli brakujący węzeł nie zameldował się tutaj, jeden z węzłów przejmuje odpowiedzialność za przywrócenie danych:
- „zamraża” wszystkie strony, które znajdowały się w pamięci podręcznej brakującego węzła;
- odczytuje dzienniki redo brakującego węzła i ponownie stosuje zmiany zapisane w tych dziennikach, sprawdzając jednocześnie, czy inne węzły mają nowsze wersje modyfikowanych stron;
- cofa niedokończone transakcje.
Aby uprościć przełączanie się między węzłami, Oracle ma koncepcję usługi – wirtualnej instancji. Instancja może obsługiwać kilka usług, a usługa może przemieszczać się między węzłami. Instancja aplikacji, która obsługuje pewną 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, gdy węzeł ulegnie awarii.
Systemy IBM Pure Data dla transakcji
Rozwiązanie klastrowe dla DBMS pojawiło się w ofercie Blue Giant w 2009 r. Ideologicznie jest następcą klastra Parallel Sysplex, zbudowanego na „zwykłym” sprzęcie. W 2009 r. wydano produkt DB2 pureScale, który jest pakietem oprogramowania, a w 2012 r. IBM oferuje pakiet sprzętu i oprogramowania (urządzenie) o nazwie Pure Data Systems for Transactions. Nie należy go mylić z Pure Data Systems for Analytics, który jest niczym więcej niż przemianowaną Netezzą.
Architektura pureScale jest na pierwszy rzut oka podobna do Oracle RAC: kilka węzłów jest połączonych ze wspólnym systemem 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 klastra ta usługa jest przenoszona do oddzielnego węzła, który w Parallel Sysplex nazywany jest obiektem sprzęgającym (CF), a w Pure Data PowerHA.
PowerHA świadczy następujące usługi:
- kierownik bloku;
- globalna pamięć podręczna bufora;
- obszar komunikacji międzyprocesowej.
Zdalny dostęp do pamięci jest używany do przesyłania danych z PowerHA do węzłów DB i z powrotem, więc połączenie klastra musi obsługiwać protokół RDMA. PureScale może używać zarówno Infiniband, jak i RDMA przez Ethernet.
Jeśli węzeł potrzebuje strony, a ta strona nie znajduje się w pamięci podręcznej, węzeł żąda strony z globalnej pamięci podręcznej i tylko jeśli jej tam nie ma, odczytuje ją z dysku. W przeciwieństwie do Oracle, żądanie jest kierowane tylko do PowerHA, a nie do sąsiednich węzłów.
Jeśli instancja ma modyfikować wiersz, blokuje go w trybie wyłączności, a stronę, na której znajduje się wiersz, w trybie współdzielonym. Wszystkie blokady są rejestrowane w globalnym menedżerze blokad. Gdy transakcja zostanie zatwierdzona, 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ęciach podręcznych innych węzłów.
Jeśli strona zawierająca modyfikowany wiersz jest już zablokowana, menedżer blokad odczyta zmodyfikowaną stronę z pamięci węzła, który dokonał modyfikacji, zwolni blokadę, unieważni zmodyfikowaną stronę w pamięci podręcznej innych węzłów i zwróci blokadę strony węzłowi, który jej zażądał.
„Brudne”, czyli zmodyfikowane strony, można zapisać na dysku zarówno ze zwykłego węzła, jak i z węzła PowerHA (castout).
Jeśli jeden z węzłów pureScale ulegnie awarii, odzyskiwanie jest ograniczone tylko do transakcji, które nie zostały jeszcze ukończone w momencie awarii: strony zmodyfikowane przez ten węzeł w ukończonych transakcjach znajdują się w globalnej pamięci podręcznej w PowerHA. Węzeł jest ponownie uruchamiany w uproszczonej konfiguracji na jednym z serwerów klastra, wycofuje nieukończone transakcje i zwalnia blokady.
PowerHA działa na dwóch serwerach, a węzeł główny synchronicznie replikuje jego stan. Jeśli węzeł główny ulegnie awarii, klaster PowerHA kontynuuje działanie z węzłem zapasowym.
Oczywiście, jeśli uzyskujesz dostęp do zestawu danych za pośrednictwem pojedynczego węzła, ogólna wydajność klastra będzie wyższa. PureScale może nawet zauważyć, że pewien obszar danych jest przetwarzany przez pojedynczy węzeł, a następnie wszystkie blokady związane z tym obszarem będą przetwarzane lokalnie przez węzeł bez komunikowania się z PowerHA. Ale gdy tylko aplikacja spróbuje uzyskać dostęp do tych danych za pośrednictwem innego węzła, scentralizowane przetwarzanie blokad zostanie wznowione.
Wewnętrzne testy IBM przy obciążeniu 90% odczytu/10% zapisu, które ściśle przypomina rzeczywiste obciążenia produkcyjne, wykazują niemal liniowe skalowanie do 128 węzłów. Niestety, warunki testu nie zostały ujawnione.
HPE NonStop SQL
Hewlett-Packard Enterprise ma również własną, wysoce dostępną platformę. Jest to platforma NonStop, wprowadzona w 1976 r. przez Tandem Computers. W 1997 r. firma została przejęta przez Compaq, który z kolei połączył się z Hewlett-Packard w 2002 r.
NonStop jest używany do tworzenia krytycznych aplikacji, takich jak HLR lub przetwarzanie kart bankowych. Platforma jest dostarczana jako kompleks sprzętowo-programowy (appliance), który obejmuje węzły obliczeniowe, system przechowywania danych i sprzęt komunikacyjny. Sieć ServerNet (Infiniband w nowoczesnych systemach) służy zarówno do wymiany między węzłami, jak i do dostępu do systemu przechowywania danych.
Wczesne wersje systemu korzystały z zastrzeżonych procesorów, 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, był wyłączany, a drugi kontynuował pracę. Później system przeszedł na konwencjonalne procesory (najpierw MIPS, potem Itanium i w końcu x86), a do synchronizacji zaczęto używać innych mechanizmów:
- wiadomości: każdy proces systemowy ma swojego „cienia” bliźniaka, do którego aktywny proces okresowo wysyła wiadomości o swoim stanie; jeśli główny proces ulegnie awarii, proces cienia zaczyna działać od momentu określonego przez ostatnią wiadomość;
- głosowanie: system pamięci masowej ma specjalny komponent sprzętowy, który akceptuje wiele identycznych żądań i wykonuje je tylko wtedy, gdy żądania są zgodne; zamiast fizycznej synchronizacji, procesory działają asynchronicznie, a wyniki ich pracy są porównywane tylko w momentach wejścia/wyjścia.
Od 1987 roku platforma NonStop opiera się na relacyjnym systemie DBMS – najpierw SQL/MP, a 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 on rejestrowanie danych, buforowanie i mechanizm blokowania. Przetwarzanie danych jest wykonywane przez procesy wykonawcze (Executor Server Process), działające na tych samych węzłach, co odpowiadające im menedżery danych. Harmonogram SQL/MX dzieli zadania między wykonawcami i łączy wyniki. Jeśli konieczne jest wprowadzenie spójnych zmian, używany jest protokół zatwierdzania dwufazowego, dostarczany przez bibliotekę TMF (Transaction Management Facility).
NonStop SQL może priorytetyzować procesy, tak aby długie zapytania analityczne nie kolidowały z wykonywaniem transakcji. Jednak jego celem jest przetwarzanie krótkich transakcji, a nie analityka. Deweloper gwarantuje dostępność klastra NonStop na poziomie pięciu „dziewiątek”, czyli czas przestoju wynosi tylko 5 minut rocznie.
SAP HANA
Pierwsza stabilna wersja systemu HANA DBMS (1.0) pojawiła się w listopadzie 2010 r., a pakiet SAP ERP przeszedł na platformę HANA w maju 2013 r. Platforma oparta jest na zakupionych technologiach: TREX Search Engine (wyszukiwanie w pamięci kolumnowej), P*TIME DBMS i MAX DB.
Samo słowo „HANA” jest akronimem High Performance ANalytical Appliance. Ten DBMS jest dostarczany jako kod, który może działać na dowolnych serwerach x86, ale instalacje przemysłowe są dozwolone tylko na certyfikowanym sprzęcie. Istnieją rozwiązania od HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Niektóre konfiguracje Lenovo pozwalają nawet na działanie bez SAN — rolę ogólnego systemu pamięci masowej pełni klaster GPFS na dyskach lokalnych.
W przeciwieństwie do platform wymienionych powyżej, HANA jest systemem DBMS działającym w pamięci, co oznacza, że podstawowy obraz danych jest przechowywany w pamięci RAM, a na dysku zapisywane są jedynie logi i okresowe migawki w celu umożliwienia odzyskania danych w razie awarii.
Każdy węzeł klastra HANA odpowiada za swoją część danych, a mapa danych jest przechowywana w specjalnym komponencie – Serwerze Nazw, znajdującym się na węźle koordynatora. Dane nie są duplikowane między węzłami. Informacje o blokadach są również przechowywane na każdym węźle, ale system ma globalny detektor impasu.
Podczas łączenia się z klastrem klient HANA pobiera swoją topologię i może następnie uzyskać bezpośredni dostęp do dowolnego węzła w zależności od potrzebnych danych. Jeśli transakcja wpływa na dane na pojedynczym węźle, może zostać wykonana lokalnie przez ten węzeł, ale jeśli dane na wielu węzłach zostaną zmienione, węzeł inicjujący kontaktuje się z węzłem koordynującym, który otwiera i koordynuje rozproszoną transakcję, zatwierdzając ją przy użyciu zoptymalizowanego dwufazowego protokołu zatwierdzania.
Węzeł koordynatora jest duplikowany, więc jeśli koordynator ulegnie awarii, węzeł zapasowy natychmiast przejmuje jego rolę. Ale jeśli węzeł danych ulegnie awarii, jedynym sposobem na dostęp do jego danych jest ponowne uruchomienie węzła. Z reguły klastry HANA mają zapasowy serwer, aby jak najszybciej ponownie uruchomić utracony węzeł.
Źródło: www.habr.com
