Gör alla saker överflödiga

Bygg in redundans i din applikation för att undvika enskilda felpunkter

En motståndskraftig applikation hanterar nuvarande fel. Identifiera kritiska vägar i programmet. Finns det redundans vid varje punkt längs vägen? Kommer programmet att växla över till något annat när ett undersystem felar?

I en perfekt implementering kan du öka systemets tillgänglighet exponentiellt genom att lägga till enhetlig redundans. Anta till exempel att du har N motsvarande, lika balanserade komponenter som:

• kan fungera fel oberoende av varandra och samtidigt avlägsnas eller plockas bort från poolen
• har samma tillstånd eller inget tillstånd
• har inget arbete under bearbetning som är permanent förlorat vid funktionsfel
• är identiska i funktioner
• har inga beroenden på varandra
• hanterar kapacitetsminskningen utan ytterligare fel

Om varje enskild komponent har en tillgänglighet på A, kan den övergripande systemtillgängligheten beräknas med hjälp av formeln 1 - (1 - A)^N.

Rekommendationer

Överväg affärskrav. Den mängd redundans som är inbyggd i ett system kan påverka både kostnad och komplexitet. Din arkitektur bör informeras av dina affärskrav, till exempel mål för återställningstid (RTO) och mål för återställningspunkter (RPO). Du bör också tänka på dina prestandakrav och teamets förmåga att hantera komplexa uppsättningar med resurser.

Överväg arkitekturer för flera zoner och flera regioner. Se till att du förstår hur tillgänglighetszoner och regioner ger återhämtning och olika uppsättningar av arkitektoniska kompromisser.

Azure-tillgänglighetszoner är isolerade uppsättningar datacenter i en region. Genom att använda tillgänglighetszoner kan du vara motståndskraftig mot fel i ett enda datacenter eller en hel tillgänglighetszon. Du kan använda tillgänglighetszoner för att göra avvägningar mellan kostnader, riskreducering, prestanda och återställning. När du till exempel använder zonredundanta tjänster i din arkitektur tillhandahåller Azure automatisk datareplikering och redundans mellan geografiskt avgränsade instanser, vilket minskar många olika typer av risker.

Om du har en verksamhetskritisk arbetsbelastning och behöver minska risken för ett regionomfattande avbrott bör du överväga en distribution i flera regioner. Distributioner i flera regioner isolerar dig mot regionala katastrofer, men de kostar något. Distributioner i flera regioner är dyrare än en distribution med en enda region och är mer komplicerade att hantera. Du behöver operativa procedurer för att hantera redundans och återställning efter fel. Beroende på dina RPO-krav kan du behöva acceptera något lägre prestanda för att aktivera datareplikering mellan regioner. Den extra kostnaden och komplexiteten kan motiveras för vissa affärsscenarier.

Mer information om hur du utformar din lösning för att använda tillgänglighetszoner och regioner finns i Rekommendationer för användning av tillgänglighetszoner och regioner.

Placera virtuella datorer bakom en lastbalanserare. Använd inte en enstaka virtuell dator för verksamhetskritiska arbetsbelastningar. Placera i stället flera virtuella datorer bakom en lastbalanserare. Om en virtuell dator blir otillgänglig distribuerar lastbalanseraren trafiken till de återstående felfria virtuella datorerna.

Replikera databaser. Azure SQL Database och Azure Cosmos DB replikerar automatiskt data inom en region och kan konfigureras för att replikera mellan tillgänglighetszoner för högre återhämtning. Du kan också välja att aktivera geo-replikering mellan regioner. Geo-replikering för Azure SQL Database och Azure Cosmos DB skapar sekundära läsbara repliker av dina data i en eller flera sekundära regioner. Om ett avbrott inträffar i den primära regionen kan databasen redundansväxla till den sekundära regionen för skrivningar. Beroende på replikeringskonfigurationen kan det uppstå viss dataförlust från oregistrerade transaktioner.

Om du använder en IaaS-databaslösning väljer du en som stöder replikering och redundans, till exempel SQL Server AlwaysOn-tillgänglighetsgrupper.

Partitionering för tillgänglighet. Databaspartitionering används ofta för att förbättra skalbarhet, men det kan även förbättra tillgängligheten. Om en shard slutar att fungera går det fortfarande att nå övriga shards. Ett fel i en shard avbryter endast en delmängd av det totala antalet transaktioner.

Testa och verifiera dina redundanta komponenter. Fördelarna med tillförlitlighet gynnas på många sätt av enkelhet, och att lägga till redundans kan öka komplexiteten. För att säkerställa att tillägg av redundans faktiskt leder till högre tillgänglighet bör du verifiera följande:

• Kan ditt system på ett tillförlitligt sätt identifiera friska och felaktiga redundanta komponenter och snabbt och säkert ta bort dem från komponentpoolen?
• Kan systemet skalas ut på ett tillförlitligt sätt och i de redundanta komponenterna?
• Kan dina rutin-, ad hoc- och nödarbetsbelastningsåtgärder hantera redundansen?

Lösningar för flera regioner

Följande diagram visar en applikation med flera regioner som använder Azure Traffic Manager för att hantera failover.

Om du använder Traffic Manager eller Azure Front Door i en lösning med flera regioner som mekanism för redundansroutning bör du överväga följande rekommendationer:

Synkronisera klient- och serverdelsredundans. Använd din routningsmekanism för att växla över frontend. Om klientdelen inte kan nås i en region dirigerar redundans nya begäranden till den sekundära regionen. Beroende på dina backend-komponenter och databaslösning kan du behöva samordna övergången av dina backend-tjänster och databaser vid fel.

Använd automatisk redundans men manuell återställning. Använd automatisering för redundans, men inte för återställning efter fel. Automatisk återställning efter fel innebär en risk att du växlar till den primära regionen innan den regionen är helt återställd. Kontrollera i stället att alla programmets undersystem är felfria innan du växlar tillbaka manuellt. Du bör också kontrollera datakonsistensen innan du återgår.

För att uppnå detta inaktiverar du den primära slutpunkten efter redundansväxlingen. Observera att om övervakningsintervallet för sonder är kort och det tolererade antalet fel är litet, sker övergång vid fel samt återgång vid fel på kort tid. I vissa fall slutförs inte inaktivering i tid. För att undvika obekräftad återställning efter fel bör du även implementera en hälsokontrollpunkt som kan kontrollera att alla undersystem fungerar korrekt. Mer information finns i hälsoslutpunktsövervakningsmönster.

Inkludera redundans för routningslösningen. Överväg att utforma en Global routningsredundanslösning för affärskritiska webbprogram.