3 High availability en clustering

NetWare

3/3 High availability en clustering 3/3.1

Inleiding

De term ‘high availability’ is een van de nieuwe buzzwords. In heel wat grote organisaties wordt al gewerkt met fouttolerante systemen, terwijl in de kleinere ondernemingen de noodzakelijkheid van een altijd beschikbaar computersysteem steeds nadrukkelijker wordt onderkend. Toch zien we dat er per bedrijf of bedrijfstak opvallende verschillen zijn in de wijze waarop high availability wordt gerealiseerd. Dit heeft meestal te maken met de implementatiekosten van een high available oplossing, en zoals zo vaak in de automatisering, er is geen eenduidige oplossing te bieden die opgaat voor elke situatie. Bovendien, gebruikers en beheerders van netwerken zullen een zo hoog mogelijke beschikbaarheid willen hebben… totdat er over de prijs wordt gesproken. Het is echter van belang om eerst de terminologie die te maken heeft met availability goed te begrijpen alvorens discussies te voeren over technologische oplossingen en de consequenties daarvan op andere niveaus. Een vlotte prater zal in staat zijn om een buurtwinkel een volledige clusteroplossing aan te praten, terwijl deze daar helemaal geen behoefte aan heeft. Even zo goed is het denkbaar dat een organisatie die een beschikbaarheid van bijvoorbeeld 99,5% wenst dit niet haalt, eenvoudig omdat ze niet begrijpen op welke punten moet worden geïnvesteerd om die beschikbaarheid te kunnen halen.

Novell Netwerkoplossingen, aanvulling 5

3/3.1-1

High availability en clustering

Vandaar dat we ons eerst buigen over de terminologie. Terminologie Mean Time Between Failure (MTBF) Mean Time To Recover (MTTR)

Availability (Beschikbaarheid)

De gemiddelde tijd tussen twee storingen aan een device. De tijd die het kost om een opgetreden storing op te lossen en de systemen hun normale manier van werken te laten hervatten. Het percentage van de totale systeemtijd dat het systeem beschikbaar is voor normaal gebruik. De formele definitie van beschikbaarheid is: availability (%) =

MTBF MTBF + MTTR

Uptime Downtime

De tijd waarin het systeem operationeel is. De tijd waarin het systeem niet beschikbaar is. Hiertoe worden zowel geplande als niet-geplande tijden gerekend. Uit de formele definitie van beschikbaarheid blijkt overigens dat het onmogelijk is om een 100%-beschikbaarheid te kunnen garanderen. De MTTR zou in dat geval gelijk moeten zijn aan 0.

3/3.1-2


NetWare

3/3.2

De zwakste schakel

Nu de definities duidelijk zijn, kan worden gekeken naar het optimaliseren van de beschikbaarheid. Een veelgehoorde uitspraak is dat een ketting nooit sterker is dan de zwakste schakel. Dit gaat zeker op als we het over ICTbeschikbaarheid hebben. Een informatiesysteem is opgebouwd uit een groot aantal onderdelen die elk hun eigen beschikbaarheid hebben. Toch is er nog veel onduidelijkheid over hoe groot de beschikbaarheid is van een systeem bij een gegeven beschikbaarheid van de onderdelen van het systeem. Velen zullen bij het volgende voorbeeld de totale beschikbaarheid van het systeem op 99,0% stellen, omdat dit het onderdeel is met de laagste betrouwbaarheid.

Als we echter de onderdelen benoemen, met van links naar rechts bijvoorbeeld: 1 2 3 4 5 6 7

schijven disk subsysteem controller scsi-kabel controller moederbord voeding


99,2% 99,1% 99,4% 99,0% 99,9% 99,7% 99,9%

3/3.2-1


wordt het al een stuk eenvoudiger om in te zien dat de betrouwbaarheid van dit gehele systeem wordt gevormd door alleen de zwakste schakel, maar dat het systeem niet meer normaal functioneert als één van de onderdelen uitvalt. De kans dat een keten een storing krijgt, is zo groot als de cumulatieve kans op een storing op een van de onderdelen. In dit geval is de kans op een storing dus: 99,2% x 99,1% x 99,4% x 99,0% x 99,9% x 99,7% x 99,9% = 96,3%!

Indeling in vijf niveaus

Het is dan ook niet mogelijk de beschikbaarheid te verbeteren door zomaar een cluster de organisatie binnen te brengen; het gehele systeem zal moeten worden bekeken. Een hulpmiddel bij het verbeteren van beschikbaarheid over de gehele linie is een indeling in vijf niveaus. Zolang er niet voldoende is geïnvesteerd in een van de niveaus, heeft het geen zin om het volgende niveau aan te pakken. De beschikbaarheid zal hierdoor namelijk hooguit marginaal toenemen. Niveau 1: betrouwbare apparatuur Een eerste stap in het creëren van een betere beschikbaarheid is gebruik te gaan maken van betrouwbare apparatuur. Dit betekent bijvoorbeeld: geen werkstation inzetten als server en geen kloon als server dienst laten doen. Het betekent ook: beter dan voorheen kijken naar de configuratie van de apparatuur, waarbij we ons de volgende vragen kunnen stellen: • Welke revisie-BIOS draait er op de servers? Leveranciers updaten de BIOS op een heel regelmatige basis. Zeker bij nieuwe (typen) machines is de kans dat er iets in de machine niet helemaal goed staat afgesteld, behoorlijk groot en vaak kan de BIOS dit soort problemen verhelpen.

3/3.2-2


NetWare

•

•

•

Welke servicepacks heb ik geladen op mijn server? Alle grote leveranciers van software zullen bij het melden van een storing altijd eerst controleren of de machine voorzien is van de laatste servicepacks. Dit lijkt een open deur, maar de statistieken bij Novell Technical Support tonen aan dat meer dan 80% van de gemelde storingen werd verholpen door de server te laten voldoen aan het minimum patch level, zoals dat op de website staat vermeld. Lees wel altijd eerst de releasenotes! Het is bovendien verstandig om nieuwere servicepacks eerst in een testomgeving te testen alvorens aanpassingen in de productieomgeving door te voeren. Wat voor adapters gebruik ik in mijn server? Probeer zo veel mogelijk gebruik te maken van onderdelen in de server waarvan is bewezen dat ze goed functioneren. SCSI-controllers van Adaptec bijvoorbeeld zijn dan wel aanzienlijk duurder dan veel andere merken, maar ze worden door zo veel mensen wereldwijd gebruikt, dat de kans dat er juist in onze configuratie een fout optreedt die niemand anders ooit heeft gehad, zeer klein is. Hoe worden de interrupts (IRQ’s) gebruikt in onze server? Steeds vaker worden kaarten gewoon maar in een vrij slot in de server geplaatst. Aangezien alle moderne operating systems plug-and-play zijn, worden de kaarten wel gedetecteerd en functioneren ze ook wel, maar optimaal is het veelal niet. Een van de punten om aandacht aan te besteden is de verdeling van IRQ’s in het systeem. IRQ 5 gebruiken voor een netwerkkaart is over het algemeen geen slimme configuratie voor een server. Verder worden echte servers steeds vaker uitgerust met twee of meer aparte PCI-bussen. Door de load


3/3.2-3


van de PCI-bus te verdelen, zal de totale doorvoer hoger kunnen worden en worden mogelijke problemen door overbelasting voorkomen.

ESD

Veel belangrijker wellicht nog is het maken en naleven van beleid om Electro Static Discharge (ESD) te voorkomen. Zeer veel systemen die vage problemen hebben, blijken (uiteindelijk!) een onderdeel te bevatten dat door een ESD beschadigd is geraakt. Aangezien we een ESD-overslag pas bemerken als deze minimaal zo’n 10.000 V bedraagt, is het onmogelijk om zeker te weten dat er geen ESD heeft plaatsgevonden. Een gemiddelde computerchip kan bij 5 V al schade oplopen. Vaak is het daarbij ook nog zo dat de machine het wel degelijk lijkt te doen, maar dat een processor een bepaalde handeling niet meer goed kan uitvoeren of dat een bepaald deel van het geheugen niet meer betrouwbaar is. Het resultaat is dan dat de machine goed lijkt te werken, maar toch geregeld storingen vertoont die niet of moeilijk te verklaren zijn. Niveau 2: redundantie De tweede stap in het bereiken van een betere beschikbaarheid is het redundant uitvoeren van onderdelen van het systeem.

Dubbel uitvoeren power supply

3/3.2-4

Een van de eerste zaken waar we bij redundantie aan denken, is het dubbel uitvoeren van de power supply. Belangrijk is dan natuurlijk ook om een noodstroomvoorziening beschikbaar te hebben. Gemiddeld wordt elk stopcontact in Nederland 1,5 keer per jaar getroffen door een stroomstoring. Een UPS, eventueel aangevuld met een aggregaat, is dus zeker geen overbodige luxe. Voor echte servers houdt het echter al lang niet meer op bij alleen de voeding.


NetWare

•

•

•

Netwerkkaart Door netwerkkaarten dubbel uit te voeren, kan ervoor worden gezorgd dat als de kaart of de kabel kapotgaat, de verbinding met de werkstations niet wordt onderbroken. Veel van de moderne serverplatformen (o.a. NetWare) zijn in staat om hetzelfde IPadres aan twee kaarten te verbinden en hiermee load balancing en fail-over uit te voeren. Voorwaarde is wel dat er een switch wordt gebruikt om de server op aan te sluiten en dat de switch deze functionaliteit ook ondersteunt. Disksysteem Harddisks dubbel uitvoeren is waarschijnlijk de oudste vorm van inbouwen van redundantie. NetWare 3.11 was al in staat om gemirrorde disks te configureren, waardoor bij de uitval van een set disks (om welke reden ook) de gebruikers gewoon konden doorwerken omdat de data ook fysiek op de andere disk staat. Hoewel deze functionaliteit ook nu nog wordt geboden, zien we toch steeds meer dat gebruik wordt gemaakt van hardwarematige mirroring of van RAID5-oplossingen. Het uitgangspunt dat door een harddiskcrash het systeem gewoon blijft functioneren, is echter onveranderd gebleven. Processor Steeds meer servers kunnen worden uitgevoerd met meerdere processoren. Vaak worden deze processoren gebruikt om extra rekencapaciteit te kunnen bieden, maar ook vanuit het oogpunt van redundantie kan het een optie zijn om een dubbele processor te plaatsen. Er zijn namelijk servers te koop die bij een geconstateerd probleem met een van de processoren de machine opnieuw starten, maar werkend op alleen de goed functionerende processor. Natuurlijk levert


3/3.2-5


•

dit verlies aan snelheid op, maar gebruikers kunnen in elk geval snel weer doorwerken. Memory Dezelfde functionaliteit als beschreven bij de processor is ook mogelijk bij de memory. Zodra de computer merkt dat een deel van het geheugen niet goed meer functioneert, kan de machine (volledig automatisch) worden gereboot en kan de machine opstarten zonder het defecte geheugen. Ook hier is een performance-dip te verwachten, maar de systemen blijven in elk geval werken.

Als serieus wordt gekeken naar beschikbaarheid, is het, zeker gezien de laatste twee aandachtspunten, verstandig om de servers niet te krap uit te voeren. Ten eerste mag worden verwacht dat de servers in de periode dat ze operationeel zijn alleen maar meer te doen krijgen, maar door het overschalen wordt er tevens voor gezorgd dat de performance-dip bij het uitschakelen van een processor of een deel van het geheugen niet of nauwelijks merkbaar is bij de gebruikers. Een ander belangrijk onderdeel van beschikbaarheid is de mogelijkheid om het netwerk redundant uit te voeren. Uiteraard is het zinvol om te kunnen garanderen dat servers het altijd doen, maar als gebruikers niet bij de services kunnen komen omdat er een netwerkverbinding uitligt, blijft het eindresultaat onbevredigend. Een veelgebruikte mogelijkheid is om het netwerk te configureren als een spanningtree-netwerk. Hierdoor wordt door het netwerk, volledig automatisch, een andere route gevonden als een onderdeel (bijv. een switch of verbinding) het begeeft.

3/3.2-6


NetWare

Niveau 3: alarmering Dat onderdelen in het netwerk meer en meer in staat zijn om zelf fouten te detecteren en daar oplossingen voor te zoeken (beter gezegd: work-arounds voor te verzinnen), is mooi, maar het nadeel is dan dat problemen in het netwerk niet meer zo duidelijk zijn voor de beheerder. Als een disk is gecrasht en dit probleem vervolgens door het gebruik van RAID-5 wordt gemaskeerd opdat iedereen gewoon kan doorwerken, bestaat het risico dat ook de beheerder er geen weet van heeft. Als dan eventueel nog een tweede schijf crasht, gaat het systeem alsnog down en zal reparatie heel wat lastiger blijken te zijn. De kans dat dat relatief snel daarna gebeurt, is aanzienlijk; de schijven zijn immers even oud. De beheerder kan een procedure in het leven roepen waarbij regelmatig (bijv. eens per week) wordt gecontroleerd of alles nog goed functioneert, maar het is veel verstandiger om dit controlewerk te automatiseren. Niet alleen kan het dan continu meedraaien op de server, maar tevens zijn goede managementtools in staat om problemen te detecteren voordat gebruiker en beheerder dit zelf merken.


3/3.2-7


Managementtools, zoals ManageWise of ZENworks for servers, zijn in staat om servers en devices die SNMP (Simple Network Management Protocol ) enabled zijn te controleren. Bij gebleken problemen kan dit worden getoond op het beeldscherm van het managementconsole, maar ook is het mogelijk om meldingen via mail te versturen aan de beheerder of leverancier of om dit via een SMS-bericht te doen. Ook in het weekend kan de beheerder zo op de hoogte worden gebracht van problemen in het netwerk. Doordat er binnen bedrijven steeds meer wordt gewerkt ook buiten de normale werkuren, neemt de druk op de ICTafdeling om ook 7x24 uur beschikbaar te zijn, steeds verder toe. Dit is overigens een van de redenen waarom beheerders graag een betere beschikbaarheid willen. Natuurlijk eist de functie van beheerder dat er eventueel in het weekend of ’s avonds wordt gewerkt, maar dit mag niet te vaak gebeuren. Met systemen die een hoge beschikbaarheid hebben, zal het aantal storingen afnemen en dat geeft de beheerder weer wat rust. Om het werk nog gemakkelijker te maken, worden steeds vaker systemen zoals terminal-servers gebruikt om kleine storingen op afstand te kunnen oplossen. Daarnaast is een duidelijke toename in het aantal supportcontracten merkbaar, waarin dan veelal wordt opgenomen dat een beschikbaarheid van 7x24 uur noodzakelijk is. Niveau 4: known goods en hot spares Als organisaties een supportcontract voor hardware afsluiten, moeten zij daarin vastleggen welke service er wordt verwacht. Er is immers een groot verschil tussen de voorwaarde dat iets binnen 8 werkuren weer beschikbaar moet zijn en bijvoorbeeld een ‘call to fix’ van 4 uur.

3/3.2-8


NetWare

Reserves

Als ook zo’n call to fix van 4 uur te lang is, is feitelijk de enige mogelijkheid om zelf maar reserves op de plank te hebben liggen. Dit lijkt een dure oplossing, maar zeker als de hardware gestandaardiseerd is (alle servers zijn van hetzelfde type), hoeft er geen grote voorraad te worden opgebouwd. Verder wordt deze voorraad vaak gebruikt voor het opbouwen van een testomgeving waarin nieuwe instellingen en software kunnen worden getest voordat het op het live-systeem wordt geïmplementeerd. Let er wel op dat de zogenaamde reservevoorraad niet als productiemiddel wordt ingezet zonder dat er aanvulling plaatsvindt. Het is nogal pijnlijk om bij een probleem te moeten constateren dat de reserveharddisk in de server van de financiële administratie zit… Het voordeel van een eigen voorraad reserveonderdelen is verder dat deze apparatuur kan worden getest, zodat zeker is dat de apparatuur ook goed functioneert als het netwerk wordt geplaatst.

Hot spare

Bij disksystemen zien we echter dat men al een stap verder gaat. Hier wordt de extra disk alvast geplaatst en deze draait dus continu mee met het systeem. De huidige RAIDsystemen kunnen namelijk volledig automatisch bij een diskcrash de defecte disk herstellen op de extra geplaatste disk. Om deze reden noemen we een dergelijke disk een hot spare. Bij servers bestaat een dergelijke mogelijkheid. De standby oplossing die lange tijd beschikbaar was voor NetWare en de SFT-III (System Fault Tolerance level III )-oplossing die Novell tot en met NetWare 4 had, zijn voorbeelden van systemen die als hot spare meedraaien in het netwerk en alleen echt worden gebruikt bij het crashen van de productieserver.


3/3.2-9


Niveau 5: clustering Hoewel pas de laatste jaren binnen de pc-serveromgeving wordt gesproken over clustering, is clustering feitelijk al een ‘oude’ technologie. Digital Electric Corporation bedacht reeds in de jaren 1980 de term voor de VAX/VMSsystemen. Nu het pc-platform steeds meer een mission critical omgeving is geworden, zijn er vele implementaties van clustering. Clustering gaat ervan uit dat hardwarestoringen niet kunnen worden voorkomen. Waar voor moet worden gezorgd, is dat bij een storing aan een stuk hardware de functionaliteit (de services) die door die hardware wordt geboden, niet verloren gaat. Binnen een cluster wordt een groep van servers dus verantwoordelijk gemaakt voor een aantal services. Als een van de servers binnen de cluster crasht, hoeft dat geen probleem te zijn, mits een van de andere servers de services maar kan overnemen. En als die overname dan maar snel genoeg verloopt (binnen enkele seconden), zal de gebruiker hier zelfs helemaal niets van merken.

3/3.2-10


NetWare

Zo kan een complete GroupWise-postoffice binnen 8 seconden van server 4 naar server 3 springen bij een storing aan server 4. De connecties van de gebruikers worden automatisch weer opgebouwd en niemand heeft dus in de gaten dat er op een andere machine wordt gewerkt. Vanuit het oogpunt van de gebruikers is er dus zelfs in het geheel geen storing geweest.


3/3.2-11


3/3.2-12


NetWare

3/3.3

Novell Cluster Services-installatie

NetWare 5- en NetWare 6-servers kunnen niet gezamenlijk in een cluster worden geplaatst. Er is een migratie mogelijk van NetWare 5- naar NetWare 6-clusters, maar tijdens deze migratie zal de cluster enige tijd down moeten. Indien gewenst kan deze downtime worden beperkt tot enkele minuten, hoewel een ‘normale’ migratie vaak wenselijker is. 3/3.3.1 Prerequisites Voor Cluster Services gelden in principe dezelfde memoryeisen als voor een normale NetWare-server. Voor NetWare 5.1 is dit 128 Mb (256 Mb aanbevolen) en voor NetWare 6 256 Mb (512 Mb aanbevolen). Dit zijn absoluut minimumwaarden. In de ontwerpfase moet al worden gedacht aan een worst case-scenario: hoeveel memory en processorcapaciteit heeft de server nodig als deze álle bedrijfskritische applicaties moet draaien. We hopen deze situatie natuurlijk nooit mee te maken, maar als alle andere cluster-servers down zijn, kan het noodzakelijk zijn om alles op één server te laten draaien.

Zoning-off

Het SYS:-volume kan niet op shared storage worden geplaatst. Dit is logisch, aangezien elke server zijn eigen SYS:-volume nodig heeft om op te starten. Er zijn leveranciers (bijv. XioTech) die de mogelijkheid hebben om servers ook te laten booten van de SAN-disks. Dit is dan mogelijk gemaakt door een proces dat zoning-off heet. Voordeel van deze methode is dat het gemakkelijk is om een spare-server aan te sluiten. Als een server crasht, is het voldoende om de kabels uit die server in de spare-server te zetten en de server weer te booten. Voorwaarde is natuurlijk wel dat de servers (min of meer) dezelfde configuratie hebben.


3/3.3-1


Hiermee kunnen ook hardwarestoringen snel worden hersteld.

SBD

Op de SAN dient minimaal 20 Mb aan ruimte te worden vrijgehouden voor het aanmaken van de SBD (Split Brain Detector)-partitie. Deze partitie wordt automatisch tijdens de installatie van Cluster Services aangemaakt en wordt gebruikt door alle member-servers om keep alive-informatie met elkaar uit te wisselen. Indien één van de servers niet meer schrijft op de SBD-partitie, concluderen de andere servers dat deze server de connectie met de SAN kwijt is en zullen ze de resources van de server op andere nodes gaan opstarten. Eenzelfde proces loopt overigens ook via het LAN, waardoor altijd de status van de servers te achterhalen is. Cluster Services kunnen alleen maar gebruikmaken van TCP/IP als transportmedium. Dit betekent niet dat er geen IPX meer geladen mag zijn op de servers, maar wel dat het niet mogelijk is om een fail-over uit te voeren op basis van IPX. Dit komt omdat IPX gebruikmaakt van de MAC-adressen van de netwerkkaarten en deze veranderen uiteraard als een volume ‘opeens’ aan een andere server hangt. Verder is het verplicht om alle servers die in een cluster worden opgenomen in hetzelfde subnet te installeren. Tevens moet er rekening mee worden gehouden dat ook elke clusterapplicatie een eigen (uniek) IP-adres moet hebben. Reserveer dus voldoende IP-adressen binnen een subnet om alle servers en alle clusterapplicaties van een uniek IP-adres te kunnen voorzien. 3/3.3.2 Set-up In de meest eenvoudige vorm dient een cluster te bestaan uit twee servers die minimaal één gezamenlijke disk heb-

3/3.3-2


NetWare

ben. In ons voorbeeld is ook voor deze set-up gekozen. Hierbij zijn beide servers aangesloten op het netwerk binnen dezelfde IP-reeks. De servers booten van een eigen disk en kunnen daarna gebruikmaken van een gesharede SCSI-disk (de SAN).

Fibre

In professionele set-ups zal vrijwel altijd worden gekozen voor een SAN dat gebaseerd is op fibre-hubs. Tegenwoordig zien we dat er, door de wens naar meer snelheid, fibreswitches zijn geïntroduceerd. Deels omdat de kans op storingen binnen een SCSI-based cluster groter zijn, maar zeker ook omdat fibre-oplossingen een veel hogere doorvoer halen (snelheden van 1 Gb zijn tegenwoordig standaard). Binnen productieomgevingen is het natuurlijk niet wenselijk om de snelheid te verhogen ten koste van de veiligheid als zo’n verhoging niet per se noodzakelijk is. Er dient dan ook telkens een zorgvuldige afweging van de voor- en nadelen te worden gemaakt. 3/3.3.3 Licenties Voor clustering zijn licenties noodzakelijk; we connecten immers aan een NetWare-server. Juist binnen de licentie-


3/3.3-3


procedure is er, bij de overgang van NetWare 5.1 naar NetWare 6, veel veranderd, wat zijn weerslag heeft op de manier waarop de licenties van Cluster Services worden berekend. Aan de hand van bovenstaande set-up en uitgaande van 200 gebruikers zullen de licentievereisten voor zowel NetWare 5 als voor NetWare 6 worden uitgelegd. Van deze 200 gebruikers werken er 100 op server 1, 75 op server 2 en 25 op beide servers. NetWare 5 In een NetWare 5-omgeving is voor elke server een Server Based License noodzakelijk. Dit is ongeacht het aantal gebruikers dat van deze server gebruik gaat maken. Daarnaast is voor iedere gebruiker een licentie per server nodig. Voordat clustering wordt geïmplementeerd, zijn dit dus de licenties die minimaal nodig zijn om in deze situatie te kunnen werken: Server Based Licenses User Access Licenses (server 1) User Access Licenses (server 2)

2 125 100

Bij de installatie van Cluster Services wordt voor elke server in de cluster de Server Based License vervangen door een Cluster Server License. Cluster Services maakt hierbij overigens geen onderscheid in NetWare 5.0- of NetWare 5.1-servers. Alle User Access Licenses worden verwijderd en vervangen door Cluster User Access Licenses. Een groot nadeel van deze methode is dat hiermee de normale toegang tot de servers niet meer mogelijk is: alle toegang zal via Cluster Resources moeten lopen. Voor de directory’s op SYS: (met name SYS:\PUBLIC) is dit een probleem. Hiervoor zijn twee mogelijke oplossingen: ofwel opnieuw User Access Licenses aanschaffen en installeren

3/3.3-4


NetWare

of alle resources daadwerkelijk naar een cluster-resource verplaatsen (SYS:\PUBLIC verplaatsen naar VO1:\PUBLIC). Ervan uitgaande dat wordt gekozen voor de eerste optie (licenties toevoegen), wat ook de aanbevolen strategie is van Novell, zijn er na de implementatie dus de volgende licenties nodig: Cluster Server License Cluster User Access License User Access License (server 1) User Access License (server 2)

2 200 125 100

Een deel van de prijs die wordt betaald voor een veiligere omgeving is dus dat er meer licenties noodzakelijk zijn. Bij een MLA-licentie worden geen licenties verwijderd of aangepast. In deze licentievorm worden alleen Cluster Server Licenses toegevoegd.

NetWare 6 Een van de meest opvallende verschillen in termen van kosten tussen NetWare 5 en NetWare 6 is de manier waarop licenties worden vastgesteld. Niet langer wordt dat per user/per server gedaan, er wordt alleen nog maar gekeken naar het aantal gebruikers dat is ingelogd in de server. Voor een NetWare 6-netwerk zonder Cluster Services geïnstalleerd, betekent dit dus dat de volgende licenties nodig zijn: Server Based Licenses User Access Licenses


2 200

3/3.3-5


Let er wel op dat licenties van NetWare 6 gedurende 75 dagen gelockt worden voor een bepaalde gebruiker. Als iemand is ingelogd, blijft de licentie dus 75 dagen alleen maar voor die gebruiker beschikbaar. Door de single license per tree-manier van licenseren is het natuurlijk niet meer noodzakelijk om User Access Licenses om te vormen. Met de licenties die aan gebruikers worden toegekend, gebeurt dus niets bij de installatie van Cluster Services. Aan de serverzijde is echter nog wel een clusterlicentie nodig per server. De eerste twee licenties hiervoor zijn echter gratis! Als er twee serverlicenties zijn aangeschaft, kan er dus zonder verdere licentiekosten een 2-nodecluster worden gebouw. Zonder extra kosten te hoeven maken, zien de licenties in ons voorbeeld er na installatie van Cluster Services dus als volgt uit: Cluster Server License User Access License

2 200

Kostentechnisch gezien is het dus voordelig om Cluster Services te installeren op NetWare 6. Zeker als er veel gebruikers in de omgeving zijn, kan dit een belangrijke (financiële) reden zijn om een migratie naar NetWare 6 te plannen. Ook vanuit technisch oogpunt is het wenselijker om Cluster Services op NetWare 6 dan op NetWare 5 te implementeren.

3/3.3-6


NetWare

3/3.3.4

Filesysteemrechten

Verschillen tussen NetWare 5- en NetWare 6-clusters Zoals al aangegeven, is er een heel goed financiële reden om clusters op NetWare 6 in plaats van op NetWare 5 te implementeren. Ook vanuit de belevingswereld van de beheerder is het wenselijk om NetWare 6 te gebruiken. Dit heeft alles te maken met de filesysteemrechten die worden uitgedeeld. Filesysteemrechten worden niet opgeslagen in de eDirectory, maar worden op het filesysteem zelf opgeslagen. In NetWare 5 worden deze rechten gegeven op basis van de local ID die een gebruiker heeft. Deze local ID is gekoppeld aan de GUID (Globally Unique ID) die in eDirectory is opgeslagen, maar is voor elke server anders. Als een volume van de ene cluster-node naar de andere wordt verplaatst, kloppen de filesysteemrechten dus niet meer. Gebruikers kunnen dan niet meer bij hun bestanden komen, ondanks dat het volume gewoon beschikbaar is.

In theorie zou het zelfs mogelijk zijn dat de local ID van gebruiker 1 op server 1 gelijk is aan de local ID van een andere gebruiker op een andere server. Deze andere gebruiker kan dan dus bij de bestanden van gebruiker 1 als het volume aan server 2 gekoppeld is. De kans dat dit gebeurt, is echter zeer klein, aangezien er zeer veel local ID’s mogelijk zijn.

Om dit probleem op te lossen, maakt Cluster Services voor NetWare 5 gebruik van de trustmig.nlm. Als deze NLM geactiveerd is voor een bepaald volume (dit wordt standaard gedaan voor alle volumes die door de cluster worden gecontroleerd), worden alle wijzigingen van filesysteemrechten bijgehouden in een file in de _netware-directory in de root van dat volume. In dit bestand staat welke


3/3.3-7


eDirectory-objecten rechten hebben. Bij het mounten (via Cluster Services) van dat volume op een server, wordt gekeken welk local ID het object op die server heeft en worden de rechten opnieuw gegeven. Het nadeel van deze ‘work around’ is dat dit enige tijd kost en dat het bestand corrupt kan raken. Om het mounten van een volume niet te lang te laten duren, raadt Novell aan om niet meer dan ± 20.000 trustees per volume te hebben. Technisch gezien is er geen limit aan de lengte van het turstmig-bestand. Voor het beperken van het risico van een corrupt bestand is het natuurlijk belangrijk regelmatig een back-up te maken van de rechten en dient ervoor te worden gezorgd dat de trustmig.nlm altijd geladen is – en dat het volume ook alleen maar via de Cluster Services wordt gemount. NetWare 6 maakt gebruik van GUID's voor het opslaan van filesysteemrechten. Hierdoor speelt bovenstaande problematiek helemaal niet meer. Een ander voordeel van werken met Cluster Services van NetWare 6 is, dat we in staat zijn de namen van volumes en (virtuele) servers zelf te bepalen. Dit was in NetWare 5 nog niet mogelijk, wat resulteerde in lange namen binnen de clusteromgeving. Voor een volume was dit opgebouwd uit de naam van de cluster aangevuld met de naam van het volume: cluster_volume. Voor een virtuele server is de naam: cluster_volume_server.

3/3.3-8


NetWare

Voorbeeld Binnen een cluster genaamd cluster1 wordt volume data9 gemount. Bij het mappen van dit volume dient dus het volgende commando te worden gegeven: map k:=cluster1_ data9_server\cluster1_data9: Via TCP/IP of DNS kan dit mappen wel gemakkelijker worden gemaakt, maar echt fraai is het natuurlijk niet. Binnen NetWare 6 kunnen we de naam van de virtuele server en van het volume helemaal zelf bepalen.


3/3.3-9


3/3.3-10


NetWare

3/3.4

Novell Cluster Services – theorie

Tussen Cluster Services versie 1.01 (NetWare 5) en 1.6 (NetWare 6) zit qua design niet zo veel verschil. In ons voorbeeld wordt daarom gemakshalve alleen ingegaan op de opbouw van Cluster Services 1.6. Naast de al eerder aangegeven verschillen met betrekking tot namen van objecten biedt Cluster Services 1.6 de mogelijkheid om vrijwel alle commando’s vanaf de command-prompt van een NetWare-server uit te voeren en heeft het de mogelijkheid om te integreren met het remote-managementconsole (de webmanager) van NetWare 6.

CLSTRLIB De Cluster Library verzorgt de communicatie met de eDirectory. Om een altijd consistente view in eDirectory te krijgen – van de cluster –, mag alleen de master node communiceren met de eDirectory. De slave nodes cachen de gegevens van de master node bij het joinen van de cluster


3/3.4-1


en verversen dit ook aan de hand van informatie die via de master node wordt aangeleverd. Bij uitval van de master node zorgt een election-proces ervoor dat er een nieuwe master wordt verkozen om zo altijd een single point of administration te houden. GIPC De Group InterProcess Communication-nlm is de nlm die controleert welke servers member zijn van de cluster. Daarnaast zorgt dit proces ervoor dat de members continu een heartbeat (via het netwerk) met elkaar uitwisselen. Indien hieruit blijkt dat een node niet meer reageert, wordt deze informatie doorgegeven aan de VLL.NLM, door de GIPC die op elk van de nodes draait. SBD De Split Brain Detector zorgt ervoor dat er via de shared storage een heartbeat-proces wordt uitgevoerd. Hiertoe wordt tijdens de installatie van Cluster Services een SBDpartitie aangemaakt waar elke node op kan schrijven. Elke node schrijft hierop zijn eigen heartbeat counter weg en leest die van de andere servers. Als een van de counters niet meer oploopt, weten de andere servers zodoende dat de bijbehorende server niet langer kan communiceren met de shared storage. Door de overblijvende servers wordt vervolgens een poison pill weggeschreven voor de server die problemen heeft, waardoor deze server, als hij niet opnieuw wordt gestart, automatisch een abend krijgt als de communicatie met de shared storage weer wordt hersteld. VLL De Virtual interface architecture Link Layer zorgt ervoor dat de informatie en de communicatie met de GIPC en de

3/3.4-2


NetWare

SBD via een gestandaardiseerde set van API’s kunnen verlopen. Zie voor meer informatie hierover www.viarch.org. VIPX De Virtual Interface Provider Library Extensions is de manier voor Novell om zich te confirmeren aan de Virtual Interface (VI)-standaard zoals die is gedefinieerd voor clusters. Door het gebruik van de VIPX is het eenvoudiger om programma’s te maken voor beheer en monitoren van de cluster. CSS De Cluster System Services wordt door cluster aware-processen gebruikt om zaken binnen de cluster te regelen. Op dit moment is dit voornamelijk nog het locken van volumes als deze zijn toegewezen aan een cluster-node, maar in de toekomst zal ook shared memory gelockt gaan worden via de CSS. CRM De Cluster Resource Manager op de master node controleert alle resources die actief zijn op de cluster. Op de slave nodes wordt deze informatie geüpdatet aan de hand van de informatie op de master node, zodat bij het uitvallen van de master node de overige nodes weten welke applicatie waar draait en welke nodes verder actief zijn. CVB De Cluster Volume Broker is de interface tussen Cluster Services en het NSS-file-systeem. De CVB zorgt er onder andere voor dat volumes kunnen worden geactiveerd op de ene server en daarmee direct worden gelockt op de andere cluster nodes. Doordat deze events door de CVB worden bijgehouden, kunnen servers die geen cluster services hebben geladen, dus ook de status van volumes niet weten.


3/3.4-3


Dit is een potentieel gevaar in een mixed node-omgeving. CMA De Cluster Management Agent regelt de communicatie met ConsoleOne. Bij deze communicatie wordt gebruikgemaakt van het proprietary-protocol. De CMA geeft onder andere de huidige status weer en voert de commando’s door die de beheerder via ConsoleOne geeft. PCLUSTER De Portal Cluster is een uitbreiding van de Novell Remote Manager (NormMan) en zorgt ervoor dat Cluster Services kan worden beheerd vanaf de webbrowser. Hiertoe hoeft alleen maar contact te worden gemaakt met het IP-adres dat bij de installatie aan de cluster is toegewezen. De master node beheert dit IP-adres. CMON De Cluster Monitor is een tool waarbij vanaf de Novell-server direct kan worden gekeken welke nodes actief zijn in een cluster en wie de master node is. Deze tool wordt automatisch opgestart op alle cluster nodes bij het activeren van de Cluster-software. Het is aan te raden deze software niet te laten draaien als de Cluster eenmaal gestart is. Alle nodes moeten namelijk aan de master node de status opvragen, wat behoorlijk veel netwerkverkeer tot gevolg heeft.

Heartbeats

3/3.4-4

3/3.4.1 Split Brain Detection Een cluster is gemaakt om in het geval van een hardwarestoring aan een van de nodes, in staat te zijn om de resources (services) van die node naar een andere machine over te doen. Om dit te kunnen bereiken, worden er via twee wegen heartbeats tussen de servers uitgewisseld: via het netwerk en via de SAN. Zodra een van de servers niet


NetWare

binnen de vastgestelde tijd via beide kanalen minimaal een heartbeat heeft uitgewisseld met de andere nodes, gaan de andere nodes ervan uit dat de machine niet meer actief is; er volgt een node cast-out en de overgebleven servers nemen de functionaliteiten over. Door de gezamenlijke clusternodes moet wel worden bepaald welke van de nodes wel correct werken en welke niet. In een grote cluster is dit relatief eenvoudig te doen, maar hoe kleiner de cluster wordt, hoe groter de kans dat de verkeerde node wordt gekozen.

In het bovenstaande voorbeeld is het, nadat de netwerkverbinding met server 4 is verbroken, logisch dat de andere drie servers overleven. Maar stel eens voor dat alleen server 3 en server 4 in deze cluster actief waren geweest! Beide hadden ze dan geoordeeld dat de andere de verbinding met het netwerk kwijt was. Deze situatie noemen we een split brain.


3/3.4-5


Regels bij split brain

3/3.4-6

De cluster heeft een aantal regels die in het geval dat een split brain optreedt, in werking treden: • De zijde met de meeste servers wint. In het bovenstaande voorbeeld is een split brain ontstaan van 3 + 1 node. De helft met drie nodes zal overleven, de andere krijgt een poison pill. • Als aan beide zijden evenveel nodes actief zijn, wint de zijde waarin de master zich bevindt. • In het specifieke geval van een 2-node-cluster is de kans dus 50% dat de goede server down gaat en er uiteindelijk geen enkele communicatie meer is. Hiervoor is vanaf de eerste SP van Cluster Services 1.01 een extra check ingebouwd: de 2 node tie breaker. Hierbij wordt voor het abend als extra nog gecontroleerd of een van beide servers een link-dead heeft op de netwerkkaart. Als dat zo is, moet dat dus de server zijn die niet meer goed functioneert en krijgt die server dus ook de poison pill.


3 High availability en clustering

Recommend Documents