Lesetid: 8 minutter
Høy tilgjengelighet er beskrivelsen av et system designet for å være feiltolerant, svært pålitelig, opererer kontinuerlig uten inngrep, eller har et enkelt feilpunkt. Disse systemene er svært ettertraktet for å øke tilgjengeligheten og oppetiden som kreves for å holde en infrastruktur i gang uten problemer. Følgende egenskaper definerer et System Med Høy Tilgjengelighet.
Serverklynger med høy Tilgjengelighet
Serverklynger Med høy tilgjengelighet (AKA HA-Klynger) er definert som en gruppe servere som støtter programmer eller tjenester som kan utnyttes pålitelig med minimal nedetid. Disse serverklyngene fungerer ved hjelp av en type spesialisert programvare som benytter redundans for å oppnå driftskritiske nivåer av five9s oppetid. For tiden krever omtrent 60% av bedriftene five9 eller større for å gi viktige tjenester til sine virksomheter. Programvare Med høy tilgjengelighet utnytter den overflødige programvaren som er installert på flere systemer, ved å gruppere eller gruppere sammen en gruppe servere som fokuserer på et felles mål i tilfelle komponenter mislykkes. Uten denne form for clustering, hvis programmet eller nettstedet krasjer, vil tjenesten ikke være tilgjengelig før serverne er reparert. HA clustering løser disse situasjonene ved å oppdage feilene og raskt starte eller erstatte serveren eller tjenesten eller serveren med en ny prosess som ikke krever menneskelig inngrep. Dette er definert som en» failover » – modell.
illustrasjonen nedenfor viser en enkel to node høy tilgjengelighet klynge.
klynger med Høy Tilgjengelighet brukes ofte til virksomhetskritiske databaser, datadeling, applikasjoner og e-handelsnettsteder spredt over et nettverk. Implementeringer av høy Tilgjengelighet bygger redundans i en klynge for å fjerne ett enkelt feilpunkt, inkludert på tvers av flere nettverkstilkoblinger og datalagring, som kan kobles redundant via geografisk forskjellige lagringsområdenettverk.
grupperte servere med Høy Tilgjengelighet bruker vanligvis en replikasjonsmetodikk kalt Hjerteslag som brukes til å overvåke hver nodes status og tilstand i klyngen over en privat nettverkstilkobling. En kritisk omstendighet all clustering programvare må kunne adressere kalles split-brain, som oppstår når alle private interne koblinger går ned samtidig, men nodene i klyngen fortsetter å kjøre. Hvis dette skjer, kan hver node i klyngen feilaktig fastslå at alle de andre nodene har gått ned og forsøke å starte tjenester som andre noder kan fortsatt kjører. Denne betingelsen for duplikatforekomster som kjører lignende tjenester, noe som kan føre til dataødeleggelse på systemet.
En typisk versjon av programvare med høy tilgjengelighet gir attributter som inkluderer både maskinvare-og programvareredundans. Disse funksjonene inkluderer:
- automatisk gjenkjenning og oppdagelse av maskinvare-og programvarekomponenter.
- Autonom tildeling av både aktive og betingede roller til nye elementer.
- Påvisning av mislykkede programvaretjenester, maskinvarekomponenter og andre systemkonstruksjoner.
- Overvåking Og varsling av overflødige komponenter og når de må aktiveres.
- Evne til å skalere klyngen for å imøtekomme de nødvendige endringene uten ekstern intervensjon.
er definert som evnen for et system infrastruktur for å forutse og motstå feil og gi en automatisk respons på disse problemene hvis oppstått. Den primære kvaliteten på disse systemene er avanserte designfaktorer, som kan påkalles hvis et problem oppstår. Å kunne konfigurere en infrastruktur som ser for seg alle mulige løsninger er en betydelig oppgave som involverer kunnskap og erfaring for å motvirke flere bekymringer før de oppstår. Systemarkitekter som utformer slike rammer vil ha metoder som ser for seg midler til å lindre disse problemene på forhånd, og evnen til å gjennomføre disse rammene.
følgende redundansmetoder er tilgjengelige og bør gjennomgås i de første stadiene av design og implementering.N + 1 Modell-dette konseptet utleder summen av utstyr som trengs (som Vi vil referere til Som ‘N’) for å holde hele rammen oppe og går, med en ekstra uavhengig komponent backup for hver Av ‘N’ komponenter i tilfelle feil.
som modeller fremgang Fra Nx til 2Nx, kostnadsfaktoren øker også eksponentielt som for virkelig redundante systemer som krever oppetid. Disse metodene er kritiske for stabilitet og tilgjengelighet.
Pålitelighet og Pålitelighet
en av de sentrale leietakerne i et system med høy tilgjengelighet er oppetid. Oppetid er av største betydning, spesielt hvis formålet med et system er å gi en viktig tjeneste som 911-systemene som reagerer på nødsituasjoner. I virksomheten er det nødvendig å ha et system med høy tilgjengelighet for å sikre at en viktig tjeneste forblir online. ET eksempel kan være EN ISP eller en annen tjeneste som ikke kan tolerere tap av funksjon. Disse systemene må utformes med høy tilgjengelighet og feiltoleranse for å sikre pålitelighet og tilgjengelighet samtidig som nedetiden minimeres.
Orkestrert Feilhåndtering
skulle det oppstå en feil, vil systemet tilpasse og kompensere for problemet mens det er oppe og på nett. Å bygge denne typen system krever omtanke og planlegging for det uventede. Å kunne forutse problemene på forhånd, og planlegging for oppløsning er en av hovedkvaliteten til et system med høy tilgjengelighet.
Skalerbarhet
skulle systemet støte på et problem som en trafikkspike eller en økning i ressursbruk, bør systemets evne til å skalere for å møte disse behovene være automatisk og umiddelbar. Å bygge funksjoner som disse inn i systemet vil gi systemets evne til å reagere raskt på enhver endring i den systemiske funksjonaliteten til arkitekturprosessene.
Tilgjengelighet& Fem 9s Oppetid
Fem 9s Er bransjestandarden for måling av oppetid. Denne målingen kan være relatert til selve systemet, systemprosessene innenfor et rammeverk eller programmet som opererer i en infrastruktur. Denne estimeringen er ofte relatert til programmet blir levert til kunder i form eller et nettsted eller web-applikasjon. En systemtilgjengelighet kan måles som prosentandelen av tiden systemene er tilgjengelige ved å bruke denne ligningen: x = (n – y) * 100 / n. denne formelen angir at hvor » n «er den totale mengden minutter i en kalendermåned, og» y » er mengden minutter som tjenesten er utilgjengelig innen en kalendermåned. Tabellen nedenfor skisserer nedetid relatert til prosentandelen av» 9 » representert.
som vi kan se, jo høyere antall «9», jo mer oppetid er gitt. Et system med høy tilgjengelighet har som mål å oppnå minimal potensiell nedetid for å sikre at systemet alltid er tilgjengelig for å levere de utpekte tjenestene.
Heartbeat
En Av De Viktigste Komponentene Med Høy Tilgjengelighet kalles Heartbeat. Heartbeat er en daemon som fungerer med en klynge programvare som Pacemaker som er utviklet spesielt for høy tilgjengelighet clustering ressursforvaltning. Dens viktigste egenskaper er:
- Ingen bestemt eller fast maksimalt antall noder-Hjerteslag kan brukes til å bygge store klynger så vel som elementære.
- Ressursovervåking: ressurser kan automatisk startes på nytt eller flyttes til en annen node ved feil.
- en gjerdemekanisme som trengs for å fjerne mislykkede noder fra klyngen.
- en raffinert policy-basert ressursforvaltning, ressurs inter-avhengigheter, og begrensninger.
- en tidsbasert regel satt til å tillate ulike policyer avhengig av en definert tidsramme.
- en gruppe av ressurs skript (for programvare Som Apache, DB2, Oracle, PostgreSQL, etc.) inkludert mer granulær ledelse.
- ET GUI for konfigurering, kontroll og overvåking av ressurser og noder.
Cluster Architecture
Konstruert Tilgjengelighet
det første segmentet av et svært tilgjengelig system er den klart utformede utnyttelsen av grupperte applikasjonsservere som er konstruert på forhånd for å distribuere belastning mellom hele klyngen, som inkluderer muligheten til å failover til et sekundært og muligens et tertiært system.
den andre divisjonen inkluderer behovet for database skalerbarhet. Dette innebærer kravet om skalering, enten horisontalt eller vertikalt, ved hjelp av multiple master replikasjon, og en lastbalanser for å forbedre stabiliteten og oppetiden til databasen.
den tredje egenskapen er geografisk mangfold. Dette sikrer at hvis en naturkatastrofe treffer en enkelt lokasjon, vil feilen ikke hindre evnen til å yte tjenesten.
den fjerde og muligens viktigste komponenten er å gi en backup replikering og disaster recovery metodikk. Evnen til å sikre en fungerende backup garanterer at våre data er trygge. Ved hjelp av den nyeste backup strategi (3-2-3) sier at du bør ha tre kopier av dataene, på to forskjellige medietyper, i tre geografisk forskjellige offsite steder for katastrofegjenoppretting.
Ukomplisert Distribusjon
når du diskuterer temaet ukompliserte distribusjoner, bør de spesifikt kartlegges til dine spesifikke forretningsbehov. Følgende egenskaper vil være til nytte for vårt operasjonelle rammeverk uavhengig av bransjens vertikale:
- Beskjedne Opplæringskrav
- Økt Produktivitet
- Utvidet Livssyklus
- Kostnadseffektivitet
- Driftseffektivitet
- Rask Implementering
- Reduserte Sikkerhetsrisikoer
- Enkel Integrasjon
- Forenklet Administrasjon
disse funksjonene definerer mange av de viktigste aspektene som trengs for å sikre en svært pålitelig, feiltolerant klyngeløsning. Høy tilgjengelighet, i kjernen, bør utformes med disse egenskapene i tankene. Funksjoner som disse er viktige tangibles som kreves eiendeler ved bruk av distribusjonsalternativer.
Mål For Beste Praksis
Design
det primære målet for enhver høy tilgjengelighet beste praksis mål er optimal design, installasjon, distribusjon, integrasjon, og overholdelse av en standard konvensjon til lavest rimelig pris og minimal kompleksitet samtidig oppnå de angitte benchmarkedsmål for å eliminere hvert enkelt punkt av svikt i systemet.
Tilgjengelighet
først bør et bestemt mål defineres før systemets utforming. Dette inkluderer å etablere Hva Recovery Point Objective (RPO) er. RPO er den største mengden nedetid som din bedrift er villig til å miste under en stor strømbrudd. HA-maskinvare, programvare og tilleggstjenester bør alle ha en definert OG testet RPO.
Distribusjon
deretter skal systemet bygges med den mest robuste og kostnadseffektive maskinvaren som er tilgjengelig. Dette inkluderer systemer som er motstandsdyktige mot strømbrudd og maskinvarefeil, som spenner over alt fra harddisker, nettverkskomponenter, operativsystemet og selve applikasjonen som omfatter hele programvarestakken.
Evaluering& Testing
når systemet er bygget, tester en integrert linchpin vårt målsystem for å sikre at failover-systemet er klart til å bytte om kilden mislykkes. Dette krever å forberede våre nettverkskonfigurasjoner, servere, sanntidssynkron replikeringsprogramvare, og bytter til overgang fra kildeproduksjonsprosessering til målsystemet som behandler overgang på et øyeblikks varsel. Denne metoden som brukes i dette scenariet er kjent som et» hot standby » – system. I tillegg inkluderer dette å sette opp en regimented testing tidsplan som systemet testes regelmessig.
Replikering
Å Sikre en reproduserbar og repeterbar iterasjon av hele programvarestakken på tvers av flere regioner er nøkkelen til konstant holdbarhet, leverbarhet og soliditet i applikasjonsrammeverket. Det andre viktige serviceområdet er det replikerbare maskinvaresegmentet, som utfyller programvare og overvåkingsrammer. Å kunne stole på en dedikert dupliseringsmetode er grunnleggende for å garantere et fullt feiltolerant og pålitelig system.
Overvåking& Sporing
til Slutt bør kontinuerlig overvåking, evaluering og observasjon reguleres tett for å sikre at ytelsesmålene blir oppfylt. Eventuelle avvik fra normen bør undersøkes og vurderes for å bestemme effekten variansen har på systemet. Når denne disposisjonen er etablert, bør det gjennomføres en oppfølgingsanalyse med hensyn til om eventuelle endringer bør iverksettes for å inkludere de justeringer eller endringer som er nødvendige for å bringe systemet inn i en ny stabil tilstand.
Konklusjon
det primære målet med et system med høy tilgjengelighet er å forhindre og eliminere alle enkeltpunkter for feil. Dette bør inkludere flere handlingsplaner som er testet og på plass, klare til å reagere uavhengig og umiddelbart på alle tjenesteforstyrrelser, forstyrrelser og feil. Dette inkluderer maskinvare -, programvare-og applikasjonsforstyrrelser. Utrydding av nedetid kan oppnås med sammensatt, dyktig planlegging og implementering av et system. Et kritisk øye er nødvendig for å forestille seg og forberede seg på enhver hendelse eller katastrofe, noe som kan hindre det primære målet for det oppgitte og forventede oppetidsmålet. Et veletablert System med Høy Tilgjengelighet kan oppnå dette målet med riktig planlegging og design, redusere eller eliminere forstyrrelser og maksimere tilgjengeligheten.
Nøye Planlegging + Pålitelige Implementeringsmetoder + Stabile Programvareplattformer + God Maskinvareinfrastruktur + Jevne Tekniske Operasjoner + Forsiktige Ledelsesmål + Konsekvent Datasikkerhet + Forutsigbare Redundanssystemer + Robuste Backup-Løsninger + Flere Gjenopprettingsalternativer = 100% Oppetid
våre talentfulle Supportteam er bemannet med erfarne Linux-teknikere og Systemadministratorer som har en intim kunnskap om flere web hosting teknologier, spesielt de som er omtalt i denne artikkelen. hvis du Er En Fullstendig Administrert VPS-server, Cloud Dedicated, VMWare Private Cloud, Private Parent server eller En Dedikert servereier, og du er ubehagelig med å utføre noen av trinnene som er skissert, kan vi nås via telefon @800.580.4985, en chat eller support billett for å hjelpe deg med denne prosessen.