Aanbevelingen voor het gebruik van beschikbaarheidszones en regio's
Is van toepassing op deze aanbeveling voor de controlelijst voor betrouwbaarheid van Azure Well-Architected Framework:
| RE:05 | Voeg redundantie toe op verschillende niveaus, met name voor kritieke stromen. Pas redundantie toe op de reken-, gegevens-, netwerk- en andere infrastructuurlagen in overeenstemming met de geïdentificeerde betrouwbaarheidsdoelen. |
|---|
Verwante handleidingen: Maximaal beschikbare multiregionale ontwerpredundantie |
In deze handleiding worden de aanbevelingen beschreven voor het bepalen wanneer workloads moeten worden geïmplementeerd in beschikbaarheidszones of regio's.
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 zakelijke vereisten 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 Goed ontworpen framework:
- Betrouwbaarheid: uw keuze voor 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 architectuurbenaderingen 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 zijn verbonden via een netwerkkoppeling met hoge bandbreedte en lage latentie, wat 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.
- Operationele uitmuntendheid: 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 Taakautomatisering, OE:10 Automation-ontwerp en OE:11-implementatieprocedures voor meer informatie.
De beveiligingspijler is echter van toepassing op uw oplossing. 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.
Tip
Voor veel productieworkloads biedt een zone-redundante implementatie de beste balans tussen compromissen. 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
| Termijn | 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 primair en verwerkt verkeer en een of meer secundaire exemplaren 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. |
| Availability zone | 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 worden 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 regioarchitecturen worden 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 beschikbaarheidszones bevat, 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:
- Zonegebonden resources worden vastgemaakt 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 resources zijn verspreid 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 beschikbaarheidszones voor meer informatie over de werking van Azure-services met beschikbaarheidszones.
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 indelingsmodus of de meeste Azure PaaS-services, plaatst Azure uw resources op intelligente wijze om de impact van platformupdates te verminderen. Daarnaast kunt u overwegen om de inrichting te overprovisioning , het implementeren van meer exemplaren van een resource, zodat sommige exemplaren beschikbaar blijven terwijl andere exemplaren worden bijgewerkt. Zie Geavanceerde veilige implementatieprocedures voor 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.
Zie Wat zijn Azure-regio's en beschikbaarheidszones voor meer informatie over hoe Azure regio's en beschikbaarheidszones gebruikt?
Inzicht in gedeelde verantwoordelijkheden
In het principe van gedeelde verantwoordelijkheid wordt beschreven 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 besturingssysteem.
Uw eigen code moet aanbevolen procedures en ontwerppatronen bieden voor het afhandelen van fouten. 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 | Likelihood |
|---|---|---|
| Hardwarestoring | Probleem met harde schijf- of netwerkapparatuur. Host wordt opnieuw opgestart. |
Hoog. Elke tolerantiestrategie moet rekening houden met deze risico's. |
| Storing in datacenter | 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. |
Beperkt |
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 De functionele en niet-functionele doelvereisten voor meer informatie.
Serviceniveaudoelstellingen
U moet inzicht hebben in de verwachte serviceniveaudoelstelling (SLO) van uw oplossing. U hebt bijvoorbeeld een bedrijfsvereiste die uw oplossing nodig heeft om te voldoen aan de uptime van 99,9%.
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 wettelijke 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 een punt hebben.
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-patroon gebruiken 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 van Azure Front Door.
Budget
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 complexer 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-facilitering
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-redundante of implementatie met meerdere regio's overwegen. In deze tabel vindt u een overzicht van enkele problemen met de pijlers:
| Pijler | Lokaal redundant | Zonegebonden (vastgemaakt) | Zone-redundant | 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 topprestaties | Lage operationele vereisten | 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 redundant | Zonegebonden (vastgemaakt) | Zone-redundant | Meerdere regio's |
|---|---|---|---|---|
| Naleving van gegevenslocatie | Hoog | Hoog | Hoog | Afhankelijk van regio |
| Regionale beschikbaarheid | Alle regio's | Regio's met beschikbaarheidszones | Regio's met beschikbaarheidszones | 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. Als er echter sprake is van een storing in een deel van de regio, is er een kans dat uw workload 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:
| Pijler | Impact |
|---|---|
| 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 aanpak biedt waarschijnlijk bevredigende prestaties. Voor zeer latentiegevoelige workloads: lage prestaties. Onderdelen bevinden zich niet gegarandeerd in dezelfde beschikbaarheidszone, dus u ziet mogelijk lagere prestaties voor zeer latentiegevoelige onderdelen. |
| Operationele topprestaties | 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 | Impact |
|---|---|
| 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:
| Pijler | Impact |
|---|---|
| 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. In een volledige regio-storing kunt u bewerkingen handmatig herstellen naar 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 aanpak biedt waarschijnlijk bevredigende prestaties. Voor zeer latentiegevoelige workloads: lage prestaties. Onderdelen bevinden zich niet gegarandeerd in dezelfde beschikbaarheidszone, dus u ziet mogelijk lagere prestaties voor zeer latentiegevoelige onderdelen. |
| Operationele topprestaties | Tijdens storingen binnen een regio: Lage operationele efficiëntie. Failover is uw verantwoordelijkheid en vereist mogelijk handmatige bewerkingen en herimplementaties. |
Deze tabel bevat een overzicht van enkele van de problemen vanuit een architectuurperspectief:
| Architectuurprobleem | Impact |
|---|---|
| Naleving van gegevenslocatie | 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 zone-vastgemaakte 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 benadering voor actief-passieve 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 is 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-regio DR of Metro DR genoemd.
In deze tabel vindt u een overzicht van enkele problemen met de pijlers:
| Pijler | Impact |
|---|---|
| Betrouwbaarheid | Wanneer deze wordt geïmplementeerd 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. Wanneer deze wordt geïmplementeerd in meerdere beschikbaarheidszones: hoge betrouwbaarheid. Services kunnen tolerant worden gemaakt voor een storing in een datacenter of beschikbaarheidszone. |
| Kostenoptimalisatie | Wanneer deze wordt geïmplementeerd in één beschikbaarheidszone: Lage kosten. Voor een implementatie met één zone is slechts één exemplaar van elke resource vereist. 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 topprestaties | 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 | Impact |
|---|---|
| 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 beschikbaarheidszones ondersteunt. |
Deze benadering wordt doorgaans gebruikt voor workloads die zijn gebaseerd op virtuele machines. Zie Beschikbaarheidszoneservice en regionale ondersteuning voor 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 van virtuele machines beschikbaar zijn in elke beschikbaarheidszone, raadpleegt u Beschikbaarheid van VM-SKU 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 beschikbaarheidszones voor 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 ondervindt, stuurt de load balancer verkeer naar exemplaren in de gezonde beschikbaarheidszones.
Uw opslaglaag is ook verspreid over meerdere beschikbaarheidszones. Kopieën van de gegevens van uw toepassing worden gedistribueerd 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-date kopie 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:
| Pijler | Impact |
|---|---|
| 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 aanpak biedt waarschijnlijk bevredigende prestaties. Voor zeer latentiegevoelige workloads: lage prestaties. Sommige onderdelen zijn mogelijk gevoelig voor latentie vanwege interzoneverkeer of tijd voor gegevensreplicatie. |
| Operationele topprestaties | 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 | Impact |
|---|---|
| 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 beschikbaarheidszones ondersteunt. |
Deze benadering 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 vele andere. Zie beschikbaarheidszoneservice en regionale ondersteuning voor 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:
| Pijler | Impact |
|---|---|
| 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 regio-storing kunt u bewerkingen 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 aanpak biedt waarschijnlijk bevredigende prestaties. Voor zeer latentiegevoelige workloads: lage prestaties. Sommige onderdelen zijn mogelijk gevoelig voor latentie vanwege interzoneverkeer of tijd voor gegevensreplicatie. |
| Operationele topprestaties | 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 vereist mogelijk handmatige bewerkingen en herimplementaties. |
Deze tabel bevat een overzicht van enkele van de problemen vanuit een architectuurperspectief:
| Architectuurprobleem | Impact |
|---|---|
| Naleving van gegevenslocatie | 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 gegevenslocatievereisten. |
| Regionale beschikbaarheid | Regio's met beschikbaarheidszones. Deze methode is beschikbaar in elke regio die beschikbaarheidszones ondersteunt. |
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 Het patroon Implementatiestempels en geode-patroon voor informatie over actief-actieve oplossingen voor meerdere regio's.
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 de latentiestatistieken van het Azure-netwerk 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:
| Pijler | Impact |
|---|---|
| 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 topprestaties | 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 gegevenslocatie | 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 workload uitvoert in een regio die geen paar heeft, moet u mogelijk een andere benadering gebruiken om uw gegevens te 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:
| Pijler | Impact |
|---|---|
| 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 | Lage prestaties. Toepassingsaanvragen vereisen verkeer tussen regio's. Afhankelijk van de afstand tussen de regio's kan synchrone replicatie aanzienlijke latentie toevoegen aan aanvragen. |
| Operationele topprestaties | 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 gegevenslocatie | 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 workload uitvoert in een regio die geen paar heeft, moet u mogelijk een andere benadering gebruiken om uw gegevens te 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-objectreplicatie te 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 zowel meerdere beschikbaarheidszones als meerdere regio's gebruiken. Zie de bedrijfskritieke workloaddocumentatie voor meer informatie over de overwegingen die u moet geven bij het ontwerpen van bedrijfskritieke workloads.
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 Betrouwbaarheidshub voor 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.
Line-Of-Business-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.
Bedrijfsvereisten: 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 die werknemers kunnen gebruiken om roosters in te dienen.
Bedrijfsvereisten: Voor deze workload is kostenefficiëntie een belangrijk aandachtspunt. 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 heeft de laagste kosten, maar heeft ook aanzienlijke risico's .
- Zone-redundante implementatie met back-up in verschillende regio's biedt betere tolerantie, 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 erg druk.
Bedrijfsvereisten: Prestaties zijn 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:
- Fabrikan 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 zonegebonden (vastgemaakte) implementatie overwegen, met passieve implementaties in meerdere beschikbaarheidszones (herstel na noodgeval in de regio).
Gezondheidszorgtoepassing
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 met meerdere zones voor meerdere regio's, 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, kunt u overwegen een zone-redundante implementatie of een zone-redundante implementatie met back-up tussen regio's een oplossing met één regio te bieden
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 aanpak: Gebruik voor een bedrijfskritiek systeem een implementatie met meerdere zones voor meerdere regio's. Zorg ervoor dat de regio's voldoen aan de vereisten voor gegevenslocatie van het bedrijf.
Software als een dienst (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 zone-redundante implementatie met één regio 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:
- Maximaal beschikbare zone-redundante webtoepassing basislijn
- Maximaal beschikbare webtoepassing voor meerdere regio's
- Toepassing met meerdere regio's N-laag
- Webtoepassing met meerdere lagen die is gebouwd voor hoge beschikbaarheid/herstel na noodgeval
Veel Azure-services bieden richtlijnen voor het gebruik van meerdere beschikbaarheidszones, waaronder de volgende voorbeelden:
- Azure Site Recovery: Herstel na noodgevallen van Azure-VM 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.
Feedback
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie: https://aka.ms/ContentUserFeedback.
Feedback verzenden en weergeven voor