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 redundans växla över till något annat när ett undersystem misslyckas?
Rekommendationer
Överväg affärskrav. Den mängd redundans som är inbyggd i ett system kan påverka både kostnad och komplexitet. Arkitekturen bör styras av affärskraven, t.ex. mål för återställningstid (RTO). En distribution i flera regioner är exempelvis dyrare än en distribution i en region, och den är mer komplicerad att hantera. Du behöver driftsprocesser för att hantera redundans och återställning efter fel. Den ytterligare kostnaden och komplexiteten kan vara motiverad för vissa affärsscenarier men inte för andra.
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. Information om hur du distribuerar den här konfigurationen finns Multiple VMs for scalability and availability (Flera virtuella datorer för skalbarhet och tillgänglighet).
Replikera databaser. Azure SQL Database och Cosmos DB replikerar automatiskt data i en region och du kan aktivera geo-replikering över regioner. Om du använder en IaaS-databaslösning väljer du en som stöder replikering och redundans, till exempel SQL Server Always On-tillgänglighetsgrupper.
Aktivera geo-replikering. Geo-replikering för Azure SQL Database och Cosmos DB skapar sekundära läsbara repliker av data i en eller flera sekundära regioner. Vid ett driftsavbrott kan databasen redundansväxla till den sekundära regionen för skrivning.
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.
Distribuera till fler än en region. Du uppnår högsta tillgänglighet genom att distribuera programmet till fler än en region. Om den sällsynta situationen då ett problem påverkar en hel region skulle uppstå kan programmet i så fall redundansväxla till en annan region. Följande diagram visar ett program med flera regioner som använder Azure Traffic Manager för att hantera redundansväxling.
Synkronisera klient- och serverdelsredundans. Använd Azure Traffic Manager för att redundansväxla klientdelen. Om det inte går att nå klientdelen i en region leder Traffic Manager nya begäranden till den sekundära regionen. Du kan behöva samordna växling över databasen, beroende på vilken databaslösning som används.
Använd automatisk redundans men manuell återställning. Använd Traffic Manager för automatisk redundans, men inte för automatisk å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. Beroende på databasen kan du även behöva kontrollera datakonsekvensen innan du växlar tillbaka.
Inkludera redundans för Traffic Manager. Traffic Manager är en möjlig felpunkt. Granska serviceavtalet för Traffic Manager, och ta reda på om det räcker att använda enbart Traffic Manager för att uppfylla företagets krav på hög tillgänglighet. Om det inte räcker bör du överväga att lägga till en ytterligare trafikhanteringslösning för återställning efter fel. Om Azure Traffic Manager-tjänsten slutar att fungera ändrar du CNAME-posterna i DNS så att de pekar mot den andra trafikhanteringstjänsten.