I den virkelige verden kan der være situationer, hvor der kan opstå et fald i dine serveres ydeevne på grund af begivenheder, der spænder fra en pludselig stigning i trafikken kan føre til en pludselig strømafbrydelse. Det kan være meget værre, og dine servere kan blive lammet – uanset om dine applikationer er hostet i skyen eller på en fysisk maskine. Sådanne situationer er uundgåelige. Men i stedet for at håbe på, at det ikke sker, er det, du faktisk bør gøre, at du gearer op, så dine systemer ikke støder på fejl.
Svaret på problemet er brugen af High Availability (HA)-konfiguration eller -arkitektur. Arkitektur med høj tilgængelighed er en tilgang til at definere komponenter, moduler eller implementering af tjenester i et system, som sikrer optimal driftspræstation, selv i perioder med høj belastning. Selv om der ikke er nogen faste regler for implementering af HA-systemer, er der generelt nogle få gode metoder, som man skal følge, så man får mest muligt ud af de færreste ressourcer.
Hvorfor har du brug for det?
Lad os definere nedetid, før vi går videre. Nedetid er den periode, hvor dit system (eller netværk) ikke er tilgængeligt til brug, eller ikke reagerer. Nedetid kan medføre store tab for en virksomhed, da alle deres tjenester bliver sat på standby, når deres systemer er nede. I august 2013 gik Amazon ned i 15 minutter (både web- og mobiltjenester) og endte med at tabe over 66 000 dollars pr. minut. Det er enorme tal, selv for en virksomhed af Amazons størrelse.
Der er to typer nedetider – planlagte og uplanlagte. En planlagt nedetid er et resultat af vedligeholdelse, som er uundgåelig. Dette omfatter anvendelse af patches, opdatering af softwares eller endda ændringer i databaseskemaet. En uplanlagt nedetid er derimod forårsaget af en uforudset hændelse som f.eks. hardware- eller softwarefejl. Dette kan ske på grund af strømafbrydelser eller svigt i en komponent. Planlagte nedetider er generelt udelukket fra beregninger af ydeevne.
Det primære mål med at implementere højtilgængelighedsarkitektur er at sikre, at dit system eller program er konfigureret til at håndtere forskellige belastninger og forskellige fejl med minimal eller ingen nedetid. Der er flere komponenter, der hjælper dig med at opnå dette, og vi vil diskutere dem kort.
Hvordan måles tilgængelighed?
Organisationer, der planlægger at udnytte en cloud-infrastruktur fuldt ud, skal også være i stand til at opfylde kravene om tilgængelighed 24/7. Tilgængelighed kan måles som den procentdel af tiden, som systemerne er tilgængelige.
x = (n – y) * 100/n
Hvor n er det samlede antal minutter i en kalendermåned, og y er det samlede antal minutter, som tjenesten er utilgængelig i den givne kalendermåned. Høj tilgængelighed henviser ganske enkelt til en komponent eller et system, der er kontinuerligt funktionsdygtigt i en ønskelig lang periode. Den almindeligt anerkendte, men næsten umulige standard for tilgængelighed for et produkt eller system kaldes “fem 9’ere” (99,999 %) tilgængelighed. Høj tilgængelighed er et krav for enhver virksomhed, der håber at kunne beskytte sin forretning mod de risici, som et systemnedbrud medfører. Disse risici, kan føre til millioner af dollars i indtægtstab.
Er det virkelig pengene værd?
Det er helt i orden at gå efter en arkitektur med høj tilgængelighed giver dig højere ydeevne, men det har også en stor pris. Du skal spørge dig selv, om du mener, at beslutningen er berettiget ud fra et økonomisk synspunkt.
Der skal tages stilling til, om den ekstra oppetid virkelig er de penge værd, der skal bruges på det. Du skal spørge dig selv, hvor skadelige potentielle nedetider kan være for din virksomhed, og hvor vigtige dine tjenester er for driften af din virksomhed.
Hvordan opnår vi det?
Nu har du besluttet dig for at gå med det, så lad os diskutere, hvordan du kan gennemføre det. Ikke-intuitivt set hjælper det ikke med at tilføje flere komponenter til et system for at gøre det mere stabilt og opnå høj tilgængelighed. Det kan faktisk føre til det modsatte, da flere komponenter øger sandsynligheden for fejl. Moderne design giver mulighed for at fordele arbejdsbyrden på flere instanser, f.eks. et netværk eller en klynge, hvilket hjælper med at optimere ressourceudnyttelsen, maksimere output, minimere svartider og undgå overbelastning af ethvert system i den proces, der kaldes load balancing. Det indebærer også skift til en standby-ressource som en server, komponent eller netværk i tilfælde af fejl på en aktiv ressource, kendt som Failover-systemer.
Brug af flere applikationsservere:
Forestil dig, at du har en enkelt server til at gengive dine tjenester, og at en pludselig stigning i trafikken fører til, at den svigter (eller går ned). I en sådan situation kan der ikke betjenes flere anmodninger, indtil din server er genstartet, hvilket fører til nedetid.
Den indlysende løsning her er at distribuere din applikation over flere servere. Du skal fordele belastningen mellem alle disse, så ingen af dem bliver overbelastet, og output er optimalt. Du kan også implementere dele af din applikation på forskellige servere. Der kan f.eks. være en separat server til håndtering af mails eller en separat server til behandling af statiske filer som f.eks. billeder (som et Content Delivery Network).
Skalering af databaser:
Databaser er den mest populære og måske en af de mest konceptuelt enkle måder at gemme brugerdata på. Man skal huske, at databaser er lige så vigtige for dine tjenester som dine applikationsservere. Databaser kører på separate servere (som Amazon RDS) og er også udsat for nedbrud. Hvad værre er, er, at nedbrud i databaser kan føre til tab af brugerdata, hvilket kan vise sig at være dyrt.
Redundans er en proces, der skaber systemer med høj tilgængelighed ved at opnå fejlopsporbarhed og undgå fejl af fælles årsag. Dette kan opnås ved at opretholde slaver, som kan træde til, hvis hovedserveren går ned. Et andet interessant koncept for skalering af databaser er “sharding”. En shard er en horisontal partition i en database, hvor rækker af den samme tabel, som så køres på en separat server.
Diversificerede geografiske placeringer:
Skalering af dine applikationer og derefter dine databaser er et rigtig stort skridt fremad, men hvad nu hvis alle serverne er på samme fysiske placering, og noget forfærdeligt som en naturkatastrofe rammer det datacenter, hvor dine servere er placeret? Det kan føre til potentielt store nedetider.
Det er derfor bydende nødvendigt, at du har dine servere på forskellige steder. De fleste moderne webtjenester giver dig mulighed for at vælge den geografiske placering af dine servere. Du bør vælge klogt for at sikre, at dine servere er fordelt over hele verden og ikke lokaliseret i et område.
I dette indlæg har jeg forsøgt at berøre de grundlæggende ideer, der danner ideen om højtilgængelighedsarkitektur. I den endelige analyse er det indlysende, at intet enkelt system kan løse alle problemerne. Derfor er du nødt til at vurdere din situation omhyggeligt og beslutte, hvilke muligheder der passer bedst til dem. Vi håber, at dette har introduceret dig til verdenen af højtilgængelighedsarkitektur og hjulpet dig med at beslutte, hvordan du selv kan opnå dette.
Hvad er den bedste praksis?
For at dæmme op for systemfejl og holde både planlagte og uplanlagte nedetider på afstand, anbefales det stærkt at bruge en højtilgængelighedsarkitektur (HA), især for missionskritiske applikationer. Eksperter inden for tilgængelighed insisterer på, at for at et system kan være højt tilgængeligt, skal dets dele være godt designet og grundigt testet. Designet og den efterfølgende implementering af en arkitektur med høj tilgængelighed kan være vanskelig på grund af det store udvalg af software, hardware og implementeringsmuligheder. En vellykket indsats starter dog typisk med klart definerede og omfattende forståede forretningskrav. Den valgte arkitektur skal kunne opfylde de ønskede niveauer for sikkerhed, skalerbarhed, ydeevne og tilgængelighed.
Den eneste måde at garantere, at computermiljøer har et ønskeligt niveau af driftskontinuitet i produktionstiden, er ved at designe dem med høj tilgængelighed. Ud over at designe arkitekturen korrekt kan virksomheder holde vigtige applikationer online ved at overholde den anbefalede bedste praksis for høj tilgængelighed.
- Databackup, genopretning og replikering
Det kendetegnende for en god databeskyttelsesplan, der beskytter mod systemfejl, er en god backup- og genoprettelsesstrategi. Værdifulde data bør aldrig opbevares uden ordentlige sikkerhedskopier, replikering eller mulighed for at genskabe dataene. Ethvert datacenter bør planlægge for datatab eller korruption på forhånd. Fejl i data kan skabe problemer med kundeautentificering, skade finansielle konti og efterfølgende erhvervslivets troværdighed. Den anbefalede strategi til opretholdelse af dataintegritet er at oprette en fuld sikkerhedskopi af den primære database og derefter gradvist teste kildeserveren for datafejl. Oprettelse af fuldstændige sikkerhedskopier er en vigtig forudsætning for at kunne genoprette et katastrofalt systemfejl.
- Clustering
Selv med den højeste kvalitet inden for softwareudvikling vil alle applikationstjenester på et tidspunkt fejle. Høj tilgængelighed handler om at levere applikationstjenester uanset fejl. Clustering kan give øjeblikkelig failover-applikationstjenester i tilfælde af en fejl. En applikationstjeneste, der er “cluster aware”, er i stand til at kalde ressourcer fra flere servere; den falder tilbage til en sekundær server, hvis den primære server går offline. En klynge med høj tilgængelighed omfatter flere knuder, der deler oplysninger via fælles datahukommelsesgitter. Det betyder, at enhver knude kan afbrydes eller lukkes ned fra netværket, og resten af klyngen vil fortsætte med at fungere normalt, så længe mindst en enkelt knude er fuldt funktionsdygtig. Hver enkelt knude kan opgraderes individuelt og genforenes, mens klyngen fungerer. De høje omkostninger ved at købe ekstra hardware for at implementere en klynge kan afbødes ved at oprette en virtualiseret klynge, der udnytter de tilgængelige hardwareressourcer.
- Netværk Load Balancing
Load balancing er en effektiv måde at øge tilgængeligheden af kritiske webbaserede applikationer på. Når der registreres serverfejlinstanser, erstattes de problemfrit, når trafikken automatisk omfordeles til de servere, der stadig er i drift. Ikke alene fører load balancing til høj tilgængelighed, det letter også inkrementel skalerbarhed. Netværksbelastningsbalancering kan udføres enten via en “pull”- eller en “push”-model. Det letter højere niveauer af fejltolerance inden for serviceapplikationer.
- Fail Over-løsninger
Højtilgængelighedsarkitektur består traditionelt set af et sæt løst koblede servere, som har failover-funktioner. Failover er grundlæggende en backup-driftstilstand, hvor funktionerne i en systemkomponent overtages af et sekundært system i tilfælde af, at det primære system går offline, enten på grund af fejl eller planlagt nedetid. Der er tale om “koldt failover”, når den sekundære server først startes, efter at den primære server er blevet lukket helt ned. En “hot failover” finder sted, når alle servere kører samtidigt, og belastningen er udelukkende rettet mod en enkelt server på et givet tidspunkt. I begge scenarier overføres opgaverne automatisk til en standby-systemkomponent, således at processen forbliver så problemfri som muligt for slutbrugeren. Failover kan styres via DNS, i et velkontrolleret miljø.
- Geografisk redundans
Geo-redundans er den eneste forsvarslinje, når det drejer sig om at forhindre servicefejl i forbindelse med katastrofale hændelser som f.eks. naturkatastrofer, der forårsager systemnedbrud. Ligesom i tilfælde af geo-replikation udrettes flere servere på geografisk forskellige steder. Stederne skal være globalt fordelt og ikke lokaliseret i et bestemt område. Det er afgørende at køre uafhængige applikationsstacks på hver af lokationerne, så hvis der opstår en fejl på den ene lokation, kan den anden fortsætte med at køre. Ideelt set bør disse lokationer være fuldstændig uafhængige af hinanden.
- Planlæg for fejl
Trods det faktum, at anvendelsen af bedste praksis for høj tilgængelighed i bund og grund er planlægning for fejl; der er andre tiltag, som en organisation kan tage for at øge deres beredskab i tilfælde af en systemfejl, der fører til nedetid. Organisationer bør opbevare data om fejl eller ressourceforbrug, som kan bruges til at isolere problemer og analysere tendenser. Disse data kan kun indsamles gennem løbende overvågning af den operationelle arbejdsbyrde. Der kan oprettes en helpdesk til genopretning for at indsamle problemoplysninger, fastlægge problemhistorikken og påbegynde øjeblikkelige problemløsninger. En genopretningsplan bør ikke blot være veldokumenteret, men også testes regelmæssigt for at sikre, at den er praktisk anvendelig i forbindelse med uplanlagte afbrydelser. Uddannelse af personalet i tilgængelighedsteknik vil forbedre deres færdigheder med hensyn til at designe, implementere og vedligeholde arkitekturer med høj tilgængelighed. Der bør også indføres sikkerhedspolitikker for at begrænse antallet af systemnedbrud på grund af brud på sikkerheden.
Eksempel: Følgende diagram forklarer, hvordan FileCloud-servere kan konfigureres til høj tilgængelighed for at forbedre tjenestens pålidelighed og reducere nedetid. Klik her for at få flere oplysninger.