Real Application Clusters

Sebastian Wyrwał
na podstawie Oracle White Papers

Niniejszy artykuł omawia rozwiązanie Real Application
Clusters firmy Oracle. Opisano architekturę tego rozwiązania, odnosząc ją krótko
do teorii. Pokazano zasadnicze cechy rozwiązania i przedstawiono jego porównanie
z konkurencyjną bazą danych DB2 firmy IBM oraz w pewnym zakresie z bazą MS
SQL Server firmy Microsoft. Ukazano nowatorskie elementy prezentowanego systemu.
Zaprezentowano dwa, zaczerpnięte z literatury, zastosowania przemysłowe
omawianego rozwiązania.

Do prezentowanego tematu można w zasadzie podejść z dwóch
stron – od strony administratora systemu oraz od strony koncepcji, co
uczynił autor. Pierwsze podejście jest bardziej przydatne dla osób pragnących
zastosować RAC, drugie natomiast bardziej pomocne będzie dla osób chcących
zrozumieć idee działania lub dokonać wyboru produktu.

Informacji na temat instalowania wraz ze skryptami ułatwiającymi
instalację jest w internecie sporo – dlatego autor jest zdania, że mogą
być one pominięte w niniejszym artykule. Warto podkreślić, iż najbardziej
nużące wydają się być czynności przygotowawcze do instalacji, zależą one
jednak silnie od sprzętu – co jest kolejnym powodem, dla którego nie
warto powielać zbyt szczegółowych informacji.

Real Application Clusters – architektura

Klaster RAC z punktu użytkownika jest serwerem bazodanowym.
W rzeczywistości, w jego skład wchodzi pewna ilość komputerów (węzłów),
które korzystają ze wspólnej pamięci masowej. Można to odnieść do
klasycznej architektury z pamięcią współdzieloną. Rozwiązanie to
przedstawiono na rysunku 1. Widać, iż komputery (węzły w terminologii
klastra) nie tylko korzystają ze wspólnej pamięci masowej ale też są ze sobą
połączone.


Rys. 1. Klaster w rozwiązaniu RAC

Podchodząc do sprawy nieco pobieżnie można powiedzieć, iż
RAC ma zapewnić wysoką niezawodność i dużą dostępność systemu idącą w
parze z równomiernym obciążeniem poszczególnych węzłów. Użytkownik nie
jest świadom, na którym z węzłów przetworzy się jego zapytanie, podobnie
jak nie jest świadom iż został „przełączony” do innego węzła
w przypadku awarii węzła, który dotychczas obsługiwał zapytanie. Na drugim
miejscu w charakterystyce klastra można wymienić skalowalność, czyli możliwość
łatwego przyłączania nowych węzłów do już istniejącego systemu. Ma to
zastosowanie w systemach przetwarzających duże ilości transakcji, gdzie
zachodzi konieczność uzyskania bardzo dużej dostępności systemu. RAC
wypiera rozwiązania składające się z niezależnych (i przełączanych w
przypadku awarii jednego z nich) serwerów. Gdyby rozwiązanie to oceniać w
kategoriach scentralizowania, należałoby stwierdzić, że pod względem
(permanentnego) przechowywania danych jest ono scentralizowane, natomiast pod
względem przetwarzania żądań jest ono zdecentralizowane.

Z formalnego punktu widzenia RAC, jest to oprogramowanie, które
działa na (do pewnego stopnia) niezależnych węzłach wchodzących w skład
„sprzętowego” klastra (rysunek 2). Aby węzeł był niezależny,
musi posiadać m. in. własny system operacyjny oraz instancję bazy danych.
Faktu posiadania własnej bazy danych nie należy mylić jednak z rozwiązaniem,
w którym niezależne byłyby również dane. Rozproszenie jest pojmowane tu w
nieco inny sposób, niż w klasycznych klastrowych systemach operacyjnych. Należy
zdać sobie sprawę z tego, iż dane nie są przetwarzane w miejscu gdzie są
permanentnie składowane. Tak więc wspólne dane są przetwarzane przez węzły
wchodzące w skład klastra. Sprawa wygląda dość prosto. Można więc zapytać
– co właściwie robi oprogramowanie wchodzące w skład rozwiązania RAC.
Aby odpowiedzieć na to pytanie, należy przyjrzeć się architekturze węzła,
a dokładniej strukturze oprogramowania „obsługującego” węzeł.
Strukturę tę przedstawiono to na rysunku 2.


Rys. 2. Struktura węzła

W skład oprogramowania obsługującego węzeł wchodzą:

  • Instancja bazy danych,
  • Oprogramowanie klastrowe (ang. Clusterware),
  • GCS czyli globalna usługa cache’u,
  • mechanizm kworum.

Instancja bazy danych wraz z GCS obsługuje żądania użytkowników.
Pamięć cache rozproszona po wszystkich węzłach pozwala na bardzo znaczne
ograniczenie operacji, które są wykonywane z udziałem pamięci masowej. Warto
tu wspomnieć, iż oprogramowanie Oracle pozwala na symulację zmian liczby
operacji wejścia/wyjścia dla różnych wielkości pamięci cache. Jest to
bardzo istotne dla szybkości działania systemu. O ile pamięć cache jest
szeroko stosowana w systemach operacyjnych i bazodanowych dla przyśpieszenia
operacji we/wy, o tyle nowatorskie jest to, iż GCS jest usługą globalną na
poziomie całego klastra. Mechanizm kworum wraz z oprogramowaniem klastrowym
odpowiada za obsługę sytuacji awaryjnych i ma zapewnić spójny widok systemu,
wydobycie z błędów itp. Pierwszy z mechanizmów służy do wykrywania awarii
na poziomie bazy danych, drugi zaś na poziomie sprzętu i systemu operacyjnego.
Tak więc obsługa sytuacji awaryjnych, to najistotniejsza rzecz, którą
„robi” RAC. Oczywiście część zadań związanych np. z
wykluczaniem węzłów jest realizowana przez system operacyjny, z którym współpracuje
oprogramowanie RAC.


Rys. 3. RAC w systemie rozproszonym

Na rysunku 3 przedstawiono RAC „wkomponowany” w
system rozproszony składający się z trzech węzłów. Wszystkie korzystają
ze wspólnej pamięci masowej, co jest niejako wpisane w oprogramowanie RAC. Jej
awaria skutkuje niestety awarią całego systemu. Jest to najsłabszy punkt całego
systemu, który został tak zaprojektowany, aby łatwo znosić awarie poszczególnych
węzłów.

Warto się nieco bardziej dokładnie zastanowić nad
mechanizmami służącymi do wykrywania i izolacji awarii. Platforma klastrowa (klastrowy
system operacyjny) jest w stanie wykryć i obsłużyć awarie węzłów na
poziomie sprzętu, czy systemu operacyjnego, odłączenie węzłów od reszty
klastra związane z transmisją w sieci itd. Nie jest jednak w stanie wykryć
awarii związanych z samą instancją bazy danych. Należy pamiętać, iż
poprawne działanie węzła i poprawna komunikacja z resztą węzła nie
gwarantują poprawnego działania bazy danych. Tak więc – powracając do
postawionego wcześniej pytania – można powiedzieć, iż głównym
zadaniem oprogramowania RAC jest współpraca z systemem operacyjnym w zakresie
wykrywania, izolacji i wydobycia z błędów w zakresie nie realizowanym przez
system. System klastrowy nie ma również możliwości przywrócenia prawidłowego
funkcjonowania bazy danych, więc musi być ono realizowane przez RAC.

Analizując rozwiązanie oferowane przez firmę Oracle można
zadać następne pytanie: co jest w nim nowatorskiego w porównaniu z klasyczną
architekturą ze współdzieloną pamięcią? Współpraca z tą pamięcią wiąże
się z dużym narzutem czasowym i może być wąskim gardłem systemu. Jeżeli
każdy węzeł ma osobną pamięć masową, to dla n węzłów i całkowitej
wielkości danych x (przy założeniu równomiernego rozłożenia danych na
poszczególnych węzłach), w pamięci masowej znajdują się dane o wielkości
x/n a operacje we/wy mogą odbywać się w wielu węzłach jednocześnie. W
prezentowanym rozwiązaniu z pamięcią współdzieloną, dane mają wielkość
x, są więc n razy większe. Ponadto wszystkie operacje we/wy muszą być obsługiwane
przez ten sam system pamięci masowej. Na marginesie tych rozważań warto
wspomnieć [za 1], iż we/wy traktowane jest po macoszemu przez projektantów
systemów. Szybkość operacji we/wy rośnie wolno w porównaniu do wzrostu
szybkości procesora. W systemach operacyjnych w celu przyśpieszenia operacji
we/wy, od dawna stosuje się pamięci typu cache. W prezentowanym rozwiązaniu
firmy Oracle również zastosowano rozwiązanie oparte o pamięć cache, tak aby
zmniejszyć do minimum współpracę z urządzeniami peryferyjnymi. Z tym oczywiście,
że rozwiązanie to jest dużo bardziej zaawansowane i skomplikowane od
powszechnie stosowanych w systemach operacyjnych. Problemy wynikające z
zastosowania architektury Shared Cache są w zasadzie tożsame z klasycznymi
problemami teoretycznymi w systemach rozproszonych z pamięcią współdzieloną.
Pamięć cache w systemie RAC jest rozproszona po wszystkich węzłach i stanowi
warstwę pośrednią przed pamięcią masową. Oczywiście, po głębszej
analizie problemu, można znaleźć bardzo istotną różnicę między
rozproszonym Cache’m a modelem systemu rozproszonego z pamięcią współdzieloną.
W modelu teoretycznym wszystkie dane znajdują się w pamięci systemu,
natomiast w modelu RAC, w pamięci cache znajduje się tylko część danych, które
są pobierane z pamięci masowej w zależności od potrzeb. Tak więc można
powiedzieć, iż dla całego rozwiązania najważniejsze i najbardziej
nowatorskie jest zastosowanie technologii Cache Fusion Architecture. Warto
jeszcze dodać [21], iż technologia ta pozwala na równoczesną edycję bloku
przez wiele instancji bez konieczności zapisu tego bloku na dysk przed edycją.

Przykłady użycia

W literaturze [3] przedstawiono zastosowania rozwiązania RAC
w firmie VeriSign Inc, oraz w samej firmie Oracle. W pierwszej z firm przed
zastosowaniem klastra używano dwóch węzłów – jednego aktywnego,
drugiego zapasowego, który był używany w momencie awarii pierwszego z węzłów.
Nie było to jednak idealne rozwiązanie, głównie ze względu na czas przełączania
oraz na to, że drugi z węzłów nie był wykorzystywany przez większość
czasu. Zastosowanie rozwiązania RAC eliminuje te wady – wykorzystywane są
wszystkie węzły. Nie jest też konieczne ich przełączanie. Co ważne,
zastosowanie rozwiązania RAC nie wymagało zmiany liczby węzłów w stosunku
do poprzednio stosowanego rozwiązania. Schematyczną architekturę
przedstawiono na rysunku 4.


Rys. 4. RAC w firmie VeriSign

Drugim przykładem jest poczta elektroniczna w firmie Oracle.
Zatrudnia ona ponad pięćdziesiąt tysięcy osób na całym świecie. Poczta
musi więc działać przez całą dobę. Wymagany czas dostępu [3] wynosi 3
sekundy a średni czas wydobycia z błędu wynosi 2 minuty. Zcentralizowanie usługi
poczty pozwoliło na prawie dziesięciokrotne zmniejszenie liczby serwerów,
24-krotne zmniejszenie liczby baz danych, ujednolicenie adresów użytkowników
itd. Bazy danych stanowiące repozytorium poczty są połączone do klastra składającego
się z dwóch węzłów. Pomiędzy tym klastrem a użytkownikami końcowymi
znajduje się jeszcze warstwa pośrednia. W artykule [3] położono nacisk na
bardzo duże ilości danych przetwarzane w takim systemie pocztowym jak również
na krótkie czasy odpowiedzi na żądanie i wydobycia z błędu. Również tu
zastosowano niewielki, bo dwuwęzłowy klaster z pięcioma urządzeniami pamięci
masowej i osobną warstwą pośrednią zarówno dla protokołu SMTP jak i osobną
dla IMAP.

Warto jeszcze raz podkreślić, że zastosowane klastry są
bardzo niewielkie. Można w tym miejscu zadać dwa pytania. Pierwsze: czy i
gdzie potrzebne są duże klastry, drugie: czy rozwiązanie jest rzeczywiście
skalowalne przy dużej liczbie węzłów. Przy klasycznym przetwarzaniu równoległym
stosuje się klastry o większych rozmiarach. Jednak nie można automatycznie
odnieść problemu sortowania liczb od obsługi systemu bazodanowego. Odpowiadając
na oba pytania można powiedzieć, że celowe jest przeprowadzenie dalszych badań
nad skalowalnością dla większej liczby węzłów.

Właściwości

Chcąc dokonać oceny rozwiązania, należy odnieść jego
istotę do problemów teoretycznych a następnie porównać z podobnymi rozwiązaniami
oferowanymi przez innych producentów. Odnosząc rozwiązanie do teorii trzeba
nadmienić, iż wszystkie rozwiązania z współdzieloną pamięcią masową są
bardzo czułe na awarie tej ostatniej. Jest rzeczą oczywistą, że każdy
producent ukazuje pozytywne cechy oferowanego przez siebie rozwiązania. W
literaturze rozwiązanie firmy Oracle porównywane jest często do bazy danych
DB2 firmy IBM oraz do bazy danych SQL Server firmy Microsoft. Porównanie tych
rozwiązań zostało przedstawione w tabeli 1, trzeba mieć jednak świadomość,
iż nie wszystkie kategorie dotyczą wszystkich rozwiązań.

Tabela 1. Porównanie rozwiązań

  RAC IBM DB2 MS SQL Server
Architektura Z pamięcią współdzieloną Z niezależnym pamięciami Zupełnie niezależne bazy danych
Platformy Różne Różne Windows
Wymaga ręcznego podziału danych pomiędzy węzły Nie Tak Tak
Awaria węzła skutkuje: Pewne obniżenie wydajności systemu Dane są dostępne ale są problemy z równoważeniem obciążeń Nie dostępnością danych na tym węźle.
Skalowalność Wg. producenta duża Szybko rośnie liczba partycji Nie dotyczy bo osobne bazy danych
Przezroczystość lokacji danych Tak Nie Nie
Średni czas wydobycia Można ustawić Nie można ustawić  
Przywrócenie do pracy Szybkie Wymaga wycofania wszystkich transakcji  
Wady Szybko rośnie ruch w sieci związany z utrzymaniem pamięci cache przy
zwiększaniu się liczby węzłów
Konieczność podziału danych pomiędzy pod-bazy i szybko rosnąca
liczba partycji przy zwiększaniu liczby węzłów
Całkowicie niezależne bazy danych ze wszystkimi tego konsekwencjami
Modyfikacja zapytań Nie Tak Tak
Odzyskiwanie bloków danych w bardzo dużych bazach danych Tak Nie  
Zaawansowane narzędzia do tworzenia backup’ów Tak Nie  
Zaawansowane metody podziału (partycjonowania) danych Tak Nie  
Zaawansowane mechanizmy ochrony danych Oracle Data Guard Nie  
Dodanie nowego węzła Proste Wymaga partycjonowania danych  
Operacje wykonywane on-line Dużo (modyfikacje samej bazy, danych, indeksów itd.) Mało – defragmentacja indeksu  
Dynamiczne dodawania pamięci współdzielonej – cache Tak Nie  
Przykładowy czas wydobycia bazy o wielkości 400 Gb 17 sekund Mniej niż 10 minut  

 

Baza DB2 jest zbudowana w architekturze, w której każdy z węzłów
ma swoją własną pamięć masową – czyli swój „własny kawałek”
bazy danych. Oczywiście, ze względu na dostępność do danych, w rzeczywistości
każde urządzenie pamięci masowej musi być podłączone więcej niż do
jednego węzła – tak aby jego awaria nie skutkowała całkowitą niedostępnością
danych. Rozwiązanie takie schematycznie przedstawiono na rysunku 5.


Rys. 5. Schematyczna architektura DB2 IBM

Jeśli chodzi o rozwiązanie firmy Microsoft, to bazy danych
są zupełnie niezależne, co nie jest oczywiście architekturą klastrową.
Analizując podstawowe, poza architekturą, różnice trzeba powiedzieć, że
RAC nie wymaga ręcznego podziału danych pomiędzy węzły tak jak np. MS SQL
czy DB2. Podobnie nie wymaga modyfikowania zapytań przesyłanych do bazy.
Zapytania kierowane do bazy DB2 są obsługiwane znacznie szybciej gdy w
klauzuli where określi się gdzie „są” dane.

W literaturze [16] można znaleźć krytyczne uwagi dotyczące
prezentowanego rozwiązania. Wymienia się tam konieczność instalowania
oprogramowania RAC oddzielnie na każdym z węzłów – co dla czterech węzłów
trwa około dwóch dni roboczych. Ponadto zwraca się uwagę na to, iż przy
wzroście liczby węzłów wykładniczo wzrasta ruch w sieci związany z
utrzymaniem spójności pamięci cache. Oczywiście zarzut długiej instalacji
staje się znaczący dopiero przy dużej liczbie węzłów – w
praktycznych rozwiązaniach, które są opisywane w dokumentacji wystarczały
dwa węzły.

Dalsze porównania rozwiązania firmy Oracle z bazą danych
DB2 firmy IBM [5] wskazują na to, iż rozwiązania mają podobne wymagania sprzętowe
i programowe (w zakresie systemu operacyjnego, a mówiąc ściśle – podobny jest wachlarz obsługiwanych systemów operacyjnych), różnią się
jednak znacznie, jeśli chodzi o możliwości skalowalności i bezpieczeństwo
danych. Ponadto, wraz z systemem RAC dostarczany jest program do zarządzania
klastrem komputerów, co umożliwia pokonanie niektórych ograniczeń (np. w
liczbie węzłów), nakładanych przez system operacyjny. RAC jest [wg 5] łatwo
skalowalny, z tym że trzeba pamiętać o jego czasie instalacji na wszystkich węzłach
oraz wykładniczo zwiększającej się liczbie przesyłanych pomiędzy węzłami
komunikatów. Jeśli chodzi o testy wydajności (benchmarki), to w różnych
testach widać różne wyniki. Warto pamiętać, że wyniki takich testów są
silnie powiązane ze specyfiką danych. Istnieją dane przemawiające za rozwiązaniem
RAC ale istnieją również dane pokazujące, iż jego zastosowanie nie poprawia
wyników w porównaniu do tych, osiąganych z użyciem pojedynczego węzła.
Oczywiście dokonując porównań nie sposób nie przedstawić porównania
samych baz danych. W pracy [18] porównano rozwiązania obu firm pod względem
dostępności wskazując jednocześnie na bardzo wysokie koszty niedostępności
systemu (1 minuta w granicach 2500-10000 dolarów). W systemie Oracle można
ustawić parametr określający średni czas wydobycia. System
szacuje i utrzymuje aktualną wartość tego czasu tak, aby spełnić wymagania
użytkownika określone powyższym parametrem. W rozwiązaniu firmy IBM nie ma
takiej możliwości. Również w tejże pracy podano, iż czas wydobycia bazy
danych Oracle o wielkości 400Gb z 2000 użytkowników wykonujących 300
transakcji na sekundę wynosi 17 sekund. Podobny czas w rozwiązaniu IBM wg tej
samej pracy wynosi mniej niż 10 minut. Jest on jednak uzyskany z dokumentacji,
a nie doświadczalnie. Bardziej przekonywające, zdaniem autora, byłoby porównanie
danych doświadczalnych dla obu baz. W bazie DB2 czas wydobycia z błędu jest
zależny do najdłuższej transakcji, która musi być wycofana. W rozwiązaniu
Oracle użytkownicy nie muszą czekać aż wszystkie transakcje zostaną
wycofane. Również czas potrzebny do odzyskania pełnej sprawności przez bazę
Oracle jest krótszy niż w DB2. Rozwiązanie firmy Oracle oferuje również
bardziej zaawansowane możliwości tworzenia backupów. Obie bazy zapewniają
partycjonowanie danych (podział tabel na mniejsze jednostki) ale tylko baza
Oracle zapewnia użytkownikowi możliwość określania, gdzie jakie dane będą
umieszczane.

W cytowanym artykule porównano również rozwiązania
„klastrowe” obu firm. Z porównań tych wynika, iż RAC szybciej
wydobywa się z błędu. Jest to związane m. in. z tym, że zadania obsługiwane
przez węzeł, który właśnie przestał działać, są równomiernie
rozdzielane pomiędzy sprawne węzły. W rozwiązaniu IBM, ze względu na
odmienną architekturę (rys. 5) przejęcie zadań znacznie się komplikuje.
Trzeba też pamiętać, iż dyski dzieli się na liczbę partycji będącą
najmniejszą wspólną wielokrotnością liczby węzłów – tak aby możliwe
było zrównoważenie obciążeń w przypadku awarii węzłów. Łatwo z tego
wywnioskować, iż liczba partycji wzrasta bardzo szybko wraz ze wzrostem liczby
węzłów. Również koszt zapytań [18] nie uwzględniających podziału na
partycje jest wielokrotnie wyższy, niż zapytań do bazy bez takiego podziału.
W DB2 zapytania nie uwzględniające podziału na partycje muszą być rozgłaszane
do wszystkich węzłów.

Dodanie nowych węzłów w systemie DB2 wymaga zamknięcia i
ponownego uruchomienia wszystkich węzłów; podobnie nie jest możliwe w tym
systemie [18] dynamiczne dodawanie pamięci.

Podsumowanie

Celem niniejszego artykułu nie jest wydanie kategorycznego
osądu na temat prezentowanej technologii, ale ukazanie jej specyfiki i możliwości
zastosowania. Prezentowane rozwiązanie jest ciekawe i będzie z dużym
prawdopodobieństwem ewoluowało. Jak się wydaje, zmiany mogą dotyczyć
algorytmów przydziału zadań lub uproszczenia instalacji (linux). Potwierdzać
to mogą wyniki zaprezentowane w pracy [16]. Wynika z nich, iż pierwszy węzeł
przetwarzał dwa razy więcej zadań niż każdy z pozostałych węzłów
(osobno) dla klastra składającego się z czterech węzłów. Trzeba jednak
pamiętać, że projektowanie algorytmów służących do równoważenia obciążeń
jest zadaniem trudnym. Często ich skuteczność zależy od specyfiki zadań. Dość
trudno jest polemizować z danymi uzyskanymi doświadczalnie. Można natomiast
odnieść się do zarzutu o bardzo szybko wzrastającej liczbie komunikatów
przy zwiększaniu liczby węzłów. Odpowiedź jest prosta: „coś za coś”.
Albo stosuje się pamięć cache (tak jak w RAC) i godzi się na to, że trzeba
ją utrzymywać w spójnym stanie, albo godzi się na kosztowne czasowo operacje
we/wy. Podchodząc do sprawy zdroworozsądkowo należy pamiętać, że przy
pewnej ilości węzłów musi istnieć granica opłacalności zastosowania rozwiązania
z pamięcią cache. Wystąpi ona w momencie, gdy nakład na komunikację przewyższy
korzyści związane z redukcją operacji we/wy. Wybierając system bazy danych
(jak również każdą inną technologię) należy najpierw zadać sobie pytanie
– do czego ten system ma służyć. Z kolei w pracy [20] przedstawiono
wyniki przedstawiające prawie liniową, a więc bardzo dobrą skalowalność
dla liczby przetwarzanych transakcji. Dla podanej poniżej konfiguracji, jeden węzeł
był w stanie obsłużyć 33000 transakcji na minutę, dwa węzły 66000, trzy węzły
98000, cztery węzły natomiast mogły obsłużyć 128000 transakcji na minutę.

Badania przeprowadzono w architekturze trójwarstwowej:

  1. Prezentacja wyników – 4 komputery Intel Pentium 4 zegar 1.7 Ghz
  2. Warstwa generowania obciążeń – 7 komputerów z procesorem Pentium 3 zegar 1 Ghz
  3. Warstwa bazy danych – RAC 4 komputery Pentium 3 Xeon zegar 700 Mhz 2 Mb cache i 4 Gb RAM

Jako pamięci masowej używano urządzenia EMC Clarion FC4700
z 1.6 Tb. Stworzenie indeksu na tabeli z 4 miliardami wierszy trwało dla 3 węzłów
nieco ponad 2 godziny, podczas gdy dla jednego węzła od 4.5 do 6 godzin.

Analizując wyniki z prac [16] i [20] nie można
jednoznacznie stwierdzić, czy potrzebna jest skalowalność w granicach setek węzłów,
czy może bardziej istotny jest czas obsługi zadań. W pracy [16] stwierdzono również,
że cztery węzły przetwarzały zadania w praktycznie takim samym czasie jak
jeden. Może to świadczyć, iż owa skalowalność nie zawsze „działa”
poprawnie. Można jednak zapytać, czy dane doświadczalne pozwalały na
ukazanie korzyści z zastosowania RAC’a? Można potencjalnie wyobrazić
sobie, że zmierzono czas sortowania 100 liczb przy użyciu jednego i czterech węzłów
przy użyciu algorytmu sortowania kubełkowego (co nie ma związku z systemem
RAC ale dobrze pokazuje problem doboru danych). Zysk dla zastosowania 4 maszyn będzie
praktycznie żaden, a czas wykonania zadania może się nawet wydłużyć ze
względu na czasy przesłania. Analizując wszelkiego rodzaju wyniki należy być
ostrożnym i zawsze brać pod uwagę, jakie dane zostały użyte do testów.
Ponadto punktem wyjścia do oceny każdego rozwiązania powinno być zrozumienie
założeń, na której się ono opiera. Baza danych firmy Oracle ma dużo
bardziej zaawansowane rozwiązania zapewniające bezpieczeństwo danych. Wiele
czynności można w niej wykonać online, co ma duży wpływ na dostępność
systemu. Trzeba też pamiętać, iż zagadnienie podziału zadań pomiędzy
przetwarzające je węzły jest na czasie i stało się tematem wielu poważnych
prac naukowych, jakkolwiek nie jest to dziedzina ściśle powiązana z bazami
danych. Można również wspomnieć, że chociaż podstawowe architektury w
systemach klastrowch pozostają bez zmian, o użyciu konkretnej z nich decydują
charakterystyki urządzeń pamięci masowej. Warto również zauważyć fakt, że
choć RAC w większości współpracuje z niesformatowanymi urządzeniami pamięci
masowej (Raw devices), to pojawił się już klastrowy system plików dla RAC
dla systemu Windows NT oraz Windows 2000. Nazywa się on CFC i ma zapewnić np.
to, iż wszystkie węzły będą miały wspólny katalog home, co
uprości instalację. CFC ma również uprościć administrację systemem. Jeśli
klastrowy system plików będzie dostępny dla wszystkich platform, upadnie
zarzut dotyczący długotrwałej instalacji.

Literatura

  • [1] Computer Architecture, A Quantitative Approach J. L. Hennessy, D.A. Patterson Morgan Kaufmann Publishers, Inc. San Francisco, California1996
  • [2] Fundamentals of Distributed Memory Computing www.tc.cornell.edu/Services/Edu/Topics/DistMemProg/
  • [3] Building Highly Available Database Servers using Oracle Real Application Clusters, An Oracle White Paper, May 2001
  • [4] Managing Oracle Real Application Clusters, An Oracle White Paper, January 2002
  • [5] Technical Comparsion of Oracle9i Real Application Clusters vs. IBM DB2 UDB v7.2, An Oracle White Paper, February 2002
  • [6] Oracle9i Real Application Clusters Cache Fusion Delivers Scalability, An Oracle White Paper, May 2001
  • [7] TruCluster Server Cluster Technical Overview June 2001, Compaq Computer Corporation Houston, Texas
  • [8] Continuos Data Availability with Oracle9i Database, An Oracle White Paper, May 2001
  • [9] Database Architecture Federated vs. Clustered, An Oracle White Paper, Fabruary 2002
  • [10] Compaq Cluster Management Utility Feature, January 2000
  • [11] Clustered Database Platform 280/3 na: www.sun.com
  • [12] Cluster Platforms na: www.sun.com
  • [13] Running E-Business Aplications on Oracle 9i Real Application Clusters, B. Kehoe, Oracle [14] IBM DB2 Version 7.2 – software announcement April 2001
  • [15] Demonstrating Scalability with Oracle9i Real Application Clusters Running on Compaq Tru64 UNIX TruCluster Server Systems.
  • [16] M. Bar, Oracle RAC on Linux BYTE.com
  • [17] M. Halls, Migrating 8i Single Instance for 9i RAC, Notes for Linux Cluster
  • [18] Technical Comparison of Oracle 9i Database vs. IBM DB2 UDB: Focus on High Availability, An Oracle White Paper, February 2002
  • [19] Installing and Configuring the Oracle9i Real Application Clusters Database
  • [20] Oracle 9i RAC Performance on Intel Architecture http://developer.intel.ru/download/eBusiness/pdf/oracle_perf.pdf
  • [21] M. Chynoweth, S Keesara Oracle9i Real Application Clusters (RAC) on Intel Architecture Fast Track to Oracle9i http://www.intel.com/ebusiness/pdf/affiliates/oracle4.pdf
  • [22] Oracle Real Application Clusters, Cluster File System, Release Notes, August 2002