Oracle’s High Availability concept nader bekeken

RAC laat meerdere computers als één databaseserver werken

Real Application Clustering — RAC — is sinds versie 9i onderdeel van de Oracle database. Deze clustertechniek maakt het mogelijk een groep onderling verbonden computers als één databaseserver te laten werken. Het idee erachter is een foutbestendige high performance schaalbare oplossing te laten ontstaan, als een low cost alternatief voor high end servers. Omdat er nogal wat onduidelijkheden zijn rond de voor en nadelen van RAC, organiseerde Centor op 14 december jl. in het Mitland Hotel in Utrecht — exclusief voor Oracle specialisten die Centor kent — een technische presentatie. Deze presentatie werd verzorgd door ir. Robert Blok van het Castricumse Continux IT Solutions. Hij ging in op wat Oracle RAC eigenlijk inhoudt, gaf een beschrijving van de architectuur en besprak de aspecten die een rol bij database clustering spelen.

Clustering op zich is geen nieuw idee; bedrijven als Tandem (nu onderdeel van Compaq) bieden al sinds enkele tientallen jaren server clustering oplossingen aan. Toch duurde het tot het midden van de jaren negentig voordat de belangrijkste leveranciers van relationele databases met deze techniek begonnen te experimenteren. Doel was de efficiëntie en de foutbestendigheid te verbeteren.

IBM en Oracle gebruiken fundamenteel verschillende methoden voor het clusteren van relationele databases, waarbij IBM heeft gekozen voor de zogeheten ‘Shared nothing’ benadering. Bij deze architectuur bevat elke node in het cluster slechts één segment van de database. Deze node handelt ook alle berekeningen af die corresponderen met de data die erin opgeslagen is. Een master server weegt de taken en verdeelt deze dan uit, waarbij een deel van de taak wordt gedistribueerd naar iedere node die de te verwerken data bevat. De taak wordt dan door alle nodes parallel uitgevoerd, waarna de master server het resultaat rapporteert.

Oracle kiest voor ‘Shared disk’ clustering
Oracle daarentegen maakt gebruik van de ‘Shared disk’ clustering techniek. Deze techniek is ontworpen rond een grote data opslag, zoals bijvoorbeeld een disk array. Iedere node in het cluster heeft gelijkwaardige toegang tot alle informatie in de data opslag. Alleen de verwerking wordt onderling verdeeld; niet de data zelf. Het resultaat is een fout tolerante database, want zelfs wanneer één of meerdere servers uitvallen, dan nog blijft de applicatiedata beschikbaar voor de andere nodes. Het is al helemaal beter dan wanneer de applicaties op een enkele databank (Risc) server lopen, want daarmee ontstaat één 'single point of failure'. Bovendien, wanneer één node in een ‘Shared nothing’ database crasht, zal de data die op die node is opgeslagen niet langer beschikbaar zijn.

Betrouwbaarheid
Clusteren is een methode om meerdere servers effectief als één enkele unit te laten acteren. Dit kan worden gedaan om redenen van betrouwbaarheid, beschikbaarheid, schaalbaarheid en om het geheel te kunnen blijven managen. Praten we over betrouwbaarheid, dan is natuurlijk de wijze waarop met foutsituaties wordt omgegaan van belang. Gelukkig is er binnen de ICT reeds langer een standaard voor bekend: de ACID standaard. Deze standaard heeft ervoor gezorgd dat ontwikkelaars zelf geen foutafhandelingsprocedures hoeven te ontwikkelen om de gevolgen van opgetreden fouten te kunnen afhandelen. ACID is een acroniem voor Atomicity, Consistency, Isolation en Durability.
• Atomicity staat voor het vermogen om transacties als een ondeelbaar geheel te kunnen behandelen. In het concrete geval van een database garandeert het dat ofwel alle taken van een transactie worden uitgevoerd, of helemaal geen enkele.
• Consistency heeft betrekking op het gegeven dat de database in een legal state moet zijn wanneer de transactie begint en wanneer deze eindigt.
• Isolation refereert aan het gegeven dat de applicatie in staat moet zijn handelingen binnen een transactie af te scheiden van alle andere operaties.
• Durability ten slotte garandeert de gebruiker dat wanneer deze eenmaal een melding van een geslaagde transactie heeft ontvangen, deze transactie ook blijvend is en niet meer ongedaan wordt gemaakt.

Beschikbaarheid
De wijze waarop de beschikbaarheid wordt geregeld, heeft alles te maken met de eisen ten aanzien van die beschikbaarheid en of het om één of meerdere sites gaat. Figuur 1 geeft een overzicht van de beschikbaarheid en de methoden waarop deze georganiseerd kan worden.

Schaalbaarheid
Ten aanzien van de schaalbaarheid identificeren we twee methoden: scale up en scale out. Bij deze laatste methode — zie figuur 2 — wordt in plaats van een klein aantal grote·servers een groot aantal kleine servers ingezet. Deze methode van zijdelingse uitbreiding biedt meerdere voordelen ten opzichte van de scale up methode en dit is dan ook de aanpak die Oracle RAC gebruikt. In de eerste plaats is scale out flexibeler, omdat gebruikers door het inzetten van extra servers geleidelijk meer verwerkingscapaciteit kunnen toevoegen. Je plugt gewoon meer capaciteit in. Daarnaast biedt scale out een hogere beschikbaarheid, omdat bij uitval van een server de overige servers gewoon doorgaan. Een ander — eerder genoemd — voordeel is dat de prijs/prestatieverhouding gunstiger is, omdat gebruik kan worden gemaakt van op PC technologie gebaseerde servers. Een nadeel is er ook en dat heeft alles te maken met het beheer van scale out. Immers, elke individuele server zal apart geïnstalleerd en beheerd moeten worden.

Het managen van RAC
Naast het nadeel van het apart moeten installeren en beheren van elke server, kent RAC natuurlijk ook voordelen ten aanzien van het managen van het databasecluster. Zo kunnen componenten ge upgrade en/of verwisseld worden, zonder de applicatie stil te hoeven leggen. Figuur 3 laat dit zien.

Architectuur Oracle RAC
Figuur 4 laat op eenvoudige wijze zien hoe RAC georganiseerd is. Meer nodes geven op deze manier ook een hogere beschikbaarheid. In de figuur is te zien dat beide nodes een tabel (als voorbeeld voor data) in geheugen kunnen hebben. Deze tabel in cache bevat de actuele informatie van deze tabel en iedere node weet wat de status van de informatie in zijn cache is. Als nu een andere node een vraag over deze tabel krijgt, wordt eerst de actuele informatie van de andere node gevraagd.

De clusterprocessen tussen de nodes onderling — zoals weergegeven in figuur 5 — verlopen als volgt. Het ‘Lock Monitor Process’ (LMON) monitort het gehele cluster en regelt op die manier de global locks en resources. LMON regelt instance en process deaths en de daarmee geassocieerde recovery voor de Distributed Lock Manager.



De ‘Lock Manager Daemon’ (LMD) is het lock agent proces dat de lock manager service requests voor Parallel Cache Management locks regelt. Op deze manier worden global locks en resources gecontroleerd. Het LMD proces zorgt ook voor deadlock detectie en voor de remote lock requests. Hiermee wordt gegevensmodificatie door verschillende cliënten tegelijk voorkomen.
De ‘Global Cache Service’ (GCS) kijkt naar de locatie en de status (mode en rol) van datablokken en de toegangsprivileges van alle instances. Oracle gebruikt het GCS voor cache coherency wanneer de huidige versie van een datablok zich in een buffer cache van één instance bevindt, terwijl een andere instance dat blok opvraagt voor modificatie. Het wordt ook gebruikt om blokken van andere instances te kunnen lezen.
GES is de ‘Global Enqueue Service’. Deze onderhoudt een inter instance overzicht van alle locks en enqueues in de database.

Cache fusion
Door gebruik te maken van Cache fusion kan elke willekeurige Oracle applicatie op een cluster draaien zonder dat aanpassing van de applicatie nodig is. Er zijn drie scenario’s mogelijk: read/read, write/write en disk write.

Figuur 6 toont het read/read scenario. Node 1 stuurt een block request wanneer deze in shared mode is met een local role. Vervolgens wordt het request doorgestuurd naar de owning instance 2. Het block wordt daarna gekopieerd naar vragende instance. Ten slotte wordt de GCS geïnformeerd.

Het tweede scenario — weergegeven in figuur 7 — is het write/write scenario. Node 1 stuurt een block request wanneer deze in exclusive mode is met een local role. Het request wordt ook hier weer doorgestuurd naar de owning instance 2. Het block wordt gekopieerd naar vragende instance. Het GCS wordt geïnformeerd.

Het derde scenario is het disk write scenario, zoals weergegeven in figuur 8. Dit start met node 2 die een write request naar het GCS stuurt. Dit request wordt doorgestuurd naar de node waarin zich het huidige mode block bevindt. Het block wordt naar disk geschreven en de resource rol wordt local gemaakt. Het GCS wordt geïnformeerd, waarna de andere nodes opdracht krijgen hun PI’s te flushen. Ten slotte verdwijnt de lock op het block.

Conclusie
Database clustering kan worden ingezet om de beschikbaarheid van een database aan te passen. Let wel, we spreken hier van aanpassen omdat clustering niet automatisch betekent dat de beschikbaarheid omhoog gaat. Naarmate de technology stack hoger wordt, neemt ook de kans op problemen toe. Een migratie van een single instance database naar een RAC database kan nooit een oplossing bieden voor (performance) problemen die al in de omgeving aanwezig zijn. Twee gebieden waar deze problemen zich regelmatig voordoen zijn High Concurrency Systems en bij batch loading in combinatie met OLTP (OnLine Transaction Processing). Wel zijn er mogelijkheden één en ander te optimaliseren, waardoor dergelijke problemen in een aantal gevallen vermeden kunnen worden.