Aanbevelingen voor het ontwerpen voor redundantie

  • Artikel

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

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

Gerelateerde handleidingen:Multiregionaal ontwerp | met hogebeschikbaarheidszones en -regio's

In deze handleiding worden de aanbevelingen beschreven voor het toevoegen van redundantie in kritieke stromen op verschillende workloadlagen, waardoor de tolerantie wordt geoptimaliseerd. Voldoe 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 om op voort te bouwen. Wanneer u uw workload bouwt zonder infrastructuurredundantie, is er een hoog risico op uitgebreide downtime vanwege mogelijke fouten.

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 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 in alle exemplaren gerepliceerd.

Belangrijke ontwerpstrategieën

Gebruik in de context van betrouwbaarheid redundantie om problemen op te lossen die van invloed zijn op één resource en zorg ervoor dat deze problemen geen invloed hebben 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 ze allemaal 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. Omdat grootschalige problemen zeldzaam zijn en het kostbaar is om een hele set replica's te implementeren, kunt u ook 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, verdeelt u de belasting over meerdere redundante knooppunten om ervoor te zorgen dat elk knooppunt optimaal presteert. In de context van betrouwbaarheid moet u reservecapaciteit inbouwen 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 het achterhoofd moeten beide strategieën samenwerken. Als u verkeer verspreidt over twee knooppunten voor prestaties en deze beide worden uitgevoerd met 60 procent gebruik en één knooppunt mislukt, loopt het resterende knooppunt het risico overbelast te raken omdat het niet kan werken met 120 procent. Verspreid de belasting met een ander knooppunt om ervoor te zorgen dat uw prestatie- en betrouwbaarheidsdoelen worden gehandhaafd.

Afwegingen:

  • Meer workloadredundantie betekent meer kosten. Overweeg zorgvuldig redundantie toe te voegen en controleer regelmatig uw architectuur om ervoor te zorgen dat u de 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 zijn wanneer u een hoge mate van redundantie inbouwt. Resources die zijn 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 het algehele ontwerp complexer maken.

Ontwerp van redundante architectuur

Overweeg twee benaderingen wanneer u een redundante architectuur ontwerpt: actief-actief of actief-passief. Kies uw aanpak, afhankelijk van de ernst van de gebruikersstroom en systeemstroom die de infrastructuuronderdelen ondersteunen. Wat betrouwbaarheid betreft, helpt een actief-actief ontwerp voor meerdere regio's u om het hoogst mogelijke niveau van betrouwbaarheid 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 voor één regio gebruiken met behulp van beschikbaarheidszones. Zie Aanbevelingen voor ontwerp met hoge beschikbaarheid voor meerdere regio's voor meer informatie.

Implementatiestempels en schaaleenheden

Of u nu implementeert in een actief-actief- of actief-passiefmodel, volg 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 zijn of een subset met dezelfde vereisten voor gegevensprivacy als uw workload. U kunt elke stempel 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-passief-implementatie te optimaliseren voor tolerantie en beheerlast. Het plannen van uitschalen voor meerdere regio's is ook belangrijk om potentiële tijdelijke beperkingen van resourcecapaciteit in een regio te overwinnen.

Beschikbaarheidszones binnen Azure-regio's

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

Richtlijnen voor infrastructuurlagen

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 doorgaans het meest geschikt voor IaaS-rekenservices (Infrastructure as a Service). Voor een containertoepassing bepaalt u de specifieke functionaliteit waarover u controle moet hebben 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, waardoor uw beheerlast wordt verminderd en er is een gedocumenteerde mate van redundantie ingebouwd.

  • Gebruik Azure Virtual Machine Scale Sets als u virtuele machines (VM's) moet implementeren. Met Virtual Machine Scale Sets kunt u uw rekenproces automatisch gelijkmatig verdelen over beschikbaarheidszones.

  • Houd uw rekenlaag vrij van alle statussen , 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 belasting te verhogen.

  • Te veel inrichten van kritieke resources om fouten van redundante exemplaren te beperken, zelfs voordat de bewerkingen voor automatisch schalen beginnen, zodat het systeem blijft 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 afwegingsbeslissingen de mate waarin u reservecapaciteit toevoegt bij overprovisioning. Overprovisioning verwijst specifiek naar uitschalen, wat betekent dat er extra instanties van een bepaald type rekenresource worden toegevoegd in plaats van dat de rekenmogelijkheden van één exemplaar worden vergroot. Bijvoorbeeld als u een VM wijzigt van een SKU van een lagere laag in een SKU van 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.

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 voor hulp bij het maken van deze beslissing.

  • 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 naarmate de hoeveelheid gegevens in uw oplossing toeneemt.  

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

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

  • Failover automatiseren na een fout met een database-exemplaar. U kunt automatische failover configureren in meerdere Azure PaaS-gegevensservices. Automatische failover is niet vereist voor gegevensarchieven die schrijfbewerkingen voor 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 polyglotpersistentie 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.

  • Houd rekening met vereisten voor gegevensconsistentie en gebruik uiteindelijke consistentie wanneer de vereisten dit toestaan. Wanneer gegevens worden gedistribueerd, gebruikt u de juiste coördinatie om sterke consistentiegaranties af te dwingen. Coördinatie kan uw doorvoer verminderen en uw systemen nauw aan elkaar koppelen, waardoor ze brozer kunnen worden. Als een bewerking bijvoorbeeld twee databases bijwerkt in plaats van deze in één transactiebereik te plaatsen, is het beter als het systeem uiteindelijke consistentie kan bieden.

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

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

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

Netwerken

  • 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 die het bouwen en schalen van uw redundantieontwerp vereenvoudigen.

  • Selecteer de juiste netwerkservice om aanvragen binnen 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 vereisten voor uitschalen.

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

  • Kies SKU's en configureer netwerkservices die kunnen voldoen aan uw bandbreedte- en beschikbaarheidsvereisten. De doorvoer van een VPN-gateway varieert op basis van hun SKU. Ondersteuning voor zoneredundantie is alleen beschikbaar voor bepaalde 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

Het Azure-platform helpt u de tolerantie van uw workload te optimaliseren en redundantie toe te voegen door:

DNS-specifieke Azure-facilitering

  • Voor interne naamomzettingsscenario's gebruikt u Azure DNS-privézones, die ingebouwde zoneredundantie en geo-redundantie hebben. Zie Azure DNS-tolerantie voor privézones voor meer informatie.

  • Voor scenario's met externe naamomzetting gebruikt u openbare Azure DNS-zones, die ingebouwde zoneredundantie en geo-redundantie hebben.

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

  • Gebruik Azure DNS Private Resolver voor scenario's voor hybride naamomzetting tussen on-premises omgevingen en cloudomgevingen. Deze service ondersteunt zoneredundantie als uw workload zich in een regio bevindt die ondersteuning biedt voor beschikbaarheidszones. Een zonebrede storing vereist geen actie tijdens zoneherstel. De service herstelt zichzelf automatisch en wordt opnieuw in balans gebracht 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 tussen 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.

Voorbeeld

Zie Baseline highly available zone-redundant web application (Maximaal beschikbare zone-redundante webtoepassing basislijn) voor een voorbeeld van een redundante implementatie voor 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.

Controlelijst voor betrouwbaarheid