Hvornår bør man overveje høj tilgængelighed?

“Høj tilgængelighed er ikke noget, du køber – det er noget, du gør.” – John Nicholson

Få ting er mere universelt eftertragtede inden for IT end løsninger med høj tilgængelighed (HA). Sig de ord, og enhver IT-professionel vil straks sige, at de vil have det. HA til deres servere, deres applikationer, deres lagring og selvfølgelig endda deres desktops. Hvis der var et afkrydsningsfelt ved siden af ethvert system, der blot sagde “HA”, hvorfor ville vi så ikke krydse det af? Det ville vi selvfølgelig. Ingen ønsker frivilligt et system, der fejler meget. Fejl er dårligt, succes er godt.

Først skal vi dog definere HA. HA kan betyde mange ting. Som minimum skal HA betyde, at tilgængeligheden af det pågældende system skal være højere end “normal”. Hvad er normalt? Det alene er svært nok at definere. HA er i bedste fald et løst begreb. I konteksten af dets mest almindelige anvendelse, som er almindelige applikationer, der kører på normale enterprise-hardwareplatforme, vil jeg tilbyde dette udgangspunkt for HA-diskussioner:

Normal eller standard tilgængelighed (SA) ville være defineret som tilgængeligheden fra en almindelig mainline-server, der kører et almindeligt enterprise-operativsystem, der kører en almindelig enterprise-applikation i et best practices-miljø med enterprise-support. Gode eksempler på dette kan inkludere Exchange, der kører på Windows Server, der kører på HP Proliant DL380 (den mest almindelige mainline commodity-server). Eller BIND (DNS-serveren), der kører på Red Hat Enterprise Linux på Dell PowerEdge R730. Dette er blot eksempler til brug for at etablere en grov baseline. Der er ingen god måde at måle dette på, men med en god supportkontrakt og hurtig reparation eller udskiftning i den virkelige verden menes pålideligheden af et system af denne art at ligge mellem fire og fem nines pålidelighed (99,99 % oppetid eller højere), når menneskelige fejl ikke er inkluderet.

Høj tilgængelighed (HA) bør generelt defineres som at have en tilgængelighed, der er væsentligt højere end standard tilgængelighed. Væsentligt højere bør være mindst én størrelsesorden stigning. Så mindst fem nines pålidelighed og sandsynligvis seks nines. (99,9999 % oppetid.)

Lav tilgængelighed (LA) ville generelt defineres som at have en tilgængelighed, der er væsentligt lavere end standard tilgængelighed, hvor væsentligt igen betyder mindst én størrelsesorden. Så LA ville typisk antages at være omkring 99 % til 99,9 % eller lavere tilgængelighed.

Måling her er meget vanskelig, da menneskelige faktorer, miljø og andet spiller en massiv rolle i bestemmelsen af oppetiden for forskellige konfigurationer. Det samme udstyr, der bruges i én rolle, kan opnå fem nines, mens det i en anden fejler i at opnå selv én. Kvaliteten af datacentret, kompetencen hos supportpersonalet, hastigheden af udskiftning af reservedele, granulariteten af overvågning og en mængde andre faktorer vil påvirke den samlede pålidelighed væsentligt. Dette er dog ikke nødvendigvis et problem for os. I de fleste tilfælde kan vi evaluere de dele af et systemdesign, som vi kontrollerer, på en sådan måde, at relativ pålidelighed kan bestemmes, så vi i det mindste kan vise, at én tilgang vil være overlegen i forhold til en anden, så vi kan udnytte velinformeret beslutningstagning, selv hvis nøjagtige fejlratemodeller ikke nemt kan bygges.

Det er vigtigt at bemærke, at bortset fra at give et sæt eksempler som baseline at arbejde ud fra, er der intet i definitionerne af høj tilgængelighed eller lav tilgængelighed, der taler om hvordan disse niveauer skal opnås – det er ikke, hvad udtrykkene betyder. Udtrykkene er resulterende sæt af pålidelighed i forhold til baseline og intet andet. Der er mange måder at opnå høj tilgængelighed på uden at bruge almindeligt antagne tilgange, og praktisk talt ubegrænsede måder at opnå lav tilgængelighed på.

Selvfølgelig kan HA defineres på hvert lag. Vi kan have HA-platforme eller -OS, men have skrøbelige applikationer oven på. Så det er meget vigtigt at forstå, på hvilket niveau vi taler på ethvert givet tidspunkt. I sidste ende vil en virksomhed kun bekymre sig om levering af tjenester med høj tilgængelighed, uanset hvordan det opnås, eller hvor. Slutresultatet er det, der betyder noget, ikke “under hjelmen”-detaljerne om, hvordan det blev opnået – eller som altid, målet helliger midlet.

Det er ekstremt almindeligt i dag, at IT-afdelinger bliver distraheret af nye og flashy HA-værktøjer på platformniveauet og glemmer at se efter HA højere og lavere i stakken for at sikre, at vi leverer tjenester med høj tilgængelighed til virksomheden – snarere end kun at se på ét lag, mens virksomheden efterlades lige så sårbar eller mere sårbar end nogensinde.

I den virkelige verden er HA dog ikke altid en mulighed, og når det er, kommer det med en omkostning. Den omkostning er næsten altid monetær og medfører generelt ekstra kompleksitet. Og som vi godt ved, bærer enhver kompleksitet også yderligere risiko, og den risiko kan, hvis vi ikke er forsigtige, få et forsøg på at opnå HA til faktisk at fejle og måske endda efterlade os med LA eller lav tilgængelighed.

Når vi forstår dette nødvendige sprog for at beskrive, hvad vi mener, kan vi begynde at tale om, hvornår høj tilgængelighed, standard tilgængelighed og endda lav tilgængelighed måske er det rigtige for os. Vi bruger dette høje detaljeringsniveau, fordi det er så svært at måle systempålidelighed, at det at blive for detaljeret bliver værdiløst.

Konceptuelt bærer alle systemer risiko for nedetid, og intet kan altid være oppe – det er umuligt. Pålidelighed koster penge, generelt set, alt andet lige. Så for at afgøre, hvilket tilgængelighedsniveau der er mest passende for en arbejdsbelastning, skal vi bestemme omkostningen ved risikoafbødning (det beløb, det koster at ændre den gennemsnitlige mængde nedetid) og sammenligne det med omkostningen ved selve nedetiden.

Dette bliver vanskeligt og kompliceret, fordi det er svært nok at bestemme omkostningen ved nedetid, og derefter er det endnu sværere at bestemme risikoen for nedetid. I mange tilfælde er nedetid ikke et fladt tal, men det kan det være. Denne omkostning kan udtrykkes som $5/minut eller $20.000/dag eller lignende. Men et endnu bedre værktøj ville være at skabe en “tabspåvirkningskurve”, der viser, hvordan penge tabes over tid (inden for et rimeligt interval).

For eksempel kan en virksomhed nemt stå over for intet tab overhovedet de første fem minutter med langsomt stigende, men små, tab indtil omkring fire timer, hvor arbejdet stopper, fordi folk ikke længere kan ty til papir eller hvad som helst, og derefter går tabene fra næsten nul til ganske store. Eller nogle virksomheder kan tage et stort tab i det øjeblik, systemerne er nede, men tabene aftager langsomt over tid. Tab kan kun have virkning på bestemte tidspunkter af dagen. Måske er nedetid om natten eller til frokost ubetydelig, men midt om morgenen eller midt om eftermiddagen er det alvorligt. Hver virksomheds påvirkning, risiko og evne til at afbøde denne risiko er forskellig, ofte dramatisk forskellig.

Til tider kommer det ned til de mennesker, der arbejder i virksomheden. Vil de alle gerne tage de nødvendige badeværelses-, kaffe-, snack- eller endda frokostpauser på det tidspunkt, et system fejler, så de kan vende tilbage til arbejde, når det er rettet? Vil folk tage hjem tidligt og komme ind tidligt i morgen for at kompensere for en større nedetid? Er der maskiner, der vil stå tomgang? Vil evnen til at reagere på kunder blive påvirket? Vil livssupportsystemer fejle? Der er utallige potentielle påvirkninger og utallige potentielle måder at afbøde forskellige typer fejl på. Alt dette skal overvejes. Omkostningen ved nedetid kan være en brøkdel af virksomhedens omsætning på minutbasis, eller nedetid kan forårsage et tab af kunder eller tillid, der er mere indflydelsesrigt end den minut-for-minut-omsætning, der genereres.

Når vi har nogle grove tabstal at arbejde med, har vi i det mindste et udgangspunkt. Selv hvis vi kun ved, at omsætningen er ~$10/minut, og tabene forventes at være omkring ~$5/minut, har vi et udgangspunkt af en art. Hvis vi har en fuld kurve eller en undersøgelse udført med mere detaljerede tal, desto bedre. Nu skal vi finde ud af, hvad vores baseline nogenlunde vil være. En velvedligeholdt server, der kører on-premises med en god supportkontrakt og gode backup- og gendannelsesprocedurer, kan ganske nemt opnå fire nines pålidelighed. Det betyder, at vi ville opleve cirka fem timers nedetid hvert femte år. Dette er faktisk mindre end den generelt forventede nedetid for SA i de fleste miljøer og potentielt langt mindre end forventede niveauer i fremragende miljøer som højkvalitetsdatacentre med reservedele og service i nærheden.

Baseret på vores baseline-eksempel på cirka fem timer hvert femte år kan vi altså beregne vores potentielle risiko. Hvis vi taber cirka ~$5/minut, og vi forventer ca. 300 minutters nedetid hvert femte år, ser vi på et potentielt tab på $1.500 hvert halvt årti.

Det betyder, at vi i det mest ekstreme tilfælde aldrig ville bruge $1.500 for at afbøde denne risiko – det ville være finansielt absurd. Dette sker af flere årsager. En af de største er, at dette kun er en risiko; at bruge $1.500 for at beskytte mod at miste $1.500 giver lidt mening, men det er en meget almindelig fejl, som folk begår, når de ikke analyserer disse tal omhyggeligt.

Den største faktor er, at enhver afbødningsteknik ikke er fuldstændig effektiv. Hvis vi formår at flytte vores fire nines-system til et fem nines-system, ville vi kun reducere 90 % af den gennemsnitlige nedetid og flytte os fra $1.500 i tab til $150 i tab. Hvis vi brugte $1.500 på den reduktion, ville det samlede “tab” stadig være $1.650 (omkostningen ved beskyttelse er en form for finansielt tab). Omkostningen ved risikoafbødning kombineret med den forventede resterende påvirkning, set under ét, skal stadig være lavere end den forventede omkostning ved risikoen uden afbødning, ellers er afbødningen selv meningsløs eller aktivt skadelig.

Mange kan undre sig over, hvorfor den samlede omkostning ved risikoafbødning skal være lavere og ikke blot lig med, da det jo må betyde, at vi er ved et “risiko-break even”-punkt. Dette synes rigtigt ved overfladen, men fordi vi har med risiko at gøre, er dette ikke tilfældet. Risikoafbødning er en sikker omkostning – finansiel skade, vi påtager os i dag i håbet om at reducere tab i morgen. Men risikoen for i morgen er et gæt, forhåbentlig et velovervejet, men kun et gæt. Omkostningen i dag er sikker. At påtage sig sikker skade i dag i håbet om at reducere mulig skade i morgen giver kun mening, når skaden i dag er lille, og den forventede eller mulige skade i morgen er meget stor, og effektiviteten af afbødningen er betydelig.

Inkluderet i idéen om “sikker forhåndsomkostning” for at reducere “mulig fremtidig omkostning” er idéen om penges tidsværdi. Selv hvis en nedetid var af en kendt størrelse og tidspunkt, ville vi ikke bruge de samme penge i dag for at afbøde den i morgen, fordi vores penge er mere værdifulde i dag.

I de mest dramatiske tilfælde ser vi til tider IT-afdelinger, der kræver, at der bruges titusinder eller hundredtusinder af dollars på forhånd for at undgå at miste et par tusinde dollars, måske, engang, måske mange år ud i fremtiden. En strategi, vi kan kalde “at skyde os selv i ansigtet i dag for måske at undgå at få en hovedpine i morgen.”

Det er inkluderet i konceptet om at evaluere risikoafbødningen, men det bør nævnes specifikt, at der i tilfældet med IT-udstyr er mange eksempler på forsøgt risikoafbødning, der muligvis ikke er så effektiv, som man tror. For eksempel vil to servere, der sidder i samme rack, potentielt være meget effektive til at afbøde risikoen for hardware-fejl på værtsniveau, men vil ikke afbøde mod naturkatastrofer, tab af lokation, brand, de fleste tilfælde af elektrisk chok, aktivering af brandslukningssystemer, netværksafbrydelser, de fleste applikationsfejl, ransomware-angreb eller andre rimeligt mulige katastrofer.

Det er almindeligt, at lagerenheder er udstyret med “dual controllers”, hvilket giver et stærkt indtryk af høj pålidelighed, men generelt sidder disse controllere inde i et enkelt chassis med delte komponenter, og selv hvis komponenterne ikke er delte, er firmware'en ofte delt, og kommunikationen mellem komponenter er kompleks – hvilket ofte fører til fejl, hvor fejlen i én komponent udløser fejlen i en anden – hvilket gør dem temmelig hyppigt til LA-enheder snarere end SA eller den HA, folk forventede, da de købte dem. Så det er meget kritisk at overveje, om risikoafbødningsstrategien vil afbøde hvilke risici, og om afbødningsteknikken sandsynligvis vil være effektiv. Ingen teknik er fuldstændig effektiv – der er altid en chance for fejl – men nogle strategier og teknikker er mere bredt effektive end andre, og nogle er simpelthen vildledende eller faktisk kontraproduktive. Hvis vi ikke er forsigtige, kan vi implementere kostbare produkter eller teknikker, der aktivt underminerer vores mål.

Nogle teknikker og produkter, der bruges i jagten på høj tilgængelighed, er ret dyre, hvilket kan inkludere køb af redundant hardware, leje af en anden bygning, installation af dyre generatorer eller licensering af særlig software. Der er også lavpristyeknikker og -software, men i de fleste tilfælde vil enhver bevægelse mod høj tilgængelighed resultere i en tilsvarende stor udbetaling af investeringskapital for at opnå det. Det er absolut kritisk at holde for øje, at høj tilgængelighed er en proces – der er ingen måde blot at købe høj tilgængelighed på. At opnå HA kræver god dokumentation, procedurer, planlægning, support, udstyr, ingeniørvidenskab og mere. I systemverdenen nærmes HA normalt først fra et miljøperspektiv med nødstrømsanlæg, redundante HVAC-systemer, strømkonditionering, luftfiltrering, brandslukningssystemer og mere for at sikre, at miljøet for tilgængelighed er på plads. Dette alene kan ofte gøre yderligere investering unødvendig, da dette kan levere utrolige resultater. Dernæst kommer HA-systemdesign, der sikrer, at ikke blot ét lag af en teknologistak har høj tilgængelighed, men at hele stakken muliggør, at de kritiske applikationer, data eller tjenester forbliver funktionelle i så meget tid som muligt. Derefter ser man på site-til-site-redundans for at kunne modstå oversvømmelser, orkaner, snestorme osv. Der er selvfølgelig helt forskellige teknikker, såsom at udnytte cloudcomputertjenester, der hostes eksternt på vores vegne. Det, der betyder noget, er, at høj tilgængelighed kræver bred tænkning og planlægning, ikke blot kan købes som et linjeelement og bedømmes ud fra evnen til at returnere en risikofaktor, der giver en resulterende oppetid eller sandsynlighed for oppetid, der er meget højere end et “standard” systemdesign ville levere.

Hvad der ofte er overraskende, næsten chokerende, for mange virksomheder og især for IT-professionelle – som sjældent foretager finansiel risikoanalyse og konstant bliver fortalt, at HA er en nødvendighed for enhver virksomhed, og at køb af de nyeste HA-produkter ubestrideligt er, hvordan deres budgetter bør bruges – er, at når tallene regnes og realiteterne i omkostningerne og effektiviteten af risikoafbødningsstrategier overvejes, er høj tilgængelighed i meget lidt grad på plads i nogen organisation, især dem, der er små eller har meget forskelligartede arbejdsbelastninger. På SMB-markedet er det næsten universelt at finde, at omkostningen og kompleksiteten (som igen medfører risiko, primært i form af manglende erfaring med teknikker og risikovurdering) af høj tilgængelighed er langt for kostbar til nogensinde at opveje den potentielle skade fra den nedetid, afbødningen er håbet at beskytte mod. Der er selvfølgelig undtagelser, og der er mange virksomheder, for hvilke løsninger med høj tilgængelighed er absolut fornuftige, men disse er undtagelsen og langt fra normen.

Det er også fornuftigt at tænke på behovet for høj tilgængelighed som baseret på en arbejdsbelastning frem for en afdelings-, virksomheds- eller teknologiomfattende basis. I en lille virksomhed er det almindeligt, at alle arbejdsbelastninger deler en fælles platform, og behovet for høj tilgængelighed hos én enkelt arbejdsbelastning kan trække andre, mindre kritiske arbejdsbelastninger med sig. Dette er fuldstændig fint og en fremragende måde at udligne omkostningen ved risikoafbødning af den kritiske arbejdsbelastning gennem ancillær gavn for de mindre kritiske arbejdsbelastninger. I en større organisation, hvor der bruges en mængde platformstilgange til forskellige arbejdsbelastninger, er det almindeligt, at kun visse arbejdsbelastninger – dem, der er både meget kritiske (med hensyn til risiko fra nedetidspåvirkning) og hvis risiko praktisk talt kan afbødes (evnen til at afbøde risiko kan variere dramatisk mellem forskellige typer arbejdsbelastninger) – får høj tilgængelighed anvendt på dem, og andre arbejdsbelastninger overlades til standardteknikker.

Eksempler på arbejdsbelastninger, der kan være kritiske og kan behandles effektivt med høj tilgængelighed, kan være et onlineordresystem, hvor den latens, der skabes af multi-regional replikering, har ringe indvirkning på det overordnede system, men tab af ordrer kan være meget finansielt indflydelsesrigt, hvis et system fejler. Et eksempel på en arbejdsbelastning, hvor høj tilgængelighed måske er let at implementere, men ineffektiv, ville være et internt intranetsite, der betjener almindelige HR-spørgsmål – det ville simpelthen ikke være omkostningseffektivt at undgå små mængder lejlighedsvis nedetid for et system som dette. Et eksempel på et system, hvor risikoen er høj, men omkostningen eller effektiviteten af risikoafbødning gør det upraktisk eller endda umuligt, kan være en finansiel “tick”-database, der kræver massive mængder data med lav latenstid at indopte, og evnen til at opretholde en replika ikke kun ville være utrolig kostbar, men kunne introducere latenstid, der ville underminere systemets evne til at yde tilstrækkeligt. Hver virksomhed og arbejdsbelastning er unik og bør evalueres omhyggeligt.

Selvfølgelig kan teknikker til høj tilgængelighed iværksættes i faser – det er ikke alt-eller-intet. Det kan være praktisk at afbøde risikoen for fejl på systemniveau ved at have fejltolerance på applikationslaget for at beskytte mod fejl i system-hardware, virtualiseringsplatform eller lagring. Men for den samme arbejdsbelastning er det måske ikke værdifuldt at beskytte mod tab af et enkelt site. Hvis en arbejdsbelastning kun betjener et bestemt site eller simpelthen ikke er værdifuld nok til den store investering, der er nødvendig for at få den til at failover mellem sites, kan den nemt falde “i midten.” Det er meget almindeligt, at arbejdsbelastninger kun implementerer delvist høje tilgængelighed løsninger, ofte fordi en IT-afdeling måske kun er ansvarlig for en del af dem og ikke har indflydelse på ting som strømsupport og HVAC, men sandsynligvis mest almindeligt fordi nogle teknikker til høj tilgængelighed ses som højt synlige og nemme at sælge til ledelsen, mens andre, såsom høj kvalitet strøm og klimaanlæg, ofte ikke er det – selvom de let kan give bedre valuta for pengene. Der er gode grunde til, at visse teknikker kan vælges og ikke andre, da de påvirker forskellige risikokomponenter, og nogle risici kan have forskellig indvirkning på en individuel virksomhed eller arbejdsbelastning.

Høj tilgængelighed kræver omhyggelig overvejelse af, om det er værd at overveje, og endnu mere omhyggelig overvejelse af implementering. At bygge ægte HA-systemer kræver en betydelig mængde indsats og ekspertise og generelt substantielle omkostninger. At forstå, hvilke komponenter af HA der er værdifulde og hvilke der ikke er, kræver ikke blot omfattende teknisk ekspertise, men også finansielle og ledelsesmæssige færdigheder. Afdelinger skal arbejde tæt sammen for virkelig at forstå, hvordan HA vil påvirke en organisation, og hvornår det vil være investeringen værd. Det er kritisk at huske, at behovet for høj tilgængelighed i en organisation eller for en arbejdsbelastning på ingen måde er en selvfølge, og det bør slet ikke overraske, at man finder, at omfattende høj tilgængelighed eller endda afslappet høj tilgængelighed viser sig at være økonomisk upraktisk.

På mange måder skyldes dette, at standard tilgængelighed har nået en sådan tilstand, at der kontinuerligt er mindre og mindre risiko at afbøde. Teknologikomponenter, der bruges i en erhvervsinfrastruktur – mest bemærkelsesværdigt servere, netværksudstyr og lagring – er blevet så pålidelige, at mængden af nedetid, vi skal beskytte os mod, er ret lav. Det meste af troen på behovet for knæfald-høj-tilgængelighed stammer fra en anden æra, da pålidelig hardware var uoverkommelig dyr, og selv det dyreste udstyr var ret upålideligt efter moderne standarder. Denne følelse af forestående undergang over, at en enhed kan fejle til enhver tid, stammer fra en ældre æra, ikke den nuværende. Moderne udstyr er, selv om det åbenbart stadig bærer risici, forbløffende pålideligt.

Ud over andre risici bærer overinvestering i løsninger med høj tilgængelighed finansielle og forretningsmæssige risici, der kan være betydelige. Det øger den tekniske gæld i lyset af forretningsmæssig usikkerhed. Hvad nu hvis virksomheden pludselig vokser, eller hvad nu hvis den pludselig skrumper, skifter retning, bliver købt op eller lukker helt? Investeringen i høj tilgængelighed er allerede brugt, selv hvis behovet for dens beskyttelse forsvinder. Hvad nu hvis teknologi eller placering ændrer sig? Noget eller alt af en investering i høj tilgængelighed kan gå tabt, inden den ville have nået sin forventede levetidsafslutning.

Som IT-praktikere er det kernen af, hvad vi gør, at evaluere fordelene, risiciene og omkostningerne ved teknologiløsninger. Som alt andet i erhvervsinfrastruktur er det vores nøgleansvar at bestemme typen af risikoafbødning, værdien af beskyttelse og, hvor meget der er finansielt korrekt – og det kan ikke overfladisk behandles eller ignoreres. Vi kan aldrig bare antage, at høj tilgængelighed er nødvendigt, eller at det simpelthen kan springes over. Det er i analyser af denne art, at IT bringer noget af sin største værdi til organisationer. Det er her, vi har potentialet til at skinne mest.