Dela via

Rekommendationer för att utforma redundans

  • Artikel

gäller för den här rekommendationen i tillförlitlighetschecklistan för Azure Well-Architected Framework:

RE:05 Lägg till redundans på olika nivåer, särskilt för kritiska flöden, för att uppfylla dina tillförlitlighetsmål. Överväg redundanta infrastrukturkomponenter som beräkning och nätverk och flera instanser av din lösning.

Relaterade guider:Multiregional design med hög tillgänglighet | Använda tillgänglighetszoner och regioner

Den här guiden beskriver rekommendationerna för att lägga till redundans i kritiska flöden i olika arbetsbelastningslager, vilket optimerar återhämtning. Uppfylla kraven för dina definierade tillförlitlighetsmål genom att tillämpa rätt redundansnivåer på dina beräknings-, data-, nätverks- och andra infrastrukturnivåer. Använd den här redundansen för att ge din arbetsbelastning en stark och tillförlitlig grund att bygga vidare på. När du skapar din arbetsbelastning utan infrastrukturredundans finns det en hög risk för längre driftstopp på grund av potentiella fel.

Definitioner

Termin Definition
Redundans Implementeringen av flera identiska instanser av en arbetsbelastningskomponent.
Polyglot persistence Konceptet att använda olika lagringstekniker med samma program eller lösning för att dra nytta av de bästa funktionerna för varje komponent.
Datakonsekvens Måttet på hur en viss datauppsättning är synkroniserad eller osynkroniserad finns i flera butiker.
Partitionering Processen att fysiskt dela upp data i separata datalager.
Skärva En horisontell databaspartitioneringsstrategi som stöder flera lagringsinstanser med ett gemensamt schema. Data replikeras inte i alla instanser.

Viktiga designstrategier

När det gäller tillförlitlighet använder du redundans för att innehålla problem som påverkar en enskild resurs och ser till att dessa problem inte påverkar hela systemets tillförlitlighet. Använd den information som du har identifierat om dina kritiska flöden och tillförlitlighetsmål för att fatta välgrundade beslut som krävs för varje flödes redundans.

Du kan till exempel ha flera webbservernoder som körs samtidigt. Det kritiska flödet som de stöder kan kräva att alla har repliker som är redo att acceptera trafik om det finns ett problem som påverkar hela poolen, till exempel ett regionalt avbrott. Eftersom storskaliga problem är sällsynta och det är kostsamt att distribuera en hel uppsättning repliker kan du distribuera ett begränsat antal repliker så att flödet fungerar i ett degraderat tillstånd tills du löser problemet.

När du utformar för redundans i samband med prestandaeffektivitet distribuerar du belastningen över flera redundanta noder för att säkerställa att varje nod presterar optimalt. När det gäller tillförlitlighet, bygg in extra kapacitet som kan hantera misslyckanden eller funktionsfel som påverkar en eller flera noder. Se till att den extra kapaciteten kan absorbera fel under hela den tid som behövs för att återställa de berörda noderna. Med denna skillnad i åtanke måste båda strategierna fungera tillsammans. Om du sprider trafik över två noder för prestanda och båda körs med 60 procents användning och en nod misslyckas riskerar den återstående noden att bli överbelastad eftersom den inte kan köras med 120 procent. Sprid ut belastningen med en annan nod för att säkerställa att dina prestanda- och tillförlitlighetsmål upprätthålls.

Kompromisser:

  • Mer redundans för arbetsbelastningar motsvarar mer kostnader. Överväg noggrant att lägga till redundans och granska din arkitektur regelbundet för att säkerställa att du hanterar kostnaderna, särskilt när du använder överprovisionering. När du använder överprovisionering som en resiliensstrategi, balansera den med en väldefinierad skalningsstrategi för att minimera kostnadsineffektivitet.
  • Det kan finnas prestandaavvägningar när du skapar en hög grad av redundans. Resurser som sprids över tillgänglighetszoner eller regioner kan till exempel påverka prestanda eftersom du måste skicka trafik över anslutningar med hög latens mellan redundanta resurser, till exempel webbservrar eller databasinstanser.
  • Olika flöden inom samma arbetsbelastning kan ha olika tillförlitlighetskrav. Flödesspecifika redundansdesigner kan potentiellt medföra komplexitet i den övergripande designen.

Redundant design av arkitektur

Överväg två metoder när du utformar en redundant arkitektur: aktiv-aktiv eller aktiv-passiv. Välj din metod beroende på hur kritiskt användarflöde och systemflöde som infrastrukturkomponenterna stöder. När det gäller tillförlitlighet hjälper en aktiv-aktiv design i flera regioner dig att uppnå högsta möjliga tillförlitlighetsnivå, men det är betydligt dyrare än en aktiv-passiv design. Att bestämma lämpliga geografiska regioner blir nästa viktiga val. Du kan också använda dessa designmetoder för en enda region med hjälp av tillgänglighetszoner. Mer information finns i rekommendationer för design med hög tillgänglighet för flera regioner.

Distributionsstämplar och skalningsenheter

Oavsett om du distribuerar i en aktiv-aktiv eller aktiv-passiv modell följer du designmönstret Distributionsstämplar för att säkerställa att du distribuerar arbetsbelastningen på ett repeterbart och skalbart sätt. Distributionsstämplar är de grupper av resurser som krävs för att leverera din arbetsbelastning till en viss delmängd av dina kunder. Delmängden kan till exempel vara en regional delmängd eller en delmängd med samma krav på datasekretess som din arbetsbelastning. Tänk på varje stämpel som en skalningsenhet som du kan duplicera för att skala arbetsbelastningen vågrätt eller för att utföra blågröna distributioner. Utforma arbetsbelastningen med distributionsstämplar för att optimera aktiv-aktiv eller aktiv-passiv implementering för återhämtning och hanteringsbelastning. Planering för utskalning i flera regioner är också viktigt för att övervinna potentiella tillfälliga resurskapacitetsbegränsningar i en region.

Tillgänglighetszoner i Azure-regioner

Oavsett om du distribuerar en aktiv-aktiv eller aktiv-passiv design kan du dra nytta av tillgänglighetszoner inom de aktiva regionerna för att optimera din motståndskraft fullt ut. Många Azure-regioner tillhandahåller flera tillgänglighetszoner, som är avgränsade grupper av datacenter i en region. Beroende på Azure-tjänsten kan du dra nytta av tillgänglighetszoner genom att distribuera element i din arbetsbelastning redundant över zoner eller fästa element i specifika zoner. Mer information finns i rekommendationer för användning av tillgänglighetszoner och regioner.

Implementera zonredundans för beräkningsresurser

  • Välj lämplig beräkningstjänst för din arbetsbelastning. Beroende på vilken typ av arbetsbelastning du utformar kan det finnas flera tillgängliga alternativ. Utforska de tillgängliga tjänsterna och förstå vilka typer av arbetsbelastningar som fungerar bäst på en viss beräkningstjänst. Till exempel är SAP-arbetsbelastningar vanligtvis bäst lämpade för IaaS-beräkningstjänster (infrastruktur som en tjänst). För ett containerbaserat program fastställer du de specifika funktioner som du behöver ha kontroll över för att avgöra om du ska använda Azure Kubernetes Service (AKS) eller en PaaS-lösning (plattform som en tjänst). Din molnplattform hanterar fullständigt en PaaS-tjänst.

  • Använd PaaS-beräkningsalternativ om dina krav tillåter det. Azure hanterar PaaS-tjänster fullt ut, vilket minskar din hanteringsbörda och en dokumenterad grad av redundans är inbyggd.

  • Använd Skalningsuppsättningar för virtuella Azure-datorer om du behöver distribuera virtuella datorer (VM). Med VM-skalningsuppsättningar kan du automatiskt sprida dina datorkraftresurser jämnt över tillgänglighetszoner.

  • Håll beräkningslagret rent från alla tillstånd eftersom enskilda noder som hanterar begäranden kan tas bort, felas eller ersättas när som helst.

  • Använd zonredundanta tjänster där det är möjligt för att ge högre motståndskraft utan att öka driftbelastningen.

  • Överetablera kritiska resurser för att undvika fel i redundanta instanser, även innan automatiska skalningsåtgärder påbörjas, så att systemet fortsätter att fungera efter ett komponentfel. Beräkna den acceptabla påverkan av ett fel när du införlivar överprovisionering i din redundansdesign. Precis som med beslutsprocessen för redundans avgör dina tillförlitlighetsmål och ekonomiska kompromissbeslut i vilken utsträckning du lägger till outnyttjad kapacitet med överetablering. Överprovisionering syftar specifikt på utskalning, vilket innebär att lägga till extra instanser av en viss beräkningsresurstyp snarare än att öka beräkningsfunktionerna för en enskild instans. Om du till exempel ändrar en virtuell dator från en SKU på lägre nivå till en SKU på högre nivå.

  • Distribuera IaaS-tjänster manuellt eller via automatisering i varje tillgänglighetszon eller region där du tänker implementera din lösning. Vissa PaaS-tjänster har inbyggda funktioner som replikeras automatiskt mellan tillgänglighetszoner och regioner.

Implementera zonredundans för dataresurser

  • Avgör om synkron eller asynkron datareplikering är nödvändig för din arbetsbelastnings funktioner. För att hjälpa dig att göra denna bedömning, se Rekommendationer för användning av tillgänglighetszoner och regioner.

  • Överväg att öka datahastigheten. För kapacitetsplanering planerar du för datatillväxt, datakvarhållning och arkivering för att säkerställa att dina tillförlitlighetskrav uppfylls när mängden data i lösningen ökar.  

  • Distribuera data geografiskt, vilket stöds av din tjänst, för att minimera effekten av geografiskt lokaliserade fel.

  • Replikera data mellan geografiska regioner för att ge motståndskraft mot regionala avbrott och katastrofala fel.

  • Automatisera failover efter ett databasinstansfel. Du kan konfigurera automatisk redundans i flera Azure PaaS-datatjänster. Automatisk redundans krävs inte för datalager som stöder skrivningar i flera regioner, till exempel Azure Cosmos DB. Mer information finns i rekommendationer för att utforma en strategi för katastrofåterställning.

  • Använd det bästa datalagret för dina data. Använd flerspråkig persistens eller lösningar som använder en blandning av datalagertekniker. Data innehåller mer än bara beständiga programdata. Den innehåller även programloggar, händelser, meddelanden och cacheminnen.

  • Överväg krav på datakonsekvens och använd slutlig konsekvens när kraven tillåter det. När data distribueras använder du lämplig samordning för att säkerställa starka konsistensgarantier. Samordning kan minska dataflödet och göra systemen tätt kopplade, vilket kan göra dem mer spröda. Om en åtgärd till exempel uppdaterar två databaser, i stället för att lägga det i en enda transaktionsomfattning, är det bättre om systemet kan hantera eventuell konsistens.

  • Partitioneringsdata för tillgänglighet. databaspartitionering förbättrar skalbarheten och kan också förbättra tillgängligheten. Om en shard går ner kan de andra shardarna fortfarande nås. Ett fel i en shard stör bara en delmängd av de totala transaktionerna.

  • Om horisontell partitionering inte är ett alternativ kan du använda CQRS-mönstret (Command and Query Responsibility Segregation) för att separera skrivskyddade och skrivskyddade datamodeller. Lägg till fler redundanta skrivskyddade databasinstanser för att öka tåligheten.  

  • Förstå de inbyggda replikerings- och redundansfunktionerna i de tillståndskänsliga plattformstjänster som du använder. Specifika redundansfunktioner för tillståndskänsliga datatjänster finns i Relaterade länkar.

Implementera zonredundans för nätverksresurser

  • Besluta om en tillförlitlig och skalbar nätverkstopologi. Använd en hub-and-spoke-modell eller en Azure Virtual WAN-modell som hjälper dig att organisera din molninfrastruktur i logiska mönster som gör redundansdesignen enklare att skapa och skala.

  • Välj lämplig nätverkstjänst för att balansera och omdirigera begäranden inom eller mellan regioner. Använd globala eller zonredundanta lastbalanseringstjänster när det är möjligt för att uppfylla dina tillförlitlighetsmål.

  • Se till att du har allokerat tillräckligt med IP-adressutrymme i dina virtuella nätverk och undernät för att ta hänsyn till planerad användning, inklusive utskalningskrav.

  • Se till att programmet kan skalas inom portgränserna för den valda programvärdplattformen. Om ett program initierar flera utgående TCP- eller UDP-anslutningar kan det uttömma alla tillgängliga portar och orsaka sämre programprestanda.

  • Välj SKU:er och konfigurera nätverkstjänster som kan uppfylla dina krav på bandbredd och tillgänglighet. En VPN-gateways dataflöde varierar beroende på deras SKU. Stöd för zonredundans är endast tillgängligt för vissa SKU:er för lastbalanserare.

  • Se till att din design för hantering av DNS skapas med fokus på motståndskraft och har stöd för redundant infrastruktur.

Azure-underlättande

Azure-plattformen hjälper dig att optimera arbetsbelastningens återhämtning och lägga till redundans genom att:

DNS-specifikt Azure-stöd

  • För interna namnmatchningsscenarier använder du privata Azure DNS-zoner som har inbyggd zonredundans och geo-redundans. Mer information finns i motståndskraft hos privata Azure DNS-zoner.

  • För scenarier med extern namnmatchning använder du offentliga Azure DNS-zoner som har inbyggd zonredundans och geo-redundans.

  • Offentliga och privata Azure DNS-tjänster är globala tjänster som är motståndskraftiga mot regionala avbrott eftersom zondata är globalt tillgängliga.

  • För hybridnamnmatchningsscenarier mellan lokala miljöer och molnmiljöer använder du Azure DNS Private Resolver. Den här tjänsten stöder zonredundans om din arbetsbelastning finns i en region som stöder tillgänglighetszoner. Ett zonomfattande avbrott kräver ingen åtgärd under zonåterställning. Tjänsten självreparerar och balanserar automatiskt om för att dra nytta av den hälsosamma zonen. Mer information finns i Motståndskraft i Azure DNS Private Resolver.

  • Om du vill eliminera en enskild felpunkt och uppnå en mer elastisk hybridnamnmatchning mellan regioner distribuerar du två eller flera privata Azure DNS-matchare i olika regioner. DNS-failover uppnås vid villkorlig vidarebefordran genom att tilldela en resolver som din primära DNS-server. Tilldela den andra namenservern i en annan region att vara en sekundär DNS-server. För mer information, se Konfigurera DNS-failover med hjälp av privata resolver.

Exempel

Ett exempel på en redundant distribution i flera regioner finns i Baslinje för zonredundant webbapplikation med hög tillgänglighet.

Följande diagram visar ett annat exempel:

diagram som visar referensimplementeringens arkitektur.

Mer information om redundans finns i följande resurser:

Checklista för tillförlitlighet

Se den fullständiga uppsättningen rekommendationer.

Tillförlitlighet checklista