När bör man överväga hög tillgänglighet?

“Hög tillgänglighet är inte något du köper, det är något du gör.” – John Nicholson

Få saker är mer universellt eftertraktade inom IT än lösningar för hög tillgänglighet (HA). Jag menar verkligen, säg de orden och vilken IT-proffs som helst kommer omedelbart att säga att de vill ha det. HA för sina servrar, sina applikationer, sin lagring och, förstås, till och med sina skrivbordsdatorer. Om det fanns en kryssruta bredvid varje system som helt enkelt sa “HA”, varför skulle vi inte kryssa i den? Det skulle vi naturligtvis göra. Ingen vill frivilligt ha ett system som havererar ofta. Haveri dåligt, framgång bra.

Först måste vi dock definiera HA. HA kan betyda många saker. Som ett minimum måste HA betyda att tillgängligheten för systemet i fråga måste vara högre än “normalt”. Vad är normalt? Det är i sig självt svårt nog att definiera. HA är en löst hållen term, i bästa fall. I sammanhanget av dess vanligaste användning, vilket är vanliga applikationer som körs på normal företagshårdvara, vill jag dock erbjuda denna utgångspunkt för diskussioner om HA:

Normal tillgänglighet eller standardtillgänglighet (SA) skulle definieras som tillgängligheten hos en vanlig huvudfårans server som kör ett vanligt företagsoperativsystem som kör en vanlig företagsapplikation i en miljö enligt bästa praxis med företagssupport. Goda exempel på detta kan inkludera Exchange som körs på Windows Server som körs på HP Proliant DL380 (den vanligaste huvudfårans standardserver). Eller för BIND (DNS-servern) som körs på Red Hat Enterprise Linux på Dell PowerEdge R730. Detta är bara exempel som ska användas för att etablera en grov baslinje. Det finns inget bra sätt att mäta detta, men med ett gott supportavtal och snabb reparation eller utbyte i den verkliga världen tros tillförlitligheten hos ett system av denna art ligga mellan fyra och fem nior i tillförlitlighet (99,99 % drifttid eller högre) när mänskligt fel inte räknas in.

Hög tillgänglighet (HA) bör allmänt definieras som att ha en tillgänglighet som är betydligt högre än den hos standardtillgänglighet. Betydligt högre bör vara en ökning på minst en storleksordning. Alltså minst fem nior i tillförlitlighet och mer sannolikt sex nior. (99,9999 % drifttid.)

Låg tillgänglighet (LA) skulle allmänt definieras som att ha en tillgänglighet som är betydligt lägre än den hos standardtillgänglighet, där betydligt återigen betyder minst en storleksordning. Så LA skulle typiskt antas ligga runt 99 % till 99,9 % eller lägre tillgänglighet.

Mätning är här mycket svår eftersom mänskliga faktorer, miljöfaktorer och andra spelar en enorm roll i att bestämma drifttiden för olika konfigurationer. Samma utrustning som används i en roll kan uppnå fem nior medan den i en annan inte ens lyckas uppnå en enda. Datacentrets kvalitet, supportpersonalens skicklighet, snabbheten i delbyten, granulariteten i övervakningen och en mängd andra faktorer kommer att påverka den övergripande tillförlitligheten avsevärt. Detta är dock inte nödvändigtvis ett problem för oss. I de flesta fall kan vi utvärdera de delar av en systemutformning som vi kontrollerar på ett sådant sätt att relativ tillförlitlighet kan fastställas, så att vi åtminstone kan visa att ett tillvägagångssätt kommer att vara överlägset ett annat, för att vi sedan ska kunna utnyttja välinformerat beslutsfattande även om exakta modeller för felfrekvens inte enkelt kan byggas.

Det är viktigt att notera att utöver att tillhandahålla en uppsättning exempel som baslinje att arbeta utifrån finns det inget i definitionerna av hög tillgänglighet eller låg tillgänglighet som talar om hur dessa nivåer bör uppnås – det är inte vad termerna betyder. Termerna är resulterande uppsättningar av tillförlitlighet i förhållande till baslinjen och inget annat. Det finns många sätt att uppnå hög tillgänglighet utan att använda allmänt antagna tillvägagångssätt och praktiskt taget obegränsade sätt att uppnå låg tillgänglighet.

Naturligtvis kan HA definieras på varje lager. Vi kan ha HA-plattformar eller HA-operativsystem men ha sköra applikationer ovanpå. Så det är mycket viktigt att förstå på vilken nivå vi talar vid varje given tidpunkt. När allt kommer omkring kommer ett företag endast att bry sig om leveransen av tjänster med hög tillgänglighet, oavsett hur den uppnås, eller var. Slutresultatet är vad som spelar roll, inte detaljerna “under huven” om hur det åstadkoms eller, som alltid, ändamålet helgar medlen.

Det är extremt vanligt idag att IT-avdelningar blir distraherade av nya och tjusiga HA-verktyg på plattformslagret och glömmer att leta efter HA högre och lägre i stacken för att säkerställa att vi tillhandahåller tjänster med hög tillgänglighet till verksamheten; snarare än att endast titta på det ena lagret medan verksamheten lämnas lika sårbar, eller mer så, än någonsin.

I den verkliga världen är HA dock inte alltid ett alternativ, och när det är det kommer det till en kostnad. Den kostnaden är nästan alltid monetär och kommer generellt med extra komplexitet också. Och som vi väl vet bär all komplexitet även med sig ytterligare risk, och den risken kan, om vi inte är försiktiga, leda till att ett försök att uppnå HA faktiskt misslyckas och till och med kan lämna oss med LA eller låg tillgänglighet.

När vi väl förstår detta nödvändiga språk för att beskriva vad vi menar kan vi börja tala om när hög tillgänglighet, standardtillgänglighet och till och med låg tillgänglighet kan vara rätt för oss. Vi använder denna höga grad av granularitet eftersom det är så svårt att mäta systemtillförlitlighet att det blir värdelöst att gå för mycket in på detaljer.

Begreppsmässigt kommer alla system med risk för driftstopp och inget kan alltid vara uppe, det är omöjligt. Tillförlitlighet kostar pengar, generellt sett, allt annat lika. Så för att avgöra vilken tillgänglighetsnivå som är mest lämplig för en arbetsbelastning måste vi fastställa kostnaden för riskreducering (mängden pengar som krävs för att förändra den genomsnittliga mängden driftstopp) och jämföra den mot kostnaden för själva driftstoppet.

Detta blir knepigt och komplicerat, eftersom det är svårt nog att fastställa kostnaden för driftstopp, och att sedan fastställa risken för driftstopp är ännu svårare. I många fall är driftstopp inte ett platt tal, men det kan vara det. Denna kostnad kan uttryckas som 5 USD/minut eller 20 000 USD/dag eller liknande. Men ett ännu bättre verktyg vore att skapa en “förlustkurva” som visar hur pengar förloras över tid (inom ett rimligt intervall.)

Till exempel kan ett företag mycket väl stå utan någon förlust alls under de första fem minuterna med långsamt ökande, men små, förluster fram till ungefär fyra timmar då arbetet stannar av eftersom folk inte längre kan övergå till papper eller vad det än är, och då går förlusterna från nästan noll till ganska stora. Eller så kan vissa företag ta en enorm förlust i det ögonblick som systemen går ner men förlusterna avtar långsamt över tid. Förlust kanske bara är påtaglig vid vissa tider på dygnet. Kanske är avbrott på natten eller under lunchen triviala men mitt på förmiddagen eller mitt på eftermiddagen är allvarliga. Varje företags påverkan, risk och förmåga att reducera den risken är olika, ofta dramatiskt så.

Ibland handlar det om de människor som arbetar på företaget. Kommer de alla glatt att ta sina behövliga toalett-, kaffe-, mellanmåls- eller till och med lunchraster vid den tidpunkt då ett system havererar, så att de kan återgå till arbetet när det är åtgärdat? Kommer folk att gå hem tidigt och komma in tidigt imorgon för att ta igen ett större avbrott? Finns det maskineri som kommer att stå stilla? Kommer förmågan att svara kunder att påverkas? Kommer livsuppehållande system att fallera? Det finns oräkneliga potentiella konsekvenser och oräkneliga potentiella sätt att reducera olika typer av haverier. Allt detta måste beaktas. Kostnaden för driftstopp kan vara en bråkdel av företagets intäkter på minutbasis, eller så kan driftstopp orsaka en förlust av kunder eller förtroende som är mer påtaglig än de intäkter som genereras minut för minut.

När vi väl har några grova förlustsiffror att arbeta med har vi åtminstone en utgångspunkt. Även om vi bara vet att intäkterna är ~10 USD/minut och förlusterna förväntas ligga runt ~5 USD/minut har vi en slags utgångspunkt. Om vi har en fullständig kurva eller en studie genomförd med några mer detaljerade siffror, desto bättre. Nu måste vi lista ut ungefär vad vår baslinje kommer att bli. En välunderhållen server, som körs lokalt, med ett gott supportavtal och goda rutiner för säkerhetskopiering och återställning kan ganska enkelt uppnå fyra nior i tillförlitlighet. Det innebär att vi skulle uppleva ungefär fem timmars driftstopp vart femte år. Detta är faktiskt mindre än det allmänt förväntade driftstoppet för SA i de flesta miljöer och potentiellt långt mindre än förväntade nivåer i utmärkta miljöer som högkvalitativa datacenter med delar och service i närheten.

Så, baserat på vårt baslinjeexempel om ungefär fem timmar vart femte år kan vi räkna ut vår potentiella risk. Om vi förlorar ungefär ~5 USD/minut och vi förväntar oss ungefär 300 minuters driftstopp vart femte år tittar vi på en potentiell förlust på 1 500 USD vart halvt decennium.

Det innebär att vi i det mest extrema fallet aldrig skulle kunna spendera 1 500 USD för att reducera den risken, det vore ekonomiskt absurt. Detta sker av flera skäl. En av de största är att detta endast är en risk; att spendera 1 500 USD för att skydda mot att förlora 1 500 USD är föga vettigt, men det är ett mycket vanligt misstag att göra när folk inte analyserar dessa siffror noggrant.

Den största faktorn är att ingen reduceringsteknik är fullständigt effektiv. Om vi lyckas flytta vårt system från fyra nior till fem nior skulle vi reducera endast 90 % av det genomsnittliga driftstoppet, vilket flyttar oss från 1 500 USD i förlust till 150 USD i förlust. Om vi spenderade 1 500 USD för den reduceringen skulle den totala “förlusten” fortfarande vara 1 650 USD (kostnaden för skydd är en form av ekonomisk förlust.) Kostnaden för riskreduceringen kombinerad med den förväntade kvarvarande påverkan måste, tagna tillsammans, fortfarande vara lägre än den förväntade kostnaden för risken utan reducering, annars är reduceringen i sig meningslös eller aktivt skadlig.

Många kanske ifrågasätter varför den totala kostnaden för riskreducering måste vara lägre och inte helt enkelt lika, eftersom det säkerligen måste innebära att vi befinner oss vid en punkt för “risknollresultat”? Detta verkar sant på ytan, men eftersom vi har att göra med risk är så inte fallet. Riskreducering är en säker kostnad – ekonomisk skada som vi tar på oss i förväg i hopp om att reducera förluster imorgon. Men risken för imorgon är en gissning, förhoppningsvis en välunderbyggd sådan, men endast en gissning. Kostnaden idag är säker. Att ta på sig säker skada idag i hopp om att reducera möjlig skada imorgon är endast vettigt när skadan idag är liten och den förväntade eller möjliga skadan imorgon är mycket stor och reduceringens effektivitet är betydande.

I idén om “säker kostnad i förväg” för att reducera “möjlig kostnad imorgon” ingår idén om pengars tidsvärde. Även om ett avbrott vore av känd storlek och tid skulle vi inte spendera samma pengar idag för att reducera det imorgon, eftersom våra pengar är mer värdefulla idag.

I de mest dramatiska fallen ser vi ibland IT-avdelningar kräva att tiotals eller hundratals tusen dollar spenderas i förväg för att undvika att förlora några tusen dollar, kanske, någon gång, kanske många år in i framtiden. En strategi som vi kan benämna “att skjuta oss själva i ansiktet idag för att undvika att kanske få huvudvärk imorgon.”

Det ingår i begreppet att utvärdera riskreduceringen, men det bör nämnas specifikt att i fallet med IT-utrustning finns det många exempel på försökt riskreducering som kanske inte är så effektiv som man tror. Till exempel kommer två servrar som står i samma rack potentiellt att vara mycket effektiva för att reducera risken för hårdvaruhaveri på värden, men kommer inte att reducera mot naturkatastrofer, platsförlust, brand, de flesta fall av elchock, aktivering av brandsläckningssystem, nätverksavbrott, de flesta applikationshaverier, ransomware-attacker eller andra rimligen möjliga katastrofer.

Det är vanligt att lagringsenheter är utrustade med “dubbla styrenheter” vilket ger ett starkt intryck av hög tillförlitlighet, men generellt sitter dessa styrenheter inuti ett enda chassi med delade komponenter, och även om komponenterna inte är delade är ofta den fasta programvaran delad och kommunikationen mellan komponenter komplex; vilket ofta leder till haverier där haveriet i en komponent utlöser haveriet i en annan – vilket gör dem ganska ofta till LA-enheter snarare än SA eller den HA som folk förväntade sig vid köpet. Så det är mycket avgörande att överväga om riskreduceringsstrategin kommer att reducera vilka risker och om reduceringstekniken sannolikt kommer att vara effektiv. Ingen teknik är fullständigt effektiv, det finns alltid en risk för haveri, men vissa strategier och tekniker är mer brett effektiva än andra och vissa är helt enkelt vilseledande eller faktiskt kontraproduktiva. Om vi inte är försiktiga kan vi komma att implementera kostsamma produkter eller tekniker som aktivt undergräver våra mål.

Vissa tekniker och produkter som används i strävan efter hög tillgänglighet är ganska dyra, vilket kan inkludera att köpa redundant hårdvara, hyra en annan byggnad, installera dyra generatorer eller licensiera specialprogramvara. Det finns även lågkostnadstekniker och lågkostnadsprogramvara, men i de flesta fall kommer varje rörelse mot hög tillgänglighet att resultera i en respektive stor utbetalning av investeringskapital för att uppnå den. Det är absolut avgörande att hålla i minnet att hög tillgänglighet är en process, det finns inget sätt att helt enkelt köpa hög tillgänglighet. Att uppnå HA kräver god dokumentation, rutiner, planering, support, utrustning, ingenjörsarbete med mera. I systemvärlden närmar man sig HA normalt först ur ett miljöperspektiv med reservgeneratorer, redundanta HVAC-system, kraftkonditionering, luftfiltrering, brandsläckningssystem med mera för att säkerställa att miljön för tillgängligheten finns där. Detta ensamt kan ofta göra ytterligare investeringar onödiga eftersom detta kan ge otroliga resultat. Sedan kommer HA-systemdesign som säkerställer att inte bara ett lager av en teknikstack är högtillgängligt utan att hela stacken tillåter att de kritiska applikationerna, datan eller tjänsterna förblir funktionella under så mycket tid som möjligt. Sedan tittar man på redundans mellan platser för att kunna stå emot översvämningar, orkaner, snöstormar och så vidare. Naturligtvis finns det helt andra tekniker, såsom att utnyttja molntjänster som driftas på distans för vår räkning. Vad som spelar roll är att hög tillgänglighet kräver brett tänkande och planering, inte helt enkelt kan köpas som en post i budgeten och bedöms utifrån förmågan att ge en riskfaktor som resulterar i en drifttid eller sannolikhet för drifttid som är mycket högre än vad en “standard”-systemdesign skulle leverera.

Vad som ofta är förvånande, nästan chockerande, för många företag och särskilt för IT-proffs, som sällan företar sig finansiell riskanalys och som ständigt får höra att HA är en nödvändighet för varje verksamhet och att köpa de senaste HA-produkterna otvivelaktigt är hur deras budgetar bör spenderas, är att när siffrorna räknas igenom och realiteten kring kostnaderna och effektiviteten hos riskreduceringsstrategier beaktas, så har hög tillgänglighet mycket liten plats i någon organisation, särskilt de som är små eller har högst skilda arbetsbelastningar. På marknaden för små och medelstora företag är det nästan universellt att finna att kostnaden och komplexiteten (som i sin tur medför risk, mestadels i form av brist på erfarenhet kring tekniker och riskbedömning) hos tillvägagångssätt för hög tillgänglighet är alldeles för kostsam för att någonsin uppväga den potentiella skadan av det avbrott som reduceringen hoppas skydda mot. Det finns undantag, naturligtvis, och det finns många verksamheter för vilka lösningar för hög tillgänglighet är absolut vettiga, men dessa är undantaget och mycket långt ifrån att vara normen.

Det är också vettigt att tänka på behoven av hög tillgänglighet som något som baseras på arbetsbelastningsnivå och inte på avdelnings-, företags- eller teknikövergripande nivå. I ett litet företag är det vanligt att alla arbetsbelastningar delar en gemensam plattform, och en enda arbetsbelastnings behov av hög tillgänglighet kan dra med sig andra, mindre kritiska, arbetsbelastningar. Detta är fullkomligt fint och ett utmärkt sätt att uppväga kostnaden för riskreduceringen av den kritiska arbetsbelastningen genom kringliggande nytta för de mindre kritiska arbetsbelastningarna. I en större organisation där det finns en uppsjö av plattformstillvägagångssätt som används för olika arbetsbelastningar är det vanligt att endast vissa arbetsbelastningar som är både högst kritiska (i termer av risk från driftstoppspåverkan) och som praktiskt kan reduceras för risk (förmågan att reducera risk kan variera dramatiskt mellan olika typer av arbetsbelastningar) får hög tillgänglighet tillämpad på sig, medan andra arbetsbelastningar lämnas till standardtekniker.

Exempel på arbetsbelastningar som kan vara kritiska och som effektivt kan hanteras med hög tillgänglighet kan vara ett system för beställning online där den latens som skapas av flerregional replikering har liten påverkan på det övergripande systemet, men att förlora beställningar skulle kunna vara mycket ekonomiskt påtagligt om ett system fallerar. Ett exempel på en arbetsbelastning där hög tillgänglighet kan vara enkel att implementera men verkningslös vore en intern intranätsida som besvarar vanligt förekommande HR-frågor; det vore helt enkelt inte kostnadseffektivt att undvika små mängder enstaka driftstopp för ett system som detta. Ett exempel på ett system där risken är hög men kostnaden för eller effektiviteten hos riskreducering gör den opraktisk eller till och med omöjlig kan vara en finansiell “tick”-databas som kräver att enorma mängder data med låg latens matas in och där förmågan att upprätthålla en replika inte bara vore otroligt kostsam utan skulle kunna introducera latens som skulle undergräva systemets förmåga att prestera tillfredsställande. Varje verksamhet och arbetsbelastning är unik och bör utvärderas noggrant.

Naturligtvis kan tekniker för hög tillgänglighet sättas i verket i etapper; det är inte ett allt-eller-inget-företag. Det kan vara praktiskt att reducera risken för haveri på systemnivå genom att ha feltolerans på applikationslagret för att skydda mot haveri i systemhårdvara, virtualiseringsplattform eller lagring. Men för samma arbetsbelastning kan det vara värdelöst att skydda mot förlusten av en enda plats. Om en arbetsbelastning endast betjänar en viss plats eller helt enkelt inte är värdefull nog för den stora investering som krävs för att få den att växla över mellan platser kan den lätt hamna “i mitten.” Det är mycket vanligt att arbetsbelastningar endast implementerar delvis högtillgängliga lösningar, ofta eftersom en IT-avdelning kanske endast ansvarar för en del av dem och inte har något att säga till om kring sådant som kraftförsörjning och HVAC, men förmodligen allra vanligast eftersom vissa tekniker för hög tillgänglighet ses som högt synliga och lätta att sälja in till ledningen medan andra, såsom högkvalitativ kraft och luftkonditionering, ofta inte är det, även om de lätt kan ge mer valuta för pengarna. Det finns goda skäl till varför vissa tekniker kan väljas och inte andra, eftersom de påverkar olika riskkomponenter och vissa risker kan ha en avvikande påverkan på en enskild verksamhet eller arbetsbelastning.

Hög tillgänglighet kräver noggrant övervägande av huruvida den är värd att överväga och ännu mer noggrant övervägande av implementeringen. Att bygga sanna HA-system kräver en betydande mängd ansträngning och expertis och generellt sett en avsevärd kostnad. Att förstå vilka komponenter av HA som är värdefulla och vilka som inte är det kräver inte bara omfattande teknisk expertis utan även finansiella och ledningsmässiga färdigheter. Avdelningar måste samarbeta omfattande för att verkligen förstå hur HA kommer att påverka en organisation och när det kommer att vara värt investeringen. Det är avgörande att man kommer ihåg att behovet av hög tillgänglighet i en organisation eller för en arbetsbelastning är allt annat än en självklar slutsats och det bör inte förvåna det minsta att finna att omfattande hög tillgänglighet eller till och med tillfälliga rutiner för hög tillgänglighet visar sig vara ekonomiskt opraktiska.

På många sätt beror detta på att standardtillgängligheten har nått ett sådant tillstånd att det kontinuerligt finns mindre och mindre risk att reducera. Teknikkomponenter som används i en företagsinfrastruktur, mest påtagligt servrar, nätverksutrustning och lagring, har blivit så tillförlitliga att den mängd driftstopp som vi måste skydda mot är ganska låg. Merparten av tron på behovet av reflexmässig hög tillgänglighet härstammar från en annan era när tillförlitlig hårdvara var oöverkomligt dyr och även den dyraste utrustningen var ganska otillförlitlig enligt moderna mått. Denna känsla av annalkande undergång att vilken enhet som helst kan fallera när som helst härstammar från en äldre era, inte den nuvarande. Modern utrustning är, även om den uppenbarligen fortfarande bär på risker, häpnadsväckande tillförlitlig.

Utöver andra risker bär överinvestering i lösningar för hög tillgänglighet på finansiella och affärsmässiga risker som kan vara avsevärda. Det ökar den tekniska skulden inför affärsmässig osäkerhet. Vad händer om verksamheten plötsligt växer, eller värre, vad händer om den plötsligt krymper, byter inriktning, blir uppköpt eller går omkull helt och hållet? Investeringen i den höga tillgängligheten är redan spenderad även om behovet av dess skydd försvinner. Vad händer om teknik eller plats förändras? Delar av eller hela en investering i hög tillgänglighet kan gå förlorad innan den skulle ha nått sitt förväntade slut på livslängden.

Som IT-utövare är att utvärdera fördelarna, riskerna och kostnaderna med tekniklösningar kärnan i vad vi gör. Liksom allt annat inom företagsinfrastruktur är att fastställa typen av riskreducering, värdet av skyddet och hur mycket som är ekonomiskt korrekt vårt nyckelansvar och kan inte slätas över eller ignoreras. Vi kan aldrig helt enkelt anta att hög tillgänglighet behövs, inte heller att den helt enkelt kan hoppas över. Det är i analys av denna art som IT tillför något av sitt allra största värde till organisationer. Det är här vi har potentialen att lysa som allra mest.