Redundans på applikasjonsnivå

De aller fleste ønsker at IT-systemene de benytter seg av skal være operative. Så godt som alle IT-systemer driftes i dag på et slags datasenter, og datasentrene har en forventet oppetid. Er datasenteret nede, vil også programmene som kjører der være nede.

Uptime Institute klassifiserer datasentre som er designet for minst 99.982 % oppetid som "Tier III". Dette er en av de høyeste klassifikasjonene deres, og setter også en øvre grense for oppetiden du kan forvente av en skyleverandør. Datasenterets del av leveransen (strøm/internett/kjøling) gir altså ca 1.5 timer per år med nedetid i gjennomsnitt over tid. I tillegg kommer nedetid som skyldes problemer med datamaskinkomponenter, problemer med programvare eller oppgradering og vedlikehold av programvare.

Ønsker du mindre nedetid enn dette, bør du vurdere redundans på applikasjonsnivå. I denne bloggposten gir vi en oversikt over hvordan du kan sette opp noe slikt.

Single point of failure

Et "single point of failure" er en del av et IT-system som alltid må fungere for at hele IT-systemet skal fungere. Generelt ønskes færrest mulig slike, og du bør analysere IT-systemene dine for å identifisere dem. For hvert single point of failure, kan du velge å utføre tiltak for å øke redundansen.

Generelt bør du velge hvor robust du ønsker at et IT-system skal være. En mulig klassifisering er om det skal tolerere at en server går ned, at et datasenter går ned eller at et område mister strøm, som for eksempel Østlandet i Norge. Dette kalles redundans på server-nivå, datasenter-nivå eller regions-nivå.

"Lokalkontor": forskjellige brukere på forskjellige steder

En tilnærming til redundans er å spre brukerne utover på "lokalkontorer". Det vil si at et IT-system finnes på flere forskjellige lokasjoner, og at nye brukere legges til én av lokasjonene når de registrerer seg. Skulle én av disse lokasjonene bli utilgjengelig, er fremdeles de andre lokasjonene operative, og de fleste brukerne kan fortsette som normalt.

Dette er en enkel løsning som gjør at du i hovedsak er beskyttet mot full nedetid på tjenestene dine, i den forstand at kun en viss brøkdel rammes.

Hvis du trenger å gjøre prosessering på et sentralt nivå kan du hente inn dataene fra "lokalkontorene" for sentral prosessering. Så lenge kundene ikke er avhengig av denne sentrale prosesseringen, vil de kunne bruke IT-systemet selv om den sentrale lokasjonen er nede.

En ulempe med en slik løsning er at det kan gjøre samkjøring mellom forskjellige brukere vanskelig, da de kan ha dataene sine på forskjellige steder. Men, det er ikke alle IT-systemer som har slike krav, og da er heller ikke dette en ulempe.

Samme data og prosessering flere steder

Et annet alternativ er å lagre de samme dataene på flere servere eller lokasjoner. Her utføres også de samme prosesseringene på flere servere og lokasjoner.

Det er to sider av ethvert IT-system. Prosessering og lagring. Disse har unike utfordringer med tanke på redundans: Det er enkelt å prosessere data på forskjellige steder, men å lagre dataene på forskjellige steder kan være vanskelig, da de må holdes i synk mellom alle lokasjonene.

Samme prosessering på flere steder

Har du servere som kun prosesserer data, kan du ha systemer for prosessering på flere servere eller lokasjoner.

En måte å gjøre dette på, er for eksempel jobb-systemer. Disse plukker oppgaver som skal utføres fra en kø, og så utfører de oppgaven. Skulle en slik arbeider-node falle ned, er det bare en annen som tar dens oppgaver.

En annen måte er lastbalansering. Da vil flere servere ta seg av prosessering av forespørsler fra brukerne. Faller en av serverne eller lokasjonene ned, blir det bare flere oppgaver på de andre som fremdeles er oppe.

En populær software-løsning som gir redundans på tvers av servere, er Kubernetes. Kubernetes inneholder lastbalansering, og vil sørge for at et visst antall instanser av en tjeneste alltid kjører på tvers av serverne.

Samme data på flere steder

Ved å spre data utover flere servere eller lokasjoner, kan dataene fremdeles være tilgjengelige om en server eller lokasjon skulle falle ned.

Linux kommer med innebygget støtte for disker som er redundante mot at servere feiler. Med programvarene Distributed Replicated Storage System (DRDB) og Heartbeat kan du sette opp en disk som alltid er tilgjengelig på én av et sett med servere.

På Windows Server finnes en lignende teknologi kalt Windows storage replication.

Det er mulig å lagre data over flere servere på Kubernetes. Ved å installere programvaren OpenEBS, har du en lagringsløsning i Kubernetes som er robust mot at noen av serverne går ned.

For databaser som PostgreSQL og MySQL kan du sette opp replikering. Dette gjør at dataene finnes på flere steder. En server er da primær og de andre reserve. Skulle primær feile, kan en av reservene promoteres til ny primær.

Slike løsninger som beskrevet over øker ofte kompleksiteten betydelig, og en ulempe er derfor at denne løsningen i seg selv kan bli en ny single point of failure.

En annen ulempe er det krever svært mye nettverkstrafikk for å synkronisere dataene over flere servere eller lokasjoner.