Aanbevelingen voor het gebruik van beschikbaarheidszones en regio's
Van toepassing op deze aanbeveling van het Azure Well-Architected Framework voor betrouwbaarheid:
| 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. |
|---|
Verwante handleidingen:maximaal beschikbare multiregionale ontwerp | Redundantie
In deze handleiding worden de aanbevelingen beschreven om te bepalen wanneer workloads over beschikbaarheidzones of regio's heen moeten worden geïmplementeerd.
Wanneer u een oplossing voor Azure ontwerpt, moet u beslissen of u in meerdere beschikbaarheidszones in een regio implementeert of in meerdere regio's implementeert. Deze beslissing is van invloed op de betrouwbaarheid, kosten en prestaties van uw oplossing en de mogelijkheid van uw team om de oplossing te gebruiken. Deze handleiding bevat informatie over de belangrijkste bedrijfsvereisten die van invloed zijn op uw beslissing, de benaderingen die u kunt overwegen, de afwegingen bij elke benadering en het effect van elke benadering op de kernpijlers van het Azure Well-Architected Framework.
De beslissing over de beste Azure-regio's die u voor uw oplossing kunt gebruiken, is een essentiële keuze. In de handleiding Azure-regio's selecteren wordt beschreven hoe u in meerdere geografische regio's kunt selecteren en werken. Uw keuze voor hoe u regio's en beschikbaarheidszones binnen uw oplossing gebruikt, heeft ook invloed op verschillende pijlers van het Well-Architected Framework:
- betrouwbaarheid: uw implementatiebenadering kan u helpen verschillende soorten risico's te beperken. Over het algemeen kunt u een hogere tolerantie bereiken door uw workload te spreiden over een geografisch gedistribueerd gebied.
- Kostenoptimalisatie: voor sommige architectuurmethoden is het implementeren van meer resources nodig dan andere, waardoor uw resourcekosten kunnen worden verhoogd. Andere benaderingen zijn het verzenden van gegevens in geografisch gescheiden beschikbaarheidszones of regio's, waarvoor mogelijk netwerkverkeerskosten in rekening worden gebracht. Het is ook belangrijk om rekening te houden met de doorlopende kosten voor het beheren van uw resources, wat meestal hoger is wanneer u uitgebreide bedrijfsvereisten hebt.
- Prestatie-efficiëntie: beschikbaarheidszones worden met elkaar verbonden via een netwerkkoppeling met hoge bandbreedte en lage latentie, die voldoende is voor de meeste werkbelastingen om synchrone replicatie en communicatie tussen de zones mogelijk te maken. Als uw workload echter is getest en gevoelig is voor netwerklatentie tussen zones, moet u mogelijk overwegen om de onderdelen van uw workload dicht bij elkaar te plaatsen om latentie te minimaliseren wanneer ze communiceren.
- Operational Excellence: een complexe architectuur kost meer moeite om te implementeren, configureren en beheren. Daarnaast moet u voor een maximaal beschikbare oplossing mogelijk een failover naar een secundaire set resources plannen. Failover, failback en transparant omleiden van uw verkeer kunnen complex zijn, met name wanneer handmatige stappen vereist zijn. Het is een goede gewoonte om uw implementatie- en beheerprocessen te automatiseren. Zie de pijlers Operational Excellence, waaronder OE:05 Infrastructure as code, OE:09 Task Automation, OE:10 Automation designen OE:11 Deployment practicesvoor meer informatie.
Hoe u uw oplossing ook ontwerpt, de beveiligingspijler blijft van toepassing. Normaal gesproken veranderen beslissingen over of en hoe u beschikbaarheidszones en regio's gebruikt uw beveiligingspostuur niet. Azure past dezelfde beveiliging toe op elke regio en beschikbaarheidszone.
Fooi
Voor veel productietaken biedt een zone-redundante implementatie de beste balans tussen afwegingen. U kunt deze benadering uitbreiden met asynchrone gegevensback-up naar een andere regio. Als u niet zeker weet welke methode u moet selecteren, begint u met dit type implementatie.
Overweeg andere werkbelastingmethoden wanneer u de specifieke voordelen nodig hebt die deze benaderingen bieden, maar houd rekening met de betrokken compromissen.
definities
| Term | Definitie |
|---|---|
| Actief-actief | Een architectuur waarin meerdere exemplaren van een oplossing aanvragen actief verwerken. |
| Actief-passief | Een architectuur waarin één exemplaar van een oplossing wordt aangewezen als de primaire en verkeer verwerkt, en een of meer secundaire instanties worden geïmplementeerd om verkeer te verwerken als de primaire instantie niet beschikbaar is. |
| Asynchrone replicatie | Een benadering voor gegevensreplicatie waarin gegevens worden geschreven en vastgelegd op één locatie. Op een later tijdstip worden de wijzigingen gerepliceerd naar een andere locatie. |
| Beschikbaarheidszone | Een gescheiden groep datacenters binnen een regio. Elke beschikbaarheidszone is onafhankelijk van de andere, met een eigen energie-, koelings- en netwerkinfrastructuur. Veel regio's ondersteunen beschikbaarheidszones. |
| Datacenter | Een faciliteit die servers, netwerkapparatuur en andere hardware bevat ter ondersteuning van Azure-resources en -workloads. |
| Lokaal redundante implementatie | Een implementatiemodel waarin een resource in één regio wordt geïmplementeerd zonder te verwijzen naar een beschikbaarheidszone. In een regio die beschikbaarheidszones ondersteunt, kan de resource worden geïmplementeerd in een van de beschikbaarheidszones van de regio. |
| Implementatie in meerdere regio's | Een implementatiemodel waarin resources worden geïmplementeerd in meerdere Azure-regio's. |
| Gekoppelde regio's | Een relatie tussen twee Azure-regio's. Sommige Azure-regio's zijn verbonden met een andere gedefinieerde regio om specifieke typen oplossingen voor meerdere regio's mogelijk te maken. Nieuwere Azure-regio's zijn niet gekoppeld. |
| Regio | Een geografische perimeter die een set datacenters bevat. |
| Regioarchitectuur | De specifieke configuratie van de Azure-regio, inclusief het aantal beschikbaarheidszones en of de regio is gekoppeld aan een andere regio. |
| Synchrone replicatie | Een benadering voor gegevensreplicatie waarbij gegevens worden geschreven en toegewezen aan meerdere locaties. Elke locatie moet de voltooiing van de schrijfbewerking bevestigen voordat de algehele schrijfbewerking als voltooid wordt beschouwd. |
| Zonegebonden (vastgemaakte) implementatie | Een implementatiemodel waarin een resource wordt geïmplementeerd in een specifieke beschikbaarheidszone. |
| Zone-redundante implementatie | Een implementatiemodel waarin een resource wordt geïmplementeerd in meerdere beschikbaarheidszones. Microsoft beheert gegevenssynchronisatie, verkeersdistributie en failover als een zone een storing ondervindt. |
Belangrijke ontwerpstrategieën
Azure heeft een grote wereldwijde footprint. Een Azure -regio is een geografische perimeter die een set datacenters bevat. U moet volledig inzicht hebben in Azure-regio's en beschikbaarheidszones.
Azure-regio's hebben verschillende configuraties, die ook wel regioarchitecturenworden genoemd.
Veel Azure-regio's bieden beschikbaarheidszones, die gescheiden groepen datacenters zijn. Binnen een regio zijn beschikbaarheidszones dicht genoeg om verbindingen met lage latentie met andere beschikbaarheidszones te hebben, maar ze zijn ver genoeg van elkaar om de kans te verkleinen dat meer dan één wordt beïnvloed door lokale storingen of het weer. Beschikbaarheidszones hebben onafhankelijke energie-, koelings- en netwerkinfrastructuur. Ze zijn zodanig ontworpen dat als één zone een storing ondervindt, regionale services, capaciteit en hoge beschikbaarheid worden ondersteund door de resterende zones.
In het volgende diagram ziet u verschillende azure-voorbeeldregio's. Regio's 1 en 2 ondersteunen beschikbaarheidszones.
Als u implementeert in een Azure-regio die beschikbaarheidszonesbevat, kunt u meerdere beschikbaarheidszones samen gebruiken. Door meerdere beschikbaarheidszones te gebruiken, kunt u afzonderlijke kopieën van uw toepassing en gegevens bewaren in afzonderlijke fysieke datacenters in een groot grootstedelijk gebied.
Er zijn twee manieren om beschikbaarheidszones in een oplossing te gebruiken:
- Zonal resources zijn gekoppeld aan een specifieke beschikbaarheidszone. U kunt meerdere zonegebonden implementaties in verschillende zones combineren om te voldoen aan hoge betrouwbaarheidsvereisten. U bent verantwoordelijk voor het beheren van gegevensreplicatie en het distribueren van aanvragen tussen zones. Als er een storing optreedt in één beschikbaarheidszone, bent u verantwoordelijk voor failover naar een andere beschikbaarheidszone.
- Zone-redundante middelen zijn verdeeld over meerdere beschikbaarheidszones. Microsoft beheert het verspreiden van aanvragen tussen zones en de replicatie van gegevens in zones. Als er een storing optreedt in één beschikbaarheidszone, beheert Microsoft failover automatisch.
Azure-services ondersteunen een of beide van deze methoden. PaaS-services (Platform as a Service) ondersteunen doorgaans zone-redundante implementaties. IaaS-services (Infrastructure as a Service) ondersteunen doorgaans zonegebonden implementaties. Zie Azure-services met ondersteuning voor beschikbaarheidszonesvoor meer informatie over hoe Azure-services met beschikbaarheidszones werken.
Wanneer Microsoft updates implementeert voor services, proberen we benaderingen te gebruiken die het minst verstorend voor u zijn. We willen bijvoorbeeld updates implementeren in één beschikbaarheidszone tegelijk. Deze aanpak kan de impact verminderen die updates mogelijk hebben op een actieve workload, omdat de werkbelasting in andere zones kan blijven worden uitgevoerd terwijl de update wordt uitgevoerd. Het is echter uiteindelijk de verantwoordelijkheid van het workloadteam om ervoor te zorgen dat hun workload blijft functioneren tijdens platformupgrades. Wanneer u bijvoorbeeld virtuele-machineschaalsets gebruikt met de flexibele indelingsmodusof de meeste Azure PaaS-services, plaatst Azure uw resources op intelligente wijze om de impact van platformupdates te verminderen. Daarnaast kunt u overwegen om overprovisioning te gebruiken - het implementeren van meer instanties van een resource - zodat sommige instanties beschikbaar blijven terwijl andere worden bijgewerkt. Zie Geavanceerde veilige implementatieproceduresvoor meer informatie over hoe Azure updates implementeert.
Veel regio's hebben ook een gekoppelde regio. Gekoppelde regio's ondersteunen bepaalde typen implementatiemethoden voor meerdere regio's. Sommige nieuwere regio's hebben meerdere beschikbaarheidszones en hebben geen gekoppelde regio. U kunt nog steeds oplossingen voor meerdere regio's implementeren in deze regio's, maar de benaderingen die u gebruikt, kunnen afwijken.
Inzicht in gedeelde verantwoordelijkheden
Het principe van gedeelde verantwoordelijkheid beschrijft hoe verantwoordelijkheden worden verdeeld tussen de cloudprovider (Microsoft) en u. Afhankelijk van het type services dat u gebruikt, neemt u mogelijk meer of minder verantwoordelijkheid voor het uitvoeren van de service.
Microsoft biedt beschikbaarheidszones en regio's om u flexibiliteit te bieden bij het ontwerpen van uw oplossing om te voldoen aan uw vereisten. Wanneer u beheerde services gebruikt, neemt Microsoft meer beheerverantwoordelijkheden voor uw resources over, waaronder mogelijk zelfs gegevensreplicatie, failover, failback en andere taken met betrekking tot het beheer van een gedistribueerd systeem.
Uw eigen code moet aanbevolen procedures en ontwerppatronen volgen om fouten op elegante wijze af te handelen. Deze procedures zijn nog belangrijker tijdens failoverbewerkingen, zoals die gebeuren wanneer een beschikbaarheidszone of regiofailover optreedt, omdat failover tussen zones of regio's meestal vereist dat uw toepassing verbindingen met services opnieuw probeert uit te voeren.
Belangrijke bedrijfs- en workloadvereisten identificeren
Als u een weloverwogen beslissing wilt nemen over het gebruik van beschikbaarheidszones en regio's in uw oplossing, moet u uw vereisten begrijpen. Deze vereisten moeten worden aangestuurd door discussies tussen oplossingsontwerpers en zakelijke belanghebbenden.
Risicotolerantie
Verschillende organisaties hebben verschillende mate van risicotolerantie. Zelfs binnen een organisatie is risicotolerantie vaak verschillend voor elke workload. De meeste workloads hebben geen extreem hoge beschikbaarheid nodig. Sommige workloads zijn echter zo belangrijk dat het zelfs de moeite waard is om risico's te beperken die waarschijnlijk niet voorkomen, zoals grote natuurrampen die van invloed zijn op een breed geografisch gebied.
Deze tabel bevat een aantal veelvoorkomende risico's die u in een cloudomgeving moet overwegen:
| Risico | Voorbeelden | Waarschijnlijkheid |
|---|---|---|
| Hardwarestoring | Probleem met harde schijf- of netwerkapparatuur. Host wordt opnieuw opgestart. |
Hoog. Elke tolerantiestrategie moet rekening houden met deze risico's. |
| Datacenterstoring | Stroom-, koelings- of netwerkstoringen in een heel datacenter. Natuurramp in één deel van een grootstedelijk gebied. |
Gemiddeld |
| Regio-storing | Grote natuurramp die van invloed is op een breed geografisch gebied. Netwerk- of serviceprobleem waardoor een of meer Azure-services niet beschikbaar zijn in een hele regio. |
Laag |
Het zou ideaal zijn om elk mogelijk risico voor elke workload te beperken, maar het is niet praktisch of rendabel om dit te doen. Het is belangrijk om een open discussie te voeren met zakelijke belanghebbenden, zodat u weloverwogen beslissingen kunt nemen over de risico's die u moet beperken.
Tip
Ongeacht de betrouwbaarheidsdoelen moeten alle workloads enige beperking hebben voor herstel na noodgevallen. Als uw workload hoge betrouwbaarheidsdoelen vereist, moeten uw risicobeperkingsstrategieën uitgebreid zijn en moet u het risico op zelfs gebeurtenissen met een lage kans verminderen. Voor andere workloads moet u een weloverwogen beslissing nemen over de risico's die u wilt accepteren en welke u moet beperken.
Tolerantievereisten
Het is belangrijk om inzicht te hebben in de tolerantievereisten voor uw workload, inclusief de beoogde hersteltijd (RTO) en de RPO (Recovery Point Objective). Deze doelstellingen helpen u te bepalen welke benaderingen u wilt uitsluiten. Als u geen duidelijke vereisten hebt, kunt u geen weloverwogen beslissing nemen over welke aanpak u moet volgen. Zie functionele en niet-functionele vereistenvoor meer informatie.
Serviceniveaudoelstellingen
U moet inzicht hebben in de verwachte serviceniveaudoelstelling (SLO) van uw oplossing. U hebt bijvoorbeeld een bedrijfsvereiste waaraan uw oplossing moet voldoen om een uptime van 99,9%% te bereiken.
Azure biedt serviceovereenkomsten (SLA's) voor elke service. Een SLA geeft het uptimeniveau aan dat u moet verwachten van de service en de voorwaarden waaraan u moet voldoen om die verwachte SLA te bereiken. Houd er echter rekening mee dat de manier waarop een Azure SLA aangeeft dat de beschikbaarheid van de service niet altijd overeenkomt met de manier waarop u de status van uw workload beschouwt.
Uw architectuurbeslissingen zijn van invloed op de samengestelde SLO-van uw oplossing. Hoe meer redundantie u in uw oplossing bouwt, hoe hoger uw SLO waarschijnlijk is. Veel Azure-services bieden hogere SLA's wanneer u services implementeert in een zone-redundante of configuratie met meerdere regio's. Bekijk de SLA's voor elk van de Azure-services die u gebruikt om ervoor te zorgen dat u begrijpt hoe u de tolerantie en SLA van de service kunt maximaliseren.
Gegevensresidentie
Sommige organisaties plaatsen beperkingen op de fysieke locaties waar hun gegevens kunnen worden opgeslagen en verwerkt. Soms zijn deze vereisten gebaseerd op wettelijke of regelgevende normen. In andere situaties kan een organisatie besluiten om een beleid voor gegevenslocatie in te stellen om zorgen van klanten te voorkomen. Als u strikte vereisten voor gegevenslocatie hebt, moet u mogelijk een implementatie met één regio gebruiken of een subset van Azure-regio's en -services gebruiken.
Notitie
Vermijd het maken van onbedoelde veronderstellingen over uw vereisten voor gegevenslocatie. Als u moet voldoen aan specifieke regelgevingsstandaarden, controleert u wat deze standaarden daadwerkelijk aangeven.
Gebruikerslocatie
Door te begrijpen waar uw gebruikers zich bevinden, kunt u een weloverwogen beslissing nemen over het optimaliseren van latentie en betrouwbaarheid voor uw behoeften. Azure biedt veel opties ter ondersteuning van een geografisch verspreide gebruikersbasis.
Als uw gebruikers zich in één gebied bevinden, kan een implementatie met één regio uw operationele vereisten vereenvoudigen en uw kosten verlagen. U moet echter overwegen of een implementatie met één regio voldoet aan uw betrouwbaarheidsvereisten. Voor bedrijfskritieke toepassingen moet u nog steeds een implementatie met meerdere regio's gebruiken, zelfs als uw gebruikers op dezelfde locatie zijn.
Als uw gebruikers geografisch verspreid zijn, kan het zinvol zijn om uw workload in meerdere regio's te implementeren. Azure-services bieden verschillende mogelijkheden ter ondersteuning van een implementatie in meerdere regio's en u kunt de wereldwijde footprint van Azure gebruiken om uw gebruikerservaring te verbeteren en uw toepassingen dichter bij uw gebruikersbasis te brengen. U kunt het patroon Implementatiestempels of het Geodes-patroongebruiken of uw resources repliceren in meerdere regio's.
Zelfs als uw gebruikers zich in verschillende geografische gebieden bevinden, moet u overwegen of u een implementatie met meerdere regio's nodig hebt. Overweeg of u uw vereisten binnen één regio kunt bereiken met behulp van wereldwijde verkeersversnelling, zoals de versnelling die wordt geleverd door Azure Front Door.
Begroting
Als u werkt onder een beperkt budget, is het belangrijk om rekening te houden met de kosten voor het implementeren van redundante workloadonderdelen. Deze kosten kunnen extra resourcekosten, netwerkkosten en de operationele kosten voor het beheren van meer resources en een complexere omgeving omvatten.
Complexiteit
Het is een goede gewoonte om onnodige complexiteit in uw oplossingsarchitectuur te voorkomen. Hoe meer complexiteit u introduceert, hoe moeilijker het wordt om beslissingen te nemen over uw architectuur. Complexe architecturen zijn moeilijker te bedienen, moeilijker te beveiligen en vaak minder presterend. Volg het principe van eenvoud.
Azure faciliteiten
Door regio's en beschikbaarheidszones te bieden, kunt u in Azure een implementatiebenadering selecteren die aansluit bij uw behoeften. Er zijn veel benaderingen waaruit u kunt kiezen, die elk voordelen bieden en kosten in rekening worden gebracht.
Bekijk een voorbeeldscenario om de implementatiemethoden te illustreren die u kunt gebruiken. Stel dat u denkt aan het implementeren van een nieuwe oplossing die een toepassing bevat die gegevens naar een soort opslag schrijft:
Dit voorbeeld is niet specifiek voor bepaalde Azure-services. Het is bedoeld om een eenvoudig voorbeeld te bieden voor het illustreren van fundamentele concepten.
Er zijn meerdere manieren om deze oplossing te implementeren. Elke benadering biedt een andere set voordelen en brengt verschillende kosten met zich mee. Op hoog niveau kunt u een lokaal redundante , zonegebonden (vastgemaakte), zone-redundanteof -implementatie in meerdere regio's overwegen. In deze tabel vindt u een overzicht van enkele problemen met de pijlers:
| Pilaar | lokaal redundante | zonegebonden (vastgemaakt) | zone-redundante | voor meerdere regio's |
|---|---|---|---|---|
| Betrouwbaarheid | Lage betrouwbaarheid | Afhankelijk van de benadering | Hoge of zeer hoge betrouwbaarheid | Hoge of zeer hoge betrouwbaarheid |
| Kostenoptimalisatie | Lage kosten | Afhankelijk van de benadering | Gemiddelde kosten | Hoge kosten |
| Prestatie-efficiëntie | Acceptabele prestaties (voor de meeste workloads) | Hoge prestaties | Acceptabele prestaties (voor de meeste workloads) | Afhankelijk van de benadering |
| Operationele uitmuntendheid | Lage operationele behoeften | Hoge operationele vereisten | Lage operationele vereisten | Hoge operationele vereisten |
Deze tabel bevat een overzicht van een aantal benaderingen die u kunt gebruiken en hoe deze van invloed zijn op uw architectuur:
| Architectuurprobleem | lokaal redundante | zonegebonden (vastgezet) | Zone-redundante | voor meerdere regio's |
|---|---|---|---|---|
| Naleving van gegevensresidentie | Hoog | Hoog | Hoog | Is afhankelijk van regio- |
| Regionale beschikbaarheid | Alle regio's | regio's met beschikbaarheidszones | regio's met beschikbaarheidszones | Is afhankelijk van regio- |
In de rest van dit artikel worden alle benaderingen beschreven die in de voorgaande tabel worden vermeld. De lijst met benaderingen is niet volledig. U kunt besluiten om meerdere benaderingen te combineren of verschillende benaderingen te gebruiken in verschillende onderdelen van uw oplossing.
Implementatiebenadering 1: Lokaal redundante implementaties
Als u niet meerdere beschikbaarheidszones of regio's opgeeft wanneer u uw resources implementeert, biedt Azure geen garanties over of de resources worden geïmplementeerd in één datacenter of worden gesplitst in meerdere datacenters in de regio. In sommige situaties kan Azure uw resource ook verplaatsen tussen beschikbaarheidszones.
De meeste Azure-resources zijn standaard maximaal beschikbaar, met hoge SLA's en ingebouwde redundantie binnen een datacenter dat wordt beheerd door het platform. Vanuit een betrouwbaarheidsperspectief, als er een storing optreedt in een deel van de regio, is er een kans dat uw werklast mogelijk wordt beïnvloed. Als dat het zo is, is uw oplossing mogelijk niet beschikbaar of kunnen uw gegevens verloren gaan.
Voor zeer latentiegevoelige workloads kan deze benadering ook leiden tot lagere prestaties. Uw workloadonderdelen bevinden zich mogelijk niet in hetzelfde datacenter, dus u kunt enige latentie voor verkeer binnen regio's observeren. Azure kan uw service-exemplaren ook transparant verplaatsen tussen beschikbaarheidszones, wat de prestaties enigszins kan beïnvloeden. Dit is echter geen probleem voor de meeste workloads.
In deze tabel vindt u een overzicht van enkele problemen met de pijlers:
| Pilaar | Invloed |
|---|---|
| Betrouwbaarheid | Lage betrouwbaarheid. Services zijn onderhevig aan storingen als een datacenter uitvalt. U kunt echter een toepassing bouwen om bestand te zijn tegen andere typen fouten. |
| Kostenoptimalisatie | Laagste kosten. U hoeft slechts één exemplaar van elke resource te hebben en er worden geen kosten in rekening gebracht voor bandbreedte tussen regio's. |
| Prestatie-efficiëntie |
Voor de meeste workloads:acceptabele prestaties. Deze benadering levert waarschijnlijk bevredigende prestaties. Voor zeer latentiegevoelige workloads:Lage prestaties. Onderdelen bevinden zich niet gegarandeerd in dezelfde beschikbaarheidszone, zodat u mogelijk lagere prestaties ziet voor zeer latentiegevoelige onderdelen. |
| Operationele uitmuntendheid | Hoge operationele efficiëntie. U hoeft slechts één exemplaar van elke resource te implementeren en te beheren. |
Deze tabel bevat een overzicht van enkele van de problemen vanuit een architectuurperspectief:
| Architectuurprobleem | Invloed |
|---|---|
| Naleving van gegevenslocatie | Hoog. Wanneer u een oplossing implementeert die gebruikmaakt van deze benadering, worden gegevens opgeslagen in de Azure-regio die u selecteert. |
| Regionale beschikbaarheid | Hoog. Deze benadering kan worden gebruikt in elke Azure-regio. |
Lokaal redundante implementaties met back-up tussen regio's
U kunt een lokaal redundante implementatie uitbreiden door regelmatige back-ups van uw infrastructuur en gegevens uit te voeren naar een secundaire regio. Deze aanpak voegt een extra beveiligingslaag toe om te beperken tegen een storing in uw primaire regio. Dit ziet er als volgt uit:
Wanneer u deze aanpak implementeert, moet u zorgvuldig rekening houden met uw RTO en RPO:
- Hersteltijd: als er een regionale storing optreedt, moet u uw oplossing mogelijk opnieuw opbouwen in een andere Azure-regio, wat van invloed is op uw hersteltijd. Overweeg om uw oplossing te bouwen met behulp van een IaC-benadering (Infrastructure-as-Code), zodat u snel opnieuw kunt implementeren in een andere regio als er zich een grote ramp voordoet. Zorg ervoor dat uw implementatiehulpprogramma's en -processen net zo tolerant zijn als uw toepassingen, zodat u ze kunt gebruiken om uw oplossing opnieuw te implementeren, zelfs als er een storing is. Plan en oefen de stappen die nodig zijn om uw oplossing terug te herstellen naar een werkende status.
- Herstelpunt: de back-upfrequentie bepaalt de hoeveelheid gegevensverlies die u mogelijk ondervindt (uw herstelpunt). U kunt doorgaans de frequentie van back-ups beheren, zodat u aan uw RPO kunt voldoen.
In deze tabel vindt u een overzicht van enkele problemen met de pijlers:
| Pilaar | Invloed |
|---|---|
| Betrouwbaarheid | Gemiddelde betrouwbaarheid. Services zijn onderhevig aan storingen als een datacenter uitvalt. Er wordt asynchroon een back-up van gegevens gemaakt in een geografisch gescheiden regio, waardoor het effect van een volledige regiostoring wordt verminderd door gegevensverlies te minimaliseren. Bij een storing in een volledige regio kunt u operaties handmatig herstellen in een andere regio. Herstelprocessen kunnen echter complex zijn en het kan tijd duren om handmatig te herstellen naar de andere regio. |
| Kostenoptimalisatie | Lage kosten. Meestal kost het toevoegen van een back-up aan een andere regio slechts iets meer dan het implementeren van een lokaal redundante resource. |
| Prestatie-efficiëntie |
Voor de meeste workloads:acceptabele prestaties. Deze benadering levert waarschijnlijk bevredigende prestaties. Voor zeer latentiegevoelige workloads:Lage prestaties. Onderdelen bevinden zich niet gegarandeerd in dezelfde beschikbaarheidszone, zodat u mogelijk lagere prestaties ziet voor zeer latentiegevoelige onderdelen. |
| Operationele uitmuntendheid | Tijdens storingen binnen een regio:Lage operationele efficiëntie. Failover is uw verantwoordelijkheid en kan handmatige bewerkingen en herimplementaties vereisen. |
Deze tabel bevat een overzicht van enkele van de problemen vanuit een architectuurperspectief:
| Architectuurprobleem | Invloed |
|---|---|
| Naleving van gegevensresidentie | Afhankelijk van regioselectie. Gegevens worden voornamelijk opgeslagen in de Azure-regio die u opgeeft. U moet echter een andere regio selecteren om uw back-ups op te slaan, dus het is belangrijk dat u een regio selecteert die compatibel is met uw vereisten voor gegevenslocatie. |
| Regionale beschikbaarheid | Hoog. U kunt deze benadering gebruiken in elke Azure-regio. |
Implementatiebenadering 2: Zonegebonden (vastgemaakte) implementaties
In een zonegebonden-implementatie geeft u op dat uw resources moeten worden geïmplementeerd in een specifieke beschikbaarheidszone. Deze benadering wordt ook wel een zonegebonden-implementatie genoemd.
Een zonegebonden benadering vermindert de latentie tussen uw onderdelen. Op zichzelf verhoogt het echter niet de tolerantie van uw oplossing. Als u uw tolerantie wilt vergroten, moet u meerdere exemplaren van uw onderdelen implementeren in meerdere beschikbaarheidszones en bepalen hoe u verkeer tussen elk exemplaar kunt routeren. In dit voorbeeld ziet u een actief-passieve benadering voor verkeersroutering:
In het vorige voorbeeld wordt een load balancer geïmplementeerd in meerdere beschikbaarheidszones. Het is belangrijk om te overwegen hoe u verkeer routeert tussen exemplaren in verschillende beschikbaarheidszones, omdat een zonestoring ook van invloed kan zijn op de netwerkresources die in die zone zijn geïmplementeerd. U kunt ook overwegen om een globale load balancer te gebruiken, zoals Azure Front Door- of Azure Traffic Manager-, die helemaal niet in een regio wordt geïmplementeerd.
Wanneer u een zonegebonden implementatiemodel gebruikt, neemt u veel verantwoordelijkheden op:
- U moet resources implementeren in elke beschikbaarheidszone en deze resources afzonderlijk configureren en beheren.
- U moet bepalen hoe en wanneer u gegevens tussen de beschikbaarheidszones repliceert en vervolgens de replicatie configureert en beheert.
- U bent verantwoordelijk voor het distribueren van de aanvragen naar de juiste resources, bijvoorbeeld met behulp van een load balancer. U moet ervoor zorgen dat de load balancer voldoet aan uw tolerantievereisten. U moet ook beslissen of u een actief-passief- of actief-actief aanvraagdistributiemodel wilt gebruiken.
- Als een beschikbaarheidszone een storing ondervindt, moet u de failover afhandelen om verkeer naar resources in een andere beschikbaarheidszone te verzenden.
Een actief-passieve implementatie in meerdere beschikbaarheidszones wordt ook wel in-region DR of Metro DRgenoemd.
In deze tabel vindt u een overzicht van enkele problemen met de pijlers:
| Pilaar | Invloed |
|---|---|
| Betrouwbaarheid |
Bij implementatie in één beschikbaarheidszone:Lage betrouwbaarheid. Een zonegebonden implementatie biedt geen tolerantie voor een storing in een datacenter of beschikbaarheidszone. U moet redundante resources implementeren in meerdere beschikbaarheidszones om hoge tolerantie te bereiken. Bij implementatie in meerdere beschikbaarheidszones:hoge betrouwbaarheid. Services kunnen tolerant worden gemaakt voor een storing in een datacenter of beschikbaarheidszone. |
| Kostenoptimalisatie |
Wanneer geïmplementeerd in één beschikbaarheidszone:Lage kosten. Een implementatie met één zone vereist slechts één exemplaar van elke resource. Bij implementatie in meerdere beschikbaarheidszones:Hoge kosten. U implementeert meerdere exemplaren van de resources, die elk afzonderlijk worden gefactureerd. |
| Prestatie-efficiëntie | Hoge prestaties. Latentie kan zeer laag zijn wanneer de onderdelen die een aanvraag verwerken zich in dezelfde beschikbaarheidszone bevinden. |
| Operationele uitmuntendheid | Lage operationele efficiëntie. U moet meerdere exemplaren van uw service configureren en beheren. U moet gegevens tussen beschikbaarheidszones repliceren. Tijdens een storing in de beschikbaarheidszone is failover uw verantwoordelijkheid. |
Deze tabel bevat een overzicht van enkele van de problemen vanuit een architectuurperspectief:
| Architectuurprobleem | Invloed |
|---|---|
| Naleving van gegevenslocatie | Hoog. Wanneer u een oplossing implementeert die gebruikmaakt van deze benadering, worden gegevens opgeslagen in de Azure-regio die u selecteert. |
| Regionale beschikbaarheid | Regio's met beschikbaarheidszones. Deze methode is beschikbaar in elke regio die ondersteuning biedt voor beschikbaarheidszones. |
Deze benadering wordt doorgaans gebruikt voor workloads die zijn gebaseerd op virtuele machines. Zie Service voor beschikbaarheidszone en regionale ondersteuningvoor een volledige lijst met services die zone-implementaties ondersteunen.
Wanneer u een zonegebonden implementatie plant, controleert u of de Azure-services die u gebruikt, worden ondersteund in de beschikbaarheidszones die u wilt gebruiken. Als u bijvoorbeeld wilt weergeven welke SKU's voor virtuele machines beschikbaar zijn in elke beschikbaarheidszone, raadpleegt u De beschikbaarheid van vm-SKU's controleren.
Tip
Wanneer u een resource in een specifieke beschikbaarheidszone implementeert, selecteert u het zonenummer. De volgorde van zonenummers verschilt voor elk Azure-abonnement. Als u resources implementeert in meerdere Azure-abonnementen, controleert u de zonenummers die u in elk abonnement moet gebruiken. Zie Fysieke en logische beschikbaarheidszonesvoor meer informatie.
Implementatiebenadering 3: Zone-redundante implementaties
Wanneer u deze benadering gebruikt, wordt uw toepassingslaag verspreid over meerdere beschikbaarheidszones. Wanneer aanvragen binnenkomen, verspreidt een load balancer die is ingebouwd in de service (die zelf beschikbaarheidszones omvat) de aanvragen over de exemplaren in elke beschikbaarheidszone. Als een beschikbaarheidszone een storing ervaart, stuurt de load balancer verkeer naar instanties in de gezonde beschikbaarheidszones.
Uw opslaglaag is ook verspreid over meerdere beschikbaarheidszones. Kopieën van de gegevens van uw toepassing worden verdeeld over meerdere beschikbaarheidszones via synchrone replicatie. Wanneer de toepassing gegevens wijzigt, schrijft de opslagservice de wijziging naar meerdere beschikbaarheidszones en wordt de transactie alleen als voltooid beschouwd wanneer al deze wijzigingen zijn voltooid. Dit proces zorgt ervoor dat elke beschikbaarheidszone altijd een up-to-datumkopie van de gegevens heeft. Als een beschikbaarheidszone een storing ondervindt, kan een andere beschikbaarheidszone worden gebruikt om toegang te krijgen tot dezelfde gegevens.
Een zone-redundante benadering verhoogt de tolerantie van uw oplossing voor problemen zoals datacentrumstoringen. Omdat gegevens synchroon worden gerepliceerd, moet uw toepassing echter wachten totdat de gegevens worden geschreven op meerdere afzonderlijke locaties die zich in verschillende delen van een grootstedelijk gebied kunnen bevinden. Voor de meeste toepassingen is de latentie bij communicatie tussen zones te verwaarlozen. Voor sommige zeer latentiegevoelige workloads kan synchrone replicatie tussen beschikbaarheidszones echter van invloed zijn op de prestaties van de toepassing.
In deze tabel vindt u een overzicht van enkele problemen met de pijlers:
| Pilaar | Invloed |
|---|---|
| Betrouwbaarheid | Hoge betrouwbaarheid. Services zijn bestand tegen een storing in een datacenter of beschikbaarheidszone. Gegevens worden synchroon gerepliceerd in beschikbaarheidszones en zonder vertraging. |
| Kostenoptimalisatie | Gemiddelde kosten. Afhankelijk van de services die u gebruikt, kunnen er kosten in rekening worden gebracht voor hogere servicelagen om zoneredundantie in te schakelen. |
| Prestatie-efficiëntie |
Voor de meeste workloads:acceptabele prestaties. Deze benadering levert waarschijnlijk bevredigende prestaties. Voor zeer latentiegevoelige workloads:Lage prestaties. Sommige onderdelen kunnen gevoelig zijn voor latentie vanwege interzoneverkeer of replicatietijd van gegevens. |
| Operationele uitmuntendheid | Hoge operationele efficiëntie. Doorgaans moet u slechts één logisch exemplaar van elke resource beheren. Voor de meeste services is failover tijdens een storing in de beschikbaarheidszone de verantwoordelijkheid van Microsoft en gebeurt automatisch. |
Deze tabel bevat een overzicht van enkele van de problemen vanuit een architectuurperspectief:
| Architectuurprobleem | Invloed |
|---|---|
| Naleving van gegevensopslaglocatie | Hoog. Wanneer u een oplossing implementeert die gebruikmaakt van deze benadering, worden gegevens opgeslagen in de Azure-regio die u selecteert. |
| Regionale beschikbaarheid | Regio's met beschikbaarheidszones. Deze methode is beschikbaar in elke regio die ondersteuning biedt voor beschikbaarheidszones. |
Deze aanpak is mogelijk met veel Azure-services, waaronder Azure Virtual Machine Scale Sets, Azure App Service, Azure Functions, Azure Kubernetes Service, Azure Storage, Azure SQL, Azure Service Bus en nog veel meer. Zie Service voor beschikbaarheidszone en regionale ondersteuningvoor een volledige lijst met services die zoneredundantie ondersteunen.
Zone-redundante implementaties met back-up tussen regio's
U kunt een zone-redundante implementatie uitbreiden door regelmatige back-ups van uw infrastructuur en gegevens uit te voeren naar een secundaire regio. Deze benadering biedt u de voordelen van een zone-redundante benadering en voegt een beveiligingslaag toe om het zeer onwaarschijnlijke geval van een volledige regio-storing te beperken.
Wanneer u deze aanpak implementeert, moet u zorgvuldig rekening houden met uw RTO en RPO:
hersteltijd: als er een regionale storing optreedt, moet u uw oplossing mogelijk opnieuw bouwen in een andere Azure-regio, wat van invloed is op uw hersteltijd. Overweeg om uw oplossing te bouwen met behulp van een IaC-benadering, zodat u snel opnieuw kunt implementeren in een andere regio tijdens een grote ramp. Zorg ervoor dat uw implementatiehulpprogramma's en -processen net zo tolerant zijn als uw toepassingen, zodat u ze kunt gebruiken om uw oplossing opnieuw te implementeren, zelfs als er een storing optreedt. Plan en oefen de stappen die nodig zijn om uw oplossing terug te herstellen naar een werkende status.
Herstelpunt: de back-upfrequentie bepaalt de hoeveelheid gegevensverlies die u mogelijk ondervindt (uw herstelpunt). U kunt doorgaans de frequentie van back-ups bepalen om te voldoen aan uw RPO.
Tip
Deze aanpak biedt vaak een goed evenwicht voor alle architectonische problemen. Als u niet zeker weet welke methode u moet gebruiken, begint u met dit type implementatie.
In deze tabel vindt u een overzicht van enkele problemen met de pijlers:
| Pilaar | Invloed |
|---|---|
| Betrouwbaarheid | Zeer hoge betrouwbaarheid. Services zijn bestand tegen een storing in een datacenter of beschikbaarheidszone. Voor de meeste services worden gegevens automatisch en zonder vertraging gerepliceerd in zones. Er wordt asynchroon een back-up van gegevens gemaakt in een geografisch gescheiden regio. Deze back-up vermindert het effect van een volledige regio-storing door gegevensverlies te minimaliseren. Na een volledige regiostoring kunt u operaties handmatig herstellen in een andere regio. Herstelprocessen kunnen echter complex zijn en het kan tijd duren om handmatig te herstellen naar de andere regio. |
| Kostenoptimalisatie | Gemiddelde kosten. Normaal gesproken kost het toevoegen van een back-up aan een andere regio slechts iets meer dan het implementeren van zoneredundantie. |
| Prestatie-efficiëntie |
Voor de meeste workloads:acceptabele prestaties. Deze benadering levert waarschijnlijk bevredigende prestaties. Voor zeer latentiegevoelige workloads:Lage prestaties. Sommige onderdelen kunnen gevoelig zijn voor latentie vanwege interzoneverkeer of replicatietijd van gegevens. |
| Operationele uitmuntendheid |
Tijdens een storing in de beschikbaarheidszone:hoge operationele efficiëntie. Failover is de verantwoordelijkheid van Microsoft en gebeurt automatisch. Tijdens een regionale storing:Lage operationele efficiëntie. Failover is uw verantwoordelijkheid en kan handmatige bewerkingen en herimplementaties vereisen. |
Deze tabel bevat een overzicht van enkele van de problemen vanuit een architectuurperspectief:
| Architectuurprobleem | Invloed |
|---|---|
| Naleving van gegevensresidency | Afhankelijk van regioselectie. Gegevens worden voornamelijk opgeslagen in de Azure-regio die u opgeeft, maar u moet een andere regio selecteren om uw back-ups op te slaan. Selecteer een regio die compatibel is met uw vereisten voor gegevenslocatie. |
| Regionale beschikbaarheid | Regio's met beschikbaarheidszones. Deze methode is beschikbaar in elke regio die ondersteuning biedt voor beschikbaarheidszones. |
Implementatiebenadering 4: Implementaties in meerdere regio's
U kunt meerdere Azure-regio's samen gebruiken om uw oplossing over een breed geografisch gebied te verdelen. U kunt deze benadering voor meerdere regio's gebruiken om de betrouwbaarheid van uw oplossing te verbeteren of om geografisch gedistribueerde gebruikers te ondersteunen. Als u in meerdere regio's implementeert, vermindert u ook het risico dat u een tijdelijke beperking voor resourcecapaciteit in één regio tegenkomt. Als gegevenslocatie belangrijk is voor uw oplossing, moet u zorgvuldig overwegen welke regio's u gebruikt om ervoor te zorgen dat uw gegevens alleen worden opgeslagen op locaties die aan uw vereisten voldoen.
Actieve en passieve regio's
Architecturen met meerdere regio's zijn complex en er zijn veel manieren om een oplossing voor meerdere regio's te ontwerpen. Voor sommige workloads is het logisch dat meerdere regio's aanvragen actief verwerken (actief-actieve implementaties). Voor andere workloads is het beter om één primaire regio aan te wijzen en een of meer secundaire regio's te gebruiken voor failover (actieve passieve implementaties). Deze sectie is gericht op het tweede scenario, waarin de ene regio actief is en een andere passief. Zie voor informatie over actief-actieve multi-regio-oplossingen, het patroon implementatiestempels en het Geode-patroon .
Gegevensreplicatie
Communiceren tussen regio's is veel langzamer dan communicatie binnen een regio. Over het algemeen veroorzaakt een grotere geografische afstand tussen twee regio's meer netwerklatentie vanwege de langere fysieke afstand die gegevens moeten afleggen. Zie Azure-netwerkstatistieken voor round-trip latentie voor de verwachte netwerklatentie wanneer u verbinding maakt tussen twee regio's.
Latentie tussen regio's kan aanzienlijk van invloed zijn op uw oplossingsontwerp, omdat u zorgvuldig moet overwegen hoe de extra latentie van invloed is op gegevensreplicatie en andere transacties. Voor veel oplossingen vereist een architectuur tussen regio's asynchrone replicatie om het effect van verkeer tussen regio's op prestaties te minimaliseren.
Asynchrone gegevensreplicatie
Wanneer u asynchrone replicatie implementeert in verschillende regio's, wacht uw toepassing niet totdat alle regio's een wijziging bevestigen. Nadat de wijziging is doorgevoerd in de primaire regio, wordt de transactie beschouwd als voltooid. De wijziging wordt op een later tijdstip gerepliceerd naar de secundaire regio's. Deze aanpak zorgt ervoor dat de latentie van verbindingen tussen regio's niet rechtstreeks van invloed is op de prestaties van de toepassing. Vanwege de vertraging in de replicatie kan een regiobrede storing echter leiden tot gegevensverlies. Dit gegevensverlies kan optreden omdat een regio mogelijk een storing ondervindt nadat een schrijfbewerking is voltooid in de primaire regio, maar voordat de wijziging naar een andere regio kan worden gerepliceerd.
In deze tabel vindt u een overzicht van enkele problemen met de pijlers:
| Pilaar | Invloed |
|---|---|
| Betrouwbaarheid | Hoge betrouwbaarheid. De oplossing is bestand tegen een storing in een datacenter, een beschikbaarheidszone of een hele regio. Gegevens worden gerepliceerd, maar zijn mogelijk niet synchroon, dus sommige gegevensverlies is mogelijk in een failoverscenario. |
| Kostenoptimalisatie | Hoge kosten. U moet afzonderlijke resources in elke regio implementeren en voor elke resource worden implementatie- en onderhoudskosten in rekening gebracht. Voor gegevensreplicatie tussen regio's kunnen ook aanzienlijke kosten in rekening worden gebracht. |
| Prestatie-efficiëntie | Hoge prestaties. Voor toepassingsaanvragen is geen verkeer tussen regio's vereist, dus verkeer is doorgaans een lage latentie. |
| Operationele uitmuntendheid | Lage operationele efficiëntie. U moet resources implementeren en beheren in meerdere regio's. U bent ook verantwoordelijk voor failover tussen regio's tijdens een regionale storing. |
Deze tabel bevat een overzicht van enkele van de problemen vanuit een architectuurperspectief:
| Architectuurprobleem | Invloed |
|---|---|
| Naleving van gegevensresidentievoorschriften | Afhankelijk van regioselectie. Voor deze aanpak moet u meerdere regio's selecteren waarin uw workload moet worden uitgevoerd. Kies regio's die compatibel zijn met uw vereisten voor gegevenslocatie. |
| Regionale beschikbaarheid | Veel Azure-regio's zijn gekoppeld. Sommige Azure-services maken gebruik van gekoppelde regio's om gegevens automatisch te repliceren. Als u uw werklast uitvoert in een regio die geen paarheeft, zou u mogelijk een andere benadering moeten gebruiken om uw gegevenste repliceren. |
Synchrone gegevensreplicatie
Als u een synchrone oplossing voor meerdere regio's implementeert, moet uw toepassing wachten tot schrijfbewerkingen in elke Azure-regio zijn voltooid voordat de transactie als voltooid wordt beschouwd. De latentie die wordt gemaakt door te wachten op schrijfbewerkingen, is afhankelijk van de afstand tussen de regio's. Voor veel workloads kan latentie tussen regio's synchrone replicatie te traag maken om nuttig te zijn.
In deze tabel vindt u een overzicht van enkele problemen met de pijlers:
| Pilaar | Invloed |
|---|---|
| Betrouwbaarheid | Zeer hoge betrouwbaarheid. De oplossing is bestand tegen een storing in een datacenter, een beschikbaarheidszone of een hele regio. Gegevens worden altijd gesynchroniseerd tussen regio's, dus zelfs als er een volledig regioverlies optreedt, zijn uw gegevens beschikbaar en voltooid in een andere regio. |
| Kostenoptimalisatie | Hoge kosten. U moet afzonderlijke resources in elke regio implementeren en voor elke resource worden implementatie- en onderhoudskosten in rekening gebracht. Voor gegevensreplicatie tussen regio's kunnen ook aanzienlijke kosten in rekening worden gebracht. |
| Prestatie-efficiëntie | Slechte prestaties. Toepassingsaanvragen vereisen verkeer tussen regio's. Afhankelijk van de afstand tussen de regio's kan synchrone replicatie aanzienlijke latentie toevoegen aan aanvragen. |
| Operationele uitmuntendheid | Lage operationele efficiëntie. U moet resources implementeren en beheren in meerdere regio's. U bent ook verantwoordelijk voor failover tussen regio's tijdens een regionale storing. |
Deze tabel bevat een overzicht van enkele van de problemen vanuit een architectuurperspectief:
| Architectuurprobleem | Impact |
|---|---|
| Naleving van gegevensresidency | Afhankelijk van regioselectie. Voor deze aanpak moet u meerdere regio's selecteren waarin uw workload moet worden uitgevoerd. Selecteer regio's die compatibel zijn met uw vereisten voor gegevenslocatie. |
| Regionale beschikbaarheid | Veel Azure-regio's zijn gekoppeld. Sommige Azure-services maken gebruik van gekoppelde regio's om gegevens automatisch te repliceren. Als u uw werkbelasting uitvoert in een regio die geen paarheeft, moet u mogelijk een andere benadering gebruiken om uw gegevenste repliceren. |
Regioarchitecturen
Wanneer u een oplossing voor meerdere regio's ontwerpt, moet u overwegen of de Azure-regio's die u wilt gebruiken, zijn gekoppeld.
U kunt een oplossing voor meerdere regio's maken, zelfs wanneer de regio's niet zijn gekoppeld. De benaderingen die u gebruikt om een architectuur met meerdere regio's te implementeren, kunnen echter verschillen. In Azure Storage kunt u bijvoorbeeld geografisch redundante opslag (GRS) gebruiken met gekoppelde regio's. Als GRS niet beschikbaar is, kunt u overwegen om functies zoals Azure Storage objectreplicatiete gebruiken of uw toepassing te ontwerpen om naar meerdere regio's te schrijven.
Methoden voor meerdere zones en meerdere regio's combineren
U moet instructies voor meerdere zones en regio's combineren als uw bedrijfsvereisten een dergelijke oplossing eisen. U kunt bijvoorbeeld zone-redundante onderdelen implementeren in elke regio en ook replicatie tussen de regio's configureren. Voor sommige oplossingen biedt deze aanpak een zeer hoge mate van betrouwbaarheid. Het configureren van dit type benadering kan echter ingewikkeld zijn en deze benadering kan duur zijn.
Belangrijk
Bedrijfskritieke workloads moeten gebruikmaken van zowel meerdere beschikbaarheidszones en als van meerdere regio's. Zie voor meer informatie over de overwegingen waarmee u rekening moet houden bij het ontwerpen van bedrijfsbelangrijke workloads, de Bedrijfskritieke workloaddocumentatie.
Hoe Azure-services implementatiemethoden ondersteunen
Het is belangrijk om inzicht te hebben in de specifieke details van de Azure-services die u gebruikt. Sommige Azure-services vereisen bijvoorbeeld dat u de configuratie van de beschikbaarheidszone configureert wanneer u de resource voor het eerst implementeert, terwijl andere later ondersteuning bieden voor het wijzigen van de implementatiebenadering. Op dezelfde manier zijn sommige servicefuncties mogelijk niet beschikbaar bij elke implementatiebenadering.
Ga naar de Betrouwbaarheidshubvoor meer informatie over de specifieke implementatieopties en benaderingen die u kunt overwegen voor elke Azure-service.
Voorbeelden
In deze sectie worden enkele veelvoorkomende use cases beschreven en de belangrijkste vereisten die u doorgaans moet overwegen voor elke workload. Voor elke workload worden een of meer voorgestelde implementatiemethoden verstrekt op basis van de vereisten en benaderingen die in dit artikel worden beschreven.
Bedrijfsspecifieke toepassing voor een onderneming
Contoso, Ltd., is een groot productiebedrijf. Het bedrijf implementeert een Line-Of-Business-toepassing om bepaalde onderdelen van de financiële processen te beheren.
Zakelijke vereisten: de informatie die het systeem beheert, is moeilijk te vervangen, zodat gegevens betrouwbaar moeten worden bewaard. De architecten zeggen dat het systeem zo weinig downtime en zo weinig mogelijk gegevensverlies moet veroorzaken. De werknemers van Contoso gebruiken het systeem gedurende de hele werkdag, dus hoge prestaties zijn belangrijk om te voorkomen dat teamleden wachten. Kosten zijn ook een probleem, omdat het financiële team moet betalen voor de oplossing.
voorgestelde benadering: zone-redundante implementatie met back-up tussen regio's biedt meerdere tolerantielagen met hoge prestaties.
Interne toepassing
Fourth Coffee is een klein bedrijf. Het bedrijf ontwikkelt een nieuwe interne toepassing waarmee werknemers urenstaten kunnen indienen.
Zakelijke vereisten: Voor deze workload is kostenefficiëntie een belangrijk probleem. Fourth Coffee heeft de bedrijfsimpact van downtime geëvalueerd en besloten dat de toepassing geen prioriteit hoeft te geven aan tolerantie of prestaties. Het bedrijf accepteert het risico dat een storing in een Azure-beschikbaarheidszone of -regio de toepassing tijdelijk niet beschikbaar maakt.
Voorgestelde benaderingen:
- lokaal redundante implementatie met back-ups in verschillende regio's de laagste kosten heeft, maar ook aanzienlijke risico's.
- Zone-redundante uitvoering met back-up tussen regio's biedt betere veerkracht, maar tegen iets hogere kosten.
Verouderde toepassingsmigratie
Fabrikam, Inc., migreert een verouderde toepassing van een on-premises datacenter naar Azure. De implementatie maakt gebruik van een IaaS-benadering die is gebaseerd op virtuele machines. De toepassing is niet ontworpen voor een cloudomgeving en de communicatie tussen de toepassingslaag en de database is zeer chatty.
Zakelijke vereisten: Prestaties is een prioriteit voor deze toepassing. Tolerantie is ook belangrijk en de toepassing moet blijven werken, zelfs als een Azure-datacenter een storing ondervindt.
voorgestelde benadering:
- Fabrikam moet eerst een zone-redundante implementatie proberen. Ze moeten controleren of de prestaties voldoen aan hun vereisten.
- Als de prestaties van de zone-redundante oplossing niet acceptabel zijn, kunt u een zonale (gebiedsgebonden) implementatie overwegen, met passieve implementaties over meerdere beschikbaarheidszones (regionale DR).
Gezondheidsapplicatie
Lamna Healthcare Company implementeert een nieuw elektronisch gezondheidsrecordsysteem in Azure.
Zakelijke vereisten: Vanwege de aard van de gegevens die in deze oplossing worden opgeslagen, is gegevenslocatie van cruciaal belang. Lamna werkt onder een strikt regelgevingskader dat verplicht stelt dat gegevens op een specifieke locatie moeten blijven.
Voorgestelde benaderingen:
- implementatie van meerdere zones, als er meerdere regio's zijn die voldoen aan de vereisten voor gegevenslocatie van Lamna.
- Als er slechts één regio is die aan hun behoeften voldoet, overweeg om een zone-redundante implementatie of een zone-redundante implementatie met een back-up over verschillende regio's die een oplossing voor een enkele regio biedt.
Banksysteem
Woodgrove Bank voert de belangrijkste bankactiviteiten uit vanuit een grote oplossing die in Azure wordt geïmplementeerd.
Bedrijfsvereisten: dit is een bedrijfskritiek systeem. Eventuele storingen kunnen grote financiële gevolgen voor klanten veroorzaken. Daardoor heeft Woodgrove Bank een zeer lage risicotolerantie. Het systeem heeft het hoogste betrouwbaarheidsniveau nodig en de architectuur moet het risico beperken van eventuele fouten die kunnen worden beperkt.
Voorgestelde benadering: voor een bedrijfskritiek systeem gebruikt u een implementatie met meerdere zones. Zorg ervoor dat de regio's voldoen aan de vereisten voor gegevenslocatie van het bedrijf.
Software as a Service (SaaS)
Proseware, Inc., bouwt software die wordt gebruikt door bedrijven over de hele wereld. Het gebruikersbestand van het bedrijf wordt geografisch breed verdeeld.
Zakelijke vereisten: Proseware moet elk van zijn klanten in staat stellen een implementatieregio te kiezen die zich dicht bij de klant bevindt. Het inschakelen van deze keuze is belangrijk voor latentie en voor de vereisten voor gegevenslocatie van klanten.
Voorgestelde benaderingen:
- Een implementatie met meerdere zones voor meerdere regio's is doorgaans een goede keuze voor een SaaS-provider, met name wanneer deze wordt gebruikt binnen het patroon implementatiestempels .
- Een implementatie met één regio zone-redundante implementatie in combinatie met een wereldwijde oplossing voor verkeersversnelling, zoals Azure Front Door-.
Verwante koppelingen
Hieronder volgen enkele referentiearchitecturen en voorbeeldscenario's voor oplossingen met meerdere zones en meerdere regio's:
- Basislijn maximaal beschikbare zone-redundante webtoepassing
- webtoepassing met hoge beschikbaarheid voor meerdere regio's
- toepassing met meerdere regio's
- webtoepassing met meerdere lagen die is gebouwd voor ha/dr-
Veel Azure-services bieden richtlijnen voor het gebruik van meerdere beschikbaarheidszones, waaronder de volgende voorbeelden:
- Azure Site Recovery: Azure-VM-noodherstel inschakelen tussen beschikbaarheidszones
- Azure NetApp Files: inzicht in replicatie tussen zones van Azure NetApp Files
- Azure Storage-redundantie
Controlelijst voor betrouwbaarheid
Raadpleeg de volledige set aanbevelingen.