Clustering verhoogt beschikbaarheid op locaties

Hoge beschikbaarheid – met name van online systemen – is van groot belang voor de business. Clustering kan bijdragen aan het verhogen van de beschikbaarheid, zodat de kans op het uitvallen van een applicatie of dienst wordt verkleind. Het is echter geen fouttolerante oplossing of vervanging van back-up. Consultants Remco Lengers en Arnold van der Kaaij over succesfactoren en mogelijke problemen.

Beschikbaarheid is een van de belangrijkste criteria aan online systemen. Met de huidige ontwikkeling van internet neemt het belang alleen maar toe. Beschikbaarheid is een ontwerpcriterium geworden. Niet dat het voorheen onbelangrijk was, maar de impact van ‘downtime’ is enorm toegenomen. De reden is dat mensen van buiten de organisatie tegenwoordig direct interactie hebben met de systemen. Er is geen isolatie tussen deze gebruikers en systeemproblemen. Denk hierbij aan volledig internetgeoriënteerde bedrijven die 100 procent van hun business doen via een webgeoriënteerde interface naar de ordersystemen. Als deze systemen down zijn, kan dit bedrijf niet alleen geen orders meer boeken, maar raken klanten gefrustreerd zodat ze wellicht ergens anders hun orders plaatsen en nooit meer terugkomen. De concurrent is immers slechts één muisklik van je verwijderd!
Er zijn verschillende technieken om de beschikbaarheid van platformen te verhogen. Vaak worden daarvoor clusteringtechnieken gebruikt.
De term ‘clustering’ wordt voor verschillende doeleinden gebruikt in de automatisering. Naast clustering van open (Unix) systemen in verband met beschikbaarheid, zien clustering ook veel in de ‘high performance’-wereld. In deze vorm van clustering wordt een grote werklast verdeeld over meerdere kleine systemen, waarbij de beschikbaarheid vaak minder belangrijk is. Je kunt op die manier met vele kleine (en vaak goedkope) systemen bijvoorbeeld een grote rekentaak aan. Hierbij valt te denken aan Linux Beowulf en Sun Gridware (zogenaamde ‘compute clusters’). Deze vormen van clustering vallen buiten het bestek van dit artikel.

Uitval

Clustering in verband met beschikbaarheid vindt plaats om te voorkomen dat een service of applicatie uitvalt door het uitvallen van een kritische component binnen het platform. Een platform is opgebouwd uit een groot aantal componenten. De beschikbaarheid van het hele platform wordt bepaald door de frequentie waarmee kritische componenten uitvallen en de snelheid waarmee deze componenten te repareren zijn. Er zijn dus twee factoren van belang: de mean time between failure (mtbf) en de mean time to repair (mttr) van de individuele componenten. De mtbf van het totale platform wordt bepaald door de som van de betrouwbaarheid van de individuele componenten. De tijd die nodig is om deze componenten te repareren (mttr) na uitval is de andere belangrijke factor die van invloed is op de beschikbaarheid van het totale platform. Met andere woorden: hoe betrouwbaarder de individuele componenten (hoge mtbf) zijn en hoe sneller je iets kunt repareren (lage mttr), des te beter is de totale beschikbaarheid. ‘Online’ reparatie speelt een belangrijke rol in de verhoging van de beschikbaarheid.
Indien een systeem de mogelijkheid biedt redundante componenten te configureren (een tweede stroomvoorziening bijvoorbeeld, terwijl het systeem er slechts één nodig heeft) en je deze ook nog online kunt vervangen zonder verstoring van de processen, kan de mttr zelfs nul worden. Er zijn systemen waarbij zelfs processoren, i/o-interfaces, geheugen en dergelijke, online vervangen kunnen worden zonder het besturingssysteem en daarop draaiende applicaties te stoppen. Hiervoor moet je naast hardwarefaciliteiten ook in het besturingssysteem het nodige geregeld hebben (‘dynamische reconfiguratie’). Dergelijke mogelijkheden brengen de beschikbaarheid van een enkel systeem al tot een zeer hoog niveau. Er zijn twee termen om aan te duiden dat een component online kan worden verwisseld: ‘hot-swap’ en ‘hot-plug’. Deze termen veroorzaken nog wel eens verwarring. De mogelijkheid om componenten op een (elektrisch) veilige manier toe te voegen aan of te verwijderen van een draaiend systeem noemen we ‘hot-plug’. Indien voor deze ‘hot-plug’-mogelijkheid ook softwarematig alles is geregeld om de componenten te kunnen verwijderen of toe te voegen, zonder applicaties en het besturingssysteem te stoppen, dan noemen we dat hot-swap.
Ondanks deze beschikbaarheidsverhogende voorzieningen zijn er in dergelijke systemen toch nog zogenaamde ‘single point of failures’ (spof’s) aan te wijzen, ofwel componenten binnen dat platform (hardware of software) die elk afzonderlijk bij uitval het hele platform platleggen (en dus ook de applicaties c.q. services). Door naast dit systeem een ander systeem neer te zetten, en deze door middel van specifieke hardware en clustersoftware aan elkaar te koppelen, wordt de mogelijkheid geboden om bij uitval van het systeem, de services over te nemen op het back-up systeem. Naast deze basisfunctionaliteit bieden ‘high availability’ (ha) clusters tegenwoordig nog vele andere mogelijkheden, waarover later meer.

Kosten en baten

De werkelijke kosten van het niet beschikbaar zijn van systemen, kunnen laag tot astronomisch hoog zijn. Het is belangrijk te onderkennen dat niet alle systemen dezelfde beschikbaarheid vereisen. De kosten voor de infrastructuur nemen exponentieel toe, wanneer er meer ‘uptime’ vereist is. Het is dus belangrijk beschikbaarheidseisen aan systemen af te zetten tegen de sla (‘service level agreement’) die met de uiteindelijke gebruikers is afgesloten. Als besloten is dat een enkelvoudig systeem niet de gewenste beschikbaarheid kan bieden, is een ha-cluster de volgende stap.
Aanvankelijk liggen in een project de beschikbaarheidseisen (vanuit het management team) vaak op 100 procent.
Een kort overzicht van de globale kosten voor 100 procent beschikbaarheid (of iets dat dicht in de buurt komt) overtuigt mensen meestal snel om de beschikbaarheidseisen af te stemmen op de reële business-eisen. Tabel 1 geeft een indruk welke configuraties welke beschikbaarheid kunnen bieden.
 
Tabel 1. Beschikbaarheid in relatie tot configuratie.

Beschikbaarheid van wat?

De getallen uit tabel 1 worden door leveranciers te pas en te onpas naar voren gebracht. Het is belangrijk te vragen waarop deze getallen betrekking hebben. Zo worden bijvoorbeeld op fouttolerante systemen garanties gegeven tot wel vijf negens (99,999%)! Bij fouttolerante systemen duiden die getallen vaak op hardware-beschikbaarheid. Ze zeggen dus niets over bijvoorbeeld de beschikbaarheid van besturingssysteem en applicaties.
Op enkelvoudige systemen en clusters geldt de garantie vaak tot en met het besturingssysteem. Anderen geven zelfs applicatiebeschikbaarheidsgaranties af, al zijn de keuzemogelijkheden van de configuraties beperkt en zijn de voorwaarden die aan de klant worden gesteld erg strikt. Controleer dus altijd wat de leverancier bedoelt met deze getallen, wat de voorwaarden zijn (of die haalbaar zijn) en wat de tegenprestatie van de leverancier is, wanneer deze getallen niet worden bereikt.
Daarnaast is het belangrijk te weten hoe de sla is opgesteld. Vaak wordt uitgegaan van de beschikbaarheid aan de zijde van de gebruiker. In dat geval dient ook gekeken te worden naar netwerkinfrastructuur en andere apparatuur die nodig is om de gebruiker te verbinden met zijn of haar applicaties. Deze overige apparatuur valt vrijwel nooit onder dit soort leveranciersgaranties.
Wanneer men garanties geeft, dan betreft dat altijd garanties ten aanzien van de ongeplande storingstijd (unplanned downtime) en nooit voor de geplande storingstijd. Bij geplande storingstijd moet worden gedacht aan het maken van back-ups, een upgrade van hardware, applicaties, databases en besturingssystemen, en reparatie aan hardware (die niet ‘hot-swapable’ is!). Dit zijn dus taken die vooraf gepland kunnen worden. Juist ook hierbij biedt een cluster uitkomst, omdat services eenvoudig verplaatst kunnen worden van het ene naar het andere knooppunt, zodat voor gepland onderhoud de services niet ‘uit de lucht’ hoeven.
Voorbeelden van ongeplande storingstijd zijn uitval van ‘single point of failures’ in hardware en software, menselijke fouten en uitgelopen geplande storingstijd.
Laten we eens verder kijken wat de precieze oorzaken zijn van ongeplande storingstijd om te kunnen zien welk deel van de storingstijd wordt geadresseerd met een cluster. Uit onderzoek blijkt dat slechts 20 procent van de (ongeplande) storingstijd wordt veroorzaakt door het platform. Dat is dus alle hard- en software (‘product’), terwijl de mensen en de processen de overige 80 procent voor hun rekening nemen. Zo kan het wijzigen van een eenvoudige systeemparameter direct storingstijd tot gevolg hebben, terwijl dit was te voorkomen door een goede wijzigingsprocedure (wijzigingsbeheer).

Technische factoren

Het platform zelf is verantwoordelijk voor 20 procent van de totale (ongeplande) storingstijd. Dit is een aanzienlijk aandeel en hier kan dus de nodige winst worden behaald. Belangrijk om te beseffen is dat ‘het platform’ niet alleen de hardware betreft. Het is een combinatie van netwerkinfrastructuur, de applicatie(s), het besturingssysteem, de ondersteunende systeemsoftware en de hardware zelf. De keuzes die hier worden gemaakt, bepalen vaak de laatste tienden van procenten van beschikbaarheid.
Wanneer je dichter bij de 100 procent beschikbaarheid komt, neemt de investering om de honderd procent te bereiken exponentieel toe. De beslissingen moeten dus worden genomen op basis van de business-eisen.
Onder de technische factoren verstaan we: netwerk-foutbestendigheid (redundante netwerken en ‘multipathing’); hardware-hardening (ongevoelig maken voor storing) door gebruik te maken van zaken als dynamische reconfiguratie, ‘alternate pathing’, ‘hot-swap’, enzovoort; softwarestabiliteit (besturingssysteem, applicaties); betrouwbare opslag (redundantie door toepassing van raid-technologieën), en het dupliceren van systemen (clustering).
Omdat fouten in deze componenten 20 procent van de totale ongeplande storingstijd veroorzaken, is gebruik van bewezen technologie belangrijk.

Processen

Niet alleen technische factoren spelen een rol. Circa 40 procent van de ongeplande storingstijd wordt veroorzaakt door fouten in processen. We kunnen veel leren van twintig jaar mainframe-beheer. De ervaringen van systeembeheerders uit het mainframe-tijdperk zijn dan ook van grote waarde in de wereld van de open systemen. Processen ter verbetering van de beschikbaarheid moeten breed georiënteerd zijn en getoetst worden op hun potentiële impact op de beschikbaarheid op alle niveaus. De meeste aandacht krijgen de procedures en processen die nodig zijn voor het beheren van het systeem waarop de applicaties draaien. Maar vergeet niet dat de service die wordt geboden door een applicatie vaak door meer zaken beïnvloed kan worden dan alleen het systeem. Het is meestal een samenspel van een aantal systemen en netwerken. Ieder proces dient zo te zijn ingericht dat het rekening houdt met alle componenten in kwestie. Van het platform zelf en de gekoppelde opslag tot aan de netwerkinfrastructuur die uiteindelijk de eindgebruiker verbindt met de service.
De benodigde processen zijn in te delen in de volgende groepen:
Regels voor systeembeheer; standaarden/blauwdrukken voor systeeminstallatie en -configuratie; wijzigingen beheer; onderhoud en patch-beheer; upgrade- en versie-beheer; probleemescalatie, ondersteuningsovereenkomsten; testvoorschriften; back-up en herstel;
systeemherstelprocedures (herinstallaties, enzovoort), en uitwijkplanning (herstel bij rampen).
Een goede leidraad hiervoor biedt de Itil-(IT Infrastructure Library) methodiek die een leidraad vormt voor inrichting van de it-organisatie op dit vlak. Een groot aantal dienstverleners heeft services in huis om bedrijven bij onderzoek en implementatie te ondersteunen.

De factor mens

De laatste 40 procent wordt bepaald door de menselijke factor. Vaak wordt gezegd dat hoge beschikbaarheid het effectiefst te bereiken is, wanneer die als een ‘houding’ wordt gezien. Een klant vertelde onlangs al hun beheerspersoneel te hebben medegedeeld dat er geen ruimte meer is voor ‘cowboys’, maar dat goede ideeën en creativiteit van mensen gestimuleerd en beloond worden. Belangrijk in deze boodschap is dat de potentiële ‘creativiteit’ voor de lange termijn is gescheiden van die voor de korte termijn, de ‘quick fix’ die uiteindelijk meer ellende veroorzaakt dan oplost.
Een andere klant vertelde dat het hun beleid was om iedere wijziging aan een systeem verplicht te laten controleren door een collega. Dit werd door de beheerders aanvankelijk uitgelegd als een ‘gebrek aan vertrouwen’, maar na verloop van tijd was de kwaliteitsverbetering als gevolg van dit beleid voor iedereen waarneembaar. Doordat iedere wijziging nog eens extra wordt doordacht, worden de (menselijke) fouten tot een minimum beperkt.
Een gedegen opleiding van beheerders en andere operationele mensen is onontbeerlijk. Het is een goede investering en voorkomt een groot deel van de problemen. Tijdelijk mensen voor beheer inhuren is vaak geen constructieve oplossing. De praktijk leert dat deze mensen goed getraind zijn of worden, maar dat met hun vertrek ook al hun kennis direct weer verdwenen is. Een goed voorbeeld hiervan vormt de groep startende bedrijven die moeite heeft om goed gekwalificeerd personeel aan te nemen, maar wel binnen enkele weken een hele omgeving moet inrichten. De mensen die de configuratie installeren en operationeel maken, verdwijnen vervolgens naar het volgende project en laten enkele collega’s achter om het volledige beheer te doen. Ook starten dergelijke bedrijfjes vaak met relatief kleine systemen en een beperkte infrastructuur, waarvan de beheerders alles nog redelijk kunnen overzien. Maar na een jaar van explosieve groei moeten ze een voetbalveld vol middelzware en zware systemen beheren, zonder daarvoor getraind te zijn.
Uiteindelijk is het belangrijk om niet alleen eigen personeel te screenen en te testen, maar ook het servicepersoneel van de leveranciers. Ontwikkelaars of beheerders die thuis hun eigen Windows 98- of Linux-machine beheren, zijn nog geen goede beheerders van bedrijfskritische systemen. Het komt wel voor dat eigen personeel goed gekwalificeerd is, en dat een binnengehaalde service-engineer rustig met een boek op schoot de problemen tracht op te lossen op het ‘live’ productiesysteem. Dit is een riskante vorm van ’training on the job’!
Als de processen en procedures echter goed zijn (en goed worden gevolgd), zijn de vaardigheden van de mensen minder belangrijk. Aan de andere kant geldt dat als mensen exact weten waar ze mee bezig zijn, strakke procedures en processen minder noodzakelijk zijn. Hiertussen dient een evenwicht gevonden te worden.

Geen fouttolerante oplossing

Clusters worden te pas en te onpas ingezet om de beschikbaarheid van applicaties te verhogen. Clustering is in potentie een goede oplossing om het beschikbaarheidprobleem aan te pakken. Het beheer wordt hierdoor echter complexer, en dat wordt nog wel eens vergeten. In plaats dat het beheer van een enkele kopie (‘instance’) van het besturingssysteem volstaat, moet nu bij iedere handeling op het ene systeem worden nagedacht over de gevolgen ervan op de andere systemen van het cluster. Intelligente cluster-raamwerken lossen dit tegenwoordig grotendeels op door gebruikmaking van globale filesystemen, netwerken en apparaten die het cluster een ‘single administrative view’ geven. Het blijft echter zaak mensen goed te trainen. Verder kan het gebruik van grafische interfaces het werk aanmerkelijk verlichten. Wanneer beheerpersoneel zes maanden na hun training een wijziging moet doorvoeren, zijn ze de ‘command line’-opties vergeten. Een grafische interface biedt dan uitkomst.
Clustering biedt hoge beschikbaarheid, maar is geen fouttolerante oplossing. De perceptie bestaat dat applicaties die draaien op een cluster nooit down gaan. Echter, uitval van een cluster-knooppunt betekent dat de applicatie op een ander kooppunt herstart moet worden. Hiervoor moeten de disks, volumemanager, volumes, filesystemen en dergelijke worden overgenomen. Pas daarna is herstel van de applicatie mogelijk. Bij grote databases zijn ‘failover’-tijden van een half uur geen uitzondering. Ook de client-software moet hiermee kunnen werken. Immers, tijdens een dergelijke ‘failover’ (overnemen van de taken tijdens storing) is de service c.q. applicatie tijdelijk niet beschikbaar en moet de client-software dus wachten en opnieuw verbinding maken wanneer die wel weer beschikbaar is. Er is clusteringsoftware op de markt waarbij services c.q. applicaties parallel gedraaid worden (meerdere kopieën verdeeld over meerdere systemen) waardoor ‘failover’ in feite een hernieuwde verbinding is naar de andere service c.q. applicatie. Ook hierop moet de client-software zijn aangepast.
Traditioneel biedt clustering software bescherming tegen uitval door ‘single point of failures’. Heel geleidelijk zien we een verschuiving naar servicemanagementraamwerken die meer en meer bestendigheid tegen fouten (‘resiliency’) bieden en naast hoge beschikbaarheid ook schaalbaarheid bieden voor applicaties. ‘Single point of failures’ worden steeds vaker in de hardware afgevangen door redundantie in componenten en geavanceerde features in de besturingsystemen (‘dynamische herconfiguratie’).

Praktische tips

Tenslotte nog wat praktische zaken die zeker niet over het hoofd gezien mogen worden.
Zet clustertechnologie in in omgevingen waarin relatief weinig wijzigingen plaatsvinden. Een platform waar continu applicaties worden toegevoegd, zaken gewijzigd moeten worden, diskindelingen aangepast moeten worden, enzovoort, is niet de ideale omgeving voor clustersoftware. Ondanks alle ’tools’ blijft dit moeilijk.
Plan als it-afdeling regelmatig tijd in om ‘failover’-tests te doen, zodat je zeker weet dat als er echt iets aan de hand is, de ‘failovers’ ook werken. Het zal niet de eerste keer zijn dat er veel aan een configuratie veranderd wordt, zonder die ook maar een keer goed te testen. Als er dan eens iets cruciaals sneuvelt, dan werkt de ‘failover’ mogelijk niet.
Tracht niet met een hoge-beschikbaarheidscluster (ha-cluster) tevens de uitwijk te regelen. Een cluster waarbij de afstand tussen de knooppunten enkele honderden meters bedraagt en zodoende staat opgesteld over twee vleugels van een gebouw, biedt een prima bescherming tegen een brand in een van de twee vleugels. Voor een ander soort rampen als overstroming, regionale stroomuitval, enzovoort dienen de knooppunten al snel enkele tientallen tot honderden kilometers van elkaar verwijderd te zijn. Dat is niet haalbaar met een cluster, hoewel sommige leveranciers hier wel producten voor menen te hebben. Hiervoor komen technieken als replicatie om de hoek kijken. Bovendien is uitwijk vooral een organisatorische kwestie, en loop je naast applicatiebeschikbaarheid tegen hele andere problemen aan. Kosten/baten-analyse is ook hier een complexe aangelegenheid.
Een cluster dient dus te worden ingezet voor hoge beschikbaarheid op een locatie. Daarnaast moet je uitwijk regelen voor bedrijfscontinuïteit gedurende rampen. Dit zijn dus twee verschillende zaken die ieder op eigen wijze onderzocht en geïmplementeerd moeten worden.
Onderzoek of de applicatie die een hoge beschikbaarheid moet krijgen ook daadwerkelijk te gebruiken is in een cluster. Vraag de leverancier of hij de applicaties standaard ondersteunt in het cluster of vraag of het ergens al eens eerder is gedaan (referenties). De applicatie moet verder goed crash-bestendig zijn. Een slecht geschreven applicatie die regelmatig uitvalt, wordt niet ineens beter beschikbaar door deze in een cluster op te nemen.
Een cluster met hoge beschikbaarheid is geen vervanger van een degelijke back-up oplossing. Back-up naar tape of een ander medium is een must.

Continu proces

Een cluster kan zeker een goede bijdrage leveren aan het verhogen van de beschikbaarheid. Het beschermt tegen de zogenaamde ‘single point of failures’, biedt de mogelijkheid om applicaties te verplaatsen naar andere machines zodat er onderhoud gepleegd kan worden, geeft een enkel administratief overzicht op het totaal van cluster-knooppunten en biedt een generiek platform voor het beheren van applicaties.
Factoren voor een succesvolle implementatie en toepassing van clusters zijn goed en regelmatig getraind personeel, een stabiele omgeving (aantal wijzigingen in configuratie), goede grafische ’tools’ voor het vereenvoudigen van het beheer, loskoppelen van uitwijk en ‘resiliency’, geen ‘single point of failures’ in personele bezetting, en het testen van ‘failover’ na iedere wijziging in configuratie (veranderingsbeheer). Met name deze laatste factoren, die 80 procent van de problemen veroorzaken, worden nogal eens onderbelicht.
Hoge beschikbaarheid regel je niet door alleen hardware aan te schaffen, clustersoftware erbij te kopen en de configuratie eenmalig op te (laten) zetten. Het bereiken van een goed werkend hoogbeschikbare configuratie is een continu proces. De juiste houding van mensen is hier minstens zo belangrijk als het opstellen van de juiste procedures.
 

Remco Lengers Arnold Van Der Kaaij Consultants Sun Microsystems Nederland