Delen via

Meer informatie over het opnieuw opstarten van een systeem voor Azure-VM

  • Artikel

Van toepassing op: ✔️ Virtuele Linux-machines ✔️ van Windows

Virtuele Azure-machines (VM's) kunnen soms om geen duidelijke reden opnieuw worden opgestart, zonder bewijs dat u de herstartbewerking hebt gestart. Dit artikel bevat de acties en gebeurtenissen die ertoe kunnen leiden dat VM's opnieuw worden opgestart en biedt inzicht in het voorkomen van onverwachte problemen met opnieuw opstarten of het verminderen van de gevolgen van dergelijke problemen.

De VM's configureren voor hoge beschikbaarheid

De beste manier om een toepassing die wordt uitgevoerd in Azure te beveiligen tegen het opnieuw opstarten van vm's en uitvaltijd, is het configureren van de VM's voor hoge beschikbaarheid.

Als u dit redundantieniveau aan uw toepassing wilt bieden, wordt u aangeraden twee of meer VM's in een beschikbaarheidsset te groeperen. Deze configuratie zorgt ervoor dat tijdens een geplande of ongeplande onderhoudsgebeurtenis ten minste één VM beschikbaar is en voldoet aan de Azure SLA van 99,95 procent.

Zie De beschikbaarheid van VM's beheren voor meer informatie over beschikbaarheidssets

Resource Health-informatie

Azure Resource Health is een service die de status van afzonderlijke Azure-resources beschikbaar maakt en bruikbare richtlijnen biedt voor het oplossen van problemen. In een cloudomgeving waar het niet mogelijk is om rechtstreeks toegang te krijgen tot servers of infrastructuurelementen, is het doel van Resource Health om de tijd te verminderen die u besteedt aan het oplossen van problemen. Het doel is met name om de tijd te beperken die u besteedt om te bepalen of de hoofdmap van het probleem zich in de toepassing bevindt of in een gebeurtenis binnen het Azure-platform. Zie Resource Health begrijpen en gebruiken voor meer informatie.

Als Azure meer informatie heeft over de hoofdoorzaak van een door het platform geïnitieerde onbeschikbaarheid voor een virtuele machine, kan die informatie maximaal 72 uur na de eerste onbeschikbaarheid in de resourcestatus worden geplaatst.

Ontbrekende VM-downtimes in activiteitenlogboek

Resource Health-waarschuwingen worden verzonden op basis van de gegevens van het activiteitenlogboek . In sommige gevallen worden VM-downtimes mogelijk niet weergegeven in het activiteitenlogboek. Als de downtime niet wordt weergegeven in het activiteitenlogboek, worden Resource Health-waarschuwingen niet verzonden voor de downtime. De downtime is nog steeds zichtbaar in Resource Health.

Hier volgen de gevallen waarin downtime van VM's niet wordt weergegeven in het activiteitenlogboek:

  • Wanneer een virtuele machine wordt gemaakt of gemigreerd naar een nieuwe host, wordt de VM-status niet correct weergegeven en wordt de status gewijzigd in Onbekend. Pas nadat alle netwerkconnectiviteits- en knooppuntprocessen tot stand zijn gebracht, wordt de status van de VM gewijzigd in Beschikbaar. De verlengde periode van de status Onbekend wordt gefilterd uit het activiteitenlogboek.
  • Wanneer de beschikbaarheidsstatus van de VM verandert van Beschikbaar in Niet beschikbaar en vervolgens binnen 35 seconden teruggaat naar Beschikbaar, wordt de downtime niet weergegeven in het activiteitenlogboek. Dit geval treedt niet op als er binnen 15 minuten vóór het optreden van de eerste overgang een gecorreleerde downtime wordt verzonden.
  • Als de status van de VIRTUELE machine verandert van een status in Onbekend en vervolgens teruggaat naar de oorspronkelijke staat, worden de onregelmatige onbekende status en gerelateerde overgangen uit het activiteitenlogboek gefilterd.

De VM-downtimes die niet worden weergegeven in het activiteitenlogboek, worden gefilterd aan de kant van het Azure-platform om te voorkomen dat tijdelijke fouten onjuiste downtime aan klanten tonen. Met doorlopende investeringen in de kwaliteit van de VM-status zijn de filters mogelijk niet meer nodig en kunnen snelle wijzigingen in de VM-status niet worden gerapporteerd. Microsoft werkt aan een fase-outplan om de beste klantervaring te bieden.

Acties en gebeurtenissen waardoor de VIRTUELE machine opnieuw kan worden opgestart

Gepland onderhoud

Microsoft Azure voert regelmatig updates uit over de hele wereld om de betrouwbaarheid, prestaties en beveiliging van de hostinfrastructuur te verbeteren die ten grondslag ligt aan VM's. Veel van deze updates, waaronder updates met geheugenbehoud, worden uitgevoerd zonder dat dit van invloed is op uw VM's of cloudservices.

Voor sommige updates moet echter wel opnieuw worden opgestart. In dergelijke gevallen worden de VM's afgesloten terwijl we de infrastructuur patchen en vervolgens worden de VM's opnieuw opgestart.

Als u wilt weten wat gepland onderhoud van Azure is en hoe dit van invloed kan zijn op de beschikbaarheid van uw Linux-VM's, raadpleegt u de artikelen die hier worden vermeld. Deze artikelen bieden achtergrondinformatie over het proces van gepland onderhoud in Azure, en over hoe u gepland onderhoud kunt inplannen om de impact ervan nog verder te beperken.

Updates met geheugenbehoud

Voor deze klasse updates in Microsoft Azure hebben gebruikers geen invloed op hun actieve VM's. Dit zijn veelal updates van onderdelen of services die kunnen worden bijgewerkt zonder de actieve sessie te verstoren. Sommige zijn updates van de platforminfrastructuur op het hostbesturingssysteem die kunnen worden toegepast zonder de VM's opnieuw op te starten.

Deze updates met geheugenbehoud worden uitgevoerd met technologie die in-place livemigratie mogelijk maakt. Wanneer deze wordt bijgewerkt, wordt de VM in een onderbroken status geplaatst. In deze status blijft de geheugeninhoud in het RAM behouden. Ondertussen ontvangt het besturingssysteem van de onderliggende host de noodzakelijke updates en patches. De VIRTUELE machine wordt doorgaans binnen 30 seconden hervat nadat deze is onderbroken. Op dat moment wordt de klok van de VM automatisch gesynchroniseerd.

Vanwege de korte onderbrekingsperiode vermindert het implementeren van updates via dit mechanisme de impact op de VM's aanzienlijk. Niet alle updates kunnen echter op deze manier worden geïmplementeerd.

Updates voor meerdere exemplaren (voor VM's in een beschikbaarheidsset) worden telkens voor één updatedomein tegelijk toegepast.

Notitie

Linux-machines met oude kernelversies worden beïnvloed door een kernel paniek tijdens deze updatemethode. Om dit probleem te voorkomen, werkt u bij naar kernelversie 3.10.0-327.10.1 of hoger. Zie Een Virtuele Linux-machine van Azure op een kernel van 3.10 in paniek na een upgrade van een hostknooppunt voor meer informatie.

Door de gebruiker geïnitieerde acties voor opnieuw opstarten of afsluiten

Als u opnieuw opstart vanuit Azure Portal, Azure PowerShell, opdrachtregelinterface of REST API, kunt u de gebeurtenis vinden in het Azure-activiteitenlogboek.

Als u de actie uitvoert vanuit het besturingssysteem van de VIRTUELE machine, vindt u de gebeurtenis in de systeemlogboeken.

Andere scenario's die ervoor zorgen dat de VIRTUELE machine meestal opnieuw wordt opgestart, bevatten meerdere acties voor configuratiewijziging. Normaal gesproken ziet u een waarschuwingsbericht dat aangeeft dat het uitvoeren van een bepaalde actie ertoe leidt dat de virtuele machine opnieuw wordt opgestart. Voorbeelden hiervan zijn bewerkingen voor het wijzigen van het formaat van een virtuele machine, het wijzigen van het wachtwoord van het beheerdersaccount en het instellen van een statisch IP-adres.

Microsoft Defender voor Cloud en Windows Update

Microsoft Defender voor Cloud bewaakt dagelijkse Windows- en Linux-VM's op ontbrekende updates van het besturingssysteem. Defender voor Cloud haalt een lijst met beschikbare beveiligingsupdates en essentiële updates op van Windows Update of Windows Server Update Services (WSUS), afhankelijk van welke service is geconfigureerd op een Windows-VM. Defender voor Cloud controleert ook op de meest recente updates voor Linux-systemen. Als er een systeemupdate ontbreekt op uw VM, raadt Defender voor Cloud u aan systeemupdates toe te passen. De toepassing van deze systeemupdates wordt beheerd via de Defender voor Cloud in Azure Portal. Nadat u enkele updates hebt toegepast, is het mogelijk dat de VM opnieuw wordt opgestart. Zie Systeemupdates toepassen in Microsoft Defender voor Cloud voor meer informatie.

Net als on-premises servers pusht Azure geen updates van Windows Update naar Windows-VM's, omdat deze machines bedoeld zijn om te worden beheerd door hun gebruikers. U wordt echter aangeraden om de automatische Windows Update-instelling ingeschakeld te laten. Automatische installatie van updates van Windows Update kan er ook toe leiden dat er opnieuw wordt opgestart nadat de updates zijn toegepast. Zie De veelgestelde vragen over Windows Update voor meer informatie.

Andere situaties die van invloed zijn op de beschikbaarheid van uw VM

Er zijn andere gevallen waarin Azure het gebruik van een virtuele machine actief kan onderbreken. U ontvangt e-mailmeldingen voordat deze actie wordt uitgevoerd, zodat u de onderliggende problemen kunt oplossen. Voorbeelden van problemen die van invloed zijn op vm-beschikbaarheid zijn beveiligingsschendingen en het verlopen van betalingswijzen.

Fouten met hostservers

De VM wordt gehost op een fysieke server die wordt uitgevoerd in een Azure-datacenter. De fysieke server voert een agent met de naam HostAgent uit naast enkele andere Azure-onderdelen. Wanneer deze Azure-softwareonderdelen op de fysieke server niet meer reageren, activeert het bewakingssysteem opnieuw opstarten van de hostserver om te proberen te herstellen. In veel gevallen is de VIRTUELE machine binnen 10-15 minuten weer beschikbaar en blijft deze actief op dezelfde host als voorheen.

Serverfouten worden meestal veroorzaakt door hardwarefouten, zoals de fout van een harde schijf of ssd-schijf. Azure bewaakt deze gebeurtenissen continu, identificeert de onderliggende bugs en implementeert updates nadat de beperking is geïmplementeerd en getest.

Omdat sommige hostserverfouten specifiek voor die server kunnen zijn, kan een herhaalde vm-herstart worden verbeterd door de VM handmatig opnieuw te implementeren op een andere hostserver. Deze bewerking kan worden geactiveerd met behulp van de optie opnieuw implementeren op de detailpagina van de VIRTUELE machine of door de VIRTUELE machine te stoppen en opnieuw op te starten in Azure Portal.

Automatisch herstel

Het Azure-platform is ontworpen voor het afhandelen van problemen met hostknooppunten met minimale invloed op de prestaties van de VM. Wanneer een hostknooppunt een probleem ondervindt, probeert Azure eerst de minst verstorende herstelmethode, namelijk om de host opnieuw op te starten. Als het opnieuw opstarten van de host niet mogelijk is of als het oorspronkelijke probleem betrekking heeft op hardware, herstelt de platformservice alle VM's op de betreffende host naar een gezond knooppunt. Hoewel het opnieuw opstarten van een host over het algemeen een lagere impact heeft, kan het herstellen van de service van VM's complexer en tijdrovender zijn, afhankelijk van het aantal VM's, hun implementatiebeperkingen en de beschikbaarheid van lokale resources. Serviceherstel wordt doorgaans gebruikt als laatste redmiddel voor hardwarefouten, omdat deze ervoor zorgt dat VM's zonder aanzienlijke downtime blijven werken.

Als een hostserver niet opnieuw kan worden opgestart, start Azure een automatische herstelactie om de defecte host niet meer te roteren voor verder onderzoek. Tijdens dit proces voor automatisch herstel worden alle VM's op de host automatisch verplaatst naar een andere goede hostserver. Hoewel dit proces meestal binnen 15 minuten wordt voltooid, kan de hersteltijd variëren op basis van factoren zoals de geheugengrootte van de host en de gebruikte herstelmethoden. Zie ServiceHerstel: automatisch herstel van virtuele machines voor meer informatie over hoe Azure deze scenario's verwerkt.

Niet-gepland onderhoud

In zeldzame gevallen moet het Azure Operations-team mogelijk onderhoudsactiviteiten uitvoeren om de algehele status van het Azure-platform te garanderen. Dit gedrag kan van invloed zijn op de beschikbaarheid van vm's en resulteert meestal in dezelfde actie voor automatisch herstel, zoals eerder is beschreven.

Niet-gepland onderhoud omvat het volgende:

  • Urgente knooppuntdefragmentatie
  • Urgente updates voor netwerkswitch

VM-crashes

VM's kunnen opnieuw worden opgestart vanwege problemen binnen de VM zelf. De workload of rol die op de VIRTUELE machine wordt uitgevoerd, kan een foutcontrole in het gastbesturingssysteem activeren. Bekijk de systeem- en toepassingslogboeken voor Windows VM's en de seriële logboeken voor Linux-VM's voor hulp bij het bepalen van de reden voor het vastlopen.

VM's in Azure zijn afhankelijk van virtuele schijven voor het besturingssysteem en de gegevensopslag die wordt gehost op de Azure Storage-infrastructuur. Wanneer de beschikbaarheid of connectiviteit tussen de virtuele machine en de bijbehorende virtuele schijven langer dan 120 seconden wordt beïnvloed, voert het Azure-platform een gedwongen afsluiting van de VM's uit om beschadiging van gegevens te voorkomen. De VM's worden automatisch weer ingeschakeld nadat de opslagconnectiviteit is hersteld. De duur van de afsluiting kan zo kort zijn als vijf minuten, maar kan aanzienlijk langer zijn.

Andere incidenten

In zeldzame gevallen kan een wijdverspreid probleem van invloed zijn op meerdere servers in een Azure-datacenter. Als dit probleem zich voordoet, stuurt het Azure-team e-mailmeldingen naar de betrokken abonnementen. U kunt het Azure Service Health-dashboard en de Azure-portal controleren op de status van lopende storingen en eerdere incidenten.

Vm-herstarts diagnosticeren

U kunt de blade Diagnose en Oplossen op de blade VM gebruiken om aanvullende diagnostische gegevens uit te voeren. Dit kan specifiekere redenen voor het opnieuw opstarten van uw virtuele machine ontdekken. Als er een probleem is met het gastbesturingssystemen, verzamelt u geheugendump en neemt u contact op met de ondersteuning.

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Azure-feedbackcommunity.