Bazy danych w klastrze

Klastry to technologia, która pozwala łączyć kilka systemów komputerowych w całość. Użytkownik nawet nie wie, czy komunikuje się z jednym komputerem czy z farmą serwerów.

Klastry to technologia, która pozwala łączyć kilka systemów komputerowych w całość. Użytkownik nawet nie wie, czy komunikuje się z jednym komputerem czy z farmą serwerów.

Można wyodrębnić 2 główne zastosowania klastrów. Pierwsze ma na celu zduplikowanie serwerów i zapewnienie nieprzerwanego funkcjonowania aplikacji (klastry typu fail-over). W przypadku serwerów bazodanowych wszystkie informacje są zapamiętywane na każdej równolegle pracującej maszynie. W razie awarii użytkownicy są "przenoszeni" na działający serwer.

Drugie zastosowanie klastrów wiąże się ze zwiększeniem liczby tzw. równoczesnych użytkowników, którzy przyporządkowywani są węzłom klastra. Trudność konstrukcji polega tu na zapewnieniu spójności danych przechowywanych w systemie.

Samodzielnie albo w grupie

Stosowane są 2 główne rozwiązania: klastry, w których dzielony jest system dyskowy, i klastry typu share-nothing, gdzie każdy węzeł jest samodzielną maszyną.

Klaster bazodanowy typu share-nothing wymaga, aby dane były w sposób jawny podzielone między poszczególne węzły. Dobrym przykładem jest klaster 4-węzłowy, w którym każdy z węzłów przechowuje informacje finansowe za jeden kwartał. W przypadku tego typu klastra potrzebna jest specyficzna struktura aplikacji i danych. System bazodanowy musi zawierać mechanizm przekierowujący określone zapytanie do konkretnego serwera. Przy umiejętnym projektowaniu jest to efektywne rozwiązanie, stosowane m.in. w MS SQL Server 2000 i w IBM DB2 Universal Database V7.1, gdzie skalowalność rośnie niemal liniowo wraz z dodawaniem nowych węzłów.

W przypadku klastrów z dzielonym systemem dyskowym (najczęściej rozwiązanie realizowane sprzętowo) pojawiają się problemy innego typu. Informacje są przechowywane w jednym miejscu, a węzeł klastra jest dodatkową maszyną, która obsługuje pewną liczbę użytkowników. Tego typu rozwiązanie wykorzystano m.in. w Oracle Parallel Server. Węzeł, wykonujący transakcję, jest w stanie samodzielnie uzyskać dostęp do systemu dyskowego i odczytać lub zapisać wymagane informacje. Wadą jest stosunkowo wolne skalowanie systemu w miarę dodawania nowych węzłów. Podstawowy problem to mała wydajność pamięci podręcznej. Często zdarza się, że informacje niedawno odczytywane przez jeden z węzłów klastra są niemal natychmiast ponownie odczytywane z dysków przez inny węzeł.

Rozwiązanie Oracle

Problem ten w bazie Oracle ma rozwiązać nowy element Oracle 9i Cache Fusion. Zadaniem tej aplikacji jest synchronizacja informacji o blokadach i przesyłanie komunikatów między poszczególnymi węzłami klastra o ostatnio odczytywanych czy zapisywanych rekordach.

Cache Fusion pozwala przesyłać komunikaty o tym, które fragmenty bazy danych były ostatnio używane w transakcji. Zazwyczaj w momencie dwóch równoległych transakcji (na poziomie izolacji read commited), przed odczytem danego elementu bazy może być konieczne nałożenie blokady, by nikt inny nie zmodyfikował danych w trakcie odczytu. Cache Fusion pozwala, by Parallel Server zapisywał blokady tylko wtedy, gdy transakcja modyfikuje dane w bazie. Cache Fusion rozsyła w klastrze komunikaty o tego typu tymczasowych blokadach, co niemal zupełnie eliminuje konieczność zapisu blokad na dysk przy odczytywaniu rekordów.

Dzięki mechanizmowi przesyłania informacji o zawartości pamięci podręcznej poszczególnych węzłów klaster dysponuje "wirtualną" pamięcią podręczną, będącą sumą informacji pomocniczych przechowywanych w poszczególnych węzłach. Wydaje się, że tego typu rozwiązanie może bardzo przyspieszyć dostęp do danych. Cache Fusion najpierw przeszukuje lokalną pamięć podręczną węzła, następnie sprawdza, czy są tam informacje o tym, że dana porcja danych została odczytana przez inny węzeł, a dopiero na końcu odwołuje się do dysku.

W pamięci podręcznej zostają także informacje związane z zapisem rekordów na dysk. Załóżmy, że równolegle wykonywane są dwie transakcje. Transakcja A modyfikuje rekord, a inna (B) chce go odczytać (nim transakcja A zostanie zatwierdzona). Przy poziomie izolacji read commited transakcja B powinna odczytać oryginalną zawartość rekordu. W związku z tym węzeł wykonujący transakcję A przechowuje w pamięci podręcznej poprzednią zawartość rekordu i na żądanie może przekazać ją innemu węzłowi (wykonującemu transakcję B).

W bazie Oracle 9i ma być wprowadzony specjalny mechanizm dystrybucji kwerend (podobny jak w przypadku klastrów share-nothing). Zapytanie ma być wstępnie analizowane i kierowane do tego węzła, który największą część informacji przechowuje już w pamięci podręcznej.

Pewność klastrów?

Na pewno system komputerowy, w którym serwery zostały zduplikowane w klastrze, ma bardzo wysoką dostępność i nieza- wodność. Warto jednak szczegółowo przyjrzeć się rozwiązaniom programowym, które rozdzielają zadania na różne serwery w celu zwiększenia prędkości działania aplikacji czy zwiększenia liczby obsługiwanych użytkowników.

W przypadku klastrów "aplikacyjnych" przy dodatkowym założeniu, że aplikacja stworzona jest przy użyciu technologii komponentowej (COM/J2EE/CORBA itp.) użytkownicy tak naprawdę są niemal niezależni od serwera, który wykonuje obliczenia. Większość rozwiązań pozwala, by w razie awarii wznowić obliczenia na innej maszynie. Podobnie jest w przypadku farm serwerów WWW.

Więcej kłopotu sprawiają klastry bazodanowe. Tu kluczową sprawą jest zapewnienie ciągłej integralności danych przechowywanych w bazie. W przypadku technologii, w których są współdzielone dyski, uszkodzenie jednego z komputerów działających w klastrze prawie w ogóle nie wpływa na funkcjonowanie aplikacji. Dużo problemów sprawia natomiast uszkodzenie podsystemu dyskowego. Nawet gdy dyski (fizyczne nośniki) nie zawiodą, to uszkodzeniu może ulec kontroler macierzy - a ten element rzadko jest duplikowany.

W przypadku klastrów bazodanowych typu share-nothing w razie uszkodzenia jednego z węzłów klastra niedostępne stają się te informacje, które przechowywał komputer. Natomiast przy odpowiednim skonstruowaniu aplikacji pozostałe informacje są nadal osiągalne.

Koszty klastrów

W rozwiązaniach share-nothing węzłami są zwykłe serwery (nie wymagają specjalnych zmian konstrukcyjnych, poza zapewnieniem szybkich łączy wewnątrzklastrowych). W przypadku klastrów bazodanowych dane muszą być ręcznie podzielone pomiędzy węzły. Może się zdarzyć, że aplikacja, która korzysta z węzłów share-nothing, będzie bardziej złożona.

W klastrach z dzielonymi dyskami podsystem dyskowy jest dosyć kosztownym elementem, a ponadto każdy z węzłów musi mieć specjalną konstrukcję, by było możliwe współdzielenie macierzy dyskowej. Nie ma natomiast żadnych wymagań co do danych czy konstrukcji aplikacji. W klastrze ze wspólnym systemem dyskowym wąskim gardłem są dyski. Z tego też powodu w testach TPC/C przodują klastry share-nothing. Może nowa technika Cache Fusion Oracle pozwoli zmniejszyć tę różnicę.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200