Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Azure Pre-Emptive Maintenance

DZone's Guide to

Azure Pre-Emptive Maintenance

Not a fan of Azure restarting your VMs for updates? See how you can take control of the process with scheduled, pre-emptive maintenance.

· Cloud Zone ·
Free Resource

Discover a centralized approach to monitor your virtual infrastructure, on-premise IT environment, and cloud infrastructure – all on a single platform.

A few years ago, it was not uncommon to see a requirement for VMs to be rebooted every few months when maintenance to apply updates to the underlying host was required. Fortunately, this is now mostly a thing of the past, with most updates now being applied using Azure’s in-place upgrade process — which just pauses for a few seconds while the host is updated. Up until recently, I had not seen a maintenance window that required VM reboots for over a year.

However, there are still some updates that do require maintenance windows to reboot VMs, and there is one of these coming up on January 10, 2018, that will impact most users of Azure. Thankfully, the planned update process has improved a lot since the last maintenance Window and we now have some new tools that will help make this less painful.

Update Notifications

Previously, the updates for a maintenance window were distributed solely by email to the subscription owners and co-admins. That means that if you were not in one of these roles, you may never know that your machines are going to be rebooted. With Azure Service Health. we can now see planned maintenance inside the Azure portal and even set up alerts to be notified when these are going to occur.

You can find planned maintenance under the “Azure Service Health” module in the portal:

Once we enter this blade, we can select the “Planned Maintenance” option and see any events that are coming up, as well as what they impact. In my environment, I have a single event for the 10th of January:

If we select this, we can then view more details about the event:

We can also click on the “Affected Resources” tab to see a list of the machines that are impacted by this maintenance window. Note that the portal will show you alerts and affected machines for the subscription you have selected, so make sure you select any subscriptions you want to look at.

Pre-Emptive Maintenance

Now that we know a maintenance window is coming, we have the option to do something about it. In the old days, when you got a maintenance notification, all you knew was that your VMs would be rebooted at some point in that window. Often, this window was 2-3 days — not very helpful. With the new pre-emptive maintenance feature, the notification (as seen above) now gives you a period running up to the maintenance window where you can reboot your VMs and have them move to an already updated host on your own schedule. If you don’t do this before the maintenance window starts, then they will be rebooted for you.

Using this proactive maintenance option, we can schedule the maintenance ourselves and provide our customers or users a much more exact time for the reboot, as it is under our control.

The easiest way to start the pre-emptive maintenance is the in the “Planned maintenance” window we looked at previously for the notifications. If you look at the “Affected Resources” tab, you will see a list of VMs that are impacted, plus their current status (whether they have been updated or not), and the option to start pro-active maintenance now.

Selecting the option to start pre-emptive maintenance takes you to a page that shows you the timescale for the window and what will happen if you do (or do not) use the pre-emptive maintenance feature.

When you're ready, click the “start maintenance” button to begin. This will begin the process of rebooting and moving your VM. In my experience, this has generally taken 5-10 minutes. Once it has completed, your VM will now show up in the list with a “completed status”.

You can also view and initiate maintenance through the Virtual Machines tab. The main page now lists the machines' maintenance status.

Note that in this example, one of the machines has the status of “Scheduled”. This means that I do not have the option to use pre-emptive maintenance for this machine for some reason, and it will be rebooted by the Azure platform during the maintenance window.

Bulk Maintenance

There is currently no option in the portal to apply maintenance to multiple machines at once. You would need to go through and initiate each one, which is a bit of a pain. If you want to do it in bulk, then the way to do this is going to be through PowerShell, where you can have it loop through a list of VMs and apply the maintenance. This can be achieved by restarting the VM with the “PerformMaintenance” flag

Restart-AzureRmVM -PerformMaintenance -name <vmName> -ResourceGroupName <resourceGroupName>


If you want to query the status of your VMs' pre-emptive maintenance using PowerShell, you can look at the MaintenanceRedeployStatus property of the VM:

$vm=get-azurermvm --ResourceGroupName <resourceGroupName> -Name <vmName> -Status
$vm.MaintenanceRedeployStatus


Mandatory Maintenance

If you do not perform pre-emptive maintenance during the allotted window (i.e. before the end of the 9th of Jan), then your VM will be shut down and restarted by Azure at some point during the maintenance window. At the moment, for the January 2018 window, this is showing a very wide range — between the 10th and 21st of Jan. Hopefully, this will be narrowed down before it occurs, but if you want to maintain control of when it happens, then take advantage of pre-emptive maintenance.

Learn how to auto-discover your containers and monitor their performance, capture Docker host and container metrics to allocate host resources, and provision containers.

Topics:
cloud ,microsoft azure ,virtual machines ,updates ,tutorial

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}