Feltolerans för arbetsbelastningar i transportföretagsklass

Telekommunikationsföretag har visat att det är möjligt att implementera program som uppfyller och överskrider tillgänglighetskraven i bärarklassen, samtidigt som de körs ovanpå otillförlitliga element. Företag överskrider dessa krav genom feltolerans, vilket omfattar följande aspekter:

• Kombination av oberoende, icke-högtillgängliga element.
• Svarsmekanismer för trafikhanteringsfel.
• Reparations- och kapacitetsåterställnings- och felhanteringsmekanismer.
• Användning av korselementdatabaser med hög tillgänglighet.

När du utformar för tillförlitlighet och återhämtning i bärvågsklassen förutsätter vi att varje komponent kan och kommer att misslyckas. Designen kräver en metod med flera lager för felmatchning. En del av valideringen av designen är att skapa en kvantitativ probabilistisk modell av de olika fellägena som tydligt identifierar de nyckelberoenden som programmet har, och visar att programmet kan uppnå nödvändig tillgänglighet eftersom dessa beroenden uppfyller sina egna servicenivåmål . Den här modellen bör behållas och valideras kontinuerligt efter utveckling och i produktion för att säkerställa att testdata och realtidsdata matchar det som modellen förutsäger.

Hög tillgänglighet via kombination

Om du vill nå hög tillgänglighet tar du oberoende element, som inte har hög tillgänglighet, och kombinerar dem så att de förblir oberoende entiteter. Sannolikheten för att flera element misslyckas tillsammans är mycket lägre än sannolikheten för fel för ett enskilt element. Vi definierar den här processen som arkitekturformatet Dela ingenting .

Svar på trafikhanteringsfel

När enskilda element misslyckas, eller om det finns anslutningsproblem, har systemets trafikhanteringslager olika sätt att svara för att upprätthålla den övergripande tjänsten. Lösningen bör implementera så många av följande mekanismer som möjligt eller nödvändigt för att uppnå tillgänglighet. De två första mekanismerna förlitar sig på ett specifikt beteende i klienten, vilket kanske inte alltid är ett alternativ:

1. Omedelbart återförsök av klienten till alternativt mål – Vid fel, eller efter inget svar från ett nytt försök, kan klienten omedelbart försöka begäran igen med ett alternativt element som anses sannolikt att lyckas, i stället för att skicka en ny DNS-fråga för att identifiera ett alternativ.

2. Klientbaserade hälsolistor – Upprätthåller listor över element som är kända felfria och kända inte felfria. Begäranden skickas alltid till ett känt felfritt element, såvida inte listan är tom. Om de är tomma provas de kända felaktiga elementen.

3. Serverbaserad avsökning – Systembaserade distributionsmekanismer, till exempel DNS eller Azure Traffic Manager (ATM), implementerar sin egen livenessidentifiering och övervakning för att möjliggöra routning runt felaktiga element.

Svar på reparations- och återställningsfel

Trafikhanteringssvar kan kringgå fel, men om felet är långvarigt eller permanent måste det defekta elementet repareras eller ersättas. Det finns två huvudsakliga alternativ här:

1. Återställer redundans – Fel i ett element minskar den övergripande systemkapaciteten. Systemdesignen bör möjliggöra denna kapacitetsminskning genom etablering av redundant kapacitet. Flera överlappande fel leder dock till verkliga avbrott. Det måste finnas en automatiserad process som identifierar felet och lägger till kapacitet för att återställa redundans till dess normala nivåer. Effekten kan fastställas utifrån felfrekvensanalysen. I många fall kan en automatisk återställning av redundansnivån öka acceptabel stilleståndstid för enskilda element.

2. (Valfritt) Reparera det felaktiga elementet – Lösningen kan behöva innehålla en mekanism som identifierar felet och försöker reparera det misslyckade elementet på plats. Den här lösningen kanske inte gäller för fall där processen med att återställa redundans instansierar ett nytt element för att ersätta det misslyckade och avslutar och inaktiverar det misslyckade elementet.

Följande diagram visar hur de två lägena för felhantering samarbetar för att tillhandahålla feltolerans på servicenivå:

Analys av felfrekvens

Ingen ansträngning leder till ett perfekt system, så börja med antagandet att allt kan och kommer att misslyckas. Överväg hur lösningen som helhet ska fungera. Analys av felfrekvens börjar med enskilda system på lägre nivå och kombinerar resultaten för att modellera den fullständiga lösningen.

Analysen görs vanligtvis med Markov-modellering, som tar hänsyn till alla möjliga fellägen. Överväg följande faktorer för varje felläge:

• Pris
• Varaktighet och lösningstid
• Sannolikhet för korrelerade fel (vad är chansen att ett fel i tjänst X orsakar ett fel i tjänsten Y)

Resultatet är en uppskattning av systemets tillgänglighet och informerar om sprängradien. Sprängradien är en uppsättning saker som inte fungerar med tanke på ett visst fel. Bra design syftar till att begränsa uppsättningens omfattning och allvarlighetsgrad, eftersom fel kommer att inträffa. Till exempel är ett fel som blockerar skapandet av nya användare, men som inte påverkar befintliga, mindre oroande än ett fel som stoppar tjänsten för alla användare.

Analys av felfrekvens ger en uppskattning av den övergripande tillgängligheten på systemnivå. Analysen identifierar de kritiska beroenden som tillgängligheten är beroende av. Om analys av felfrekvens indikerar att systemets tillgänglighet inte är tillgänglig ger den också specifika, kvantitativa insikter om var förbättringar behövs och i vilken utsträckning.

Mer information om analys av felläge i Azure finns i Analys av felläge för Azure-program.

Sammanhängande fel och överlagring

Designen av program i bärarklass måste vara noga med riskerna med sammanhängande fel, där fel i ett element leder till fel i andra element, ofta på grund av överbelastning. Sammanhängande fel är inte unika för program i bärvågsklass, men tillförlitligheten och svarstiden kräver korrekt försämring och automatiserad återställning.

Nästa steg

Granska det område för datamodelldesign som övervägs för arbetsbelastningar i bärvågsklass.

Designområde: Datamodell