Maybaygiare.org

Blog Network

Vad är hög tillgänglighet? En handledning

Lästid: 8 minuter

hög tillgänglighet är beskrivningen av ett system som är utformat för att vara feltolerant, mycket pålitligt, arbetar kontinuerligt utan ingrepp eller har en enda felpunkt. Dessa system är mycket eftertraktade för att öka tillgängligheten och drifttiden som krävs för att hålla en Infrastruktur igång utan problem. Följande egenskaper definierar ett system med hög tillgänglighet.

hög tillgänglighet Clustering

hög tillgänglighet serverkluster (aka ha kluster) definieras som en grupp av servrar som stöder applikationer eller tjänster som kan utnyttjas på ett tillförlitligt sätt med en minimal mängd driftstopp. Dessa serverkluster fungerar med hjälp av en typ av specialiserad programvara som använder redundans för att uppnå uppdragskritiska nivåer av five9s drifttid. För närvarande kräver cirka 60% av företagen fem 9: or eller mer för att tillhandahålla viktiga tjänster för sina företag.

programvara med hög tillgänglighet utnyttjar redundant programvara installerad på flera system genom att gruppera eller gruppera ihop en grupp servrar som fokuserar på ett gemensamt mål om komponenter misslyckas. Utan denna form av kluster, om applikationen eller webbplatsen kraschar, kommer tjänsten inte att vara tillgänglig förrän servrarna repareras. HA clustering adresserar dessa situationer genom att upptäcka felen och snabbt starta om eller ersätta servern eller tjänsten eller servern med en ny process som inte kräver mänsklig intervention. Detta definieras som en” failover ” – modell.

illustrationen nedan visar en enkel två nod hög tillgänglighet kluster.

hög tillgänglighet kluster används ofta för verksamhetskritiska databaser, datadelning, applikationer och e-handelswebbplatser spridda över ett nätverk. Implementeringar med hög tillgänglighet bygger redundans i ett kluster för att ta bort en enda felpunkt, inklusive över flera nätverksanslutningar och datalagring, som kan anslutas redundant via geografiskt olika lagringsnätverk.

hög tillgänglighet klustrade servrar brukar använda en replikering metod som kallas Heartbeat som används för att övervaka varje nod status och hälsa i klustret över en privat nätverksanslutning. En kritisk omständighet som alla klusterprogram måste kunna ta itu med kallas split-brain, vilket inträffar när alla privata Interna Länkar går ner samtidigt, men noderna i klustret fortsätter att köras. Om detta inträffar kan varje nod i klustret felaktigt bestämma att alla andra noder har gått ner och försöka starta tjänster som andra noder fortfarande kan köras. Detta villkor för dubbla instanser som kör liknande tjänster, vilket kan orsaka datakorruption på systemet.

en typisk version av hög tillgänglighet programvara ger attribut som inkluderar både hårdvara och programvara redundans. Dessa funktioner inkluderar:

  • automatisk detektering och upptäckt av hårdvaru-och programvarukomponenter.
  • autonom tilldelning av både aktiva och kontingenta Roller till nya element.
  • upptäckt av misslyckade programvarutjänster, hårdvarukomponenter och andra systemkonstruktioner.
  • övervakning och anmälan av redundanta komponenter och när de behöver aktiveras.
  • förmåga att skala klustret för att tillgodose de nödvändiga ändringarna utan extern intervention.

feltolerans

feltolerans definieras som förmågan för ett systems Infrastruktur att förutse och motstå fel och ge ett automatiskt svar på dessa problem om de uppstår. Den primära kvaliteten på dessa system är avancerade designfaktorer, som kan uppmanas om ett problem uppstår. Att kunna konfigurera en infrastruktur som föreställer sig alla möjliga lösningar är en betydande uppgift som innebär kunskap och erfarenhet för att motverka de många problemen innan de uppstår. Systemarkitekter som utformar sådana ramar kommer att ha de metoder som föreställer sig medel för att lindra dessa problem i förväg och förmågan att implementera dessa ramar.

följande redundansmetoder finns tillgängliga och bör ses över under de inledande stadierna av design och implementering.

  • n + 1 Modell – detta koncept drar slutsatsen summan av utrustning som behövs (som vi kommer att referera till som ’N’) för att hålla hela ramverket igång, med ytterligare en oberoende komponentbackup för var och en av ’N’ – komponenterna i händelse av fel.
  • n + 2 – modell-liknar n + 1-modellen men med ett extra skyddslager om två komponenter skulle misslyckas.
  • 2n Modell-denna modalitet har en dubbel redundant backup för varje element för att säkerställa att systemets ramverk är fullt fungerande.
  • 2n + 1 Modell – återigen liknar denna modell 2N-modellen men med en kompletterande komponent för att lägga till ett tertiärt skyddsskikt i systemets ramverk.

När modellerna går från Nx till 2Nx ökar kostnadsfaktorn också exponentiellt som för verkligt överflödiga system som kräver drifttid. Dessa metoder är avgörande för stabilitet och tillgänglighet.

pålitlighet och tillförlitlighet

en av de centrala hyresgästerna i ett system med hög tillgänglighet är drifttid. Drifttid är av största vikt, särskilt om syftet med ett system är att tillhandahålla en viktig tjänst som 911-systemen som svarar på framväxande situationer. I affärer krävs ett system med hög tillgänglighet för att säkerställa att en viktig tjänst förblir online. Ett exempel skulle vara en ISP eller annan tjänst som inte kan tolerera en funktionsförlust. Dessa system måste utformas med hög tillgänglighet och feltolerans för att säkerställa tillförlitlighet och tillgänglighet samtidigt som driftstopp minimeras.

Orchestrated Error Handling

om ett fel uppstår kommer systemet att anpassa och kompensera för problemet medan det återstår och online. Att bygga denna typ av system kräver eftertanke och planering för det oväntade. Att kunna förutse problemen i förväg och planera för deras upplösning är en av de viktigaste egenskaperna hos ett system med hög tillgänglighet.

skalbarhet

om systemet stöter på ett problem som en trafikspik eller en ökning av resursanvändningen bör systemets förmåga att skala för att möta dessa behov vara automatisk och omedelbar. Att bygga funktioner som dessa i systemet kommer att ge systemets förmåga att reagera snabbt på alla förändringar i den systemiska funktionaliteten hos arkitekturprocesserna.

tillgänglighet & fem 9: s drifttid

fem 9: s är branschstandarden för mätning av drifttid. Denna mätning kan relateras till själva systemet, systemprocesserna inom ett ramverk eller programmet som fungerar i en Infrastruktur. Denna uppskattning är ofta relaterad till programmet som levereras till kunder i form eller en webbplats eller webbapplikation. En systemtillgänglighet kan mätas som procentandelen tid som system är tillgängliga med hjälp av denna ekvation: x = (n – y) * 100/n. denna formel anger att där ”n” är den totala mängden minuter inom en kalendermånad, och ”y” är mängden minuter som tjänsten är otillgänglig inom en kalendermånad. Tabellen nedan beskriver driftstopp relaterade till andelen ”9” representerade.

som vi kan se, ju högre antalet ”9”, desto mer drifttid tillhandahålls. Ett högtillgänglighetssystems mål är att uppnå en minimal mängd potentiella driftstopp för att säkerställa att systemet alltid är tillgängligt för att tillhandahålla de utsedda tjänsterna.

hjärtslag

en av de viktigaste komponenterna med hög tillgänglighet kallas hjärtslag. Heartbeat är en demon som arbetar med ett kluster programvara som Pacemaker som är utformad speciellt för hög tillgänglighet klustring resurshantering. Dess viktigaste egenskaper är:

  • inget specifikt eller fast maximalt antal noder – hjärtslag kan användas för att bygga stora kluster såväl som elementära.
  • Resursövervakning: resurser kan startas om automatiskt eller flyttas till en annan nod vid fel.
  • en fäktningsmekanism som behövs för att ta bort misslyckade noder från klustret.
  • en förfinad policybaserad resurshantering, resursinterberoenden och begränsningar.
  • en tidsbaserad regeluppsättning som tillåter olika policyer beroende på en definierad tidsram.
  • en grupp resursskript (för programvara som Apache, DB2, Oracle, PostgreSQL, etc.) ingår mer detaljerad hantering.
  • ett GUI för att konfigurera, styra och övervaka resurser och noder.

Klusterarkitektur

konstruerad tillgänglighet

det första segmentet av ett mycket tillgängligt system är det tydligt utformade utnyttjandet av klustrade applikationsservrar som är konstruerade i förväg för att fördela belastningen mellan hela klustret, vilket inkluderar möjligheten att failover till ett sekundärt och eventuellt ett tertiärt system.

den andra divisionen innehåller behovet av Databas skalbarhet. Detta innebär kravet på skalning, antingen horisontellt eller vertikalt, med användning av multiple master replication, och en lastbalanserare för att förbättra stabiliteten och drifttiden för databasen.

den tredje egenskapen är geografisk mångfald. Detta säkerställer att om en naturkatastrof träffar en enda plats, att misslyckande inte kommer att hindra förmågan att tillhandahålla tjänsten.

den fjärde och kanske viktigaste komponenten är att tillhandahålla en säkerhetskopierings-och katastrofåterställningsmetodik. Möjligheten att säkerställa en fungerande säkerhetskopia garanterar att våra data är säkra. Med hjälp av den senaste säkerhetskopieringsstrategin (3-2-3) anges att du ska ha tre kopior av dina data, på två olika medietyper, på tre geografiskt olika offsite-platser för katastrofåterställning.

okomplicerad distribution

När du diskuterar temat okomplicerade distributioner bör de specifikt mappas till dina specifika affärskrav. Följande egenskaper kommer att gynna vår operativa ram oavsett bransch vertikal:

  • blygsamma utbildningskrav
  • ökad produktivitet
  • förlängd livscykel
  • kostnadseffektivitet
  • operativ effektivitet
  • snabbt genomförande
  • minskade säkerhetsrisker
  • enkel Integration
  • förenklad hantering

dessa funktioner definierar många av de primära aspekter som behövs för att säkerställa en mycket pålitlig, feltolerant, klusterlösning. Hög tillgänglighet, i sin kärna, bör utformas med dessa egenskaper i åtanke. Funktioner som dessa är viktiga saker som krävs tillgångar när du antar distributionsalternativ.

bästa praxis mål

Design

det primära målet för alla best practice-mål med hög tillgänglighet är optimal design, installation, distribution, integration och efterlevnad av en standardkonvention till lägsta rimliga kostnad och minimal komplexitet samtidigt som de angivna riktmärkta målen uppnås för att eliminera varje enskild felpunkt i systemet.

tillgänglighet

först bör ett bestämt mål definieras före systemets utformning. Detta inkluderar att fastställa vad Återställningspunktmålet (RPO) är. RPO är den största mängden driftstopp som ditt företag är villigt att förlora under ett stort avbrott. HA-hårdvaran, programvaran och tilläggstjänsterna bör alla ha en definierad och testad RPO.

Deployment

därefter ska systemet byggas med den mest robusta, kostnadseffektiva hårdvaran som finns tillgänglig. Detta inkluderar system som är motståndskraftiga mot strömavbrott och hårdvarufel, som spänner över allt från hårddiskar, nätverkskomponenter, operativsystemet och själva applikationen som omfattar hela programstacken.

utvärdering & testning

När systemet är byggt testar en integrerad linchpin vårt målsystem för att säkerställa att failover-systemet är klart att växla om källan misslyckas. Detta kräver att vi förbereder våra nätverkskonfigurationer, servrar, synkron replikationsprogramvara i realtid och växlar till övergång från källproduktionsbearbetning till målsystemet som behandlar övergången med ett ögonblick. Denna metod som används i detta scenario kallas ett ”hot standby” – system. Dessutom inkluderar detta att ställa in ett regimenterat testschema eftersom systemet testas regelbundet.

Replication

att säkerställa en reproducerbar och repeterbar iteration av hela programstacken över flera regioner är nyckeln till konstant hållbarhet, leverans och sundhet i applikationsramen. Det andra viktiga serviceområdet är det replikerbara hårdvarusegmentet, som kompletterar mjukvaru-och övervakningsramarna. Att kunna förlita sig på en särskild dupliceringsmetod är grundläggande för att garantera ett helt feltolerant och pålitligt system.

övervakning & spårning

slutligen bör pågående övervakning, utvärdering och observation regleras tätt för att säkerställa att prestationsmålen uppnås. Varje avvikelse från normen bör undersökas och bedömas för att bestämma vilken inverkan variansen har på systemet. När denna disposition har fastställts bör en uppföljningsanalys utföras om eventuella ändringar bör antas för att inkludera de justeringar eller ändringar som behövs för att få systemet till ett nytt stabilt tillstånd.

slutsats

det primära målet med ett system med hög tillgänglighet är att förhindra och eliminera alla enskilda felpunkter. Detta bör omfatta flera handlingsplaner som har testats och på plats, redo att reagera oberoende och omedelbart på alla servicestörningar, störningar och misslyckanden. Detta inkluderar maskinvara, programvara och oegentligheter i applikationen. Utrotning av driftstopp kan åstadkommas med sammansatt, skicklig planering och genomförande av ett system. Ett kritiskt öga krävs för att föreställa sig och förbereda sig för varje händelse eller katastrof, vilket kan hindra det primära målet för det angivna och förväntade upptidsmålet. Ett välinrättat system med hög tillgänglighet kan uppnå detta mål med korrekt planering och design, minska eller eliminera störningar och maximera tillgängligheten.noggrann planering + tillförlitliga implementeringsmetoder + stabila mjukvaruplattformar + sund hårdvaruinfrastruktur + smidiga tekniska operationer + försiktiga Hanteringsmål + konsekvent datasäkerhet + förutsägbara Redundanssystem + robusta backuplösningar + flera återställningsalternativ = 100% drifttid

våra begåvade supportteam är bemannade med erfarna Linux-tekniker och systemadministratörer som har en intim kunskap om flera webbhotell tekniker, särskilt de som diskuteras i den här artikeln.
om du är en helt hanterad VPS-server, Cloud Dedicated, VMWare Private Cloud, Private Parent server eller en dedikerad serverägare och du är obekväm med att utföra något av de steg som beskrivs, kan vi nås via telefon @800.580.4985, en chatt eller supportbiljett för att hjälpa dig med denna process.

Lämna ett svar

Din e-postadress kommer inte publiceras.