Bazy danych ujawniły zalety systemów klastrowych.

Nowe zastosowania baz danych, związane głównie z Internetem, przyspieszyły rozwój systemów klastrowych. Okazało się, że w wielu przypadkach wzrost wydajności uzyskany na skutek skalowania pionowego, czyli zwiększania mocy pojedynczego serwera bazodanowego, nie usprawiedliwia wysokich kosztów rozbudowy.

Bezpieczeństwo lub szybkość

Jednym z podstawowych zadań klastra jest zapewnienie nieprzerwanego działania systemu bazodanowego. Klaster typu fail-over to najczęściej "kopia" serwera głównego. Przejmuje wszystkie zadania w razie awarii. Producenci wykorzystują różne mechanizmy, np. log shipping przesuwający na drugi serwer aktywną część pliku log, zawierającego ostatnio wykonywane transakcje. Innym sposobem na zapewnienie nieprzerwanej pracy jest szybkie odzyskiwanie danych z kopii zapasowej lub mechanizm wymuszający jednoczesne wykonywanie operacji na obu komputerach.

Drugim celem, stawianym przed konfiguracją klastrową, jest zwiększenie skalowalności systemu, obsłużenie większej liczby klientów, skrócenie czasu odpowiedzi. W tym przypadku stosuje się dwa typy architektury: klastry, w których każdy węzeł jest samodzielnym serwerem (share-nothing), i klastry ze wspólnym systemem dyskowym.

Klaster podzielony

W architekturze share-nothing zakłada się, że węzłami są standardowe komputery, ewentualnie wyposażone w karty do szybkiej komunikacji. Systemy share--nothing od ponad roku zajmują pierwsze miejsca w testach TPC/C.

W takiej konfiguracji baza musi być odpowiednio partycjonowana, tzn. tak by każdy węzeł zajmował się odpowiednim jej fragmentem. W strukturze bazy musi istnieć klucz partycjonujący, który określa kryterium jej podziału. Klucz musi być znany każdemu węzłowi. Należy go tak zdefiniować, aby każdy węzeł klastra mógł skierować zapytanie do innego.

Przez długi czas aktualizacja klucza partycjonującego (zarówno zmiana jego wartości, jak i dopisywanie nowych elementów) sprawiała duże problemy. Obecnie prawie każda baza umożliwia aktualizację klucza partycjonującego.

Warto przyjrzeć się mechanizmowi log shipping (zaimplementowanemu m.in. w Microsoft SQL Server 2000). Jest to z jednej strony mechanizm, który pozwala tworzyć na bieżąco kopie serwera centralnego, z drugiej - w przypadku dużego obciążenia systemu - przekazywać zapytania do serwerów zapasowych. Należy jednak podkreślić, że w tego typu klastrze zapasowe motory bazy danych są przeznaczone tylko do odczytu (czyli np. zapytanie aktualizujące musi być i tak przekazane do serwera głównego).

Drugi typ klastrów zakłada istnienie współdzielonego systemu dyskowego. Takie rozwiązanie wykorzystuje Oracle w Real Application Cluster. Informacje są przechowywane w jednym miejscu, a węzeł klastra jest dodatkową maszyną, która obsługuje pewną liczbę użytkowników. Węzeł wykonujący transakcję uzyskuje dostęp do systemu dyskowego i odczytuje lub zapisuje informacje.

Podstawową wadą tego rozwiązania jest stosunkowo wolne skalowanie w miarę dodawania nowych węzłów klastra. Na przeszkodzie staje mała wydajność pamięci podręcznej. Często zdarza się, że informacje niedawno odczytywane przez jeden węzeł po chwili muszą być ponownie odczytywane przez drugi.

Oracle w wersji 9i proponuje mechanizm rozproszonego cache - Cache Fusion, gdzie pomiędzy węzłami klastra przesyłane są komunikaty informujące o tym, które fragmenty bazy były ostatnio używane w transakcji. W ten sposób węzły mają informację, na którym serwerze znajduje się określony fragment danych, i kierują zapytanie bezpośrednio do tego węzła.

Rozwiązania współdzielące zasoby nie nakładają ograniczeń na strukturę bazodanową ani na konstrukcję aplikacji. Są wprawdzie wolniejsze, ale cechuje je wyższa niezawodność. W klastrach share-nothing, w razie awarii jednego węzła dane będą niedostępne (oczywiście można zduplikować każdy z węzłów, ale jest to dosyć trudne i kosztowne). W klastrach ze wspólnym systemem dyskowym zastosowanie sprzętowego mirroringu sprawia, że ryzyko awarii jest niewielkie. Awaria węzła powoduje tylko spadek wydajności.

Na jednym komputerze

Rozwiązania klastrowe są trudniejsze w utrzymaniu i zarządzaniu niż pojedyncze serwery. 28 sierpnia br. w wynikach testów TPC/C na czwartej pozycji uplasowało się rozwiązanie Fujitsu, wykorzystujące oprogramowanie SymfoWARE Server Enterprise Edition for VLM 3.0.1 na serwerze PRIMEPOWER 2000 ze 128 procesorami SPARC64 GP 563 MHz i 256 GB RAM.

SymfoWARE jest wyspecjalizowanym serwerem bazodanowym, w rozwoju którego główny nacisk położono na wykorzystanie wielu równoległych procesorów. Analizator kwerend dzieli zadanie, tak by konkretny procesor odwoływał się do określonego fragmentu danych. Baza jest dzielona na jak najmniejsze jednostki, które następnie są przetwarzane przez poszczególne procesory. Ciekawym pomysłem Fujitsu jest losowy rozkład danych na dysku. Dzięki temu, przy założeniu intensywnego dostępu do całej bazy, serwer uniknie (statystycznie) większości wąskich gardeł związanych z podsystemem dyskowym.

SymfoWARE to serwer relacyjny. Dostępny jest specjalny moduł, który na dane relacyjne "nakłada" strukturę wielowymiarowych kostek OLAP. w

Artykuł jest kontynuacją tematu o konstrukcji baz danych, opublikowanego w poprzednim tygodniu (CW nr 36).