Aanbevelingen voor het gebruik van beschikbaarheidszones en -regio's
Is van toepassing op deze aanbeveling voor de betrouwbaarheidschecklist van Azure Well-Architected Framework:
| RE:05 | Voeg redundantie toe op verschillende niveaus, met name voor kritieke stromen. Redundantie toepassen op de reken-, gegevens-, netwerk- en andere infrastructuurlagen in overeenstemming met de geïdentificeerde betrouwbaarheidsdoelen. |
|---|
Gerelateerde handleidingen:Maximaal beschikbare multiregionaleontwerpredundantie |
In deze handleiding worden de aanbevelingen beschreven voor het bepalen wanneer workloads in beschikbaarheidszones of -regio's moeten worden geïmplementeerd.
Wanneer u een oplossing voor Azure ontwerpt, moet u beslissen of u in meerdere beschikbaarheidszones in een regio of in meerdere regio's implementeert. Deze beslissing is van invloed op de betrouwbaarheid, kosten en prestaties van uw oplossing, en op het vermogen 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 compromissen die bij elke benadering zijn betrokken 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 meerdere geografische regio's kunt selecteren en gebruiken. Uw keuze voor het gebruik van regio's en beschikbaarheidszones binnen uw oplossing is ook van invloed op een aantal van de pijlers van het Well-Architected Framework:
- Betrouwbaarheid: Uw gekozen implementatiebenadering kan u helpen om verschillende soorten risico's te beperken. Over het algemeen kunt u een hogere tolerantie bereiken door uw workload te spreiden over een geografisch verdeeld gebied.
- Kostenoptimalisatie: voor sommige architectuurbenaderingen moet u meer resources implementeren dan andere, waardoor uw resourcekosten kunnen toenemen. Andere benaderingen omvatten het verzenden van gegevens naar geografisch gescheiden beschikbaarheidszones of regio's, waarvoor mogelijk netwerkverkeerskosten in rekening kunnen worden gebracht. Het is ook belangrijk om rekening te houden met de doorlopende kosten voor het beheren van uw resources, die meestal hoger zijn wanneer u uitgebreide bedrijfsvereisten hebt.
- Prestatie-efficiëntie: Beschikbaarheidszones zijn met elkaar verbonden via een netwerkkoppeling met hoge bandbreedte en lage latentie, wat voldoende is voor de meeste workloads 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 fysiek dicht bij elkaar te plaatsen om de 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 plannen hoe u een failover uitvoert naar een secundaire set resources. 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 handleidingen voor operationele uitmuntendheid voor meer informatie, waaronder OE:05 Infrastructuur als code, OE:09 Taakautomatisering, OE:10 Automation-ontwerp en OE:11-implementatieprocedures.
Hoe u uw oplossing ook ontwerpt, de pijler Beveiliging is van toepassing. Beslissingen over of en hoe u beschikbaarheidszones en -regio's gebruikt, hebben meestal geen verandering in uw beveiligingspostuur. Azure past dezelfde beveiligingsproblemen 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 benadering u moet selecteren, begint u met dit type implementatie.
Overweeg andere werkbelastingmethoden wanneer u de specifieke voordelen van deze benaderingen nodig hebt, maar houd rekening met de compromissen die hiermee gepaard gaan.
Definities
| Termijn | Definitie |
|---|---|
| Actief-actief | Een architectuur waarin meerdere exemplaren van een oplossing aanvragen tegelijkertijd actief verwerken. |
| Actief-passief | Een architectuur waarin één exemplaar van een oplossing is aangewezen als de primaire oplossing 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 waarbij gegevens naar één locatie worden geschreven en doorgevoerd. 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 wordt geïmplementeerd in één regio zonder verwijzing 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. |
| Region | 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 doorgevoerd op meerdere locaties. Elke locatie moet bevestigen dat de schrijfbewerking is voltooid voordat de algehele schrijfbewerking als voltooid wordt beschouwd. |
| Zonegebonden implementatie (vastgemaakt) | 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, distributie van verkeer 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 te hebben met andere beschikbaarheidszones, maar ze zijn ver genoeg uit elkaar om de kans te verkleinen dat meer dan één wordt beïnvloed door lokale storingen of weersomstandigheden. Beschikbaarheidszones hebben een onafhankelijke energie-, koelings- en netwerkinfrastructuur. Ze zijn zo 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 tegelijk gebruiken. Door meerdere beschikbaarheidszones te gebruiken, kunt u afzonderlijke kopieën van uw toepassing en gegevens bewaren in afzonderlijke fysieke datacenters in een groot stedelijk 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 over zones en de replicatie van gegevens tussen zones. Als er een storing optreedt in één beschikbaarheidszone, beheert Microsoft de failover automatisch.
Azure-services ondersteunen een of beide van deze benaderingen. 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 hoe Azure-services werken met beschikbaarheidszones.
Wanneer Microsoft updates voor services implementeert, proberen we benaderingen te gebruiken die het minst storend voor u zijn. We willen bijvoorbeeld updates implementeren in één beschikbaarheidszone tegelijk. Deze aanpak kan de impact van updates op een actieve workload verminderen, omdat de workload in andere zones kan blijven worden uitgevoerd terwijl de update wordt uitgevoerd. Uiteindelijk is het echter de verantwoordelijkheid van het workloadteam om ervoor te zorgen dat hun workload blijft functioneren tijdens platformupgrades. Wanneer u bijvoorbeeld virtuele-machineschaalsets met de flexibele indelingsmodus of de meeste Azure PaaS-services gebruikt, plaatst Azure uw resources op intelligente wijze om de impact van platformupdates te verminderen. Daarnaast kunt u overwegen om meer exemplaren van een resource te implementeren, 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 geen gekoppelde regio. U kunt nog steeds oplossingen voor meerdere regio's implementeren in deze regio's, maar de methoden die u gebruikt, kunnen verschillen.
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, kunt u meer of minder verantwoordelijkheid nemen voor het uitvoeren van de service.
Microsoft biedt beschikbaarheidszones en -regio's om u flexibiliteit te bieden in de wijze waarop u uw oplossing ontwerpt om aan uw vereisten te voldoen. Wanneer u beheerde services gebruikt, neemt Microsoft meer van de beheerverantwoordelijkheden voor uw resources op zich, waaronder mogelijk zelfs gegevensreplicatie, failover, failback en andere taken met betrekking tot het beheren van een gedistribueerd systeem.
Uw eigen code moet aanbevolen procedures en ontwerppatronen voor het probleemloos afhandelen van fouten. Deze procedures zijn nog belangrijker tijdens failoverbewerkingen, zoals de procedures die plaatsvinden wanneer een failover van een beschikbaarheidszone of regio plaatsvindt, omdat failover tussen zones of regio's meestal vereist dat uw toepassing verbindingen met services opnieuw probeert.
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 niveaus 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 zich waarschijnlijk niet voordoen, zoals grote natuurrampen die een breed geografisch gebied treffen.
Deze tabel bevat een aantal veelvoorkomende risico's waarmee u rekening moet houden in een cloudomgeving:
| Risico | Voorbeelden | Likelihood |
|---|---|---|
| Hardwarestoring | Probleem met harde schijf of netwerkapparatuur. De host wordt opnieuw opgestart. |
Hoog. Elke tolerantiestrategie moet rekening houden met deze risico's. |
| Datacentrumstoring | Stroom-, koelings- of netwerkstoringen in een heel datacenter. Natuurramp in een deel van een grootstedelijk gebied. |
Normaal |
| Regio-uitval | Een grote natuurramp die een breed geografisch gebied treft. 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 gebeurtenissen met een lage kans verminderen. Voor andere workloads moet u een weloverwogen beslissing nemen over welke risico's u bereid bent te accepteren en welke u moet beperken.
Tolerantievereisten
Het is belangrijk om inzicht te hebben in de tolerantievereisten voor uw workload, waaronder 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 de aanpak die u moet volgen. Zie Functionele en niet-functionele vereisten targeten voor meer informatie.
Serviceniveaudoelstellingen
U moet de verwachte SLO (Service Level Objective) van uw oplossing voor uptime begrijpen. U hebt bijvoorbeeld een bedrijfsvereiste dat uw oplossing moet voldoen aan een uptime van 99,9%.
Azure biedt serviceovereenkomsten (SLA's) voor elke service. Een SLA geeft het uptime-niveau aan dat u van de service moet verwachten 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 de beschikbaarheid van de service aangeeft, 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. Over het algemeen geldt dat hoe meer redundantie u in uw oplossing inbouwt, hoe hoger uw SLO waarschijnlijk is. Veel Azure-services bieden hogere SLA's wanneer u services implementeert in een zone-redundante configuratie of configuratie voor 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.
Gegevenslocatie
Sommige organisaties stellen 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 aan te nemen om klantproblemen te voorkomen. Als u strikte vereisten voor gegevenslocatie hebt, moet u mogelijk een implementatie van één regio gebruiken of een subset van Azure-regio's en -services gebruiken.
Notitie
Vermijd ongegronde veronderstellingen over uw vereisten voor gegevenslocatie. Als u moet voldoen aan specifieke regelgevingsnormen, controleert u wat deze standaarden daadwerkelijk specificeren.
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 voor de ondersteuning van een geografisch verspreide gebruikersgroep.
Als uw gebruikers zich op één gebied concentreren, 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 voor meerdere regio's gebruiken, zelfs als uw gebruikers een locatie 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 gebruikersbestand te brengen. U kunt het patroon Implementatiestempels of Geodes gebruiken, of uw resources repliceren tussen 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 onder een beperkt budget werkt, is het belangrijk om rekening te houden met de kosten voor het implementeren van redundante workloadonderdelen. Deze kosten kunnen bestaan uit extra resourcekosten, netwerkkosten en de operationele kosten voor het beheren van meer resources en een complexere omgeving.
Complexiteit
Het is een goede gewoonte om onnodige complexiteit in uw oplossingsarchitectuur te voorkomen. Hoe complexer u maakt, hoe moeilijker het wordt om beslissingen te nemen over uw architectuur. Complexe architecturen zijn moeilijker te gebruiken, 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 bij uw behoeften past. Er zijn veel benaderingen waaruit u kunt kiezen, die allemaal voordelen en kosten met zich meebrengen.
Bekijk een voorbeeldscenario om de implementatiemethoden te illustreren die u kunt gebruiken. Stel dat u overweegt om een nieuwe oplossing te implementeren die een toepassing bevat waarmee gegevens naar een bepaald soort opslag worden geschreven:
Dit voorbeeld is niet specifiek voor bepaalde Azure-services. Het is bedoeld als een eenvoudig voorbeeld voor het illustreren van basisconcepten.
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 aandachtspunten:
| Pijler | Lokaal redundant | Zonegebonden (vastgemaakt) | Zone-redundant | Meerdere regio's |
|---|---|---|---|---|
| Betrouwbaarheid | Lage betrouwbaarheid | Is afhankelijk van de aanpak | Hoge of zeer hoge betrouwbaarheid | Hoge of zeer hoge betrouwbaarheid |
| Kostenoptimalisatie | Lage kosten | Is afhankelijk van de aanpak | Gemiddelde kosten | Hoge kosten |
| Prestatie-efficiëntie | Acceptabele prestaties (voor de meeste workloads) | Hoge prestaties | Acceptabele prestaties (voor de meeste workloads) | Is afhankelijk van de aanpak |
| Operationele topprestaties | Lage operationele vereisten | Hoge operationele vereisten | Lage operationele vereisten | Hoge operationele vereisten |
In deze tabel vindt u een overzicht van enkele benaderingen die u kunt gebruiken en hoe deze van invloed zijn op uw architectuur:
| Architecturale zorg | 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 ervoor kiezen 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, geeft Azure geen garanties over of de resources worden geïmplementeerd in één datacenter of worden gesplitst over 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 het oogpunt van betrouwbaarheid is er echter een kans dat uw workload wordt beïnvloed als een deel van de regio een storing ondervindt. Als dat zo is, is uw oplossing mogelijk niet beschikbaar of gaan uw gegevens verloren.
Voor zeer latentiegevoelige workloads kan deze aanpak ook leiden tot lagere prestaties. Uw workloadonderdelen bevinden zich mogelijk niet in hetzelfde datacenter, dus u kunt enige latentie zien voor verkeer binnen regio's. 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 aandachtspunten:
| 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 soorten fouten. |
| Kostenoptimalisatie | Laagste kosten. U hoeft slechts één exemplaar van elke resource te hebben en u maakt geen kosten voor bandbreedte tussen zones of regio's. |
| Prestatie-efficiëntie | Voor de meeste workloads:acceptabele prestaties. Deze aanpak levert waarschijnlijk bevredigende prestaties op. Voor zeer latentiegevoelige workloads:Lage prestaties. Onderdelen bevinden zich niet gegarandeerd in dezelfde beschikbaarheidszone, dus mogelijk ziet u 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 problemen vanuit een architecturaal perspectief:
| Architecturale zorg | 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 aanpak kan worden gebruikt in elke Azure-regio. |
Lokaal redundante implementaties met back-up tussen regio's
U kunt een lokaal redundante implementatie uitbreiden door regelmatig back-ups van uw infrastructuur en gegevens uit te voeren naar een secundaire regio. Deze aanpak voegt een extra beveiligingslaag toe om een storing in uw primaire regio te verhelpen. 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 groot noodgeval voordoet. Zorg ervoor dat uw implementatiehulpprogramma's en -processen net zo flexibel 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: uw back-upfrequentie bepaalt de hoeveelheid gegevensverlies die u mogelijk ondervindt (uw herstelpunt). Meestal kunt u de frequentie van back-ups beheren, zodat u aan uw RPO kunt voldoen.
In deze tabel vindt u een overzicht van enkele aandachtspunten:
| 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 regio-storing wordt verminderd door gegevensverlies tot een minimum te beperken. In een volledige regio-storing kunt u bewerkingen handmatig herstellen in een andere regio. Herstelprocessen kunnen echter complex zijn en het kan even duren om handmatig te herstellen naar de andere regio. |
| Kostenoptimalisatie | Lage kosten. Normaal gesproken 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 levert waarschijnlijk bevredigende prestaties op. Voor zeer latentiegevoelige workloads:Lage prestaties. Onderdelen bevinden zich niet gegarandeerd in dezelfde beschikbaarheidszone, dus mogelijk ziet u lagere prestaties voor zeer latentiegevoelige onderdelen. |
| Operationele topprestaties | Tijdens een storing 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 problemen vanuit een architectonisch perspectief:
| Architectuurprobleem | Impact |
|---|---|
| Naleving van gegevenslocatie | Is afhankelijk van de 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. Het is dus belangrijk dat u een regio selecteert die compatibel is met uw vereisten voor gegevenslocatie. |
| Regionale beschikbaarheid | Hoog. U kunt deze methode in elke Azure-regio gebruiken. |
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. Het verhoogt echter op zichzelf de tolerantie van uw oplossing niet. 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 wilt routeren. In dit voorbeeld ziet u een benadering van 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 routert tussen exemplaren in verschillende beschikbaarheidszones, omdat een zone-onderbreking 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:
- U moet resources implementeren in elke beschikbaarheidszone en deze resources afzonderlijk configureren en beheren.
- U moet bepalen hoe en wanneer u gegevens repliceert tussen de beschikbaarheidszones en vervolgens de replicatie configureren en beheren.
- 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 distributiemodel voor actief-passief of een actief-actief-aanvraagdistributiemodel wilt gebruiken.
- Als een beschikbaarheidszone een storing ondervindt, moet u de failover afhandelen om verkeer te verzenden naar resources in een andere beschikbaarheidszone.
Een actief-passieve implementatie in meerdere beschikbaarheidszones wordt ook wel in-region DR of Metro DR genoemd.
Deze tabel bevat een overzicht van enkele aandachtspunten op de pijler:
| Pijler | Impact |
|---|---|
| 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 een hoge tolerantie te bereiken. Bij implementatie in meerdere beschikbaarheidszones:hoge betrouwbaarheid. Services kunnen tolerant worden gemaakt voor uitval van een datacentrum of beschikbaarheidszone. |
| Kostenoptimalisatie | Bij implementatie 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. U moet ook betalen voor verkeer tussen zones voor gegevensreplicatie. |
| Prestatie-efficiëntie | Hoge prestaties. Latentie kan erg 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 repliceren tussen beschikbaarheidszones. Tijdens een storing in de beschikbaarheidszone is failover uw verantwoordelijkheid. |
Deze tabel bevat een overzicht van enkele problemen vanuit een architectonisch perspectief:
| Architectuurprobleem | Impact |
|---|---|
| Naleving van gegevenslocatie | Hoog. Wanneer u een oplossing implementeert die gebruikmaakt van deze methode, worden gegevens opgeslagen in de Azure-regio die u selecteert. |
| Regionale beschikbaarheid | Regio's met beschikbaarheidszones. Deze benadering is beschikbaar in elke regio die ondersteuning biedt voor beschikbaarheidszones. |
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 ondersteuning bieden voor zonegebonden implementaties.
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's controleren.
Tip
Wanneer u een resource implementeert in een specifieke beschikbaarheidszone, 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 methode gebruikt, is 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 om naar exemplaren in de gezonde beschikbaarheidszones.
Uw opslaglaag is ook verdeeld over meerdere beschikbaarheidszones. Kopieën van de gegevens van uw toepassing worden verdeeld over meerdere beschikbaarheidszones via synchrone replicatie. Wanneer de toepassing een wijziging aanbrengt in gegevens, 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 voor toegang tot dezelfde gegevens.
Een zone-redundante benadering verhoogt de tolerantie van uw oplossing voor problemen zoals storingen in datacenters. Omdat gegevens synchroon worden gerepliceerd, moet uw toepassing echter wachten tot de gegevens zijn geschreven over meerdere afzonderlijke locaties die zich mogelijk in verschillende delen van een grootstedelijk gebied bevinden. Voor de meeste toepassingen is de latentie bij communicatie tussen zones verwaarloosbaar. Voor sommige zeer latentiegevoelige workloads kan synchrone replicatie tussen beschikbaarheidszones echter van invloed zijn op de prestaties van de toepassing.
Deze tabel bevat een overzicht van enkele aandachtspunten op de pijler:
| Pijler | Impact |
|---|---|
| Betrouwbaarheid | Hoge betrouwbaarheid. Services zijn bestand tegen uitval van een datacenter of beschikbaarheidszone. Gegevens worden synchroon gerepliceerd tussen 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, of sommige netwerkkosten tussen zones. |
| Prestatie-efficiëntie | Voor de meeste workloads:acceptabele prestaties. Deze aanpak levert waarschijnlijk bevredigende prestaties op. Voor zeer latentiegevoelige workloads:Lage prestaties. Sommige onderdelen zijn mogelijk gevoelig voor latentie vanwege verkeer tussen zones of gegevensreplicatietijd. |
| Operationele topprestaties | Hoge operationele efficiëntie. Doorgaans hoeft u slechts één logisch exemplaar van elke resource te beheren. Voor de meeste services is failover tijdens een storing in de beschikbaarheidszone de verantwoordelijkheid van Microsoft en vindt deze automatisch plaats. |
Deze tabel bevat een overzicht van enkele problemen vanuit een architectonisch perspectief:
| Architectuurprobleem | Impact |
|---|---|
| Naleving van gegevenslocatie | Hoog. Wanneer u een oplossing implementeert die gebruikmaakt van deze methode, worden gegevens opgeslagen in de Azure-regio die u selecteert. |
| Regionale beschikbaarheid | Regio's met beschikbaarheidszones. Deze benadering is beschikbaar in elke regio die ondersteuning biedt voor beschikbaarheidszones. |
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 nog veel meer. 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 regelmatig 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 uiterst onwaarschijnlijke geval van een volledige regio-storing te beperken.
Wanneer u deze aanpak implementeert, moet u zorgvuldig nadenken over 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, zodat u tijdens een groot noodgeval snel opnieuw kunt implementeren in een andere regio. 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 weer te herstellen naar een werkende status.
Herstelpunt: uw 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 goede balans voor alle architecturale kwesties. Als u niet zeker weet welke benadering u moet gebruiken, begint u met dit type implementatie.
Deze tabel bevat een overzicht van enkele aandachtspunten op de pijler:
| Pijler | Impact |
|---|---|
| Betrouwbaarheid | Zeer hoge betrouwbaarheid. Services zijn bestand tegen uitval van een datacenter of beschikbaarheidszone. Voor de meeste services worden gegevens automatisch en zonder vertraging gerepliceerd tussen 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 naar een andere regio. Herstelprocessen kunnen echter complex zijn en het kan even 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 levert waarschijnlijk bevredigende prestaties op. Voor zeer latentiegevoelige workloads:Lage prestaties. Sommige onderdelen zijn mogelijk gevoelig voor latentie vanwege verkeer tussen zones of gegevensreplicatietijd. |
| Operationele topprestaties | Tijdens een storing in de beschikbaarheidszone:hoge operationele efficiëntie. Failover is de verantwoordelijkheid van Microsoft en vindt automatisch plaats. 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 problemen vanuit een architectonisch perspectief:
| Architectuurprobleem | Impact |
|---|---|
| Naleving van gegevenslocatie | Is afhankelijk van de 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 benadering 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 te verdelen over een breed geografisch gebied. U kunt deze benadering voor meerdere regio's gebruiken om de betrouwbaarheid van uw oplossing te verbeteren of om geografisch gedistribueerde gebruikers te ondersteunen. Door in meerdere regio's te implementeren, verkleint u ook het risico dat u een tijdelijke beperking van de 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 voor meerdere regio's zijn complex en er zijn veel manieren om een oplossing voor meerdere regio's te ontwerpen. Voor sommige workloads is het zinvol om meerdere regio's tegelijkertijd aanvragen te laten verwerken (actief-actief-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 (actief-passieve implementaties). Deze sectie is gericht op het tweede scenario, waarin de ene regio actief is en de andere passief is. Zie Implementatiestempelpatroon en Geode-patroon voor meer informatie over actief-actief-oplossingen voor meerdere regio's.
Gegevensreplicatie
Communiceren tussen regio's is veel langzamer dan communicatie binnen een regio. Over het algemeen zorgt een grotere geografische afstand tussen twee regio's voor meer netwerklatentie vanwege de langere fysieke afstand die gegevens moeten afleggen. Zie Azure-netwerk-retourlatentiestatistieken voor de verwachte netwerklatentie wanneer u verbinding maakt tussen twee regio's.
Netwerklatentie tussen regio's kan een aanzienlijke invloed hebben op het ontwerp van uw oplossing, omdat u zorgvuldig moet overwegen hoe de extra latentie van invloed is op gegevensreplicatie en andere transacties. Voor veel oplossingen vereist een architectuur voor meerdere regio's asynchrone replicatie om het effect van regiooverschrijdend verkeer op de prestaties te minimaliseren.
Asynchrone gegevensreplicatie
Wanneer u asynchrone replicatie tussen regio's implementeert, wacht uw toepassing niet totdat alle regio's een wijziging bevestigen. Nadat de wijziging is doorgevoerd in de primaire regio, wordt de transactie als voltooid beschouwd. De wijziging wordt op een later tijdstip gerepliceerd naar de secundaire regio's. Deze benadering zorgt ervoor dat verbindingslatentie tussen regio's niet rechtstreeks van invloed is op de prestaties van de toepassing. Vanwege de vertraging in de replicatie kan een storing in de hele regio 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.
Deze tabel bevat een overzicht van enkele aandachtspunten op de pijler:
| Pijler | Impact |
|---|---|
| Betrouwbaarheid | Hoge betrouwbaarheid. De oplossing is bestand tegen storingen in een datacenter, een beschikbaarheidszone of een hele regio. Gegevens worden gerepliceerd, maar zijn mogelijk niet synchroon, dus er is mogelijk gegevensverlies 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. Gegevensreplicatie tussen regio's kan ook aanzienlijke kosten met zich meebrengen. |
| Prestatie-efficiëntie | Hoge prestaties. Voor toepassingsaanvragen is geen verkeer tussen regio's vereist, waardoor verkeer meestal een lage latentie heeft. |
| 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 problemen vanuit een architectonisch perspectief:
| Architectuurprobleem | Impact |
|---|---|
| Naleving van gegevenslocatie | Is afhankelijk van de 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 de schrijfbewerkingen in elke Azure-regio zijn voltooid voordat de transactie als voltooid wordt beschouwd. De latentie die wordt veroorzaakt door het wachten op schrijfbewerkingen, is afhankelijk van de afstand tussen de regio's. Voor veel workloads kan latentie tussen regio's ervoor zorgen dat synchrone replicatie te traag is om nuttig te zijn.
Deze tabel bevat een overzicht van enkele aandachtspunten op de pijler:
| Pijler | Impact |
|---|---|
| Betrouwbaarheid | Zeer hoge betrouwbaarheid. De oplossing is bestand tegen storingen in een datacenter, een beschikbaarheidszone of een hele regio. Gegevens zijn 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. Gegevensreplicatie tussen regio's kan ook aanzienlijke kosten met zich meebrengen. |
| Prestatie-efficiëntie | Lage prestaties. Voor toepassingsaanvragen is regiooverschrijdend verkeer vereist. 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 problemen vanuit een architectonisch perspectief:
| Architectuurprobleem | Impact |
|---|---|
| Naleving van gegevenslocatie | Is afhankelijk van de 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 als de regio's niet zijn gekoppeld. De benaderingen die u gebruikt om een architectuur voor 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 functies zoals Azure Storage-objectreplicatie gebruiken of uw toepassing ontwerpen om naar meerdere regio's te schrijven.
Benaderingen voor meerdere zones en meerdere regio's combineren
U moet instructies voor meerdere zones en regio's combineren als uw bedrijfsvereisten een dergelijke oplossing vragen. U kunt bijvoorbeeld zone-redundante onderdelen in elke regio implementeren en ook replicatie tussen de regio's configureren. Voor sommige oplossingen biedt deze benadering een zeer hoge mate van betrouwbaarheid. Het configureren van dit type benadering kan echter ingewikkeld zijn en deze aanpak kan duur zijn.
Belangrijk
Bedrijfskritieke workloads moeten zowel meerdere beschikbaarheidszones als meerdere regio's gebruiken. Zie 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 dat u de specifieke details begrijpt 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 de implementatiebenadering later ondersteunen. Op dezelfde manier zijn sommige servicefuncties mogelijk niet beschikbaar bij elke implementatiebenadering.
Ga naar de Reliability Hub voor meer informatie over de specifieke implementatieopties en benaderingen die u kunt overwegen voor elke Azure-service.
Voorbeelden
In deze sectie worden enkele veelvoorkomende gebruiksvoorbeelden en de belangrijkste vereisten beschreven waarmee u doorgaans rekening moet houden voor elke workload. Voor elke workload worden een of meer voorgestelde implementatiemethoden aangeboden, 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 sommige onderdelen van de financiële processen te beheren.
Bedrijfsvereisten: de informatie die door het systeem wordt beheerd, is moeilijk te vervangen, dus gegevens moeten betrouwbaar worden bewaard. De architecten zeggen dat het systeem zo weinig mogelijk downtime en zo weinig mogelijk gegevensverlies moet hebben. 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 aanpak: 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 van de belangrijkste aandachtspunten. 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 een 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 zeer spraakmakend.
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 aanpak:
- 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 systeem voor elektronische patiëntendossiers in Azure.
Zakelijke vereisten: vanwege de aard van de gegevens die in deze oplossing worden opgeslagen, is gegevenslocatie van cruciaal belang. Lamna werkt volgens een strikt regelgevend kader dat bepaalt dat gegevens op een specifieke locatie moeten blijven.
Voorgestelde benaderingen:
- Implementatie in meerdere zones in 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 een zone-redundante implementatie of een zone-redundante implementatie met back-up tussen regio's overwegen om een oplossing voor één regio te bieden
Banksysteem
Woodgrove Bank voert de belangrijkste bankactiviteiten uit vanuit een grote oplossing die is geïmplementeerd in Azure.
Bedrijfsvereisten: dit is een bedrijfskritiek systeem. Eventuele storingen kunnen grote financiële gevolgen hebben voor klanten. Als gevolg hiervan heeft Woodgrove Bank een zeer lage risicotolerantie. Het systeem heeft het hoogst mogelijke betrouwbaarheidsniveau nodig en de architectuur moet het risico op fouten beperken die kunnen worden beperkt.
Voorgestelde aanpak: gebruik voor een bedrijfskritiek systeem een implementatie met meerdere zones in 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 is geografisch wijd verspreid.
Zakelijke vereisten: Proseware moet elke klant in staat stellen om een implementatieregio te kiezen die dicht bij de klant ligt. Het inschakelen van deze keuze is belangrijk voor latentie en voor de vereisten voor de gegevenslocatie van klanten.
Voorgestelde benaderingen:
- Een implementatie met meerdere zones in 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 oplossing voor wereldwijde verkeersversnelling, zoals Azure Front Door.
Verwante koppelingen
Hieronder volgen enkele referentiearchitecturen en voorbeeldscenario's voor oplossingen voor meerdere zones en regio's:
- Maximaal beschikbare zone-redundante webtoepassing basislijn
- Maximaal beschikbare webtoepassing voor meerdere regio's
- Een N-tier-toepassing in meerdere regio's
- Webtoepassing met meerdere lagen, ontworpen voor HA/DR
Veel Azure-services bieden richtlijnen voor het gebruik van meerdere beschikbaarheidszones, waaronder de volgende voorbeelden:
- Azure Site Recovery: herstel na noodgevallen van Azure-VM tussen beschikbaarheidszones inschakelen
- 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