Delen via


Aanbevelingen voor het ontwerpen voor redundantie

Is van toepassing op deze aanbeveling voor de controlelijst voor betrouwbaarheid van Azure Well-Architected Framework:

RE:05 Voeg redundantie toe op verschillende niveaus, met name voor kritieke stromen. Pas redundantie toe op de reken-, gegevens-, netwerk- en andere infrastructuurlagen in overeenstemming met de geïdentificeerde betrouwbaarheidsdoelen.

Verwante handleidingen: Maximaal beschikbaar multiregional ontwerp | Met behulp van beschikbaarheidszones en regio's

In deze handleiding worden de aanbevelingen beschreven voor het toevoegen van redundantie in kritieke stromen op verschillende workloadlagen, waarmee de tolerantie wordt geoptimaliseerd. Voldoen aan de vereisten van uw gedefinieerde betrouwbaarheidsdoelen door de juiste redundantieniveaus toe te passen op uw reken-, gegevens-, netwerk- en andere infrastructuurlagen. Pas deze redundantie toe om uw workload een sterke, betrouwbare basis te geven waarop u kunt bouwen. Wanneer u uw workload bouwt zonder infrastructuurredundantie, is er een hoog risico op uitgebreide downtime vanwege mogelijke storingen.

Definities

Termijn Definitie
Redundantie De implementatie van meerdere identieke exemplaren van een workloadonderdeel.
Polyglot persistence Het concept van het gebruik van verschillende opslagtechnologieën door dezelfde toepassing of oplossing om te profiteren van de beste mogelijkheden van elk onderdeel.
Gegevensconsistentie De meting van hoe een bepaalde gegevensset wordt gesynchroniseerd of niet gesynchroniseerd, is in meerdere winkels.
Partitionering Het proces van het fysiek verdelen van gegevens in afzonderlijke gegevensarchieven.
Shard Een horizontale strategie voor databasepartitionering die ondersteuning biedt voor meerdere opslagexemplaren met een gemeenschappelijk schema. Gegevens worden niet gerepliceerd in alle exemplaren.

Belangrijke ontwerpstrategieën

Gebruik redundantie in de context van betrouwbaarheid om problemen te bevatten die van invloed zijn op één resource en ervoor te zorgen dat deze problemen niet van invloed zijn op de betrouwbaarheid van het hele systeem. Gebruik de informatie die u hebt geïdentificeerd over uw kritieke stromen en betrouwbaarheidsdoelen om weloverwogen beslissingen te nemen die vereist zijn voor de redundantie van elke stroom.

U kunt bijvoorbeeld meerdere webserverknooppunten tegelijk uitvoeren. De ernst van de stroom die ze ondersteunen, kan vereisen dat alle stromen replica's hebben die gereed zijn om verkeer te accepteren als er een probleem is dat van invloed is op de hele pool, bijvoorbeeld een regionale storing. U kunt ook, omdat grootschalige problemen zeldzaam zijn en het kostbaar is om een hele set replica's te implementeren, kunt u een beperkt aantal replica's implementeren, zodat de stroom in een gedegradeerde status werkt totdat u het probleem hebt opgelost.

Wanneer u ontwerpt voor redundantie in de context van prestatie-efficiëntie, distribueert u de belasting over meerdere redundante knooppunten om ervoor te zorgen dat elk knooppunt optimaal presteert. Bouw in de context van betrouwbaarheid reservecapaciteit om storingen of storingen op te vangen die van invloed zijn op een of meer knooppunten. Zorg ervoor dat de reservecapaciteit fouten kan opvangen gedurende de hele tijd die nodig is om de betrokken knooppunten te herstellen. Met dit onderscheid in gedachten moeten beide strategieën samenwerken. Als u verkeer verspreidt over twee knooppunten voor prestaties en ze beide worden uitgevoerd met een gebruik van 60 procent en één knooppunt mislukt, loopt het resterende knooppunt het risico om overbelast te raken omdat het niet met 120 procent kan werken. Verspreid de belasting met een ander knooppunt om ervoor te zorgen dat uw prestatie- en betrouwbaarheidsdoelen worden gehandhaafd.

Compromissen:

  • Meer workloadredundantie komt overeen met meer kosten. Overweeg zorgvuldig redundantie toe te voegen en regelmatig uw architectuur te controleren om ervoor te zorgen dat u kosten beheert, met name wanneer u overprovisioning gebruikt. Wanneer u overprovisioning als een tolerantiestrategie gebruikt, moet u deze in balans brengen met een goed gedefinieerde schaalstrategie om de kosten inefficiëntie te minimaliseren.
  • Er kunnen prestatieproblemen optreden wanneer u een hoge mate van redundantie bouwt. Resources die zich verspreid over beschikbaarheidszones of regio's kunnen bijvoorbeeld van invloed zijn op de prestaties, omdat u verkeer moet verzenden via verbindingen met hoge latentie tussen redundante resources, zoals webservers of database-exemplaren.
  • Verschillende stromen binnen dezelfde workload kunnen verschillende betrouwbaarheidsvereisten hebben. Stroomspecifieke redundantieontwerpen kunnen de complexiteit in het algehele ontwerp introduceren.

Ontwerp van redundante architectuur

Overweeg twee benaderingen wanneer u een redundante architectuur ontwerpt: actief-actief of actief-passief. Kies uw benadering, afhankelijk van de ernst van de gebruikersstroom en systeemstroom die de infrastructuuronderdelen ondersteunen. Een actief-actief ontwerp voor meerdere regio's helpt u het hoogste betrouwbaarheidsniveau te bereiken, maar het is aanzienlijk duurder dan een actief-passief ontwerp. Het bepalen van de juiste geografische regio's wordt de volgende kritieke keuze. U kunt deze ontwerpmethoden ook gebruiken voor één regio met behulp van beschikbaarheidszones. Zie Aanbevelingen voor maximaal beschikbare ontwerp voor meerdere regio's voor meer informatie.

Implementatiestempels en schaaleenheden

Of u nu implementeert in een actief-actief- of actief-passief model, volgt u het ontwerppatroon implementatiestempels om ervoor te zorgen dat u uw workload op een herhaalbare, schaalbare manier implementeert. Implementatiestempels zijn de groeperingen van resources die nodig zijn om uw workload te leveren aan een bepaalde subset van uw klanten. De subset kan bijvoorbeeld een regionale subset of een subset zijn met dezelfde privacyvereisten voor gegevens als uw workload. U kunt elke zegel beschouwen als een schaaleenheid die u kunt dupliceren om uw workload horizontaal te schalen of om blauwgroene implementaties uit te voeren. Ontwerp uw workload met implementatiestempels om uw actief-actief- of actief-passieve implementatie te optimaliseren voor tolerantie en beheerlast. Het plannen van uitschalen in meerdere regio's is ook belangrijk om potentiële tijdelijke resourcecapaciteitsbeperkingen in een regio te overwinnen.

Beschikbaarheidszones binnen Azure-regio's

Of u nu een actief-actief of actief-passief ontwerp implementeert, profiteert u van beschikbaarheidszones binnen de actieve regio's om uw tolerantie volledig te optimaliseren. Veel Azure-regio's bieden meerdere beschikbaarheidszones, die gescheiden groepen datacenters binnen een regio zijn. Afhankelijk van de Azure-service kunt u profiteren van beschikbaarheidszones door elementen van uw workload redundant te implementeren in meerdere zones of elementen vast te maken aan specifieke zones. Zie Aanbevelingen voor het gebruik van beschikbaarheidszones en regio's voor meer informatie.

Zoneredundantie implementeren voor rekenresources

  • Kies de juiste rekenservice voor uw workload. Afhankelijk van het type workload dat u ontwerpt, zijn er mogelijk verschillende opties beschikbaar. Onderzoek de beschikbare services en begrijp welke typen workloads het beste werken voor een bepaalde rekenservice. SAP-workloads zijn bijvoorbeeld meestal het meest geschikt voor IaaS-rekenservices (Infrastructure as a Service). Voor een containertoepassing bepaalt u de specifieke functionaliteit die u moet beheren om te bepalen of u Azure Kubernetes Service (AKS) of een PaaS-oplossing (Platform as a Service) wilt gebruiken. Uw cloudplatform beheert een PaaS-service volledig.

  • Gebruik PaaS-rekenopties als uw vereisten dit toestaan. Azure beheert PaaS-services volledig, wat uw beheerlast vermindert en een gedocumenteerde mate van redundantie is ingebouwd.

  • Gebruik Virtuele-machineschaalsets van Azure als u virtuele machines (VM's) wilt implementeren. Met Virtuele-machineschaalsets kunt u uw rekenkracht automatisch gelijkmatig verdelen over beschikbaarheidszones.

  • Houd uw rekenlaag schoon van elke status omdat afzonderlijke knooppunten die aanvragen verwerken, op elk gewenst moment kunnen worden verwijderd, beschadigd of vervangen.

  • Gebruik waar mogelijk zone-redundante services om een hogere tolerantie te bieden zonder uw operationele last te verhogen.

  • Overprovision kritieke resources om fouten van redundante exemplaren te beperken, zelfs voordat automatische schaalbewerkingen beginnen, dus blijft het systeem werken na een onderdeelfout. Bereken het acceptabele effect van een fout wanneer u overprovisioning in uw redundantieontwerp opneemt. Net als bij het besluitvormingsproces voor redundantie bepalen uw betrouwbaarheidsdoelen en financiële compromisbeslissingen de mate waarin u reservecapaciteit toevoegt met overprovisioning. Overprovisioning verwijst specifiek naar uitschalen, wat betekent dat er extra exemplaren van een bepaald rekenresourcetype worden toegevoegd in plaats van de rekenmogelijkheden van één exemplaar te verhogen. Als u bijvoorbeeld een VIRTUELE machine wijzigt van een SKU met een lagere laag in een SKU met een hogere laag.

  • Implementeer IaaS-services handmatig of via automatisering in elke beschikbaarheidszone of regio waarin u uw oplossing wilt implementeren. Sommige PaaS-services hebben ingebouwde mogelijkheden die automatisch worden gerepliceerd in beschikbaarheidszones en regio's.

Zoneredundantie implementeren voor gegevensbronnen

  • Bepaal of synchrone of asynchrone gegevensreplicatie nodig is voor de functionaliteit van uw workload. Zie Aanbevelingen voor het gebruik van beschikbaarheidszones en regio's om u te helpen deze beslissing te nemen.

  • Houd rekening met de groeisnelheid van uw gegevens. Plan voor capaciteitsplanning gegevensgroei, gegevensretentie en archivering om ervoor te zorgen dat aan uw betrouwbaarheidsvereisten wordt voldaan wanneer de hoeveelheid gegevens in uw oplossing toeneemt.  

  • Distribueer gegevens geografisch, zoals ondersteund door uw service, om het effect van geografisch gelokaliseerde fouten te minimaliseren.

  • Repliceer gegevens in geografische regio's om tolerantie te bieden voor regionale storingen en onherstelbare fouten.

  • Automatiseer failover na een storing in een database-exemplaar. U kunt geautomatiseerde failover configureren in meerdere Azure PaaS-gegevensservices. Automatische failover is niet vereist voor gegevensarchieven die schrijfbewerkingen in meerdere regio's ondersteunen, zoals Azure Cosmos DB. Zie Aanbevelingen voor het ontwerpen van een strategie voor herstel na noodgevallen voor meer informatie.

  • Gebruik het beste gegevensarchief voor uw gegevens. Gebruik polyglot persistence of oplossingen die gebruikmaken van een combinatie van technologieën voor gegevensopslag. Gegevens bevatten meer dan alleen persistente toepassingsgegevens. Er zijn ook toepassingslogboeken, gebeurtenissen, berichten en caches.

  • Overweeg vereisten voor gegevensconsistentie en gebruik uiteindelijke consistentie wanneer vereisten dit toestaan. Wanneer gegevens worden gedistribueerd, gebruikt u de juiste coördinatie om sterke consistentiegaranties af te dwingen. Coördinatie kan de doorvoer verminderen en ervoor zorgen dat uw systemen nauw gekoppeld zijn, waardoor ze minder broos worden. Als een bewerking bijvoorbeeld twee databases bijwerkt, in plaats van deze in één transactiebereik te plaatsen, is het beter als het systeem de uiteindelijke consistentie kan opvangen.

  • Partitiegegevens voor beschikbaarheid. Databasepartitionering verbetert de schaalbaarheid en kan ook de beschikbaarheid verbeteren. Als de ene shard uitvalt, zijn de andere shards nog steeds bereikbaar. Een fout in één shard verstoort alleen een subset van de totale transacties.

  • Als sharding geen optie is, kunt u het patroon Command and Query Responsibility Segregation (CQRS) gebruiken om uw alleen-lezen- en alleen-lezengegevensmodellen te scheiden. Voeg meer redundante database-exemplaren met het kenmerk Alleen-lezen toe om meer flexibiliteit te bieden.  

  • Inzicht in de ingebouwde replicatie- en redundantiemogelijkheden van de stateful platformservices die u gebruikt. Zie Gerelateerde koppelingen voor specifieke redundantiemogelijkheden van stateful gegevensservices.

Zoneredundantie implementeren voor netwerkresources

  • Beslis over een betrouwbare en schaalbare netwerktopologie. Gebruik een hub-and-spoke-model of een Azure Virtual WAN-model om uw cloudinfrastructuur te organiseren in logische patronen, waardoor uw redundantieontwerp eenvoudiger te bouwen en te schalen is.

  • Selecteer de juiste netwerkservice om aanvragen in of tussen regio's te verdelen en om te leiden. Gebruik waar mogelijk globale of zone-redundante taakverdelingsservices om te voldoen aan uw betrouwbaarheidsdoelen.

  • Zorg ervoor dat u voldoende IP-adresruimte in uw virtuele netwerken en subnetten hebt toegewezen om rekening te houden met gepland gebruik, inclusief uitschaalvereisten.

  • Zorg ervoor dat de toepassing kan worden geschaald binnen de poortlimieten van het gekozen platform voor het hosten van toepassingen. Als een toepassing meerdere uitgaande TCP- of UDP-verbindingen initieert, kan deze alle beschikbare poorten uitputten en slechte toepassingsprestaties veroorzaken.

  • Kies SKU's en configureer netwerkservices die aan uw bandbreedte- en beschikbaarheidsvereisten kunnen voldoen. De doorvoer van een VPN-gateway varieert op basis van hun SKU. Ondersteuning voor zoneredundantie is alleen beschikbaar voor sommige load balancer-SKU's.

  • Zorg ervoor dat uw ontwerp voor het verwerken van DNS is gebouwd met een focus op tolerantie en ondersteuning biedt voor redundante infrastructuur.

Azure-facilitering

Met het Azure-platform kunt u de tolerantie van uw workload optimaliseren en redundantie toevoegen door:

DNS-specifieke Azure-facilitering

  • Voor scenario's voor interne naamomzetting gebruikt u privézones van Azure DNS, met ingebouwde zoneredundantie en georedundantie. Zie Tolerantie van privézones in Azure DNS voor meer informatie.

  • Voor scenario's voor externe naamomzetting gebruikt u openbare Azure DNS-zones met ingebouwde zoneredundantie en georedundantie.

  • De openbare en persoonlijke Azure DNS-services zijn globale services die bestand zijn tegen regionale storingen, omdat zonegegevens wereldwijd beschikbaar zijn.

  • Voor scenario's voor hybride naamomzetting tussen on-premises en cloudomgevingen gebruikt u azure DNS Private Resolver. Deze service ondersteunt zoneredundantie als uw workload zich in een regio bevindt die beschikbaarheidszones ondersteunt. Een zonebrede storing vereist geen actie tijdens zoneherstel. De service herstelt automatisch en herbalanceerd om te profiteren van de gezonde zone. Zie Tolerantie in azure DNS Private Resolver voor meer informatie.

  • Als u een single point of failure wilt elimineren en een tolerantere hybride naamomzetting in verschillende regio's wilt bereiken, implementeert u twee of meer privé-resolvers van Azure DNS in verschillende regio's. DNS-failover, in een scenario voor voorwaardelijk doorsturen, wordt bereikt door een resolver toe te wijzen als uw primaire DNS-server. Wijs de andere resolver in een andere regio toe als een secundaire DNS-server. Zie DNS-failover instellen met behulp van privé-resolvers voor meer informatie.

Opmerking

Zie Basislijn voor zone-redundante webtoepassing met hoge beschikbaarheid voor een voorbeeld van een redundante implementatie met meerdere regio's.

In het volgende diagram ziet u een ander voorbeeld:

Diagram met de architectuur van de referentie-implementatie.

Zie de volgende bronnen voor meer informatie over redundantie:

Controlelijst voor betrouwbaarheid

Raadpleeg de volledige set aanbevelingen.