|
Tags: Database | Oracle
| ||
| ||
Cold Failover met Oracle Clusterware
Nu de winter weer voor de deur staat
is een artikel over
Cold Failover wel toepasselijk. Maar wat
is dat nu precies cold failover met
Oracle Clusterware?
Enige cluster kennis tijdens het lezen van
het artikel is gewenst.
Sinds de komst van Oracle 10g is er Oracle Clusteware wat een verplicht onderdeel is als men een Cluster omgeving opzet voor Oracle Real Application Cluster (RAC). Nu is het over het algemeen zo dat men Oracle Clusterware installeert omdat het een requirement is voor RAC. Men heeft deze software tenslotte nodig om te zorgen dat node's in een cluster als eenheid opereren. Door deze functionaliteit ook in te zetten voor het hoger beschikbaar maken van applicaties kan de business continuïteit ten goede komen. Vanaf de introductie van 10gR1 was dit al mogelijk maar werd door Oracle niet gesupport en was toen ook niet gedocumenteerd. Tegenwoordig kan men e.a. dus wel gebruiken. Sterker nog sinds Maart dit jaar kunnen Oracle klanten die Oracle Unbreakable Linux gebruiken en daar support (basis/premium) voor hebben kostenloos Oracle Clusterware ook op andere systemen inzetten om Oracle of andere niet Oracle applicaties hoger beschikbaar te maken. Aangezien Real Application Cluster (RAC) en Dataguard bestaande oplossingen zijn van Oracle, is het wellicht lastig om Cold Failover te positioneren. Ben van mening dat je Cold Failover het beste in het midden kunt plaatsen qua functionaliteit. Het doel van Dataguard is over het algemeen om te beschermen tegen side failures. RAC zet men in voor hoge beschikbaarheid en/of schaalbaarheid/flexibiliteit en downtime geen optie is. Oracle Clusterware kan men inzetten om automatisch een failover te laten uitvoeren indien er een probleem optreedt of voor onderhouds werkzaamheden. Voor de windows gebruikers onder ons kan men Cold Failover met Clusterware vergelijken met de windows tegen hanger Oracle FAILSAFE. Maar waar Oracle Failsafe alleen voor windows beschikbaar is, kan Oracle Clusterware op verschillende platformen worden ingezet. Hoe moet men nu een coldfailover omgeving inrichten? Deze vraag wordt hieronder beantwoord aan de hand van een voorbeeld, waar we een single instance database gebruiken. We gaan er vanuit dat men een RAC infrastructuur heeft neergezet. Oracle Clusterware is geïnstalleerd en de RDBMS software (zonder RAC optie) op beide nodes in het cluster. Tevens is er een database instance actief. In dit voorbeeld werken we met instance siprod, tevens maken we gebruik van ASM. Wat hebben we naast bovenstaande nog meer nodig?
1) Start/Stop/Check Script:Het onderstaande script vormt de basis voor de Cold Failover. Het script moet aangeroepen kunnen worden met start,stop en status als argument. In dit geval wordt voor via sqlplus startup uitgevoerd. Als stop als argument wordt meegegeven een shutdown immediate. En de check controleert of het achtergrond proces pmon actief is. Mocht men nu een andere soort applicatie beheren via Cold Failover moeten deze gedeeltes dus worden aangepast.Het script moet op alle nodes worden neergezet in de $CRS_HOME/crs/public directory. Zorg dat de executie rechten correct staan. Voer het script eventueel uit als Oracle user, door de parameter _USR_ORA_LANG=/u01/app/oracle/product/11.1.0/si_1, _USR_ORA_SRV=siprod en _USR_ORA_FLAGS=1 te zetten. De eerste is de ORACLE_HOME locatie, 2de parameter de SID en de derde parameter geeft aan of men wel of niet ASM gebruikt (1 is wel ASM, 0 is geen ASM). | ||
| ||
| ||
2) Creëren en registeren resource profileNu het script op de locatie is gezet kan men een resource profile aanmaken. In het profiel geven we het gedrag aan. Zoals hoe vaak we een check willen uitvoeren, of er direct een Cold Failover plaats vindt of eerst nog een restart proberen uit te voeren. | ||
| ||
|
Als de profile is aangemaakt moet deze nog worden geregistreerd in de Oracle Cluster Registry (OCR). | ||
| ||
3) kopiëren pfile en passwordfile.Om te zorgen dat een Cold Failover gemakkelijk verloopt, bereiden we de "uitwijk" node ook voor zodat geen additionele stappen achteraf nodig zijn. Kopieer daarom de pfile en de passwordfile. Mocht je zelf nog andere files hebben die nodig zijn, zorg dan dat deze ook op de andere node beschikbaar zijn.4) Opzetten TNSNAMES.oraNu is men al klaar met de server, moeten de cliënts natuurlijk ook gebruik kunnen maken van de instance, zowel als deze actief is op de eerste dan wel de 2de node. Gebruik maken van een applicatie VIP is ook mogelijk, maar daar gaan we hier niet verder op in. Wil je daarover weten kijk dan op rachelp.nl en coldfailover. De entry kijkt eerst of op racworkshop1-vip een listener actief is met de service name dat niet het geval dan zal deze connectie opgaan zetten naar racworkshop2-vip. | ||
| ||
5) Testen.Testen is natuurlijk een van de belangrijkste aspecten. Door gebruikt te maken van lifecycle commando's om Oracle clusterware resources te beheren kunnen we diverse zaken testen. Zo hebben we ook crs_start, crs_stop, crs_stat en crs_relocate.We beginnen het het starten van de resource op de eerste node. | ||
| ||
| ||
|
Nu dit succesvol is stoppen we de resource ook weer op de eerste node. | ||
| ||
| ||
|
Herhaal bovenstaande stap nu ook voor de 2de node in het cluster. Dit zal aantonen of een failover succesvol zal werken. Als de database instance dus correct gestart wordt op de andere node kunnen we beginnen met het controleren of een failover correct werkt. Relocate van de resources van node 1 naar node 2. | ||
| ||
|
De basistests zijn nu met succes afgerond. Wat nog ontbreekt is failure situatie. Tijdens het aanmaken van de resource profile is deze aangegeven ra=5, dit betekent dat clusterware eerst 5 maal zal proberen de instance te starten op de node waar die op dat moment actief is. (Deze waarden kunnen uiteraard aangepast worden.) Dit betekent dat we tot 6 maal toe een problemen moeten veroorzaken om een failover te laten plaatsvinden. In de test wordt dit gedaan door 5x een kill van pmon te doen. De derde kolom geeft aan hoeveel restart attempts er zijn uitgevoerd. Als uitgangspositie zijn er reeds 5 kill statements uitgevoerd bij nummer 6 zal er dus een failover plaatsvinden. Hier het resultaat. | ||
| ||
| ||
|
We zien nu dat op racworkshop2 node siprod resource actief is en dat Oracle Cluster een failover heeft uitgevoerd. Conclusie: zoals men ziet is de basis een start/stop/check script en een clusterware applicatie profile. Hiermee kan elk soort applicatie ( database, webservers etc.. ) worden ingezet voor Cold Failover en dus ook op middle-tier omgevingen. De mogelijkheden zijn eigenlijk onbeperkt. Daarnaast zijn de kosten minimaal, zeker als men al Real Application Cluster gebruikt. Tevens een mooi alternatief als schaalbaarheid geen business requirements is. Een uitgebreider document met meerdere opties kan men downloaden op www.rachelp.nl, onderdeel van GRID-IT. Uiteraard heeft Oracle op OTN ook een aantal voorbeelden staan. Mocht men zich dus in de winter vervelen is Cold Failover een leuke bezigheid en zal men ontdekken dat de mogelijkheden zeer divers zijn en ingezet kan worden om de business continuïteit te bevorderen. Bernhard de Cock Buning GRID-IT | ||
| Lees meer over GRID-IT | ||
| Ga terug naar We Love IT uitgave 5 - 2008 | ||
|
 |
|
