Hvad er høj tilgængelighed? En Tutorial

Læsetid: 8 minutter

høj tilgængelighed er beskrivelsen af et system designet til at være fejltolerant, meget pålidelig, fungerer kontinuerligt uden intervention eller har et enkelt fejlpunkt. Disse systemer er meget efterspurgte for at øge tilgængeligheden og oppetiden, der kræves for at holde en infrastruktur kørende uden problemer. Følgende egenskaber definerer et system med høj tilgængelighed.

Clustering med høj tilgængelighed

serverklynger med høj tilgængelighed (aka HA-klynger) defineres som en gruppe servere, der understøtter applikationer eller tjenester, der kan bruges pålideligt med en minimal mængde nedetid. Disse serverklynger fungerer ved hjælp af en type specialiseret program, der bruger redundans til at opnå missionskritiske niveauer af five9s oppetid. 60% af virksomhederne fem9 ‘ er eller derover for at levere vitale tjenester til deres virksomheder. programmer med høj tilgængelighed udnytter det redundante program, der er installeret på flere systemer, ved at gruppere eller gruppere en gruppe servere, der fokuserer på et fælles mål, hvis komponenter mislykkes. Uden denne form for klynge, hvis applikationen eller hjemmesiden går ned, vil tjenesten ikke være tilgængelig, før serverne er repareret. HA clustering adresserer disse situationer ved at opdage fejlene og hurtigt genstarte eller udskifte serveren eller tjenesten eller serveren med en ny proces, der ikke kræver menneskelig indgriben. Dette er defineret som en” failover ” model.

illustrationen nedenfor viser en simpel to node høj tilgængelighed klynge.

klynger med høj tilgængelighed bruges ofte til missionskritiske databaser, datadeling, applikationer og e-handelssider spredt over et netværk. Implementeringer med høj tilgængelighed bygger redundans inden for en klynge for at fjerne et enkelt fejlpunkt, herunder på tværs af flere netværksforbindelser og datalagring, som kan forbindes overflødigt via geografisk forskellige lagringsområdenetværk.grupperede servere med høj tilgængelighed bruger normalt en replikationsmetode kaldet hjerteslag, der bruges til at overvåge hver Knudes status og helbred i klyngen via en privat netværksforbindelse. En kritisk omstændighed, som alle klyngeprogrammer skal kunne adressere, kaldes split-brain, som opstår, når alle private Interne links går ned samtidigt, men knudepunkterne i klyngen fortsætter med at køre. Hvis dette sker, kan hver node i klyngen forkert bestemme, at alle de andre noder er gået ned og forsøge at starte tjenester, som andre noder muligvis stadig kører. Denne betingelse for duplikatforekomster, der kører lignende tjenester, hvilket kan forårsage datakorruption på systemet.

en typisk version af høj tilgængelighed giver attributter, der omfatter både udstyr og redundans. Disse funktioner omfatter:

• automatisk registrering og opdagelse af komponenter til udstyr og programmer.
• autonom tildeling af både aktive og betingede roller til nye elementer.
• registrering af fejlbehæftede programmeltjenester, komponenter og andre systemkonstruktioner.
• overvågning og anmeldelse af overflødige komponenter, og når de skal aktiveres.
• evne til at skalere klyngen for at imødekomme de krævede ændringer uden ekstern intervention.

fejltolerance

fejl tolerance defineres som evnen for et Systems infrastruktur til at forudse og modstå fejl og give et automatisk svar på disse problemer, hvis de opstår. Den primære kvalitet af disse systemer er avancerede designfaktorer, som kan påberåbes, hvis der opstår et problem. At være i stand til at konfigurere en infrastruktur, der forestiller sig enhver mulig løsning, er en betydelig opgave, der involverer viden og erfaring til at imødegå de mange bekymringer, før de opstår. Systemarkitekter, der designer sådanne rammer, vil have de metoder, der forestiller sig midlerne til at afhjælpe disse problemer på forhånd, og evnen til at implementere disse rammer.

følgende redundansmetoder er tilgængelige og bør gennemgås i de indledende faser af design og implementering.

• n + 1 Model – dette koncept udleder summen af det nødvendige udstyr (som vi vil henvise til som ‘N’) for at holde hele rammen i gang med en ekstra uafhængig komponentbackup for hver af ‘N’ komponenterne i tilfælde af fejl.
• n + 2-Model-svarende til N + 1-modellen, men med et ekstra beskyttelseslag, hvis to komponenter skulle mislykkes.
• 2n Model – denne modalitet har en dobbelt redundant backup for hvert element for at sikre systemets rammer er fuldt funktionel.
• 2n + 1 Model – igen svarer denne model til 2n-modellen, men med en supplerende komponent for at tilføje et tertiært beskyttelseslag til systemets ramme.

efterhånden som modellerne skrider frem fra Nks til 2nks, øges omkostningsfaktoren også eksponentielt som for virkelig overflødige systemer, der kræver oppetid. Disse metoder er afgørende for stabilitet og tilgængelighed.

pålidelighed og pålidelighed

en af de centrale lejere i et system med høj tilgængelighed er oppetid. Oppetid er af største betydning, især hvis formålet med et system er at levere en vigtig service som 911-systemerne, der reagerer på nye situationer. I erhvervslivet er det nødvendigt at have et system med høj tilgængelighed for at sikre, at en vital service forbliver online. Et eksempel ville være en internetudbyder eller anden tjeneste, der ikke tåler et tab af funktion. Disse systemer skal være designet med høj tilgængelighed og fejltolerance for at sikre pålidelighed og tilgængelighed og samtidig minimere nedetid.

orkestreret fejlhåndtering

skulle der opstå en fejl, vil systemet tilpasse og kompensere for problemet, mens det forbliver op og online. Opbygning af denne type system kræver omtanke og planlægning for det uventede. At kunne forudse problemerne på forhånd og planlægge deres løsning er en af hovedkvaliteterne i et system med høj tilgængelighed.

skalerbarhed

skulle systemet støde på et problem som en trafikspids eller en stigning i ressourceforbruget, skal systemets evne til at skalere for at imødekomme disse behov være automatisk og øjeblikkelig. Opbygning af funktioner som disse i systemet vil give systemets evne til at reagere hurtigt på enhver ændring i den systemiske funktionalitet af arkitekturprocesserne.

tilgængelighed & fem 9 ‘er oppetid

fem 9′ er er industristandarden for måling af oppetid. Denne måling kan relateres til selve systemet, systemprocesserne inden for en ramme eller programmet, der opererer inden for en infrastruktur. Dette estimat er ofte relateret til det program, der leveres til klienter i formularen eller en hjemmeside eller internetapplikation. En systemtilgængelighed kan måles som den procentdel af tid, som systemer er tilgængelige ved hjælp af denne ligning: * 100/N. denne formel angiver, at hvor “n” er det samlede antal minutter inden for en kalendermåned, og “y” er mængden af minutter, som tjenesten er utilgængelig inden for en kalendermåned. Tabellen nedenfor skitserer nedetid relateret til procentdelen af “9 ‘ er” repræsenteret.

som vi kan se, jo højere er antallet af “9 ‘ er”, jo mere oppetid leveres. Et system med høj tilgængelighed er at opnå en minimal mængde potentiel nedetid for at sikre, at systemet altid er tilgængeligt for at levere de udpegede tjenester.

hjerteslag

en af de vigtigste komponenter med høj tilgængelighed kaldes hjerteslag. Heartbeat er en dæmon, der arbejder med en klynge management program som Pacemaker, der er designet specielt til høj tilgængelighed clustering resource management. Dens vigtigste egenskaber er:

• intet specifikt eller fast maksimalt antal noder – hjerteslag kan bruges til at opbygge store klynger såvel som elementære.
• Ressourceovervågning: ressourcer kan automatisk genstartes eller flyttes til en anden node ved fejl.
• en hegnmekanisme, der er nødvendig for at fjerne mislykkede noder fra klyngen.
• en raffineret politikbaseret ressourcestyring, ressourceinterafhængigheder og begrænsninger.
• et tidsbaseret regelsæt, der giver mulighed for forskellige politikker afhængigt af en defineret tidsramme.
• en gruppe af ressource scripts (til programmer som Apache, DB2, Oracle, Postgraduate osv.) inkluderet mere detaljeret styring.
• en GUI til konfiguration, styring og overvågning af ressourcer og noder.

Klyngearkitektur

Konstrueret tilgængelighed

det første segment af et meget tilgængeligt system er den klart designede udnyttelse af klyngede applikationsservere, der er konstrueret på forhånd til at distribuere belastning blandt hele klyngen, hvilket inkluderer evnen til at failover til et sekundært og muligvis et tertiært system.

den anden division omfatter behovet for database skalerbarhed. Dette indebærer kravet om skalering, enten vandret eller lodret, ved hjælp af multiple master replikation og en belastningsbalancer for at forbedre databasens stabilitet og oppetid.

den tredje karakteristik er geografisk mangfoldighed. Dette sikrer, at hvis en naturkatastrofe rammer en enkelt lokalitet, vil denne fiasko ikke hindre evnen til at levere tjenesten.

den fjerde og muligvis vigtigste komponent er at give en backup replikation og disaster recovery metode. Evnen til at sikre en fungerende backup garanterer, at vores data er sikre. Ved hjælp af den nyeste backup strategi (3-2-3) hedder det, at du skal have tre kopier af dine data, på to forskellige medietyper, i tre geografisk forskellige offsite steder for disaster recovery.

ukompliceret implementering

når man diskuterer temaet ukomplicerede implementeringer, skal de specifikt kortlægges til dine specifikke forretningskrav. Følgende træk vil gavne vores operationelle rammer uanset branchens vertikale:

• beskedne træningskrav
• øget produktivitet
• forlænget livscyklus
• omkostningseffektivitet
• hurtig implementering
• reducerede sikkerhedsrisici
• ligetil Integration
• forenklet styring

disse funktioner definerer mange af de primære aspekter, der er nødvendige for at sikre en meget pålidelig, fejltolerant klyngeløsning. Høj tilgængelighed skal i sin kerne udformes med disse egenskaber i tankerne. Funktioner som disse er vigtige tangibles, der er nødvendige aktiver, når du vedtager implementeringsmuligheder.

bedste praksis mål

Design

det primære mål for ethvert mål for bedste praksis med høj tilgængelighed er det optimale design, installation, implementering, integration, og overholdelse af en standardkonvention til de laveste rimelige omkostninger og den minimale kompleksitet, samtidig med at de angivne benchmarkede mål nås for at eliminere hvert enkelt fejlpunkt i systemet.

tilgængelighed

først skal et bestemt mål defineres inden systemets design. Dette omfatter fastlæggelse af, hvad Recovery Point Objective (RPO) er. RPO er den største mængde nedetid, som din virksomhed er villig til at tabe under en større afbrydelse. HA-udstyr, programmel og adjungerede tjenester skal alle have en defineret og testet RPO.

implementering

Dernæst skal systemet bygges med det mest robuste, omkostningseffektive udstyr til rådighed. Dette inkluderer systemer, der er modstandsdygtige over for strømafbrydelser og udstyrsfejl, der spænder over alt fra harddiske, netværkskomponenter, operativsystemet og selve applikationen, der omfatter hele programstakken.

evaluering& test

når systemet er bygget, tester en integreret linchpin vores målsystem for at sikre, at failover-systemet er klar til at skifte over, hvis kilden fejler. Dette kræver forberedelse af vores netværkskonfigurationer, servere, synkron replikeringsprogrammer i realtid og skifter til overgang fra kildeproduktionsbehandling til målsystemet, der behandler overgangen med et øjebliks varsel. Denne metode, der anvendes i dette scenario, er kendt som et “hot standby” – system. Derudover inkluderer dette opsætning af en regimenteret testplan, da systemet testes regelmæssigt igen.

replikation

sikring af en reproducerbar og gentagelig iteration af hele programstakken på tværs af flere regioner er nøglen til konstant holdbarhed, leveringsevne og soliditet af applikationsrammen. Det andet vigtige serviceområde er det replikerbare udstyrssegment, der supplerer programmel-og overvågningsrammerne. At være i stand til at stole på en dedikeret duplikationsmetode er grundlæggende for at garantere et fuldt fejltolerant og pålideligt system.

overvågning & sporing

Endelig bør løbende overvågning, evaluering og observation reguleres tæt for at sikre, at præstationsmålene er opfyldt. Enhver afvigelse fra normen bør undersøges og vurderes for at bestemme, hvilken indvirkning variansen har på systemet. Når denne disposition er fastslået, bør der foretages en opfølgende analyse af, om der skal foretages ændringer for at inkludere den justering eller de ændringer, der er nødvendige for at bringe systemet i en ny stabil tilstand.

konklusion

det primære mål med et system med høj tilgængelighed er at forhindre og eliminere alle enkeltpunkter for fiasko. Dette bør omfatte flere handlingsplaner, der er testet og på plads, klar til at reagere uafhængigt og øjeblikkeligt på alle serviceforstyrrelser, forstyrrelser og fejl. Dette omfatter uregelmæssigheder i udstyr, programmer og applikationer. Udryddelsen af nedetid kan opnås med den sammensatte, dygtige planlægning og implementering af et system. Der kræves et kritisk øje for at forestille sig og forberede sig på enhver begivenhed eller katastrofe, hvilket kan hindre det primære mål for det angivne og forventede oppetidsmål. Et godt indført system med høj tilgængelighed kan nå dette mål med korrekt planlægning og design, reducere eller eliminere forstyrrelser og maksimere tilgængeligheden.

omhyggelig planlægning + pålidelige implementeringsmetoder + stabile Programmelplatforme + infrastruktur til lydudstyr + glatte tekniske operationer + forsigtige Styringsmål + konsistent datasikkerhed + forudsigelige Redundanssystemer + robuste backupløsninger + flere gendannelsesmuligheder = 100% oppetid

vores talentfulde supportteam er bemandet med erfarne teknikere og systemadministratorer, der har en intim viden om flere hostingteknologier, især dem, der diskuteres i denne artikel.
Hvis du er en fuldt administreret VPS-server, Cloud Dedicated, privat server eller en dedikeret Serverejer, og du er ubehagelig med at udføre et af de skitserede trin, kan vi nås via telefon @800.580.4985, en chat-eller supportbillet til at hjælpe dig med denne proces.