Wat zijn redundantie, replicatie en back-up?

We denken vaak aan de cloud als een wereldwijd gedistribueerd, alomtegenwoordig systeem. In werkelijkheid bestaat de cloud echter uit hardware die wordt uitgevoerd in datacenters. Tolerantie vereist dat u rekening houdt met een aantal van de risico's die zijn gekoppeld aan de fysieke locaties waarop uw cloudonderdelen worden uitgevoerd.

Dit artikel bevat een algemene inleiding tot redundantie, replicatie en back-up. Dit zijn methoden die worden gebruikt om workloads te maken die bestand zijn tegen fysieke risico's die serviceonderbreking, storingen of gegevensverlies veroorzaken.

Redundantie is de mogelijkheid om meerdere identieke kopieën van een serviceonderdeel te onderhouden en deze kopieën te gebruiken op een manier die voorkomt dat een onderdeel een single point of failure wordt.

Replicatie of gegevensredundantie is de mogelijkheid om meerdere kopieën van gegevens te onderhouden, replica's genoemd.

Back-up is de mogelijkheid om een tijdstempel te onderhouden van gegevens die kunnen worden gebruikt om gegevens te herstellen die verloren zijn gegaan.

Vanuit een betrouwbaarheidsperspectief is een belangrijke manier om veel risico's te beperken het opnemen van een vorm van redundantie, replicatie of back-up in uw bedrijfscontinuïteitsplanning.

Notitie

Dit artikel bevat geen ontwerprichtlijnen of gedetailleerde informatie over afzonderlijke Azure-services. Zie de betrouwbaarheidshandleiding van elke service voor informatie over hoe specifieke Azure-services werken vanuit het perspectief van betrouwbaarheid.

Redundantie

Redundantie bestaat uit het implementeren van meerdere exemplaren van een onderdeel. Hoewel redundantie eenvoudig te begrijpen is, kan het in sommige situaties complex worden om te implementeren.

Wanneer u de redundantie begrijpt, is het het eenvoudigst om redundantie te overwegen in relatie tot staatloze onderdelen, die onderdelen zijn die geen gegevens opslaan. Hoewel de meeste echte oplossingen de status moeten beheren, bespreken we in deze sectie redundantie in termen van een voorbeeld van een stateless application programming interface (API). De voorbeeld-API accepteert invoer, werkt wel aan die invoer en retourneert vervolgens een uitvoer, zonder gegevens op te slaan. In de volgende sectie, Replicatie: Redundantie voor gegevens, bespreken we overwegingen voor toestandvolle redundantie.

Scenario: Staatloze redundantie

In dit voorbeeld wordt een stateless API-onderdeel geïmplementeerd op een virtuele machine. Om downtime voor het API-onderdeel te voorkomen als er een hardwarefout op de fysieke host is, implementeert het voorbeeld een redundante oplossing die:

• Hiermee worden meerdere exemplaren van het API-exemplaar geïmplementeerd.
• Implementeert een load balancer om aanvragen te distribueren tussen API-exemplaren.

De load balancer bewaakt de status van elk exemplaar om aanvragen alleen naar gezonde exemplaren te verzenden.

Overwegingen voor redundantie

Bij het implementeren van redundante oplossingen, zoals in het bovenstaande scenario, is het belangrijk om rekening te houden met het volgende:

• Kosten van middelen. Redundantie omvat per definitie meerdere kopieën van iets, waardoor de totale kosten voor het hosten van de oplossing worden verhoogd.

• Voorstelling. Hoe groter een geografisch gebied dat u de kopieën van de dingen distribueert, hoe meer risico's u helpt te beperken. Het duurt echter langer voordat aanvragen van clients langere afstanden afleggen omdat ze meer netwerkinfrastructuur moeten doorlopen en hierdoor de netwerklatentie toeneemt.

  In de meeste praktijksituaties is de netwerklatentie inconsequent voor korte afstanden, zoals binnen een datacenter of zelfs tussen datacenters in een stad. Maar als u kopieën over een lange afstand distribueert, kan de netwerklatentie aanzienlijk groter worden.

• Consistentie van exemplaren. Het is belangrijk om exemplaren consistent met elkaar te houden en om te voorkomen dat exemplaren afzonderlijk worden geconfigureerd, omdat u per ongeluk verschillen tussen de exemplaren kunt introduceren. Als er verschillen zijn tussen instances, dan kunnen aanvragen anders worden verwerkt, afhankelijk van welke instance ze dient. Dit kan fouten en gedrag veroorzaken die moeilijk te diagnosticeren zijn.

• Verdeling van werk. Wanneer u meerdere exemplaren van een onderdeel hebt, moet u er werk onder verdelen. U kunt alle exemplaren gelijkmatig verdelen of u kunt aanvragen verzenden naar één primair exemplaar en alleen een secundair exemplaar gebruiken als het primaire exemplaar niet beschikbaar is.

  Voor componenten die binnenkomende aanvragen ontvangen, worden load balancers vaak gebruikt om die aanvragen naar instantiaties te sturen. Soms werken onderdelen echter onafhankelijk en ontvangen ze geen aanvragen van clients, dus in deze situaties moeten instanties mogelijk hun werk met elkaar coördineren.

• Gezondheidsmonitoring. De status van elk exemplaar bepaalt of dat exemplaar zijn werk kan doen en statuscontrole is belangrijk om snel herstel mogelijk te maken als er een probleem is.

  Load balancers voeren doorgaans gezondheidscontrole uit. Voor onderdelen die geen load balancer bevatten, hebt u mogelijk een extern onderdeel dat de status van alle exemplaren bewaakt, of elk exemplaar kan de status van andere exemplaren controleren.

Fysieke locaties in de cloud

De noodzaak van redundantie is duidelijk wanneer u begrijpt dat, zelfs in een cloudomgeving, een exemplaar of een stukje gegevens wordt opgeslagen op een specifieke fysieke locatie.

Voorbeeld:

• Een virtuele machine draait op elk moment op een enkele fysieke locatie.
• Gegevens worden opgeslagen op een specifieke fysieke locatie, zoals op een SSD (Solid State Drive) of harde schijf die is verbonden met servers.

Zelfs als er meerdere kopieën van een stukje gegevens of exemplaren van een onderdeel zijn, is elke kopie gekoppeld aan de fysieke hardware waarop deze is opgeslagen.

De fysieke locatie van een cloudomgeving als geheel kan worden ingedeeld in fysieke bereiken. Bij elk fysiek gebied zijn er potentiële risico's die de onderdelen of gegevens binnen dat gebied in gevaar kunnen brengen. Hier volgt een niet-volledige lijst met risico's die kunnen worden gedefinieerd in termen van fysiek bereik:

Fysiek bereik	Mogelijk risico
Een specifiek stuk hardware, zoals een schijf of server	Hardwarestoring
Een rek in een datacenter	Storing bij de bovenste-rack netwerkswitch
Een datacenter	Probleem met het koelsysteem van het gebouw
Een groep datacenters, die in Azure een beschikbaarheidszone wordt genoemd	Stadsbrede elektrische onweersbui
Het bredere geografische gebied waarin het datacenter zich bevindt, zoals een stad, een Azure-regio	Wijdverspreide natuurramp

Vanuit een betrouwbaarheidsperspectief is een belangrijke manier om de risico's te beperken die zijn gekoppeld aan een fysieke omgeving, door exemplaren van een onderdeel over verschillende fysieke omgevingen te verdelen. Azure-services met ingebouwde redundantie bieden u mogelijk een of meer van de volgende drie manieren om redundante exemplaren te implementeren:

• Lokale redundantie plaatst exemplaren in meerdere onderdelen van één Azure-datacenter en beschermt tegen hardwarefouten die van invloed kunnen zijn op één exemplaar. Lokale redundantie biedt doorgaans de laagste kosten en latentie. Een datacenterfout kan echter betekenen dat alle exemplaren niet beschikbaar zijn.

• Zoneredundantie verspreidt exemplaren over meerdere beschikbaarheidszones in één Azure-regio. Zoneredundantie beschermt tegen datacenterfouten, naast hardwarefouten.

• Met georedundantie worden instanties in meerdere Azure-regio's geplaatst en wordt bescherming geboden tegen grootschalige regionale storingen. Georedundantie kost hogere kosten en vereist overweging van uw bredere oplossingsontwerp en hoe u schakelt tussen exemplaren van uw onderdelen in elke regio. U moet ook rekening houden met latentie, die wordt beschreven in synchrone en asynchrone replicatie.

Hoe redundantie werkt in Azure: Compute-services

Redundantie wordt in bijna elk deel van Azure gebruikt. Als voorbeeld van hoe Azure redundantie implementeert, moet u rekening houden met de services die rekenworkloads uitvoeren.

In Azure wordt een afzonderlijke virtuele machine (VM) uitgevoerd op één fysieke host in een Azure-datacenter. U kunt instructies voor Azure opgeven om ervoor te zorgen dat de VM wordt uitgevoerd op de plaats die u verwacht, zoals de regio en beschikbaarheidszone, en in sommige gevallen wilt u deze zelfs op een host plaatsen die aan u is toegewezen.

Het is gebruikelijk om meerdere exemplaren van een virtuele machine uit te voeren. In dat scenario kunt u ervoor kiezen om ze afzonderlijk te beheren of door een virtuele-machineschaalset te gebruiken. Wanneer u een schaalset gebruikt, kunt u nog steeds de afzonderlijke VM's zien die deze ondersteunen, maar de schaalset biedt een scala aan mogelijkheden om redundante VM's te beheren. Deze mogelijkheden omvatten automatische plaatsing van de VM's op basis van regels die u opgeeft, zoals door ze over foutdomeinen binnen de regio of beschikbaarheidszone te spreiden.

Er zijn veel andere Azure-rekenservices die afhankelijk zijn van virtuele machines om rekentaken uit te voeren. Compute-services bieden over het algemeen verschillende redundantie-instellingen die bepalen hoe de virtuele machines worden gedistribueerd. Een service kan bijvoorbeeld een zoneredundantieinstelling bieden, die u kunt inschakelen om virtuele machines automatisch te distribueren over beschikbaarheidszones en taakverdeling te configureren.

Replicatie: Redundantie voor gegevens

Redundantie, wanneer deze wordt toegepast op status (gegevens), wordt replicatie genoemd. Met replicatie kunt u meerdere realtime of bijna realtime kopieën van livegegevens onderhouden, ook wel replica's genoemd. Om de tolerantie voor risico's te verbeteren, kunt u replica's over verschillende locaties distribueren. Als een replica niet meer beschikbaar is, kan het systeem een failover uitvoeren , zodat een andere replica de functie overneemt.

Er zijn verschillende typen replicatie en elk type replicatie plaatst verschillende prioriteiten voor gegevensconsistentie, prestaties en kosten. Elk replicatietype is van invloed op twee belangrijke metrische gegevens die worden gebruikt in discussies over bedrijfscontinuïteit: beoogde hersteltijd (RTO), wat de maximale hoeveelheid downtime is die u kunt tolereren in een noodscenario en RPO (Recovery Point Objective ), wat de maximale hoeveelheid gegevensverlies is die u kunt tolereren in een noodscenario. Zie Wat zijn bedrijfscontinuïteit, hoge beschikbaarheid en herstel na noodgevallen voor meer informatie over deze metrische gegevens en hoe deze betrekking hebben op bedrijfscontinuïteit.

Vanwege het belang van replicatie bij het voldoen aan functionele en prestatievereisten, omvatten de meeste databasesystemen en andere gegevensopslagproducten en -services een soort replicatie als een nauw geïntegreerde functie. De typen replicatie die ze aanbieden, zijn meestal gebaseerd op hun architectuur en de manieren waarop ze moeten worden gebruikt. Zie de azure-servicebetrouwbaarheidshandleidingen voor meer informatie over de typen replicatie die worden ondersteund door Azure-services.

Belangrijk

Replicatie is niet hetzelfde als back-up. Replicatie synchroniseert alle wijzigingen tussen meerdere replica's en onderhoudt geen oude kopieën van gegevens.

Stel dat u per ongeluk bepaalde gegevens verwijdert. De verwijderingsbewerking wordt gerepliceerd naar elke replica en uw gegevens worden overal verwijderd. In dit geval moet u waarschijnlijk de verwijderde gegevens uit een back-up herstellen. Back-up wordt verderop in dit artikel beschreven.

Synchrone en asynchrone replicatie

Wanneer u gegevens repliceert, moeten eventuele wijzigingen in die gegevens gesynchroniseerd blijven tussen replica's. Er zijn een aantal belangrijke uitdagingen bij het behouden van consistentie wanneer gegevens worden gewijzigd:

• Wachttijd. Het bijwerken van een replica kost tijd en hoe verder van elkaar de replica's zijn, hoe langer het duurt om gegevens over de afstand tussen de replica's te verzenden en een bevestiging te ontvangen.

• Wijzigingsbeheer. Gegevens kunnen veranderen terwijl replica's worden gesynchroniseerd en het beheer van de consistentie van de gegevens kan dus complex worden.

Om deze uitdagingen aan te pakken, zijn er twee belangrijke manieren waarop u gegevenswijzigingen kunt repliceren en gegevensconsistentie kunt beheren:

• Voor synchrone replicatie moeten updates plaatsvinden op meerdere replica's voordat de update als voltooid wordt beschouwd. In het volgende diagram ziet u hoe synchrone replicatie werkt:

  

  In dit voorbeeld vindt de volgende reeks stappen plaats:

  1. Een client wijzigt de gegevens en de aanvraag wordt verzonden naar replica 1, waarmee de aanvraag wordt verwerkt en de gewijzigde gegevens worden opgeslagen.
  2. Replica 1 verzendt de wijzigingen naar replica 2, waarmee de aanvraag wordt verwerkt en de gewijzigde gegevens worden opgeslagen.
  3. Replica 2 bevestigt de wijziging terug naar replica 1.
  4. Replica 1 bevestigt de wijziging terug naar de client.

  Synchrone replicatie kan consistentie garanderen, wat betekent dat het een RPO van nul kan ondersteunen. Dit komt echter ten koste van de prestaties. Hoe verder uit elkaar uw replica's zich geografisch bevinden en hoe meer netwerkhops moeten worden doorlopen, hoe meer latentie wordt geïntroduceerd door het replicatieproces.

• Asynchrone replicatie vindt plaats op de achtergrond. In het volgende diagram ziet u hoe asynchrone replicatie werkt:

  

  In dit voorbeeld vindt de volgende reeks stappen plaats:

  1. Een client wijzigt de gegevens en de aanvraag wordt verzonden naar replica 1.
  2. Replica 1 verwerkt de aanvraag, slaat de gewijzigde gegevens op en bevestigt onmiddellijk de wijziging terug naar de client.
  3. Later in de tijd synchroniseert replica 1 de wijziging naar replica 2.

  Omdat asynchrone replicatie buiten transactiestromen plaatsvindt, wordt replicatie verwijderd als een beperking voor de prestaties van toepassingen. Als u echter een failover naar een andere replica wilt uitvoeren, beschikt deze mogelijk niet over de meest recente gegevens en moet uw RPO dus groter zijn dan nul. De exacte RPO die asynchrone replicatie kan ondersteunen, is afhankelijk van de replicatiefrequentie.

Replica-rollen

In veel replicatiesystemen kunnen replica's verschillende rollen aannemen, wat helpt bij het coördineren van wijzigingen in gegevens en het verminderen van de kans op conflicten. Er zijn twee hoofdtypen rollen, actief en passief. Er zijn twee veelvoorkomende manieren om replica's met deze rollen te distribueren:

• Actief-passieve replicatie betekent dat u één actieve replica hebt, die verantwoordelijk is voor het fungeren als de bron van waarheid. Wijzigingen in de gegevens moeten worden toegepast op die replica. Alle andere replica's werken in een passieve rol, wat betekent dat ze updates ontvangen voor de gegevens van de actieve replica, maar ze verwerken wijzigingen niet rechtstreeks van clients. Passieve replica's worden niet gebruikt voor live verkeer, tenzij er een failover plaatsvindt en de rollen van de replica's veranderen. In het volgende diagram ziet u een actief-passief systeem met één passieve replica:

  

  In een actief-passief systeem wordt de RTO bepaald door de tijd die nodig is om een "failover" uit te voeren. Doorgaans wordt de RTO voor een actief-passief systeem gemeten in minuten.

  Sommige replicatieoplossingen ondersteunen ook alleen-lezen replica's, waarmee u gegevens van de passieve replica's kunt lezen (maar niet schrijven). Deze methode kan handig zijn om meer gebruik te krijgen van uw replica's, zoals wanneer u analyses of rapportages moet uitvoeren op gegevens zonder dat dit van invloed is op de primaire replica die u gebruikt voor het transactionele werk van uw toepassing. Verschillende Azure-services ondersteunen alleen-lezen replica's, waaronder Azure Storage met het replicatietype leestoegang GRS (RA-GRS) en actieve geo-replicatie van Azure SQL Database.

• Met actief-actieve replicatie kunt u meerdere actieve replica's tegelijk gebruiken voor liveverkeer. Alle replica's kunnen aanvragen verwerken:

  

  Actief-actieve replicatie maakt een hoog prestatieniveau mogelijk omdat het systeem de resources op alle replica's kan gebruiken. Actief-actieve replicatie kan in sommige situaties ondersteuning bieden voor een RTO van nul. Deze voordelen hebben echter als nadeel dat ze de gegevensconsistentie bemoeilijken, doordat gelijktijdige concurrerende wijzigingen tussen meerdere replica's een asynchrone afstemming vereisen.

Complexe gegevensservices kunnen zowel actief-actief als actief-passieve replicatie combineren. Ze kunnen bijvoorbeeld één set replica's implementeren in de ene Azure-regio en een andere in een andere regio. Binnen elke regio verwerkt één actieve replica verzoeken, terwijl een of meer passieve replica's gereed staan voor failover. Ondertussen werken beide regio's in een actief-actief model, waardoor verkeer over deze regio's kan worden verdeeld.

Hoe replicatie werkt in Azure-gegevensservices

Elke Azure-service waarin gegevens worden opgeslagen, biedt een vorm van replicatie. Elke service kan echter een andere benadering gebruiken die specifiek is voor de architectuur en de beoogde toepassingen van de service.

Azure Storage kan bijvoorbeeld zowel synchrone als asynchrone replicatie bieden via een set mogelijkheden:

• Meerdere kopieën van uw gegevens worden synchroon gerepliceerd binnen uw primaire regio. U kunt kiezen of u replica's op verschillende fysieke hardware in één datacenter in lokaal redundante opslag (LRS) wilt plaatsen of wilt verspreiden over meerdere beschikbaarheidszones voor zone-redundante opslag (ZRS).
• Als uw primaire regio is gekoppeld en u geografisch redundante opslag (GRS) inschakelt, worden de gegevens ook gerepliceerd naar de gekoppelde regio. Omdat gekoppelde regio's geografisch ver weg zijn, gebeurt deze replicatie asynchroon om de impact op de doorvoer van uw toepassing te verminderen.
• U kunt ervoor kiezen om zone-redundante opslag en geografisch redundante opslag tegelijkertijd te gebruiken met behulp van de geografisch zone-redundante opslaglaag (GZRS). Gegevens binnen de regio worden synchroon gerepliceerd en gegevens tussen regio's worden asynchroon gerepliceerd.

Zie Redundantie in Azure Storage voor meer informatie.

Een ander voorbeeld is Azure Cosmos DB, dat ook replicatie biedt. Alle Azure Cosmos DB-databases hebben meerdere replica's. Wanneer u replica's wereldwijd distribueert, ondersteunt dit schrijven in meerdere regio's, waarbij clients naar een replica kunnen schrijven in een van de regio's die u gebruikt. Deze schrijfbewerkingen worden synchroon gerepliceerd binnen de regio en vervolgens asynchroon gerepliceerd in andere regio's. Azure Cosmos DB biedt een mechanisme voor conflictoplossing voor het geval er schrijfconflicten zijn tussen de verschillende replica's. Voor meer informatie, zie Globale gegevensdistributie met Azure Cosmos DB - achter de schermen.

Als u virtuele machines gebruikt, kunt u Azure Site Recovery gebruiken om virtuele machines en hun schijven tussen beschikbaarheidszones of naar een andere Azure-regio te repliceren.

Wanneer u een Azure-oplossing ontwerpt, raadpleegt u de betrouwbaarheidshandleidingen voor elke service om te begrijpen hoe deze service redundantie en replicatie biedt, ook op verschillende locaties.

Reservekopie

Back-up maakt een kopie van uw gegevens op een bepaald tijdstip. Als er een probleem is, kunt u de back-up later herstellen . Wijzigingen in uw gegevens die zijn aangebracht nadat de back-up is gemaakt, bevinden zich echter niet in de back-up en gaan mogelijk verloren.

Met behulp van back-up kunt u oplossingen bieden voor het maken van back-ups en het herstellen van uw gegevens in of naar de Microsoft Azure-cloud. Back-ups kunnen u beschermen tegen verschillende risico's, waaronder:

• Onherstelbare verliezen van hardware of andere infrastructuur.
• Gegevensbeschadiging en -verwijdering.
• Cyberaanvallen, zoals ransomware.

Belangrijk

Het is van cruciaal belang dat u uw back-up- en herstelprocessen regelmatig test en controleert, naast uw andere herstelstappen. Testen zorgt ervoor dat uw back-ups uitgebreid en foutloos zijn en dat uw processen ze correct herstellen. Tests zijn ook belangrijk om ervoor te zorgen dat uw team de processen begrijpt die moeten worden gevolgd. Zie Testen en oefeningen voor meer informatie.

Hoe back-up van invloed is op uw vereisten

Wanneer back-ups worden gebruikt als onderdeel van een strategie voor herstel na noodgevallen, ondersteunen back-ups doorgaans een RTO en RPO die in uren worden gemeten:

• RTO wordt beïnvloed door de tijd die nodig is om uw herstelprocessen te initiëren en te voltooien, waaronder het herstellen van een back-up en het valideren dat het herstel is voltooid. Afhankelijk van de grootte van de back-up en het aantal back-upbestanden waaruit moet worden gelezen, duurt het vaak enkele uren of zelfs langer om een back-up volledig te herstellen.

• RPO wordt beïnvloed door de frequentie van uw back-upproces. Als u vaker back-ups maakt, betekent dit dat u minder gegevens kwijtraakt als u een back-up moet herstellen. Back-ups vereisen echter opslag en in sommige situaties kunnen ze van invloed zijn op de prestaties van de service terwijl back-ups worden gemaakt. Daarom moet u rekening houden met de back-upfrequentie en de juiste balans vinden voor de vereisten van uw organisatie. Back-upfrequentie moet een overweging zijn in de planning van bedrijfscontinuïteit.

Sommige back-upsystemen ondersteunen complexere back-upvereisten, waaronder meerdere back-uplagen met verschillende bewaarperioden en differentiële of incrementele back-ups die sneller kunnen worden opgeslagen en minder opslagruimte verbruiken.

Back-up maken in Azure-services

Veel Azure-services bieden back-upmogelijkheden voor uw gegevens.

Azure Backup is een toegewezen back-upoplossing voor verschillende belangrijke Azure-services, waaronder virtuele machines, Azure Storage en Azure Kubernetes Service (AKS).

Veel beheerde databases bieden ook hun eigen back-upmogelijkheden als onderdeel van de service, zoals:

• Azure SQL Database biedt geautomatiseerde back-ups.
• Azure Cosmos DB biedt zowel continue als periodieke back-upmogelijkheden.
• Met Azure Key Vault kunt u een back-up van de gegevens in uw kluis downloaden.
• Azure App Service biedt zowel automatische als aangepaste back-ups voor webtoepassingen en kan ook een back-up maken van hun databases.

Back-up versus replicatie

Back-up en replicatie beschermen u tegen verschillende risico's en de twee benaderingen vormen een aanvulling op elkaar.

Replicatie ondersteunt dagelijkse tolerantie en wordt vaak gebruikt in een strategie voor hoge beschikbaarheid. Sommige replicatiemethoden vereisen weinig tot geen downtime of gegevensverlies en ondersteunen een lage RTO en RPO. Replicatie beschermt u echter niet tegen risico's die leiden tot gegevensverlies of beschadiging.

Back-up is daarentegen vaak een laatste verdedigingslinie tegen catastrofale risico's. Back-ups vereisen vaak een relatief hoge RTO en RPO, hoewel de manier waarop u back-ups configureert, van invloed is op hoe hoog ze zijn. Een totaal herstel vanuit een back-up maakt vaak deel uit van een noodherstelplan.

Onderdelen voorbereiden voor redundantie

Wanneer u een systeem ontwerpt dat gebruikmaakt van redundantie als onderdeel van de architectuur, is het belangrijk om ook na te denken over het volgende:

• Maak een dubbele resourceconfiguratie voor consistentie.
• Capaciteit tijdens storingen van instanties beheren door overcapaciteit te plannen.

Resourceconfiguratie dupliceren

In cloudomgevingen is de configuratie van elk van uw resources essentieel. Wanneer u bijvoorbeeld een netwerktaakverdeling maakt, configureert u verschillende instellingen die van invloed zijn op de werking ervan; en wanneer u een functie implementeert met behulp van Azure Functions, configureert u instellingen met betrekking tot beveiligings-, prestatie- en toepassingsconfiguratie-instellingen. Elke resource in Azure heeft een soort configuratie die het gedrag aanstuurt.

Wanneer u redundante kopieën van resources op verschillende locaties beheert, is het belangrijk dat u de configuratie beheert. Veel instellingen moeten op dezelfde manier worden ingesteld voor elke kopie, zodat de resources zich op dezelfde manier gedragen. Sommige instellingen kunnen echter verschillen tussen elke kopie, zoals verwijzingen naar het virtuele netwerk van een specifieke regio.

Een veelvoorkomende benadering voor het behouden van consistentie in uw resources is het gebruik van infrastructuur als code (IaC), zoals Bicep of Terraform. Met deze hulpprogramma's kunt u bestanden maken die een resource definiëren en kunt u deze definities opnieuw gebruiken voor elk exemplaar van de resource. Met behulp van IaC kunt u de last van het maken en beheren van meerdere instanties van resources voor tolerantiedoeleinden verminderen, en er zijn ook veel andere voordelen. Zie Wat is infrastructuur als code (IaC)? en aanbevelingen voor het gebruik van infrastructuur als code voor meer informatie.

Capaciteit beheren met overprovisioning

Wanneer een exemplaar uitvalt, kan de totale systeemcapaciteit afwijken van de capaciteit die nodig is tijdens gezonde bewerkingen. Stel dat u doorgaans zes exemplaren van een webserver hebt om uw binnenkomende webverkeer te verwerken en dat deze exemplaren gelijkmatig worden verdeeld over drie Azure-beschikbaarheidszones in een regio:

Als een beschikbaarheidszone een storing ondervindt, verliest u mogelijk tijdelijk twee exemplaren en blijft u bij slechts vier webserverexemplaren staan. Als uw applicatie doorgaans druk is en alle zes exemplaren nodig heeft om uw normale verkeer bij te houden, kan het draaien op een verminderde capaciteit van invloed zijn op de prestaties van uw oplossing.

Als u zich wilt voorbereiden op fouten, kunt u extra capaciteit voor uw service inplannen. Met overinrichting kan de oplossing enige mate van capaciteitsverlies tolereren en toch blijven functioneren zonder verminderde prestaties.

Als u exemplaren van uw webserver wilt over-inrichten om rekening te houden met de fout in één beschikbaarheidszone, voert u de volgende stappen uit:

1. Bepaal het aantal exemplaren dat uw piekworkload nodig heeft.
2. Haal het aantal instanties van overprovisioning op door het aantal piekworkloadinstanties te vermenigvuldigen met de factor [(zones/(zones-1)].
3. Rond het resultaat af op het dichtstbijzijnde gehele getal.

Notitie

In de volgende tabel wordt ervan uitgegaan dat u drie beschikbaarheidszones gebruikt en dat u rekening wilt houden met het verlies in capaciteit van een van deze zones. Als uw vereisten afwijken, past u de formule dienovereenkomstig aan.

Piekaantal werklastinstanties	Factor van [(zones/(zones-1)]	Formule	Te provisioneren instanties (afgerond)
3	1,5	(3 x 1,5 = 4,5)	5exemplaren
4	1,5	(4 x 1,5 = 6)	6 gevallen
5	1,5	(5 x 1,5 = 7,5)	8 exemplaren
6	1,5	(6 x 1,5 = 9)	9 gevallen
7	1,5	(7 x 1,5 = 10,5)	11 voorbeelden
8	1,5	(8 x 1,5 = 12)	12 exemplaren
9	1,5	(9 x 1,5 = 13,5)	14 exemplaren
10	1,5	(10 x 1,5 = 15)	15 exemplaren

In het voorgaande voorbeeld vereist de piekworkload zes exemplaren van de webserver, dus voor overinrichting zijn in totaal negen exemplaren vereist:

Volgende stappen

Meer informatie over failover en failback.