Scenario's voor hoge beschikbaarheid en herstel na noodgevallen voor IaaS-apps

Azure Site Recovery
Azure Virtual Machines
Azure Disk Storage

In dit artikel vindt u een beslissingsstructuur en voorbeelden van hoge beschikbaarheid (HA) en herstel na noodgevallen (DR) bij het implementeren van IaaS-apps (Infrastructure-as-a-Service) voor meerdere lagen in Azure.

Architectuur

This diagram illustrates the high availability decision tree.

Werkstroom

Beschikbaarheidssets (ASs) bieden redundantie en beschikbaarheid binnen een datacenter door VM's over meerdere geïsoleerde hardwareknooppunten te distribueren. Een subset van VM's blijft actief tijdens geplande of ongeplande downtime, zodat de hele app beschikbaar en operationeel blijft.

Beschikbaarheidszones (AZ's) zijn unieke fysieke locaties die datacenters binnen een Azure-regio omvatten. Elke AZ heeft toegang tot een of meer datacenters met onafhankelijke voeding, koeling en netwerken, en elke Azure-regio met AZ-functionaliteit heeft minimaal drie afzonderlijke AZ's. De fysieke scheiding van AZ's binnen een regio beschermt geïmplementeerde VM's tegen een storing in het datacenter.

Het beslissingsstroomdiagram weerspiegelt het principe dat HA-apps zo mogelijk AZ's moeten gebruiken. Cross-zone en daarom biedt > hoge beschikbaarheid 99,99% SLA vanwege tolerantie voor datacenterfouten.

AS's en AZ's voor verschillende app-lagen zijn niet gegarandeerd binnen dezelfde datacenters. Als app-latentie een belangrijk probleem is, moet u services in één datacenter plaatsen met behulp van nabijheidsplaatsingsgroepen (PPG's) met AZ's en AS's.

Onderdelen

Alternatieven

  • Als alternatief voor regionale herstel na noodgevallen met behulp van Azure Site Recovery, kunt u, als de app systeemeigen gegevens kan repliceren, dr in meerdere regio's implementeren met hot/cold stand-byservers, zoals alleen een stretched cluster voor herstel na noodgeval. Dit alternatief is niet specifiek beschreven in de voorbeelden, maar kan worden toegevoegd aan een van de oplossingen. Houd er rekening mee dat replicatie tussen regio's asynchroon is en dat er gegevensverlies wordt verwacht.

    Als u uw eigen technologie voor gegevensreplicatie hebt, kunt u deze ook gebruiken om een secundaire zone in de regio te maken voor herstel na noodgevallen. Afhankelijk van de regio van uw workloads kan het ook mogelijk zijn om Azure Site Recovery te gebruiken om items te repliceren naar een alternatieve zone, kunt u de regionale beschikbaarheid controleren en meer lezen over deze functie op Enable Zone to Zone Disaster Recovery voor virtuele Azure-machines.

  • Hoge beschikbaarheid voor meerdere regio's is mogelijk, maar vereist een wereldwijde load balancer, zoals Front Door of Traffic Manager. Zie Een N-tier-toepassing uitvoeren in meerdere Azure-regio's voor hoge beschikbaarheid voor meer informatie.

Scenariodetails

Architectuur met meerdere lagen of n-lagen is gebruikelijk in traditionele on-premises apps, dus ze zijn een natuurlijke keuze voor het migreren van on-premises apps naar de cloud of bij het ontwikkelen van apps voor zowel on-premises als de cloud. Architecturen met N-lagen worden doorgaans geïmplementeerd als IaaS-apps die zijn onderverdeeld in logische lagen en fysieke lagen, met een bovenste web- of presentatielaag, een middelste bedrijfslaag en een gegevenslaag.

In een IaaS n-tier-app wordt elke laag uitgevoerd op een afzonderlijke set virtuele machines. De web- en bedrijfslagen zijn staatloos, wat betekent dat elke VIRTUELE machine in de laag elke aanvraag voor die laag kan verwerken. De gegevenslaag is een gerepliceerde database, objectopslag of bestandsopslag. Meerdere VM's in elke laag bieden tolerantie als één VM mislukt en load balancers verdelen aanvragen over de VM's.

U kunt lagen uitschalen door meer VM's toe te voegen aan de pools en virtuele-machineschaalsets te gebruiken om identieke VM's automatisch uit te schalen. Omdat u load balancers gebruikt, kunt u lagen uitschalen zonder dat dit van invloed is op de uptime van apps.

Als voor de SERVICE Level Agreement (SLA) voor een IaaS-app een beschikbaarheid van 99% is vereist>, kunt u VM's in beschikbaarheidssets, beschikbaarheidszones en nabijheidsplaatsingsgroepen plaatsen om hoge beschikbaarheid voor de app te configureren. De oplossingen voor hoge beschikbaarheid en herstel na noodgevallen die u kiest, zijn afhankelijk van de vereiste SLA, latentieoverwegingen en regionale noodherstelvereisten.

Potentiële gebruikscases

  • Migreer een n-tier-app van on-premises naar de cloud.
  • Implementeer een n-tier-app zowel on-premises als in de cloud.
  • Configureer hoge beschikbaarheid en herstel na noodgevallen voor een IaaS-app.

Deze oplossing kan worden gebruikt voor elke branche, met inbegrip van de volgende scenario's:

  • Toepassingen in de publieke sector
  • Banken (financiële sector)
  • Gezondheidszorg

Overwegingen

  • AZ's zijn niet beschikbaar in alle Azure-regio's.

  • Bepaal welke implementatieoptie u wilt gebruiken voordat u de oplossing bouwt. Hoewel het mogelijk is, is het niet eenvoudig om van de ene optie naar een andere na de implementatie over te stappen. U moet de VM's verwijderen en deze opnieuw maken van de onderliggende beheerde schijven. Dit is een betrokken proces.

  • Zorg ervoor dat u uw toepassing kunt toewijzen aan de geselecteerde oplossing. Veel app-laagtolerantiepatronen en -ontwerpen vallen buiten het bereik van deze beslissingsstructuur.

  • Drie scenario's kunnen ertoe leiden dat azure-VM opnieuw wordt opgestart: ongepland hardwareonderhoud, onverwachte downtime en gepland onderhoud. Zie Voor meer informatie over deze gebeurtenissen en aanbevolen procedures voor hoge beschikbaarheid om de impact ervan te verminderen, meer informatie over het opnieuw opstarten van vm's, onderhoud versus downtime.

Enkele VM's

Als voor een app geen beschikbaarheid van 99,9% is vereist > , hoeft u deze niet te configureren voor hoge beschikbaarheid en kunt u enkele VM's implementeren. U kunt virtuele-machineschaalsets gebruiken om identieke VM's automatisch uit te schalen. Implementeer enkele VM's zonder een zone op te geven, zodat ze in een regio worden gedistribueerd. Deze apps hebben een SLA van 99,9% als u Azure Premium SSD-schijven gebruikt.

Individuele VM's maken gebruik van de standaardfunctionaliteit voor het herstellen van services die is ingebouwd in alle Azure-datacenters. Voor voorspelbare fouten maakt deze functionaliteit doorgaans gebruik van livemigratie, maar tijdens onvoorspelbare gebeurtenissen kunnen VM's opnieuw worden opgestart of niet beschikbaar worden gemaakt.

Hoge beschikbaarheid

Als voor de app een SLA van > 99,9% is vereist, ontwerpt u de app voor hoge beschikbaarheid. Gebruik AZ's indien mogelijk, omdat ze datacenterfouttolerantie bieden. U kunt AS's gebruiken in plaats van AZ's, maar het gebruik van ASs vermindert de beschikbaarheid van 99,99% tot 99,95%, omdat AS's datacenterfouten niet kunnen tolereren.

AZ's zijn geschikt voor veel geclusterde app-scenario's, waaronder AlwaysOn SQL-clusters, met behulp van actief-actief, actief-passief of een combinatie van beide HA-niveaus op elke laag met snelle failover. Synchrone replicatie is mogelijk tussen dbms-knooppunten (Database Management System), vanwege de lage latentie van het zoneoverschrijdende netwerk. U kunt ook een stretched-clusterconfiguratie uitvoeren tussen zones, met een hogere latentie en ondersteuning voor asynchrone replicatie.

Als u een cluster-arbiter op basis van een VM wilt gebruiken, bijvoorbeeld een bestandssharewitness, plaatst u deze in de derde AZ om ervoor te zorgen dat quorum niet verloren gaat als er één zone uitvalt. U kunt ook een cloudwitness in een andere regio gebruiken.

Alle VM's in een AZ bevinden zich in één foutdomein (FD) en updatedomein (UD), wat betekent dat ze een gemeenschappelijke voedingsbron en netwerkswitch delen en allemaal tegelijkertijd opnieuw kunnen worden opgestart. Als u VM's in verschillende AZ's maakt, worden uw VM's effectief verdeeld over verschillende FD's en UD's, zodat ze niet allemaal mislukken of tegelijkertijd opnieuw worden opgestart. Als u redundante in-zone-VM's en cross-zone-VM's wilt hebben, moet u de in-zone-VM's in AS's in PPG's plaatsen om ervoor te zorgen dat ze niet allemaal tegelijk opnieuw worden opgestart. Zelfs voor VM-workloads met één exemplaar die momenteel niet redundant zijn, kunt u AS's in de PPG's nog steeds gebruiken om toekomstige groei en flexibiliteit mogelijk te maken.

Voor het implementeren van virtuele-machineschaalsets in AZ's kunt u overwegen de Orchestration-modus te gebruiken, momenteel in openbare preview, waarmee FD's en AZ's kunnen worden gecombineerd.

AZ's met in-zone PPG's bieden een van de laagste netwerklatenties in Azure en een SLA van ten minste 99,99% vanwege tolerantie voor meerdere datacenters. Gebruik waar mogelijk versneld netwerken op de VM's.

Deze oplossing kan een scenario opleveren waarin een service die wordt uitgevoerd op een VM in de ene zone, moet communiceren met een service in een andere zone. Er kan bijvoorbeeld een actief-actief-weblaag en een actief-passieve databaselaag tussen zones zijn. Sommige aanvragen worden door meerdere zones heen gekruist, waardoor latentie wordt geïntroduceerd. Hoewel latentie tussen zones nog steeds erg laag is, moet u, als u de laagst mogelijke latentie wilt garanderen, alle netwerkcommunicatie tussen app-lagen binnen een zone behouden.

Overwegingen voor latentie

Netwerklatentie is onder andere afhankelijk van de fysieke afstand tussen geïmplementeerde VM's. Als voor een app een zeer lage latentie tussen lagen is vereist, kunt u deze in één datacenter implementeren met behulp van een PPG met AS's voor elke laag. Gebruik indien mogelijk versneld netwerken op de VM's. Dit scenario maakt een van de laagste netwerklatenties in Azure mogelijk en een SLA van 99,95%.

U kunt de volgende hulpprogramma's gebruiken om beter inzicht te krijgen in latentievoorwaarden voor verschillende scenario's:

  • Als u de latentie tussen VM's wilt testen, raadpleegt u De netwerklatentie van de VM testen.
  • Gebruik de AvZone-Latency-Test om latentie tussen zones te testen. Met deze test kunt u bepalen welke logische zones de laagste latentie voor uw abonnement hebben.
  • Als u latentie tussen Azure-regio's wilt testen, gebruikt u http://www.azurespeed.com/. Dit hulpprogramma dat regelmatig wordt bijgewerkt, kan handig zijn bij het overwegen van asynchrone replicatie tussen regio's.

Herstel na noodgeval

Overwegingen voor herstel na noodgevallen zijn onder andere beschikbaarheid, de mogelijkheid van de app om in goede staat te blijven werken en duurzaamheid van gegevens, het bewaren van gegevens als er zich een noodgeval voordoet.

Hoge beschikbaarheidsfailover moet snel zijn, zonder gegevensverlies en heeft een zeer beperkt effect op de service. Een traditionele DR-failover kan daarentegen een langere gekoppelde RTO (Recovery Time Objective) en RPO (Recovery Point Objective) hebben, en is asynchroon, met mogelijk gegevensverlies.

U kunt profiteren van AZ's voor zowel HA als DR met behulp van een andere AZ voor uw DR-oplossing. Het gebruik van een andere AZ garandeert echter niet dat de datacenters in elke AZ zich fysiek ver van elkaar bevinden.

Met Azure Site Recovery kunt u VM's repliceren naar een andere Azure-regio voor regionaal herstel na noodgevallen en bedrijfscontinuïteit. U kunt Azure Site Recovery gebruiken om uw apps te herstellen in het geval van storingen in de bronregio of om periodieke noodherstelanalyses uit te voeren om ervoor te zorgen dat u voldoet aan de nalevingsvereisten.

Als uw app Ondersteuning biedt voor Azure Site Recovery, kunt u een regionale dr-oplossing bieden voor betere beveiliging, als de ernst van de app dit vereist. Cross-zone, cross-datacenter HA alleen kan echter voldoende beveiliging zijn, omdat als een app volledig bestand is tegen storingen in datacenters, er geen downtime of gegevensverlies zou moeten zijn.

Kostenoptimalisatie

Er zijn geen extra kosten verbonden aan VM's die zijn geïmplementeerd in AZ's. Er zijn mogelijk extra kosten voor gegevensoverdracht tussen AZ VM-naar-VM's. Zie de pagina bandbreedteprijzen voor meer informatie.

Bijdragers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

Volgende stappen