Gör allt redundant

Bygg in redundans i programmet för att undvika felkritiska systemdelar

Ett flexibelt program leder runt fel. Identifiera kritiska vägar i programmet. Finns det redundans vid varje punkt längs vägen? Kommer programmet att redundansväsnas till något annat när ett undersystem misslyckas?

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 oberoende och samtidigt tas bort från poolen
• har identiskt tillstånd eller inget tillstånd
• har inget pågående arbete som är permanent förlorat under fel
• är identiska i funktioner
• har inga beroenden på varandra
• hanterar kapacitetsminskningen utan ytterligare fel

Om varje enskild komponent har en tillgänglighet på kan den övergripande systemtillgängligheten beräknas med hjälp av Aformeln 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.

Dricks

För många arbetsbelastningar ger en zonredundant arkitektur den bästa uppsättningen kompromisser. Överväg en arkitektur för flera regioner om dina affärskrav anger att du behöver minska den osannolika risken för ett regionomfattande avbrott, och om du är beredd att acceptera de kompromisser som ingår i en sådan metod.

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. Tillförlitlighetsfördelar på många sätt från enkelhet och tillägg av 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 systemet på ett tillförlitligt sätt identifiera felfria och felfria 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 ett program med flera regioner som använder Azure Traffic Manager för att hantera redundansväxling.

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 routningsmekanismen för att redundansväxla över klientdelen. Om klientdelen inte kan nås i en region dirigerar redundans nya begäranden till den sekundära regionen. Beroende på serverdelskomponenterna och databaslösningen kan du behöva samordna redvikten över serverdelstjänsterna och databaserna.

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 felfri. Kontrollera i stället att alla programmets undersystem är felfria innan du växlar tillbaka manuellt. Du bör också kontrollera datakonsekvensen innan du säkerhetskopieras.

För att uppnå detta inaktiverar du den primära slutpunkten efter redundansväxlingen. Observera att om övervakningsintervallet för avsökningar är kort och det tolererade antalet fel är litet, sker redundans och återställning efter fel på kort tid. I vissa fall slutförs inte inaktivering i tid. Om du vill undvika obekräftad återställning efter fel bör du även implementera en hälsoslutpunkt som kan kontrollera att alla undersystem är felfria. Se mönstret Hälsoslutpunktsövervakning.

Inkludera redundans för routningslösningen. Överväg att utforma en global routningsredundanslösning för verksamhetskritiska webbprogram.