Delen via

Betrouwbaarheid in virtuele machines

  • Artikel

Dit artikel bevat gedetailleerde informatie over regionale tolerantie van VM's met beschikbaarheidszones en herstel na noodgevallen in meerdere regio's en bedrijfscontinuïteit.

Ondersteuning voor beschikbaarheidszone

Beschikbaarheidszones zijn fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

Zie Wat zijn beschikbaarheidszones in Azure voor meer informatie over beschikbaarheidszones?

Virtuele machines ondersteunen beschikbaarheidszones met drie beschikbaarheidszones per ondersteunde Azure-regio en zijn ook zone-redundant en zonegebonden. Zie ondersteuning voor beschikbaarheidszones voor meer informatie. De klant is verantwoordelijk voor het configureren en migreren van hun virtuele machines voor beschikbaarheid.

Zie voor meer informatie over gereedheidsopties voor beschikbaarheidszones:

Vereisten

  • De SKU's van uw virtuele machine moeten beschikbaar zijn in de zones voor uw regio. Als u wilt controleren welke regio's beschikbaarheidszones ondersteunen, raadpleegt u de lijst met ondersteunde regio's.

  • Uw VM-SKU's moeten beschikbaar zijn in de zones in uw regio. Gebruik een van de volgende methoden om te controleren op beschikbaarheid van VM-SKU's:

SLA-verbeteringen

Omdat beschikbaarheidszones fysiek gescheiden zijn en afzonderlijke energiebron, netwerk en koeling bieden, nemen SLA's (serviceovereenkomsten) toe. Zie de SLA voor virtuele machines voor meer informatie.

Een resource maken waarvoor beschikbaarheidszones zijn ingeschakeld

Ga aan de slag door een virtuele machine (VM) te maken waarvoor de beschikbaarheidszone is ingeschakeld via de volgende implementatieopties hieronder:

Ondersteuning voor zonegebonden failover

U kunt virtuele machines instellen voor een failover naar een andere zone met behulp van de Site Recovery-service. Zie Site Recovery voor meer informatie.

Fouttolerantie

Virtuele machines kunnen een failover naar een andere server in een cluster uitvoeren, waarbij het besturingssysteem van de virtuele machine opnieuw wordt opgestart op de nieuwe server. Raadpleeg het failoverproces voor herstel na noodgevallen, het verzamelen van virtuele machines in herstelplanning en het uitvoeren van noodherstelanalyses om ervoor te zorgen dat de fouttolerantieoplossing is geslaagd.

Zie de siteherstelprocessen voor meer informatie.

Zone-down-ervaring

Tijdens een storing in de hele zone verwacht u een korte verslechtering van de prestaties totdat de self-healing van de virtuele machineservice de onderliggende capaciteit herverdeelt om zich aan te passen aan gezonde zones. Zelfherstel is niet afhankelijk van zoneherstel; Naar verwachting compenseert de door Microsoft beheerde service zelfherstelstatus voor een verloren zone, met behulp van capaciteit van andere zones.

U moet zich ook voorbereiden op de mogelijkheid dat er een storing optreedt in een hele regio. Als er een serviceonderbreking is voor een hele regio, zijn de lokaal redundante kopieën van uw gegevens tijdelijk niet beschikbaar. Als geo-replicatie is ingeschakeld, worden drie andere kopieën van uw Azure Storage-blobs en tabellen opgeslagen in een andere regio. Wanneer er sprake is van een volledige regionale storing of een noodgeval waarbij de primaire regio niet kan worden hersteld, wijst Azure alle DNS-vermeldingen opnieuw toe aan de geografisch gerepliceerde regio.

Voorbereiding en herstel van zonestoring

De volgende richtlijnen worden gegeven voor virtuele Azure-machines tijdens een serviceonderbreking van de hele regio waar uw azure-toepassing voor virtuele machines wordt geïmplementeerd:

Ontwerp met lage latentie

Cross Region (secundaire regio), Cross Subscription (preview) en Cross Zoneal (preview) zijn beschikbare opties om rekening mee te houden bij het ontwerpen van een virtuele-machineoplossing met lage latentie. Zie de ondersteunde herstelmethoden voor meer informatie over deze opties.

Belangrijk

Door geen zonebewuste implementatie uit te schakelen, moet u geen bescherming bieden tegen isolatie van onderliggende fouten. Het gebruik van SKU's die geen ondersteuning bieden voor beschikbaarheidszones of die zich afmelden voor de configuratie van beschikbaarheidszones, dwingt af op resources die niet voldoen aan de plaatsing en scheiding van zones (inclusief onderliggende afhankelijkheden van deze resources). Deze resources moeten niet worden verwacht om scenario's met zone-down te overleven. Oplossingen die gebruikmaken van dergelijke resources moeten een strategie voor herstel na noodgevallen definiëren en een herstel van de oplossing in een andere regio configureren.

Veilige implementatietechnieken

Wanneer u kiest voor isolatie van beschikbaarheidszones, moet u veilige implementatietechnieken gebruiken voor toepassingscode en toepassingsupgrades. Naast het configureren van Azure Site Recovery en het implementeren van een van de volgende veilige implementatietechnieken voor VM's:

Omdat Microsoft regelmatig geplande onderhoudsupdates uitvoert, kunnen er zeldzame gevallen zijn wanneer voor deze updates opnieuw moet worden opgestart van uw virtuele machine om de vereiste updates toe te passen op de onderliggende infrastructuur. Zie beschikbaarheidsoverwegingen tijdens gepland onderhoud voor meer informatie.

Voordat u de volgende set knooppunten in een andere zone bijwerken, moet u de volgende taken uitvoeren:

Migreren naar ondersteuning voor beschikbaarheidszones

Zie Virtual Machines en Virtual Machine Scale Sets migreren naar ondersteuning voor beschikbaarheidszones voor meer informatie over het migreren van een VM naar ondersteuning voor beschikbaarheidszones.

Herstel na noodgevallen en bedrijfscontinuïteit tussen regio's

Herstel na noodgevallen (DR) gaat over het herstellen van gebeurtenissen met een hoge impact, zoals natuurrampen of mislukte implementaties die downtime en gegevensverlies tot gevolg hebben. Ongeacht de oorzaak is de beste oplossing voor een noodgeval een goed gedefinieerd en getest DR-plan en een toepassingsontwerp dat actief dr ondersteunt. Zie aanbevelingen voor het ontwerpen van een strategie voor herstel na noodgevallen voordat u begint na te denken over het maken van uw plan voor herstel na noodgevallen.

Als het gaat om herstel na noodgevallen, gebruikt Microsoft het model voor gedeelde verantwoordelijkheid. In een model voor gedeelde verantwoordelijkheid zorgt Microsoft ervoor dat de basisinfrastructuur en platformservices beschikbaar zijn. Tegelijkertijd repliceren veel Azure-services niet automatisch gegevens of vallen ze terug van een mislukte regio om kruislings te repliceren naar een andere ingeschakelde regio. Voor deze services bent u verantwoordelijk voor het instellen van een plan voor herstel na noodgevallen dat geschikt is voor uw workload. De meeste services die worden uitgevoerd op PaaS-aanbiedingen (Platform as a Service) van Azure bieden functies en richtlijnen ter ondersteuning van herstel na noodgeval en u kunt servicespecifieke functies gebruiken om snel herstel te ondersteunen om uw DR-plan te ontwikkelen.

U kunt herstel tussen regio's gebruiken om Virtuele Azure-machines te herstellen via gekoppelde regio's. Met herstel tussen regio's kunt u alle Virtuele Azure-machines voor het geselecteerde herstelpunt herstellen als de back-up wordt uitgevoerd in de secundaire regio. Raadpleeg de tabelrijvermelding Meerdere regio's in onze herstelopties voor meer informatie over het herstellen van meerdere regio's.

Herstel na noodgevallen in geografie in meerdere regio's

In het geval van een serviceonderbreking in de hele regio werkt Microsoft zorgvuldig om de service van de virtuele machine te herstellen. U moet echter nog steeds vertrouwen op andere toepassingsspecifieke back-upstrategieën om het hoogste beschikbaarheidsniveau te bereiken. Zie de sectie over gegevensstrategieën voor herstel na noodgevallen voor meer informatie.

Detectie, melding en beheer van storingen

Hardware of fysieke infrastructuur voor de virtuele machine kan onverwacht mislukken. Onverwachte fouten kunnen lokale netwerkfouten, lokale schijffouten of andere storingen op rackniveau omvatten. Wanneer dit wordt gedetecteerd, migreert het Azure-platform uw virtuele machine automatisch (herstelt) naar een gezonde fysieke machine in hetzelfde datacenter. Tijdens deze procedure treedt downtime (opnieuw opstarten) op de virtuele machines op en in sommige gevallen gaat de tijdelijke schijf verloren. Het besturingssysteem en de gegevensschijven die zijn bijgevoegd, blijven altijd behouden.

Zie de richtlijnen voor herstel na noodgevallen voor meer informatie over serviceonderbrekingen van virtuele machines.

Herstel na noodgevallen en detectie van storingen instellen

Wanneer u herstel na noodgevallen instelt voor virtuele machines, begrijpt u wat Azure Site Recovery biedt. Schakel herstel na noodgevallen in voor virtuele machines met de onderstaande methoden:

Herstel na noodgevallen in geografie met één regio

Met het instellen van herstel na noodgevallen worden Virtuele Azure-machines continu gerepliceerd naar een andere doelregio. Als er een storing optreedt, kunt u een failover uitvoeren van VM's naar de secundaire regio en deze daar openen.

Wanneer u Virtuele Azure-machines repliceert met Behulp van Site Recovery, worden alle VM-schijven continu asynchroon gerepliceerd naar de doelregio. De herstelpunten worden om de paar minuten gemaakt, waardoor u in de volgorde van minuten een RPO (Recovery Point Objective) krijgt. U kunt noodherstelanalyses zo vaak uitvoeren als u wilt, zonder dat dit van invloed is op de productietoepassing of de doorlopende replicatie. Zie Een noodherstelanalyse uitvoeren naar Azure voor meer informatie.

Zie architectuuronderdelen en regiokoppeling van Azure-VM's voor meer informatie.

Tolerantie voor capaciteit en proactief herstel na noodgevallen

Microsoft en haar klanten werken onder het Model voor gedeelde verantwoordelijkheid. Gedeelde verantwoordelijkheid betekent dat u voor herstel na noodgeval (klantverantwoordelijke services) herstel na noodgeval moet aanpakken voor elke service die ze implementeren en beheren. Om ervoor te zorgen dat herstel proactief is, moet u altijd vooraf secundaire bestanden implementeren, omdat er geen garantie is voor capaciteit op het moment van impact voor degenen die de toewijzing niet vooraf hebben toegewezen.

Voor het implementeren van virtuele machines kunt u de flexibele indelingsmodus op virtuele-machineschaalsets gebruiken. Alle VM-grootten kunnen worden gebruikt met de flexibele indelingsmodus. Flexibele indelingsmodus biedt ook garanties voor hoge beschikbaarheid (maximaal 1000 VM's) door VM's over foutdomeinen binnen een regio of binnen een beschikbaarheidszone te spreiden.

Volgende stappen