Oracle on Linux – dlaczego tak późno?

Ewa Palarczyk
ewa.palarczyk@mp.pl

Linux wkracza na pole walki

Milowym krokiem w rozwoju Linuksa jako platformy dla rozwiązań
biznesowych był listopad 1998 roku, kiedy na rynku pojawiły się wersje Oracle
8 i serwer aplikacji Oracle dla Linuksa. Krok ten przyczynił się do
postrzegania Linuksa nie jedynie jako swoistej alternatywy dla Windows, czy płatnych
Uniksów, produktu w pewnym sensie niszowego, dla zapaleńców, ale jako w pełni
stabilnego, wydajnego i dojrzałego systemu operacyjnego. Przez długi czas
Linux kojarzony był z oszczędnością środków finansowych, a więc z
sektorem małych i średnich przedsiębiorstw. Paradoks sytuacji polegał na
tym, że Linux wymaga specjalistycznej wiedzy, której małe firmy zwykle nie
mają. Z drugiej strony, w małych sieciach równie dobrze można poradzić
sobie korzystając z oprogramowania bardziej intuicyjnego i przyjaznego dla użytkownika,
jakim jest Windows. Linux nie jest systemem prostym w użytkowaniu, a zwłaszcza
w administracji. Praca z Linuksem wymaga doskonałej znajomości systemu, jako
że to administrator gwarantuje bezpieczeństwo systemu – system zainstalowany
z płyty nie jest w zasadzie w żaden sposób zabezpieczony. Dopiero bardzo
dobra znajomość działania Linuksa pozwala postępować z nim w jakiś sposób
intuicyjnie. Zatem segment MSP nie był najlepszym rynkiem dla systemów
linuksowych – niewielkie firmy rzadko mogą pozwolić sobie na zatrudnienie i
szkolenie wysokiej klasy specjalistów. Wprawdzie kolejne wersje wielu
dystrybucji Linuksa stają się coraz bardziej przyjazne dla użytkownika, nadal
jednak zaawansowana praca z systemem jest znacznie trudniejsza od pracy z
systemami Windows, które zajmują silną pozycję w tym segmencie.

Ostatnie miesiące pokazują, że sytuacja rynkowa Linuksa
ulega zmianie. Z jednej strony zainteresowanie Linuksem wykazywane przez Oracle
i potentatów branży informatycznej sprawiło, że system ten intensywnie
rozwija się w kręgach „dużego” biznesu. Z drugiej strony, zwiększa się
zainteresowanie tym systemem w administracji państwowej wielu krajów (niestety
Polska się do nich nie zalicza), dla przykładu wymienić można Norwegię,
Niemcy, Wielką Brytanię a nawet Pakistan. Rosnąca popularność Linuksa w kręgach
państwowych powodowana jest najczęściej obawą przed lukami bezpieczeństwa w
systemach Windows, zwłaszcza, jeśli chodzi o dziedziny kluczowe dla gospodarki
czy bezpieczeństwo państwa. Co więcej, stosowanie otwartych systemów
operacyjnych, takich jak Linux, w administracji, jest zgodne z zaleceniami
unijnego programu rozwoju e-Europe. Przykładowo, rząd niemiecki, podejmując
decyzję o wdrożeniu systemów linuksowych, wyraził nadzieję, iż posunięcie
to pozwoli zredukować uzależnienie administracji od firmy Microsoft oraz
utrudni ataki hackerów. Są to dwa zasadnicze powody niechęci do Windows: z
jednej strony powszechne wątpliwości, co do bezpieczeństwa systemu, z
drugiej, poczucie rosnącego uzależnienia użytkownika od producenta, potęgowane
przez ciągle nowe pomysły Microsoft’u na przywiązanie użytkownika do
systemu, często bez jego woli i wiedzy.

Nowy, dojrzały Linux

Prawdziwy boom dla pracy aplikacji Oracle na systemie
linuksowym miał miejsce dopiero w tym roku. Można by sobie zadać pytanie (tym
razem w aspekcie stricte technicznym), dlaczego dopiero teraz?

Wydaje się to uzasadnione czynnikami związanymi z
niedostosowaniem Oracle i Linuksa do wspólnej pracy. W niniejszym artykule
postaram się omówić „braki” po obu stronach oraz pokazać rozwiązania,
które wreszcie umożliwiają wydajną i bezawaryjną pracę Oracle na
platformie linuksowej. Po pierwsze, dopiero teraz Linux stał się systemem
naprawdę stabilnym i dojrzałym (jądra 2.2.x i 2.4.x). Wcześniejsze wersje jądra
nie wspierały pracy wielu urządzeń, czy rozwiązań technologicznych. Trudna
w realizacji była implementacja rozwiązań klastrowych, które odgrywają
istotne znaczenie w przypadku dużych baz Oracle.

Istotna okazała się tu współpraca programistów Oracle i
Red Hat, która zaowocowała tym, że w jądrze serii 2.4.x znajdziemy wsparcie
między innymi dla Oracle Real Application Clusters, co zapewnia taką wydajność
bazy pracującej na Linuksie, jak na każdym innym dotychczas wykorzystywanym
systemie operacyjnym. Wydaje się, że tak dynamiczne wkroczenie Oracle na rynek
linuksowy, a Linuksa na rynek „dużego” biznesu, nie byłoby możliwe bez
współpracy z producentem jednej z najbardziej popularnych dystrybucji. Jest to
posunięcie tym bardziej skuteczne, że Red Hat rozpoczął również kooperację
z IBM, dzięki czemu Linux bezproblemowo powinien pracować na dużych serwerach
typu Big Blue. Dotychczas Red Hat Linux wspierał jedynie serwery serii xSeries
(platforma Intel), teraz dołączą do tego high-endowe pSeries, iSeries i
zSeries. Ten krok świadczy nieodwołalnie o wchodzeniu Red Hata, a przede
wszystkim Linuksa w świat największych rozwiązań e-biznesowych.

Jednocześnie wraz z wprowadzeniem 64-bitowych systemów typu
Itanium, Linux stał się systemem o wiele bardziej wydajnym i skalowalnym na
platformie Intel’a. Oracle wprowadzał wersje deweloperskie oprogramowania
bazodanowego na IA-64 począwszy, od Oracle8i wydanie 8.1.7. Komercyjne wydanie
Oracle9iR2 na IA-64 zbiega się w zakresie dostępności z systemami opartymi na
serwerach dwuprocesorowych Itanium Intel’a. Oracle na IA-64 może skalować
dla większej liczby użytkowników, wspierać większą alokację SGA i
dostarczać większe możliwości procesora i systemu I/O, niż baza na
systemach 32-bitowych. Patrząc na bliską współpracę Oracle, Red Hat i
innych partnerów, należy się spodziewać w niedalekiej przyszłości licznych
usprawnień i kolejnych rozwiązań RH Advanced Server na IA-64, które są
typowe dla Itanium 2 Intel’a. A co za tym idzie, należy tu oczekiwać
dalszego intensywnego rozwoju Oracle na Linuksie. Jednocześnie należy zauważyć,
że Red Hat nie jest jedynym twórcą dystrybucji Linuksa, z którym współpracuje
Oracle, choć akurat ta współpraca wydaje się najbardziej intensywna. Obok
Red Hat znajdują się tu bowiem jeszcze SuSE (zwłaszcza wersja 7.2 i SuSE
Linux Enterprise Server) oraz Caldera – Caldera OpenUnix 8.

Nowy kernel, nowe możliwości

Co ma przekonać decydentów i administratorów baz danych do
tego, że warto „przesiąść się” na Linuksa? Wśród korzyści instalacji
bazy danych na Linuksie, oprócz znacznie niższego kosztu wdrożenia, wymienić
należy znacznie niższe koszty sprzętu (sam Linux to, w przeciwieństwie do
Windows, system mało wymagający sprzętowo) i utrzymania, a także coraz większą
prostotę korzystania. Na wydajność i stabilność systemu wpływa przede
wszystkim jądro systemowe. To od wersji kernela, a później jego ustawień
zależy, czy dana technologia będzie wspierana i w jaki sposób. Jądra serii
2.4.x zostały wzbogacone w liczne rozwiązania, które między innymi znacznie
polepszają obsługę wielu technologii. Jakie nowości niesie kolejna wersja jądra?
Kernel 2.4.x, oprócz wsparcia dla Real Application Clusters, rozbudowany został
w podsystemie asynchronicznego I/O, co pozwoliło na eliminację wielokrotnego
kopiowania do buforów pamięci podczas zapisu danych na dysk. Istotne znaczenie
miała praca nad sterownikiem Firewire, który umożliwia współdzielenie urządzeń
dyskowych. Jest to pomocne przy testowaniu aplikacji klastrowych, czy
sprawdzeniu zaawansowanych możliwości technologii Real Application Clusters.
Opracowano sterownik Firewire, który umożliwia zdalne debugowanie jądra,
usunięto błędy w szynie Firewire. Do jądra mogą być dołączone łaty
Watchdog, którego funkcjonalność ma istotne znaczenie w przypadku klastra
Oracle. W sytuacji, gdy węzeł klastra ze współdzielonym dyskiem wypadnie z
synchronizacji, Watchdog automatycznie wyłącza węzeł, zanim dojdzie do
uszkodzenia dysku. Jako alternatywę dla łaty Watchdog, można zastosować I/O
Fence. Jego działanie polega na zapobieganiu sytuacji, w której pozostawione
do zapisu dane w uszkodzonych bazach otrzymują dostęp do pamięci po rozpoczęciu
odzysku, co może zniszczyć spójność przechowywanych danych. Sytuacja ma
miejsce, gdy funkcja klastrów została uszkodzona w węzłach, ale węzły ciągle
pracują na poziomie systemu operacyjnego. Z punktu widzenia prawidłowego działania
systemu klastrowego, istotne znaczenie ma również naprawa uszkodzonej karty
sieciowej, co użytkownik może skonfigurować poprzez NIC failover.

Bardzo istotne wydają się prace nad klastrowym systemem
plików dla Linuksa, który oparty został o projekt takiego systemu dla Windows
NT. Znacznie ułatwia to administrowanie klastrową bazą danych, jako że łatwiej
pracuje się z takim systemem plików, niż z raw devices (urządzenia
niesformatowane, bez systemu plików).

Dla rozbudowy systemu i stałego zwiększania jego
funkcjonalności, bardzo duże znaczenie odgrywają biblioteki systemowe. Dla
wspomnianego przeze mnie podsystemu asynchronicznego I/O, niezbędna jest
biblioteka Libaio, umożliwiająca nowe wywołania systemowe AIO (asynchroniczne
I/O) dla jądra Linuksa. Biblioteka jest opakowaniem odpowiadającym Single Unix
Specification w zakresie funkcji aio_read, aio_write, aio_error, aio_return oraz
aio_suspend i implementacji lio_listio i aio_reap dla przetwarzania wsadowego.
Biblioteka wymaga wspomnianej łaty AIO na jądro systemu.

Dla deweloperów pomocnym narzędziem jest Rasta, będąca
strukturą służącą opisywaniu zadań na systemie komputerowym. Rasta ułatwia
tworzenie kreatorów i programów dialogowych z użytkownikiem takich, jak
instalacja czy konfiguracja produktu. Dla utworzenia kreatora lub dialogu,
deweloper opisuje zadanie w plikach XML, a następnie biblioteka Rasta parsuje
te pliki XML i przekazuje do interfejsu klienta, który udostępnia go użytkownikowi.
Kolejną biblioteką jest Timbo, będąca katalogiem wiadomości, co znacznie ułatwia
tworzenie naturalnie brzmiących plików źródłowych, wykorzystywanych do
internacjonalizacji. Timbo zbudowane jest jako prosta haszowana baza danych
indeksów wiadomości. Istotną rolę odgrywa również Userfs z GnomeVFS, będący
systemem plików, który pracuje częściowo w przestrzeni użytkownika i może
być powiązany z GnomeVFS. Ponieważ Userfs trzyma właściwy kod systemu plików
w przestrzeni użytkownika, deweloper może znacznie łatwiej tworzyć lub
rozszerzać systemy plików, niż wtedy gdy są one wbudowane w jądro. Powiązanie
z GnomeVFS sprawia, że dostęp do różnych rodzajów lokalnych i zdalnych
systemów plików np. ftp lub webdav, staje się przezroczysty dla użytkownika
i dewelopera.

Dla optymalizacji wydajności ma również znaczenie
harmonogram procesów, czyli innymi słowy kontrola dostępu procesów do
procesora. W Advanced Server zastosowano nowe rozwiązania do szeregowania
procesów, w których zlikwidowano niedostatki poprzednich. Naprawiono między
innymi algorytm tworzenia harmonogramu, umożliwiono tworzenie harmonogramu równolegle
dla oddzielnych procesorów.

Do nowych funkcjonalności mających zwiększyć walory użytkowe
produktów Oracle na Linuksie należy między innymi narzędzie lsraid, pomagające
zarządzaniu pamięcią programowego RAID. lsraid służy do odpytywania
linuksowych urządzeń md. Może opisać złożone urządzenie oraz urządzenia
blokowe, które do niego należą. Może również dostarczyć opis urządzenia md
odpowiedni do umieszczenia w pliku konfiguracyjnym /etc/raidtab. lsraid może
współpracować z urządzeniami będącymi online i offline. Może odczytywać
informacje o urządzeniu będącym online poprzez interfejs jądra i dostarczać
o nim informacje. Jeśli natomiast urządzenie jest offline, lsraid patrzy na
urządzenia blokowe będące częścią urządzenia md i odczytuje trwałą
informację zawartą w superbloku md.

Kolejną nowością zawartą w Advanced Server jest
funkcjonalność konsoli sieciowej, która zapisuje wszystkie wiadomości jądra,
w tym linuksowe wiadomości o awariach systemu, do centralnego serwera poprzez
sieć. Narzędzie netdump dostarcza scentralizowaną i złożoną perspektywę
systemu i logów jądra, co pozwala na znacznie szybszą reakcję na pojawiające
się problemy.

Klastry, RAC i Red Hat Advanced Server

Istotną przeszkodą w pracy Oracle na platformie linuksowej
było zagadnienie funkcjonowania systemu klastrów. Wspominałam o
rozszerzeniach jądra Linuksa, które umożliwiają pracę Oracle w trybie
klastrów; przy okazji należałoby krótko wyjaśnić samo pojęcie klastra. Otóż
klaster jest grupą niezależnych serwerów, które pracują jako pojedynczy
system. Podstawowe komponenty klastra obejmują węzły procesorowe, połączenia
wewnętrzne oraz podsystem współdzielonych dysków. Klastry współdzielą
dostęp do dysków i zasobów, zarządzają danymi, ale odrębne sprzętowo węzły
nie współdzielą pamięci. Klaster może być zbudowany z wielu pojedynczych
procesorów, co jest znane powszechnie jako Symmetric Multi-Processor lub węzeł
SMP. W takim wariancie każdy węzeł posiada własną dedykowaną pamięć
systemową, podobnie jak własny system operacyjny, instancję bazy danych i
oprogramowanie aplikacji. Wśród najczęściej spotykanych architektur
klastrowych wymienić można klastry o wspólnych dyskach i klastry typu shared
nothing
. Do zalet klastrów należą: zwiększona odporność na awarie,
wzrost systemu, który następuje przez przyrosty modularne, wysoka dostępność
dla użytkownika, wolne komponenty programowe, takie jak dodatkowe węzły, połączenia
wewnętrzne i dyski. Dzięki temu unika się pojedynczych punktów awarii, a
system staje się wobec ewentualnych uszkodzeń bardziej elastyczny.

Obok architektury sprzętowej klastrów występuje również
architektura klastrowa baz danych. Wśród architektury klastrowej baz danych
wyróżnić można współdzielenie dysków, dzielenie danych na segmenty
przyporządkowane pamięciom dyskowym poszczególnych procesorów (shared
nothing
) oraz federację baz danych. Pierwsze podejście opiera się na założeniu,
że każdy przetwarzający węzeł ma jednakowy dostęp do dysków (danych).
Drugie podejście zakłada, że pliki bazy danych są partycjonowane/dzielone między
instancje pracujące na różnych węzłach systemu wielokomputerowego. Każda
instancja lub węzeł związany jest z określonym zestawem danych, a cały dostęp
do tych danych realizowany jest wyłącznie poprzez daną instancję (węzeł).
Trzecie podejście do klastrowej architektury baz danych nie jest bazą klastrową
w pełnym tego słowa znaczeniu. Taka baza składa się z wielu pojedynczych węzłów
serwerów bazodanowych, gdzie każdy węzeł uruchamia oddzielną bazę danych,
każdy z własnym słownikiem bazodanowym.

Architektura Real Application Clusters (RAC) prezentowana
przez Oracle, różni się od powyższych. Realizowana jest poprzez Oracle Cache
Fusion, czyli mechanizm współdzielenia buforów. Architektura ta łączy korzyści
współdzielenia dysków i baz danych typu shared nothing, unikając
jednocześnie ich wad. Dzieje się tak dzięki wykorzystaniu pamięci dyskowej i
technologii komunikacji wewnętrznej. Oracle RAC ma rozszerzać możliwości
wcześniejszego Parallel Server w zakresie skalowalności i wysokiej dostępności.
Zaimplementowany w Real Application Clusters Cache Fusion gwarantuje spójność
pamięci cache między wieloma węzłami klastra (osobne Linuksy pracujące na
oddzielnych maszynach o podobnie skonfigurowanych instancjach RAC), mającymi
dostęp do tych samych baz danych, bez ponoszenia wysokich kosztów I/O. W
przypadku użytkowników Linuksa istotna jest tutaj uwaga, że do podobnej pracy
nie można wykorzystać systemu plików NFS lub podobnych mu systemów plików
sieciowych, ponieważ systemy te nie gwarantują spójnego mechanizmu blokowania
dostępu, a ich protokoły nie dostarczają spójności buforów. Technologia
Cache Fusion została od podstaw zaprojektowana do realizacji takich zadań,
podobnie jak system plików openMosix. Obok skalowalności i wysokiej dostępności,
Oracle Real Application Clusters w połączeniu z Cache Fusion, ma zapewnić
administratorowi łatwość zarządzania – obraz systemu jest przechowywany w
klastrze co oznacza, że administrator dokonuje czynności instalacji,
konfiguracji, tworzenia kopii zapasowych, aktualizacji i monitoringu tylko raz.
Czynności te są następnie automatycznie przekazywane do odpowiednich węzłów.
Oprócz tego istotne znaczenie ma automatyczne wykrywanie dostępnych węzłów
i równoważenie obciążenia dla bardziej wydajnego wykorzystania węzłów RAC
– Oracle automatycznie równoważy obciążenie użytkowników pomiędzy węzłami
klastra. Instancje bazy RAC na różnych węzłach „zapisują się” do
wszystkich lub niektórych usług bazy danych. Dzięki temu administrator może
określić, czy dana aplikacja kliencka łącząca się z określoną usługą
bazy, może łączyć się ze wszystkimi, czy też wybranymi węzłami klastra.
Aplikacja kliencka łączy się na poziomie logicznym nazwy usługi bazodanowej.
Architektura Cache Fusion natychmiast wykorzystuje zasoby procesora i pamięci
nowego węzła. Administrator nie musi ręcznie ponownie partycjonować danych.
Real Application Clusters potrafi dynamicznie realokować zasoby bazy danych,
aby optymalnie wykorzystywać zasoby systemu klastrowego z minimalnym dyskowym
I/O i niską zwłoką w komunikacji między węzłami. Warto wymienić najważniejsze
cechy Cache Fusion, które umożliwiają taką pracę RAC. Po pierwsze jest to
wykorzystywanie zebranej pamięci cache bazy danych wszystkich węzłów w
systemie, aby zaspokoić żądania aplikacji wobec każdego węzła. Po drugie,
usuwanie operacji dyskowych z krytycznej ścieżki wewnątrzwęzłowej
synchronizacji, oraz znaczne zmniejszanie liczby wiadomości tej synchronizacji.
Kolejnymi cechami są wykorzystanie skalowalnego transferu bloków danych wewnątrz
węzła i wykorzystanie niewielkiego opóźnienia protokołów do połączeń
wewnątrz klastra, zarówno w przypadku wiadomości bazodanowych, jak i wysyłanych
danych.

Tak wygląda architektura, a co za tym idzie potrzeby Oracle
wobec platformy systemowej. Jak do realizacji tych wymogów przyczyniła się
współpraca Oracle i Red Hat? Rezultatem ich prac nad rozszerzeniami jądra
systemu Linux jest nowa dystrybucja Red Hat Advanced Server 2.1, która jest
strojona pod kątem serwera baz danych i aplikacji Oracle. Interfejs
programistyczny oraz funkcjonalność Linuksa jest podobna do większości
platform uniksowych. Oznacza to, że architektura Oracle9i na Linuksie jest
bardzo zbliżona do architektury Oracle na uniksowych systemach operacyjnych,
takich jak Solaris, HP-UX, czy True64. Gwarantuje to stabilność i wydajność
produktów Oracle na Linuksie, porównywalną do tradycyjnych platform
uniksowych.

Architektura Oracle na Linuksie opiera się na modelu
procesowym, podobnie jak ma to miejsce na platformach uniksowych, w przeciwieństwie
do wątkowej architektury Windows. W Linuksie Oracle wykorzystuje procesy do
implementacji zadań odbywających się w tle, takich jak database writers, log
writer, monitory procesów, oraz zadań pierwszoplanowych, jak obsługa nadchodzących
połączeń klienta. W Windows wszystkie te zadania zaimplementowano jako wątki
jednego procesu. Model wątkowy w systemach opartych na 32-bitowych platformach
Intel Pentium posiada ograniczenia, ponieważ wątki dzielą tę samą przestrzeń
adresową, wynoszącą 3GB, między SGA, PGA i inną pamięć. Przykładowo, w
przypadku wykonywania sporych czynności sortowania, może występować problem
z dostępną pamięcią, jako że wszystkie pierwszoplanowe wątki korzystają z
tej samej puli pamięci, równej 3GB. W modelu procesowym, każdy
pierwszoplanowy proces otrzymuje własną przestrzeń adresową i dzięki temu
ma więcej pamięci do wykorzystania. Należy zaznaczyć, że problem ten nie
dotyczy systemów 64-bitowych, gdzie każdy proces posiada przynajmniej 8TB
przestrzeni adresowej użytkownika.

Oracle może korzystać ze standardowego systemu plików
Linuksa, czyli „ext2”. Oprócz tego może pracować z raw devices,
czyli „pierwotnymi” (niesformatowanymi) partycjami dyskowymi. Pliki
„pierwotne” cechują się wyższą wydajnością I/O, ponieważ nie ma nad
nimi systemu plików. Wykorzystywane są one przez Real Application Clusters, który
takich „pierwotnych” plików wymaga.

Przepustowość I/O systemu przy obciążeniu bazy Oracle
jest znacznie wyższa na Advanced Server. Jak wspomniałam wcześniej, do
najistotniejszych ulepszeń w podsystemie wejścia-wyjścia są asynchroniczne
I/O, eliminacja wielokrotnych kopii do buforów pamięci podczas zapisu na dysk,
usprawnienie realizacji blokowania (lock) jądra oraz liczne ulepszenia
sterowników I/O. Postaram się teraz dokładniej przyjrzeć powyższym
zagadnieniom i ich realizacji w przypadku Advanced Server. Przed wprowadzeniem
asynchronicznego I/O, procesy składały żądania I/O do dysku sekwencyjnie. Każde
żądanie I/O powodowało uśpienie procesu wywołującego, aż do ukończenia
realizacji żądania. Asynchroniczne I/O pozwala procesowi złożyć żądania
I/O bez oczekiwania na jego realizację. Implementacja ta pozwala jednocześnie
procesom Oracle wydawać wiele żądań I/O do dysku, za pojedynczym wywołaniem
systemu, zamiast wielu pojedynczych żądań I/O. Pozwala to dwojako poprawić
wydajność: po pierwsze dzięki temu, że proces może kolejkować wiele żądań
do obsłużenia przez jądro systemowe, a jądro może optymalizować aktywność
dysku poprzez zmianę kolejności żądań lub połączenie wielu pojedynczych,
sąsiadujących na dysku żądań w mniejszą liczbę większych żądań. Po
drugie, ponieważ system nie usypia procesu na czas przetwarzania żądania
przez sprzęt, a proces może wykonywać inne zadania do czasu ukończenia I/O.

Domyślnie w Oracle9iR2 wsparcie dla asynchronicznego I/O
jest wyłączone. Jest to konieczne, aby spełnić wymagania innych dystrybucji,
które tej cechy nie obsługują. Aby włączyć/wyłączyć obsługę
asynchronicznego I/O należy:

  • przejść do katalogu $ORACLE_HOME/rdbms/lib:

    cd $ORACLE_HOME/rdbms/lib
  • w przypadku włączenia wydać polecenia:

    make -f ins_rdbms.mk async_on
    make -f ins_rdbms.mk ioracle
  • w przypadku wyłączenia wydać polecenia:

    make -f ins_rdbms.mk async_off
    make -f ins_rdbms.mk ioracle
  • ustawienie parametrów w init.ora dla raw devices

    disk_asynch_io=true (wartość domyślna – true)
  • ustawienie parametrów w init.ora dla systemów plików –
    w tym celu należy się upewnić, że pliki z danymi Oracle znajdują się w
    systemie plików, który wspiera asynchroniczne I/O (np. „ext2”)

    disk_asynch_io=true (wartość domyślna - true)
    filesystemio_options=asynch

Na początku starałam się omówić pokrótce istotę
funkcjonowania systemów klastrowych, zwłaszcza Oracle RAC.
W tym obszarze tkwiła kolejna przyczyna późnej implementacji Oracle RAC na
Linuksie. Główne problemy wiążą się tutaj z ograniczeniami w zakresie
maksymalnej liczby raw devices, maksymalnej liczby partycji na dysku i ciągłe
wiązanie nazw urządzeń dyskowych. Znacznie utrudnia to konfigurację baz
danych Oracle9i RAC. Dla rozwiązania tych problemów proponowane są obecnie
dwa programy: Linux Logical Volume Manager oraz Linux Metadisk Software RAID.
Jedną z podstawowych funkcjonalności systemu operacyjnego, która w istotny
sposób wpływa na funkcjonowanie baz Oracle jest charakter i budowa systemu
pamięciowego klastra. Wpływa on na instalację i konfigurację wykonywaną
przez standardowe narzędzia Oracle takie, jak Oracle Universal Installer (OUI)
czy Database Configuration Assistant (DBCA). Oddziałuje także na prawidłowe
funkcjonowanie systemu klastrowego, oczywiście w zakresie oprogramowania Oracle.
Funkcjonalność systemu pamięciowego determinuje ilość i rodzaj dodatkowych
działań, jakie należy wykonać, w celu utworzenia, przeniesienia, zwiększenia
lub usunięcia plików danych bazy Oracle RAC. Jest to szczególnie dotkliwy
problem w przypadku Oracle RAC działających na Linuksie – zakładam, że nie
jest wykorzystywane wyżej wymienione oprogramowanie. Do uruchomienia bazy RAC
konieczne jest używanie raw devices do współdzielenia plików danych
bazy i innych niezbędnych informacji. Niestety, powoduje to pewne problemy;
przede wszystkim niektóre karty rozszerzeń kanału FC używają protokołu
komunikacyjnego, który wykorzystuje przeplot, poprzez który urządzenia
raportują swoją tożsamość. Przeplot, inaczej warunek wyścigu (race
condition
), są to pewne warunki, przed którymi można się ochronić
stosując blokady (spin lock). Przeplot może potencjalnie owocować
innymi rezultatami zależnymi od systemu operacyjnego, a dokładnie od tego,
jakiego mechanizmu używa dany system operacyjny do wykrywania i identyfikacji
dysków. Niektóre systemy operacyjne używają etykiet do identyfikacji dysków,
ignorując kolejność, w jakiej dyski były wykryte. Inne systemy operacyjne z
kolei, mogą identyfikować dyski w oparciu o czas ich wykrywania, tworząc
sytuację, w której zmiany w kolejności raportowania powodują zmiany w
identyfikacji dysków. Ta druga sytuacja może powodować kłopoty, ponieważ
RAC wymaga całkowitej ciągłości w czasie identyfikacji dysków raw
devices
. Takiej ciągłości może brakować w Real Application Clusters na
Linuksie. Warunek wyścigu może powodować, że jądro będzie wiązać ten sam
zestaw urządzeń do różnych nazw urządzeń w sytuacji, gdy nastąpi
uruchomienie lub uruchomienie ponowne (reboot) systemu. Dzieje się tak, ponieważ
jądro opiera się właśnie na kolejności odkrywanych urządzeń przy
ustaleniu ich nazw. Oznacza to, że instancja RAC mając pracować na określonej
maszynie, może nie działać po uruchomieniu lub rebootowaniu systemu, ponieważ
nie będzie mogła prawidłowo zlokalizować potrzebnych plików z danymi, plików
kontrolnych i logów. Oznacza to także, że różne instancje RAC
w klastrze mogą działać poprawnie lub też nie działać
w zupełnie nieokreślony sposób, ponieważ jądra na maszynach zainicjowały
proces wiązania nazwy urządzenia
w różnych czasach. Problemu tego nie można w łatwy sposób w Linuksie rozwiązać,
bez zastosowania oprogramowania, które potrafi identyfikować dyski na
podstawie ich zawartości, jeśli nie ma możliwości określenia wyniku warunku
wyścigu na poziomie systemu operacyjnego.

Większość kart rozszerzeń FC „przedstawia się” jako
kontrolery SCSI. Dlatego też liczba dysków i partycji, które RAC może
zaakceptować jest ograniczona przez maksymalną liczbę dysków i partycji SCSI,
jakie dany system operacyjny może przedstawić. Jeśli oba maksima są wysokie,
administratorzy systemu i baz danych mają szerokie pole wyboru tego, jak
zainstalują bazę RAC i będą nią administrować w trakcie jej rozrastania się.
Problemy pojawiają się dopiero wtedy, gdy jedno bądź oba maksima przyjmują
niskie wartości, powodując ograniczenia w konfiguracji RAC. Niestety w
Linuksie takie ograniczenia występują. Ograniczenia te pozwalają podłączyć
128 dysków SCSI do maszyny, na której uruchomiono instancję Oracle; co więcej,
maksymalna liczba partycji na dysku wynosi 15. Z tych 15 partycji w zasadzie użytych
może być jedynie 14, a to z powodu związku między partycjami primary i
extended używanymi przez fdisk w Linuksie. Problemy z konfiguracją RAC występują,
ponieważ każda partycja może być powiązana z tylko jednym raw device.
Aby zrozumieć te problemy, można spróbować rozważyć poniższy przypadek.
Załóżmy, że mamy bazę RAC na 4 węzłach. Na każdym węźle działa jedna
instancja bazy. Baza RAC jest połączona do trzech współdzielonych dysków o
pojemności 36GB i każda instancja bazy musi mieć dostęp do czterech plików
logów o pojemności 100MB
(2 grupy i po 2 członków w grupie). Baza RAC ma dostęp do 42 partycji na całej
współdzielonej przestrzeni dyskowej 108GB. Ponad 1/3 dostępnych partycji (16
– cztery pliki logów na instancję) musi być przeznaczona na pliki logów po
100MB, zabierając jedynie 1,6GB dostępnej przestrzeni dyskowej. Poza tym,
przynajmniej 2 małe partycje (poniżej 128MB) muszą być przeznaczone jako wspólne
urządzenia Oracle – oprogramowanie klastrowe i narzędzia do zarządzania. Idąc
dalej, przynajmniej 3 dodatkowe małe partycje na różnych dyskach muszą być
przeznaczone na pliki kontrolne bazy. Dodatkowo jedna mała partycja musi być
przeznaczona na plik spfile bazy.

Z pozostałych dostępnych 20 partycji, każda musi mieć
wielkość średnio 5,4GB, aby uniknąć zmarnowania przestrzeni dyskowej. Oprócz
tego, standardowa baza utworzona przez DBCA wykorzysta przynajmniej 8 z owych 20
partycji, na pliki danych powiązane ze standardowymi tabelami (SYSTEM, UNDO,
DRSYS, EXAMPLE, INDX, TEMP, TOOLS,
i USERS). Dopiero na pozostałych 12 partycjach użytkownicy będą mogli tworzyć
pliki z danymi tabel do przechowywania ich własnych danych. Utworzenie nowych węzłów,
nie więcej jednak niż 3 instancje, spowoduje, że RAC pożre część z tych
pozostałych partycji – po 4 pliki logów na instancję, co uniemożliwi użytkownikom
przechowywanie tam swoich własnych danych i spowoduje niewykorzystanie znacznej
części dysku, jako że utworzone partycje będą miały zaledwie po 100MB (a
partycja pierwotna wynosiła 5,4GB). Oczywiście znacznie utrudnia to proces
projektowania bazy i zmniejsza elastyczność użytkowników w dopasowywaniu
bazy do własnych potrzeb.

Kolejny problem wiąże się z tym, że różne systemy
operacyjne stosują różne metody nazewnicze i dostępowe urządzeń raw
devices
. Tak w przypadku innych zasobów systemowych, maksymalna liczba dysków
raw devices może ograniczać możliwości konfiguracji. Metoda używana
obecnie przez Linuksa ogranicza liczbę urządzeń raw devices do 255. W
konsekwencji ogranicza to maksymalny rozmiar bazy RAC i maksymalną liczbę
instancji RAC, które mogą tę bazę dzielić.

Dostępne na rynku dwa produkty, polecane do rozwiązywania
powyższych problemów, to Linux Logical Volume Manager oraz Linux Metadisk
Software RAID (korzystające
z /dev/md). Oba narzędzia mają za zadanie wykorzystanie całej powierzchni
dyskowej (LVM) lub powierzchni partycji dyskowych (LVM i Metadisk Software RAID)
i prezentowanie serii urządzeń systemu operacyjnego, które mogą być używane
jak partycje dyskowe. Taka funkcjonalność pozwala znacznie zwiększyć wydajność,
niezawodność i elastyczność alokacji pamięci. Narzędzia te pozwalają w
zasadzie wyeliminować omawiane powyżej problemy. Zasada działania LVM opiera
się na podziale abstrakcyjnych urządzeń na 3 warstwy logiczne, co ma ułatwić
zadanie zarządzania pamięcią przez Linuksa. Pierwszą warstwą są jednostki
zwane woluminami fizycznymi, będące całymi dyskami lub partycjami dyskowymi.
Woluminy te łączy się
w grupy woluminów. Grupy te są następnie arbitralnie dzielone na woluminy
logiczne, które mogą być traktowane przez Linuksa w ten sam sposób jak
partycje dyskowe (jako raw devices lub sformatowane z systemami plików).
Dzięki takiemu rozwiązaniu możliwe jest gromadzenie grup woluminów z różnych
woluminów fizycznych na różnych dyskach, rozdzielanie danych w grupie woluminów
na składowe woluminy fizyczne, dodawanie woluminów fizycznych do grup woluminów,
aby utworzyć więcej miejsca, tworzenie dodatkowych woluminów fizycznych,
przenoszenie danych w woluminach fizycznych z jednego woluminu fizycznego na
drugi w tej samej grupie woluminów, przenoszenie grup woluminów z jednej
maszyny na drugą, a także tworzenie zrzutów woluminów logicznych, co może
być wykorzystywane do tworzenia kopii zapasowych.

Alternatywą dla sprzętowych kontrolerów RAID jest darmowe
oprogramowanie Metadisk Software RAID (używające /dev/md). Narzędzie to realizuje swoje zadanie poprzez
dodanie dodatkowej warstwy abstrakcji urządzeń w linuksowym systemie
operacyjnym zwanej metadisk, która – podobnie jak wolumin logiczny LVM – może
być używana
w dokładnie ten sam sposób jak partycja dyskowa. Metadisk łączy zawartość
jednej lub więcej partycji dyskowych razem (może używać niepartycjonowanych
dysków, gdzie cały dysk funkcjonuje jako jedna partycja) i przedstawia je jako
jedno urządzenie logiczne, które może występować na różnych dyskach.

Pamięć, pamięć i jeszcze raz pamięć

W systemach IA-32, pierwszy gigabajt pamięci fizycznej
nazywany jest „pamięcią dolną”, natomiast pamięć powyżej 1GB określana
jest jako „pamięć wysoka”. Poprzednie wersje jądra Linuksa wymagały, aby
bufory danych dedykowane obsłudze urządzeń pamięciowych były zlokalizowane
w obszarze dolnej pamięci fizycznej RAM, chociaż aplikacje mogły korzystać z
dolnej i wysokiej pamięci. Żądania
I/O buforów danych z dolnej pamięci oznaczały operację bezpośredniego dostępu
do pamięci. Jednakże, jeżeli aplikacja przekazała bufor danych z wysokiej
pamięci do jądra jako część żądania I/O, kernel był zmuszony do alokacji
tymczasowego bufora danych w pamięci dolnej i skopiowania danych do/z bufora
aplikacji w pamięci wysokiej. Takie dodatkowe kopiowanie danych może znacznie
obniżać wydajność aplikacji bazodanowych intensywnie korzystających z I/O.
Dzieje się tak, ponieważ duża liczba takich „odbijanych” buforów zużywa
sporo pamięci, a jednocześnie kopiowanie „odbijanych” buforów powoduje
dodatkowe obciążenie szyny pamięci systemowej. W Red Hat
Advanced Server znacznie zredukowano, a w wielu przypadkach całkowicie
wyeliminowano potrzebę kopiowania buforów.

Z tą samą niedoskonałością wcześniejszych wersji jądra
wiąże się również problem związany z PTE (Page Table Entries), które mogły
być alokowane jedynie w pamięci dolnej,
a więc poniżej 1GB. W przypadku aplikacji takich jak Oracle9iR2, które zużywają
ogromne ilości pamięci i uruchamiają mnóstwo procesów, całkowity rozmiar
PTE jest wysoki.
W sytuacji wystąpienia wielu połączeń użytkowników do bazy, kernelowi może
braknąć przestrzeni na PTE. Wtedy nawet, pomimo dostępnych wolnych zasobów
pamięci
i swap, system zawiesi się lub padnie. Rozwiązaniem tego problemu jest łata,
która pozwala pamięci wirtualnej używać puli pamięci wysokiej dla alokacji
PTE. Oznacza to,
że w przypadku, gdy wzrasta liczba użytkowników, którzy łączą się z bazą
danych i uruchamiają dodatkowe procesy, obszar przechowujący PTE rozszerza się
na pamięć wysoką, umożliwiając systemowi obsługę od 3 do 5 razy większej
liczby użytkowników, niż było to możliwe we wcześniejszych wersjach. Co więcej,
jeżeli liczba użytkowników wzrasta ponad pojemność systemu, następuje
stopniowe pogorszenie czasu odpowiedzi bazy danych, aż w końcu nie nastąpi
akceptacja nowego połączenia do bazy. Pozwala to uniknąć sytuacji załamań
systemu, które miały miejsce
w przypadku wcześniejszych wersji jądra.

Jądro linuksowe używa blokady spin lock (mechanizm
zapewniający ochronę pewnych obszarów kodu lub zmiennych przed jednoczesną
modyfikacją przez równoległe wątki, np. pracujące na dwóch procesorach,
tzn. gwarantuje,
że następujący po nim fragment kodu będzie wykonywany jednocześnie najwyżej
przez jeden procesor) do utrzymania integralności struktur danych jądra, które
są wykorzystywane w tym samym czasie przez wiele procesów. Wcześniejsze
wersje kernela korzystały z jednego blokowania spin lock dla całego
podsystemu urządzeń pamięciowych. Wymuszało to na procesach wykonywanie I/O
w całości dla pojedynczego zasobu, nawet gdy wykonywane operacje
I/O odnosiły się do różnych urządzeń, czego skutkiem było zmniejszenie
przepustowości całego systemu I/O. W Advanced Server zaimplementowano nowy
mechanizm blokowania systemu urządzeń blokowych, który osobno zamyka każde
urządzenie. Uzyskano dzięki temu znacznie wyższą przepustowość dla systemów
SMP, posiadających wiele kontrolerów I/O pracujących pod dużym obciążeniem
bazy danych.

Dla wydajności baz danych krytyczne znaczenie ma system pamięci
wirtualnej (VM). Architektura baz Oracle opiera się w znacznym stopniu na
obszarze Shared Global Area (SGA), który jest obszarem pamięci współdzielonym
przez wszystkie procesy pierwszoplanowe i wykonywane w tle. Rozmiar SGA, który
przechowuje bufor danych, jest głównym parametrem strojącym wydajność
Oracle. Większy SGA umożliwia przechowywanie większej ilości danych w pamięci,
prowadząc do zwiększenia wydajności wielu zadań bazy danych. Rozmiar SGA,
podobnie jak inne parametry, łącznie
z rozmiarem strony systemu operacyjnego, są określone przez system pamięci
wirtualnej. Ponieważ różne zadania mają różne charakterystyki zużycia
pamięci cache bazy danych, nie ma jednej recepty na ustawienie optymalnych
parametrów w każdej sytuacji. Przydatne może się okazać obserwowanie i
gromadzenie statystyk wykonywania typowych zadań dla ustalenia optymalnej
konfiguracji systemu.

Większość dystrybucji Linuksa, które posiadają do 4GB
pamięci RAM pozwala Oracle’owi wykorzystać około 1,7GB przestrzeni
adresowej na SGA. Red Hat Advanced Server dostarcza w tym zakresie regulowany
parametr w katalogu
/proc, który pozwala zwiększyć użyteczną przestrzeń adresową na procesy.
Aby zwiększyć ten rozmiar, Oracle musi zostać związany z niższą podstawą
adresową SGA, a Linux musi mieć zamapowaną obniżoną podstawę dla procesów
uruchamiających Oracle.

Najpierw – podstawowy adres SGA, którego używa Oracle,
musi być przełączony w celu jego obniżenia. Obecnie Oracle wiąże się z
tym adresem ustawionym na 0x50000000, dzięki czemu jest kompatybilny z domyślnymi
ustawieniami większości dystrybucji linuksowych. Obniżenie tego adresu
pozwoli Oracle wykorzystywać więcej przestrzeni adresowej
w procesie, ale istotne jest to, że zmodyfikowana i przełączona binarka
Oracle nie będzie działać, dopóki nie zostanie dokonana odpowiednia zmiana w
Advanced Server 2.1. Aby obniżyć podstawowy adres SGA należy:

  • zamknąć wszystkie instancje Oracle
  • przejść do katalogu $ORACLE_HOME/lib
    cd $ORACLE_HOME/lib
  • utworzyć kopię bezpieczeństwa pliku libserver9.a
    cp -a libserver9.a libserver9.a.org
  • zmienić katalog:
    cd $ORACLE_HOME/bin
  • utworzyć kopię bezpieczeństwa pliku oracle
    cp -a oracle oracle.org
  • ponownie zmienić katalog:
    cd $ORACLE_HOME/rdbms/lib
  • obniżyć podstawę SGA na 0x15000000
    genksms -s 0x15000000 >ksms.s
  • skompilować nową podstawę adresową SGA
    make -f ins_rdbms.mk ksms.o
  • skompilować nowe powiązanie
    make -f ins_rdbms.mk ioracle

Kolejnym etapem jest obniżenie zamapowanej podstawy jądra
systemu poniżej nowej podstawy SGA Oracle. W przypadku Advanced Server,
parametr w katalogu /proc obniża zamapowaną podstawę jądra dla każdego
procesu. Parametr ten nie obejmuje swoim zasięgiem całego systemu, ale dotyczy
konkretnego procesu, przy czym jest on dziedziczony przez procesy potomne.
Parametr ten można jedynie modyfikować będąc zalogowanym jako root. Poniższe
kroki pozwolą obniżyć zamapowaną podstawę dla sesji jednego terminala powłoki
bash. Po zmodyfikowaniu sesji poprzez obniżenie zamapowanej podstawy, sesja będzie
musiała być wykorzystywana do wszystkich poleceń Oracle, aby procesy Oracle
mogły dziedziczyć tę obniżoną podstawę.

  • zamknąć wszystkie instancje Oracle
  • otworzyć sesję terminala (sesję Oracle)
  • otworzyć drugą sesję terminala (ALT + F2) i zalogować się jako root (su root)
  • znaleźć id procesu (pid) sesji Oracle, np. poprzez echo $$ w sesji Oracle lub ps -ax
  • obniżyć zamapowaną bazę dla sesji Oracle do 0x10000000. Z sesji roota wykonać polecenie
    echo 268435456 >/proc/<pid>/mapped_base
    wstawiając odpowiedni id procesu
  • zwiększyć wartość shmmax, tak aby Oracle umieścił SGA w jednym segmencie. W tym celu należy w sesji roota wykonać polecenie
    echo 3000000000 >/proc/sys/kernel/shmmax
  • w sesji Oracle włączyć instancję Oracle. SGA zaczyna się
    teraz na niższym adresie, dzięki czemu większa ilość przestrzeni adresowej
    może być wykorzystana przez Oracle.

Teraz można zwiększyć wartości w init.ora parametrów
db_cache_size lub db_block_buffers, aby zwiększyć tym samym rozmiar bufora
bazy danych.

Jądro Advanced Server 2.1 pozwala Oracle alokować i używać
ponad 4GB pamięci dla bufora bazy na 32-bitowej platformie Intel. Funkcjonalność
ta nazywana jest VLM – Very Large Memory. Teoretycznie w takim zestawieniu,
SGA może zostać zwiększona do 62GB, zależnie od dostępnej dla systemu pamięci
RAM. Obecnie warunki sprzętowe i kwestie praktyczne znacznie ograniczają
rozmiar SGA, jaki może być skonfigurowany, ale jest on nadal kilkakrotnie większy
od SGA bez VLM. Praca w trybie VLM wymaga dokonania pewnych zmian w ustawieniach
Linuksa i nakłada pewne ograniczenia na używane cechy i parametry init.ora.
Modyfikacja systemu wygląda w ten sposób, że należy jako root zamontować
wewnątrzpamięciowy system plików w /dev/shm równy lub większy od ilości
pamięci, która będzie wykorzystywana przez bufor bazy danych. Jeśli taki
system plików jest już zamontowany (do sprawdzenia tego służy polecenie
mount), można już zacząć z niego korzystać. Jeśli system nie jest
zamontowany należy wydać polecenie:

mount -t shm shmfs -o nr_blocks=2097152 /dev/shm

Parametr shmmax powinien być ustawiony na połowę wielkości
pamięci RAM:

echo 3000000000 >/proc/sys/kernel/shmmax

Utworzy to system plików shmfs o rozmiarze 8GB na /dev/shm. Każdy nr_block wynosi 4096 bajtów. Uruchomienie Oracle z włączoną
opcją poszerzonego bufora, spowoduje utworzenie pliku w /dev/shm, który
odpowiada buforowi Oracle’a. Włączenie tej opcji następuje poprzez
ustawienie use_indirect_data_buffers=true w pliku init.ora. Pozwala to na określenie
większego bufora cache. Jednakże opcja ta nie jest kompatybilna z nowymi
dynamicznymi
parametrami cache (np. db_cache_size, db_2k_cache_size, db_4k_cache_size,
db_8k_cache_size, db_16k_cache_size, db_32k_cache_size). Oznacza to, że w
przypadku włączenia tej opcji należy określić rozmiar bufora za pomocą
dyrektywy db_block_buffers.

Typowy rozmiar bloku stronicowego w jądrze Linuksa wynosi
4kB. W Advanced Server istnieje możliwość zwiększenia tego rozmiaru do 2MB
lub 4MB dla rozmieszczenia SGA. Wykorzystanie dużych stron dla SGA może
znacznie poprawić wydajność systemu. Procesory IA-32 obsługują pamięć o
wielkości stron 4kB używając tablicy stronic 2-giego lub 3-ciego poziomu, aby
zmapować adresy wirtualne do adresów fizycznych. Dzięki obsłudze dużych
stron, procesor obsługuje strony pamięci wielkości 4 lub 2MB. Zmniejsza to
znacznie straty TLB (Translation Look-aside Buffer), odpowiedzialnego za
buforowanie translacji adresów wirtualnych na fizyczne. Jednocześnie, ze zwiększeniem
rozmiaru stron wiąże się zmniejszenie tablicy stronic, co prowadzi do
lepszego wykorzystania pamięci. Dzieje się tak, ponieważ 1024
czterokilobajtowe PTE (Page Table Entry) są obsługiwane przez 1 PTE wielkości
4MB. Lepszą wydajność uzyskuje się również dzięki temu, że duże strony
nie są wymieniane, co oznacza, że całe db_block_buffers są zablokowane w
pamięci fizycznej. Zwiększenie wydajności uzyskuje się tu dzięki temu, że
jądro systemu nie musi „myśleć” o wymianie tych stron, a jednocześnie
uzyskuje się więcej dostępnej pamięci swap, która nie jest teraz do nich
przeznaczana; mniej złożone jest także buforowanie stron. Aby zwiększyć
wielkości stron, należy:

  • zmienić parametr programu bootującego system
    (np. /etc/lilo.conf), podając bigpages=<rozmiar>MB
  • aby zmiany w pliku /etc/lilo.conf odniosły skutek, należy
    przeładować program bootujący, w tym wypadku poprzez wydanie polecenia lilo
  • wpisać do pliku /proc/sys/kernel/shm-use-bigpages wartość
    2. Inne możliwe wartości to 0 – nie używa dużych stron i 1 – duże
    strony za pomocą pamięci współdzielonej sysV, jako przeciwieństwo shmfs.

Maksymalną wielkość dużych stron można określić za
pomocą następującej formuły:

Max_wielkość_dużych_stron = HighTotal / 1024 * 0.8 MB

HighTotal jest wartością podaną w kilobajtach, uzyskaną
z /proc/meminfo. Zakłada się, że 20% pamięci jest zarezerwowane dla jądra.
Przykładowo, maszyna posiadająca 8GB RAM ma wartość HighTotal równą
7208944 kB i zgodnie
z powyższym wzorem maksymalna wartość bigpages wynosi 5631MB. Jeżeli
wartość ta jest ustawiona bardzo wysoko, niewielka będzie ilość pamięci
przeznaczonej na połączenia użytkowników. Istnieje zależność między
liczbą użytkowników, a wartością bigpages. Jeśli istnieje możliwość
oszacowania maksymalnej liczby połączeń użytkowników i ilości pamięci zużywanej
na każde połączenie, można przedstawić odpowiednią wartość bigpages
jako zależność:

bigpages = (HighTotal - Pamięć_max_połączeń [kB]) / 1024 *0.8 MB

gdzie Pamięć_max_połączeń, to pamięć wymagana przez
maksymalną liczbę połączeń użytkowników wyrażona w kB.

A co z Oracle?

Niedostatki wcześniejszych wersji jądra Linuksa,
niewystarczająca obsługa klastrów i problemy z wykorzystaniem systemu pamięci
były istotną przeszkodą dla implementacji Oracle na platformie linuksowej. Również
jednak w przypadku produktów Oracle, konieczne było dokonanie pewnych
poprawek. W przypadku RAC dla Oracle9i i wcześniejszych wersji, RAC Cluster
Manager komunikował się między węzłami klastra za pomocą protokołu TCP/IP.
Liczba połączeń do procesu Cluster Manager’a wzrastała w takiej sytuacji
proporcjonalnie do liczby użytkowników i węzłów.
W klastrach o dużej liczbie węzłów (np. 8 lub więcej), limit połączeń
TCP/IP przypadających na proces ograniczał całkowitą liczbę jednoczesnych
połączeń użytkowników do bazy w ramach danego klastra. W Oracle9iR2 problem
ten rozwiązano w ten sposób, że Cluster Manager komunikuje się między węzłami
klastra wykorzystując protokół UDP. Jako że UDP jest protokołem bezpołączeniowym,
ograniczenia maksymalnej liczby połączeń TCP/IP przypadającej na proces nie
odgrywa tu żadnej roli. Rozwiązanie to zwiększa skalowalność linuksowych
klastrów RAC przy znacznie większej liczbie jednocześnie pracujących użytkowników,
niż to miało miejsce w poprzednich wersjach Oracle na Linuksie.

Wspomniany Cluster Manager jest komponentem architektury
Oracle RAC. Implementuje usługi „członkostwa” w klastrze
i monitoringu węzłów. Jednym z podstawowych zadań Cluster Manager’a jest
odcięcie z klastra uszkodzonego węzła, co zostało zaimplementowane poprzez
sprzętowy reset węzła za pomocą linuksowego urządzenia śledzącego (Watchdog).
Oracle rozszerzył funkcjonalność narzędzia Watchdog dla lepszego zarządzania
Real Application Clusters w Linuksie. Przykładowo, margines czasowy Watchdog
jest definiowany przez parametr soft_margin, określony w trakcie ładowania
modułu. We wcześniejszych wersjach jądra nie było mechanizmu, który by
pozwalał uzyskać wartości soft_margin z jądra w czasie pracy. Konieczne było
jawne ustawienie dodatkowego parametru dla Cluster Manager’a, który był kopią
lustrzaną soft_margin. W Advanced Server możliwe jest uzyskanie wartości
soft_margin od jądra w czasie pracy, poprzez wywołanie ioctl. Innym
ulepszeniem w tym zakresie jest możliwość zmiany domyślnej konfiguracji;
np., dzięki poleceniu shutdown abort wydanemu do instancji bazy danych na
uszkodzonym węźle, nie nastąpi jest sprzętowy reset.

Podsumowanie

Zauważalny zwrot Oracle w kierunku Linuksa zaowocuje na
pewno intensywnymi pracami nad oprogramowaniem narzędziowym tworzonym dla
Linuksa przez firmy partnerskie Oracle. W niedalekim czasie będziemy zapewne
mieli tak samo szeroki wachlarz rozwiązań dla Linuksa, jak i dla innych systemów
operacyjnych z dłuższym stażem współpracy z Oracle. Niniejszy artykuł
skupia się głównie na aspektach architektury systemu w korelacji z
architekturą baz Oracle. W następnym numerze postaram się przedstawić
praktyczne aspekty współpracy Oracle i Linuksa. Sądzę, że warto zapoznać
się z tymi zagadnieniami dokładniej, bo wszystko wskazuje na to, że Linux już
jest i będzie coraz bardziej istotnym nurtem w działaniach Oracle.

Literatura: