Meer informatie over het opnieuw opstarten van het systeem voor azure-VM

  • Artikel

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

De VM's configureren voor hoge beschikbaarheid

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

Als u dit niveau van redundantie wilt bieden aan uw toepassing, raden we u aan twee of meer VM's in een beschikbaarheidsset te groepren. 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 verminderen die u besteedt aan het bepalen of de oorzaak van het probleem ligt in de toepassing 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 niet-beschikbaarheid voor een virtuele machine, kan die informatie tot 72 uur na de eerste niet-beschikbaarheid in de resourcestatus worden geplaatst.

Ontbrekende VM-downtime in activiteitenlogboek

Resource Health waarschuwingen worden verzonden op basis van de gegevens van het activiteitenlogboek. In sommige gevallen worden vm-downtime 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.

Dit zijn de gevallen waarin downtime van vm's niet wordt weergegeven in het activiteitenlogboek:

  • Wanneer een VM wordt gemaakt of gemigreerd naar een nieuwe host, wordt de VM-status van het Azure-platform niet correct weergegeven en wordt de status gewijzigd in Onbekend. Pas nadat alle netwerkconnectiviteit en knooppuntprocessen tot stand zijn gebracht, verandert de VM-status in Beschikbaar. De langere periode van de status Onbekend wordt uit het activiteitenlogboek gefilterd.
  • 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 probleem treedt niet op als er binnen 15 minuten vóór het optreden van de eerste overgang een gecorreleerde downtime wordt verzonden.
  • Als de VM-status verandert van een status in Onbekend en vervolgens teruggaat naar de oorspronkelijke status, worden de onregelmatige status Onbekend en gerelateerde overgangen uit het activiteitenlogboek gefilterd.

De VM-downtime die niet wordt weergegeven in het activiteitenlogboek, worden gefilterd aan de azure-platformzijde om te voorkomen dat tijdelijke fouten onjuiste downtimes aan klanten tonen. Met voortdurende 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 die ertoe kunnen leiden dat de VM opnieuw wordt opgestart

Gepland onderhoud

Microsoft Azure voert regelmatig wereldwijd updates uit om de betrouwbaarheid, prestaties en beveiliging van de hostinfrastructuur die ten grondslag ligt aan virtuele machines te verbeteren. Veel van deze updates, waaronder updates met geheugenbehoud, worden uitgevoerd zonder enige invloed op uw VM's of cloudservices.

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

Zie de artikelen die hier worden vermeld om te begrijpen wat gepland azure-onderhoud is en hoe dit van invloed kan zijn op de beschikbaarheid van uw Linux-VM's. In de artikelen vindt u achtergrondinformatie over het azure-proces voor gepland onderhoud en het plannen van gepland onderhoud om de impact verder te verminderen.

Updates met geheugenbehoud

Voor deze klasse updates in Microsoft Azure ondervinden gebruikers geen invloed op hun actieve VM's. Veel van deze updates zijn bedoeld voor onderdelen of services die kunnen worden bijgewerkt zonder het actieve exemplaar 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. Met deze status blijft het geheugen in het RAM-geheugen behouden, terwijl het onderliggende hostbesturingssysteem de benodigde updates en patches ontvangt. De VM wordt doorgaans binnen 30 seconden na onderbreking hervat. Nadat de VM is hervat, wordt de klok 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 met meerdere exemplaren (voor VM's in een beschikbaarheidsset) worden per updatedomein toegepast.

Opmerking

Linux-machines met oude kernelversies worden beïnvloed door een kernel panic tijdens deze updatemethode. U kunt dit probleem voorkomen door bij te werken naar kernelversie 3.10.0-327.10.1 of hoger. Zie Een Azure Linux-VM op een 3.10-gebaseerde kernel panics 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 de 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 VM, kunt u de gebeurtenis vinden in de systeemlogboeken.

Andere scenario's die er meestal voor zorgen dat de VM opnieuw wordt opgestart, omvatten meerdere configuratiewijzigingsacties. Normaal gesproken ziet u een waarschuwingsbericht dat aangeeft dat het uitvoeren van een bepaalde actie resulteert in het opnieuw opstarten van de VM. Voorbeelden hiervan zijn bewerkingen voor het wijzigen van het formaat van de VM, 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 dagelijks windows- en Linux-VM's op ontbrekende updates van het besturingssysteem. Defender for 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 for Cloud controleert ook op de nieuwste 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 Defender for Cloud in de Azure Portal. Nadat u enkele updates hebt toegepast, is het mogelijk dat de VM opnieuw moet worden 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 zijn bedoeld om te worden beheerd door hun gebruikers. U wordt echter aangeraden de instelling automatische Windows Update ingeschakeld te laten. Automatische installatie van updates van Windows Update kan er ook voor zorgen dat opnieuw wordt opgestart nadat de updates zijn toegepast. Zie 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 VM actief onderbreekt. U ontvangt e-mailmeldingen voordat deze actie wordt uitgevoerd, zodat u de kans krijgt om de onderliggende problemen op te lossen. Voorbeelden van problemen die van invloed zijn op de beschikbaarheid van vm's zijn beveiligingsschendingen en het verlopen van betalingswijzen.

Hostserverfouten

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

Serverfouten worden meestal veroorzaakt door hardwarestoringen, zoals een storing van een harde schijf of een SSD-station. Azure bewaakt deze exemplaren voortdurend, 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 situatie waarbij de VM opnieuw wordt opgestart, 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 VM, of door de VM te stoppen en opnieuw op te starten in de Azure Portal.

Automatisch herstel

Als de hostserver om wat voor reden dan ook niet opnieuw kan worden opgestart, initieert het Azure-platform een actie voor automatisch herstel om de defecte hostserver uit de rotatie te halen voor verder onderzoek.

Alle VM's op die host worden automatisch verplaatst naar een andere, gezonde hostserver. Hoewel dit proces doorgaans binnen 15 minuten wordt voltooid, kan de benodigde tijd voor herstel variëren, afhankelijk van verschillende factoren, waaronder de grootte van het hostgeheugen en de gebruikte herstelmethoden. Zie Automatisch herstel van VM's voor meer informatie over het proces voor automatisch herstel.

Ongepland 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 netwerkswitchs

VM loopt vast

VM's kunnen opnieuw worden opgestart vanwege problemen binnen de VM zelf. De workload of rol die wordt uitgevoerd op de VM kan een bugcontrole 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 de crash.

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

Andere incidenten

In zeldzame gevallen kan een wijdverbreid probleem van invloed zijn op meerdere servers in een Azure-datacenter. Als dit probleem zich voordoet, verzendt 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 opnieuw opstarten diagnosticeren

U kunt de blade Diagnose en oplossen op de vm-blade gebruiken om aanvullende diagnostische gegevens uit te voeren. Dit kan specifiekere redenen aan het licht brengen voor de recente herstart van de VM. Als er een probleem met het gastbesturingssystemen is, verzamelt u de 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 Feedback-community van Azure.