1 INLEIDING HIGH AVAILABILITY Bart Muijzer SUN Microsystems Nederland Introductie In dit paper wordt een introductie gegeen an het begrip High Aailabi...
INLEIDING HIGH AVAILABILITY Bart Muijzer SUN Microsystems Nederland
Introductie In dit paper wordt een introductie gegeven van het begrip High Availability en hoe dit te implementeren. Trends Voor steeds meer bedrijven wordt het hoog beschikbaar zijn van hun systemen of services 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 van markten en diensten: 24 uur per dag is er van ergens uit de wereld wel vraag om een service of dienst De enorme groei van de ebusiness is hiervan het meest sprekende voorbeeld. Op technisch gebied is er een duidelijke verschuiving van mainframe technologie naar gedistribueerde oplossingen. Verder worden applicaties steeds complexer. Op het gebied van het beheer van deze omgevingen neemt de noodzaak voor problemmanagement, change management en het voortdurend beschikbaar hebben en houden van diensten alleen maar toe. En tenslotte kost het niet-beschikbaar zijn van services bedrijven een vermogen (in termen van omzetverlies, slechte naamsbekendheid etc etc) terwijl de kosten om services hoog beschikbaar te maken alleen maar afnemen. Voorspelbaarheid versus flexibiliteit Deze trends geven aan dat er een combinatie van twee bestaande werelden nodig is: de datacenter-wereld (voorspelbaar, werkt met service-level agreements, heel procedureel geregeld) met de internet-wereld (onvoorspelbaar, flexibel, universeel toegangkelijk, networked services). In andere woorden: lage risicos moeten gecombineerd worden met hoge service-levels. Services worden geacht altijd beschikbaar te zijn en zijn van levensbelang voor een bedrijf. Ter illustratie hierbij een aantal gevolgen van het tijdelijk niet beschikbaar zijn van services: v Verminderde productiviteit v Interne en externe ontevredenheid van klanten v Slecht imago v Lagere winst, zowel van openstaande als van toekomstige transacties v Daling van de aandelenkoers
v v
Claims Verlies van bestaande klanten en van prospects.
Wat is beschikbaarheid? Beschikbaarheid kan gedefinieerd worden als: Continue toegang tot applicaties, met een voorspelbaar service-level: 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 bijvoorbeeld een probleem in het netwerk) is de applicatie voor de gebruiker toch niet beschikbaar! Ook plotseling langer durende responstijden geven de gebruiker een gevoel van niet/mindere beschikbaarheid. In een formule uitgedrukt: Beschikbaarheid = (MTBF / (MTBF + MTTR)) x 100% Hierbij is: v
MTBF: Mean Time Between Failure De gemiddelde tijd voordat een component defect gaat (statistisch).
v
MTTR: Mean Time To Repair De gemiddelde tijdsduur om een reparatie aan die component uit te voeren
Interessant om te zien is, dat wanneer de MTTR naar 0 gaat (het kost nauwelijks tijd om een reparatie uit te voeren) de beschikbaarheid richting 100% stijgt. Ook is het zo dat naarmate de MTBF groter wordt, de impact van MTTR kleiner is. Anders gezegd: als de gemiddelde duur van 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 actieve leven van een systeem is te splitsen in uptime en downtime. Met name de downtime is natuurlijk van invloed op de beschikbaarheid van het systeem. Downtime is te op te delen in: v
v
Planned downtime (20%): v backup v software onderhoud v hardware onderhoud v applicatie/database upgrades v OS upgrades v hardware upgrades Unplanned downtime (80%): v uitloop van planned downtime (!) v menselijke fouten
v v v v
applicatie/database failures OS failures disk failures hardware failures
Nuttig is het om ook te kijken naar de betekenis van het woordje 'hoog' in 'hoog beschikbaar'. De volgende 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 voor geclusterde systemen 99,9999 % ~ ½ minuut 0.6 seconde Fault Tolerant Systemen 99,99999 % ~ 3 seconden Vliegtuig computers Wanneer leveranciers zogenaamde 'uptime' garanties verstrekken is het goed te beseffen dat dit alleen van toepassing is op unplanned downtime. Controleer zorgvuldig waarop deze garantie van toepassing is. Soms is dat alleen hardware beschikbaarheid, soms zelfs hardware + besturingssysteem + applicaties. Controleer verder welke eisen de leverancier aan u als klant stelt voordat deze garanties gegeven kunnen worden en of deze haalbaar zijn. De drie P's: Product-People-Process De oorzaken van unplanned downtime kunnen verdeeld worden in drie categorien :
Product (20%) Hierbij kun je denken aan servers, storage, applicaties, databases, power/omgeving. v
20% van unplanned downtime wordt dus veroorzaakt door de gebruikte producten. Het gebruik van bewezen technologieen is daarom belangrijk. People(40%) Eindgebruikers, systeembeheerders, service personeel, change management v
Risicofactoren bij mensen zijn: training, ervaring, coaching, screenen van externe mensen, de eindgebruiker, service personeel. Ook de organisatiestructuur is van belang: als er geen vervanging is voor iemand is dat een potentieel risico (Single Point of Failure in mensen) ! Process (40%) Backup, "best practices", change management, problem management v
Bij processen kun je denken aan ITIL (IT Infrastructure Library), maar ook aan procedures rondom backup/recovery, het adequaat inrichten van de omgeving
(stroomvoorziening, airco) en het documenteren van zaken. Tussen People en Process bestaat een relatie: "naarmate processen beter beschreven zijn, worden de vaardigheden van mensen minder belangrijk". En andersom: "hoe beter de vaardigheden van mensen, hoe minder [beschreven] processen noodzakelijk zijn". Ergens hiertussen dient een balans gevonden te worden. Beschikbaarheidseisen aan systemen Beschikbaarheid is een relatief begrip. Het is dan ook iets dat afgezet moet worden tegen bijvoorbeeld de kosten om het te implementeren, of tegen afgesproken servicelevels (SLA's). In het algemeen kunnen de volgende catagorieen onderscheiden worden: 1. Basic systems: Doe niets speciaals. Dit betekent dat er geen enkele bescherming is en dat data verloren mag gaan. Het maken van regelmatige backups is het minste dat je kunt doen. Deze situatie is typerend voor applicatieservers: bij een crash wordt het systeem inclusief de applicatie gewoon opnieuw geinstalleerd. Op applicatieservers is data is immers statisch. 2. System level availability: Bescherm de server Dit kan op twee manieren gedaan worden: enerzijds door de MTBF te verbeteren en hiermee het voorkomen van downtime te minimaliseren, en anderzijds door de MTTR te reduceren om zo de impact van downtime te verlagen. Met andere woorden : Toepassing van betrouwbare componenten zorgt ervoor dat de MTBF van het hele systeem hoger wordt. Door redundantie in componenten toe te passen en te zorgen dat uitval geen impact heeft (de redundante component neemt transparant over) kun je zorgen dat minder betrouwbare componenten geen downtime tot gevolg hebben. Als je deze defecte componenten dan ook nog online kan vervangen, zonder het systeem te stoppen (hot swap), is de MTTR ook 0. Met name de impact van componenten met een lage MTBF (denk aan voedingen, disken etc) kan tot een minimum worden beperkt door toepassing van redundantie. Gouden regel #1: Ontwerp systemen zodanig, dat een failover nooit noodzakelijk is! 3. Redundante data: Bescherm de data Bescherm de data op alle lagen: v applicatie/database v filesystem/raw devices v software RAID/Volume Management v Hardware RAID v Fysieke disks Gouden regel #2: Data is vitaal voor een bedrijf!!! 4. Clustering en Fault Tolerance (FT): Bescherming tegen iedere Single Point of Failure (SPOF)
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 van belang elk component te dupliceren, zodat als een component uitvalt zijn duplicaat automatisch de taak kan overnemen. Op deze manier wordt elk single point of failure geelimineerd. Fault Tolerance: Hierbij wordt alle hardware dubbel of soms zelfs driedubbel uitgevoerd. Groot verschil 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 van dit soort machines is dat ze 'slechts' hardware redundantie bieden, duur zijn en slechts in beperkte configuraties leverbaar zijn. Gouden regel #3: High Availability wordt niet bereikt door enkel failover software te installeren en daarna nooit meer naar een systeem om te kijken! 5. Disaster Recovery: Bescherm de organisatie. Dit is de duurste oplossing, maar geeft wel de hoogste bescherming. De organisatie wordt beschermd tegen het verlies van het hele datacenter of tegen uitval van alle services. Dit wordt onder andere bereikt door geografische scheiding van de plaatsen waar services draaien. Disaster Recovery heeft veel meer te maken met mensen en processen dan met producten. Disaster Recovery wordt als volgt geclassificeerd: DR Classificatie AAA
Hersteltijd (uren) <4
Acceptabel verlies van data (uren) max. 1
AA
4-12
4
A
12-24
24
B
24-72
24
Implementatie Database replicatie en/of network mirroring Standby database transport van tapes restore van geografisch gescheiden backup altijd restoren van geografisch gescheiden backup
Gouden regel #4: Probeer de kosten veroorzaakt door unplanned downtime in te schatten. Dit geeft een indicatie van hetgeen een bedrijf reeel gezien kan besteden om unplanned downtime te voorkomen. Wat kost beschikbaarheid? Nu de diverse catagorieen van beschikbaarheid gedefinieerd zijn kunnen de kosten voor de implementatie daarvan met elkaar vergeleken worden. Onderstaande grafiek geeft hiervan een beeld:
Disaster Recovery
Clustering and FT
Redundant Data
System Level Availability
Availability Basic Systems
Costs
Naarmate je dichter bij de 100% beschikbaarheid komt, neemt het bedrag dat je moet uitgeven steeds verder toe. De beslissingen moeten dus worden genomen op basis van reeele business requirements. Dit is nog niet alles... Hoewel de drie P's behoorlijk alle oorzaken van unplanned downtime weergeven, zijn er nog een aantal andere zaken die zeker niet vergeten mogen worden: v v v
v
v v v
Netwerk resiliency (redundante netwerken en multipathing) Software stabiliteit (Besturingssysteem, Applicaties, gevoeligheid voor crashes) Hardware hardening (ongevoelig maken voor storing) door gebruik te maken van zaken als Dynamic Reconfiguration, Alternate Pathing etc Resource management, performance (ook als alle services op 1 node van een cluster draaien moet de performance acceptabel blijven) Betrouwbare opslag (redundantie door toepassing van RAID technologieën) Test, test, test, ... Meten, meten, meten, ...
Samenvattend v v v
v
Unplanned downtime is duur! De beschikbaarheid van systemen wordt steeds belangrijker Mensen en processen zijn belangrijker bij het verhogen van de beschikbaarheid van systemen dan producten. "Beschikbaarheid" is iets dat door de klant bepaald wordt en niet door de
v
leverancier. Onthoudt de gouden regels.
Literatuur: Blueprints for High Availability, Evan Marcus en Hal Stern, Wiley Computer Publishing, ISBN 0-471-35601-8
