Share via

Rekommendationer för att utforma för redundans

  • Artikel

Gäller för den här rekommendationen om checklista för tillförlitlighet i Azure Well-Architected Framework:

RE:05 Lägg till redundans på olika nivåer, särskilt för kritiska flöden. Tillämpa redundans på beräknings-, data-, nätverks- och andra infrastrukturnivåer i enlighet med de identifierade tillförlitlighetsmålen.

Relaterade guider:Design med hög tillgänglighet för flera regioner | Med hjälp av 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å 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 stilleståndstid på grund av potentiella fel.

Definitioner

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

Viktiga designstrategier

När det gäller tillförlitlighet kan du använda redundans för att innehålla problem som påverkar en enskild resurs och se 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 ta emot 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 dyrt 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 bygger du in outnyttjad kapacitet för att absorbera fel eller fel som påverkar en eller flera noder. Se till att reservkapaciteten kan absorbera fel under hela den tid som behövs för att återställa de berörda noderna. Med den här skillnaden 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 att lägga till redundans och granska din arkitektur regelbundet för att säkerställa att du hanterar kostnader, särskilt när du använder överetablering. När du använder överetablering som en återhämtningsstrategi kan du balansera den med en väldefinierad skalningsstrategi för att minimera ineffektiviteten i kostnaderna.
  • 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 prestandan eftersom du måste skicka trafik via anslutningar med lång svarstid 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 arkitekturdesign

Ö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 i 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 din arbetsbelastning 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 datasekretesskrav som din arbetsbelastning. Tänk på varje stämpel som en skalningsenhet som du kan duplicera för att skala arbetsbelastningen horisontellt eller för att utföra blågröna distributioner. Utforma din arbetsbelastning med distributionsstämplar för att optimera din aktiva-aktiva eller aktiv-passiva implementering för återhämtning och hantering. Det är också viktigt att planera för utskalning i flera regioner för att lösa potentiella tillfälliga resurskapacitetsbegränsningar i en region.

Tillgänglighetszoner i Azure-regioner

Oavsett om du distribuerar en aktiv-aktiv eller en aktiv-passiv design kan du dra nytta av tillgänglighetszoner i de aktiva regionerna för att helt optimera din återhämtning. Många Azure-regioner tillhandahåller flera tillgänglighetszoner, som är avgränsade grupper av datacenter inom 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 på specifika zoner. Mer information finns i Rekommendationer för användning av tillgänglighetszoner och regioner.

Vägledning för infrastrukturskikt

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 med 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 helt en PaaS-tjänst.

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

  • Använd Azure Virtual Machine Scale Sets om du behöver distribuera virtuella datorer (VM). Med Virtual Machine Scale Sets kan du automatiskt sprida beräkningen jämnt mellan tillgänglighetszoner.

  • Håll beräkningslagret rent från alla tillstånd eftersom enskilda noder som hanterar begäranden kan tas bort, felsökas 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 driftbördan.

  • Överetablera kritiska resurser för att undvika fel i redundanta instanser, även innan autoskalningsåtgärderna påbörjas, så att systemet fortsätter att fungera efter ett komponentfel. Beräkna den godkända effekten av ett fel när du införlivar överetablering i redundansdesignen. 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. Överetablering syftar specifikt på utskalning, vilket innebär att lägga till extra instanser av en viss beräkningsresurstyp i stället för 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.

Dataresurser

  • Avgör om synkron eller asynkron datareplikering krävs för din arbetsbelastnings funktioner. Information om hur du gör detta finns i Rekommendationer för användning av tillgänglighetszoner och regioner.

  • Överväg tillväxttakten för dina data. För kapacitetsplanering, planera 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 din lösning ö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 oåterkalleliga fel.

  • Automatisera redundansväxlingen 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 haveriberedskap.

  • 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. De innehåller också programloggar, händelser, meddelanden och cacheminnen.

  • Överväg kraven på datakonsekvens och använd eventuell konsekvens när kraven tillåter det. När data distribueras använder du lämplig samordning för att framtvinga starka konsekvensgarantier. 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 placera den i ett enda transaktionsomfång, är det bättre om systemet kan hantera slutlig konsekvens.

  • Partitioneringsdata för tillgänglighet. Databaspartitionering förbättrar skalbarheten och kan också förbättra tillgängligheten. Om en shard kraschar kan de andra fragmenten 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 dina datamodeller med läs- och skrivbehörighet. Lägg till mer redundanta skrivskyddade databasinstanser för att ge mer motståndskraft.  

  • 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.

Nätverk

  • Bestäm 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 belastningsutjämningstjä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 ta slut på 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 återhämtningsförmågan för din arbetsbelastning och lägga till redundans genom att:

DNS-specifik Azure-underlättande

  • För interna namnmatchningsscenarier använder du privata Azure DNS-zoner, som har inbyggd zonredundans och geo-redundans. Mer information finns i Återhämtning av privata Azure DNS-zoner.

  • För externa namnmatchningsscenarier använder du offentliga Azure DNS-zoner som har inbyggd zonredundans och geo-redundans.

  • De offentliga och privata Azure DNS-tjänsterna ä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ällningen. Tjänsten återställer automatiskt och balanserar om för att dra nytta av den felfria zonen. Mer information finns i Återhämtning i Azure DNS Private Resolver.

  • Om du vill eliminera en enskild felpunkt och uppnå en mer motståndskraftig hybridnamnmatchning mellan regioner distribuerar du två eller flera privata Azure DNS-matchare i olika regioner. DNS-redundans i ett scenario med villkorsstyrd vidarebefordring uppnås genom att tilldela en matchare som din primära DNS-server. Tilldela den andra matcharen i en annan region som en sekundär DNS-server. Mer information finns i Konfigurera DNS-redundans med hjälp av privata matchare.

Exempel

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

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.

Checklista för tillförlitlighet