INLEIDING HIGH AVAILABILITY Bart Muijzer SUN Microsystems Nederland

Transcriptie

1 INLEIDING HIGH AVAILABILITY Bart Muijzer SUN Microsystems Nederland Introductie In dit paper wordt een introductie gegeen an het begrip High Aailability en hoe dit te implementeren. Trends Voor steeds meer bedrijen wordt het hoog beschikbaar zijn an hun systemen of serices steeds meer een noodzaak. Aan deze ontwikkeling ligt een aantal trends ten grondslag. Waar je een aantal jaren geleden zag dat IT ondersteunend was aan de primaire bedrijfsprocessen, zie je nu dat deze zelfde processen stoppen wanneer de IT stopt. Ook zien we een globalisering an markten en diensten: 24 uur per dag is er an ergens uit de wereld wel raag om een serice of dienst De enorme groei an de e- business is hieran het meest sprekende oorbeeld. Op technisch gebied is er een duidelijke erschuiing an mainframe technologie naar gedistribueerde oplossingen. Verder worden applicaties steeds complexer. Op het gebied an het beheer an deze omgeingen neemt de noodzaak oor problemmanagement, change management en het oortdurend beschikbaar hebben en houden an diensten alleen maar toe. En tenslotte kost het niet-beschikbaar zijn an serices bedrijen een ermogen (in termen an omzeterlies, slechte naamsbekendheid etc etc) terwijl de kosten om serices hoog beschikbaar te maken alleen maar afnemen. Voorspelbaarheid ersus flexibiliteit Deze trends geen aan dat er een combinatie an twee bestaande werelden nodig is: de datacenter-wereld (oorspelbaar, werkt met serice-leel agreements, heel procedureel geregeld) met de internet-wereld (onoorspelbaar, flexibel, unierseel toegangkelijk, networked serices). In andere woorden: lage risicos moeten gecombineerd worden met hoge serice-leels. Serices worden geacht altijd beschikbaar te zijn en zijn an leensbelang oor een bedrijf. Ter illustratie hierbij een aantal geolgen an het tijdelijk niet beschikbaar zijn an serices: Verminderde productiiteit Interne en externe onteredenheid an klanten Slecht imago Lagere winst, zowel an openstaande als an toekomstige transacties Daling an de aandelenkoers

2 Claims Verlies an bestaande klanten en an prospects. Wat is beschikbaarheid? Beschikbaarheid kan gedefinieerd worden als: Continue toegang tot applicaties, met een oorspelbaar serice-leel: End-to-end. Belangrijk hierbij is te beseffen dat dit geldt zoals de eindgebruiker dit beleeft: een systeem kan goed werken, de applicatie kan draaien, maar als een gebruiker er niet bij kan (door bijoorbeeld een probleem in het netwerk) is de applicatie oor de gebruiker toch niet beschikbaar! Ook plotseling langer durende responstijden geen de gebruiker een geoel an niet/mindere beschikbaarheid. In een formule uitgedrukt: Hierbij is: Beschikbaarheid = (MTBF / (MTBF + MTTR)) x 100% MTBF: Mean Time Between Failure De gemiddelde tijd oordat een component defect gaat (statistisch). MTTR: Mean Time To Repair De gemiddelde tijdsduur om een reparatie aan die component uit te oeren Interessant om te zien is, dat wanneer de MTTR naar 0 gaat (het kost nauwelijks tijd om een reparatie uit te oeren) de beschikbaarheid richting 100% stijgt. Ook is het zo dat naarmate de MTBF groter wordt, de impact an MTTR kleiner is. Anders gezegd: als de gemiddelde duur an een reparatie 3 dagen is, en de gemiddelde tijd tussen storingen 3 maanden, dan is dat erger dan wanneer de gemiddelde tijd tussen storingen 3 jaar bedraagt. Waaruit bestaat beschikbaarheid? Het actiee leen an een systeem is te splitsen in uptime en downtime. Met name de downtime is natuurlijk an inloed op de beschikbaarheid an het systeem. Downtime is te op te delen in: Planned downtime (20%): backup software onderhoud hardware onderhoud applicatie/database upgrades OS upgrades hardware upgrades Unplanned downtime (80%): uitloop an planned downtime (!) menselijke fouten

3 applicatie/database failures OS failures disk failures hardware failures Nuttig is het om ook te kijken naar de betekenis an het woordje 'hoog' in 'hoog beschikbaar'. De olgende tabel geeft een indruk: Beschikbaarheid Totale unplanned downtime Positionering per jaar per week ============================================================ 90 % > 1 maand 17 uur? 99 % < 4 dagen 2 uur Slecht 99,9 % < 9 uur 10 minuten Standalone systemen 99,99 % ~ 1 uur 1 minuut Geclusterde systemen 99,999 % > 5 minuten 6 sec Uitdaging oor geclusterde systemen 99,9999 % ~ ½ minuut 0.6 seconde Fault Tolerant Systemen 99,99999 % ~ 3 seconden Vliegtuig computers Wanneer leeranciers zogenaamde 'uptime' garanties erstrekken is het goed te beseffen dat dit alleen an toepassing is op unplanned downtime. Controleer zorguldig waarop deze garantie an toepassing is. Soms is dat alleen hardware beschikbaarheid, soms zelfs hardware + besturingssysteem + applicaties. Controleer erder welke eisen de leerancier aan u als klant stelt oordat deze garanties gegeen kunnen worden en of deze haalbaar zijn. De drie P's: Product-People-Process De oorzaken an unplanned downtime kunnen erdeeld worden in drie categorien : Product (20%) Hierbij kun je denken aan serers, storage, applicaties, databases, power/omgeing. 20% an unplanned downtime wordt dus eroorzaakt door de gebruikte producten. Het gebruik an bewezen technologieen is daarom belangrijk. People(40%) Eindgebruikers, systeembeheerders, serice personeel, change management Risicofactoren bij mensen zijn: training, eraring, coaching, screenen an externe mensen, de eindgebruiker, serice personeel. Ook de organisatiestructuur is an belang: als er geen eranging is oor iemand is dat een potentieel risico (Single Point of Failure in mensen)! Process (40%) Backup, "best practices", change management, problem management Bij processen kun je denken aan ITIL (IT Infrastructure Library), maar ook aan procedures rondom backup/recoery, het adequaat inrichten an de omgeing

4 (stroomoorziening, airco) en het documenteren an zaken. Tussen People en Process bestaat een relatie: "naarmate processen beter beschreen zijn, worden de aardigheden an mensen minder belangrijk". En andersom: "hoe beter de aardigheden an mensen, hoe minder [beschreen] processen noodzakelijk zijn". Ergens hiertussen dient een balans geonden te worden. Beschikbaarheidseisen aan systemen Beschikbaarheid is een relatief begrip. Het is dan ook iets dat afgezet moet worden tegen bijoorbeeld de kosten om het te implementeren, of tegen afgesproken sericeleels (SLA's). In het algemeen kunnen de olgende catagorieen onderscheiden worden: 1. Basic systems: Doe niets speciaals. Dit betekent dat er geen enkele bescherming is en dat data erloren mag gaan. Het maken an regelmatige backups is het minste dat je kunt doen. Deze situatie is typerend oor applicatieserers: bij een crash wordt het systeem inclusief de applicatie gewoon opnieuw geinstalleerd. Op applicatieserers is data is immers statisch. 2. System leel aailability: Bescherm de serer Dit kan op twee manieren gedaan worden: enerzijds door de MTBF te erbeteren en hiermee het oorkomen an downtime te minimaliseren, en anderzijds door de MTTR te reduceren om zo de impact an downtime te erlagen. Met andere woorden : Toepassing an betrouwbare componenten zorgt eroor dat de MTBF an het hele systeem hoger wordt. Door redundantie in componenten toe te passen en te zorgen dat uital geen impact heeft (de redundante component neemt transparant oer) kun je zorgen dat minder betrouwbare componenten geen downtime tot geolg hebben. Als je deze defecte componenten dan ook nog online kan erangen, zonder het systeem te stoppen (hot swap), is de MTTR ook 0. Met name de impact an componenten met een lage MTBF (denk aan oedingen, disken etc) kan tot een minimum worden beperkt door toepassing an redundantie. Gouden regel #1: Ontwerp systemen zodanig, dat een failoer nooit noodzakelijk is! 3. Redundante data: Bescherm de data Bescherm de data op alle lagen: applicatie/database filesystem/raw deices software RAID/Volume Management Hardware RAID Fysieke disks Gouden regel #2: Data is itaal oor een bedrijf!!! 4. Clustering en Fault Tolerance (FT): Bescherming tegen iedere Single Point of Failure (SPOF)

5 Clustering: Dit kan gedaan worden door een groep systemen te configureren die een aantal resources delen, en die functioneert als een enkel systeem. Het is an belang elk component te dupliceren, zodat als een component uitalt zijn duplicaat automatisch de taak kan oernemen. Op deze manier wordt elk single point of failure geelimineerd. Fault Tolerance: Hierbij wordt alle hardware dubbel of soms zelfs driedubbel uitgeoerd. Groot erschil met clustering is dat de hardware parallel draait onder 1 besturingssysteem. Bij een 8 cpu FT machine kun je dan netto 4 cpu's gebruiken, waarbij de ander 4 in een 'lockstep' meedraaien. Nadeel an dit soort machines is dat ze 'slechts' hardware redundantie bieden, duur zijn en slechts in beperkte configuraties leerbaar zijn. Gouden regel #3: High Aailability wordt niet bereikt door enkel failoer software te installeren en daarna nooit meer naar een systeem om te kijken! 5. Disaster Recoery: Bescherm de organisatie. Dit is de duurste oplossing, maar geeft wel de hoogste bescherming. De organisatie wordt beschermd tegen het erlies an het hele datacenter of tegen uital an alle serices. Dit wordt onder andere bereikt door geografische scheiding an de plaatsen waar serices draaien. Disaster Recoery heeft eel meer te maken met mensen en processen dan met producten. Disaster Recoery wordt als olgt geclassificeerd: DR Classificatie Hersteltijd Acceptabel erlies Implementatie (uren) an data (uren) AAA < 4 max. 1 Database replicatie en/of network mirroring AA Standby database transport an tapes A restore an geografisch gescheiden backup B altijd restoren an geografisch gescheiden backup Gouden regel #4: Probeer de kosten eroorzaakt door unplanned downtime in te schatten. Dit geeft een indicatie an hetgeen een bedrijf reeel gezien kan besteden om unplanned downtime te oorkomen. Wat kost beschikbaarheid? Nu de dierse catagorieen an beschikbaarheid gedefinieerd zijn kunnen de kosten oor de implementatie daaran met elkaar ergeleken worden. Onderstaande grafiek geeft hieran een beeld:

6 Aailability System Leel Aailability Redundant Data Clustering and FT Disaster Recoery Basic Systems Costs Naarmate je dichter bij de 100% beschikbaarheid komt, neemt het bedrag dat je moet uitgeen steeds erder toe. De beslissingen moeten dus worden genomen op basis an reeele business requirements. Dit is nog niet alles... Hoewel de drie P's behoorlijk alle oorzaken an unplanned downtime weergeen, zijn er nog een aantal andere zaken die zeker niet ergeten mogen worden: Netwerk resiliency (redundante netwerken en multipathing) Software stabiliteit (Besturingssysteem, Applicaties, geoeligheid oor crashes) Hardware hardening (ongeoelig maken oor storing) door gebruik te maken an zaken als Dynamic Reconfiguration, Alternate Pathing etc Resource management, performance (ook als alle serices op 1 node an een cluster draaien moet de performance acceptabel blijen) Betrouwbare opslag (redundantie door toepassing an RAID technologieën) Test, test, test,... Meten, meten, meten,... Samenattend Unplanned downtime is duur! De beschikbaarheid an systemen wordt steeds belangrijker Mensen en processen zijn belangrijker bij het erhogen an de beschikbaarheid an systemen dan producten. "Beschikbaarheid" is iets dat door de klant bepaald wordt en niet door de

7 leerancier. Onthoudt de gouden regels. Literatuur: Blueprints for High Aailability, Ean Marcus en Hal Stern, Wiley Computer Publishing, ISBN