Delen via

Aanbevelingen voor het ontwerpen voor redundantie

  • Artikel

Van toepassing op deze aanbeveling voor betrouwbaarheid van Azure Well-Architected Framework:

RE:05 Redundantie toevoegen op verschillende niveaus, met name voor kritieke stromen, om te voldoen aan uw betrouwbaarheidsdoelen. Overweeg redundante infrastructuuronderdelen, zoals compute en netwerk, en meerdere exemplaren van uw oplossing.

Gerelateerde handleidingen:hoogbeschikbaar multiregionaal ontwerp | Gebruik 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 groot risico op uitgebreide downtime vanwege mogelijke storingen.

definities

Term Definitie
Redundantie De implementatie van meerdere identieke exemplaren van een workloadonderdeel.
Polyglot persistentie 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 mate waarin een gegevensset synchroon of niet synchroon is in verschillende winkels.
Partitioneren Het proces van het fysiek verdelen van gegevens in afzonderlijke gegevensarchieven.
Scherf Een horizontale strategie voor databasepartitionering die ondersteuning biedt voor meerdere opslagexemplaren met een gemeenschappelijk schema. Gegevens worden niet gerepliceerd in alle gevallen.

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 webservers tegelijk laten draaien. De cruciale aard van de stroom die ze ondersteunen, kan vereisen dat alle van hen replica's hebben die gereed zijn om verkeer te accepteren als er een probleem optreedt dat de hele pool treft, zoals een regionale storing. U kunt er ook voor kiezen een beperkt aantal replica's te implementeren, omdat grootschalige problemen zeldzaam zijn en het kostbaar is om een volledige set replica's in te zetten. Hierdoor kan de stroom in een verminderde staat blijven functioneren 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. In de context van betrouwbaarheid, bouw reservecapaciteit in om fouten 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 kostenefficiënties 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. Voor meer informatie, zie Aanbevelingen voor een ontwerp met hoge beschikbaarheid voor meerdere regio's.

Implementatiestempels en schaaleenheden

Of u nu implementeert in een actief-actief of actief-passief model, volg het ontwerppatroon Implementatiestempels om uw workload herhaalbaar en schaalbaar te implementeren. 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 werkbelasting horizontaal te schalen of om blauwgroene implementaties uit te voeren. Ontwerp uw werkbelasting met implementatiestempels om uw actief-actief of actief-passief implementatie te optimaliseren voor veerkracht en beheerlasten. 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'svoor meer informatie.

Zoneredundantie implementeren voor rekenresources

  • Kies de juiste compute-service 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 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 last te verhogen.

  • Overprovisioneer kritieke middelen om de impact van fouten in redundante exemplaren te verminderen, zelfs voordat automatische schaalbewerkingen beginnen, zodat het systeem na een onderdeelfout blijft functioneren. 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 u extra exemplaren van een bepaald rekenresourcetype toevoegt in plaats van de rekenmogelijkheden van één exemplaar te verhogen. Als u bijvoorbeeld een virtuele machine wijzigt van een lagere SKU naar een hogere SKU.

  • 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'som u te helpen deze beslissing te nemen.

  • Houd rekening met de groeisnelheid van uw gegevens. Bij capaciteitsplanning, plan voor de gegevensgroei, de gegevensretentie en de archivering zodat uw betrouwbaarheidsvereisten worden gehaald wanneer de hoeveelheid gegevens in uw oplossing groeit.  

  • 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 noodgevallenvoor meer informatie.

  • Gebruik de beste gegevensopslag 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. Het bevat 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 strak gekoppeld zijn, 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 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 CQRS-patroon (Command and Query Responsibility Segregation) gebruiken om uw lezen-en-schrijven en alleen-lezen gegevensmodellen te scheiden. Voeg meer redundante database-exemplaren met het kenmerk Alleen-lezen toe om meer flexibiliteit te bieden.  

  • Begrijp de ingebouwde replicatie- en redundantiemogelijkheden van de toestandsbehoudende platformservices die u gebruikt. Voor specifieke redundantiemogelijkheden van stateful gegevensservices, zie Gerelateerde koppelingen.

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 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 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-ondersteuning

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

  • 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 hybride naamomzettingsscenario's 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 herbalanceert om te profiteren van de gezonde zone. Zie Resiliency in Azure DNS Private Resolvervoor 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 voorwaardelijk doorstuurscenario, 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é-resolversvoor meer informatie.

Voorbeeld

Zie Baseline zeer beschikbare zone-redundante webtoepassingvoor een voorbeeld van een multi-region redundante implementatie.

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.

Betrouwbaarheidscontrolelijst