Planned Maintenance – Azure Style
Hello Folks,
All of us IT pros and DevOps people need to have some time for patching servers, applications, making changes to the infrastructure. It’s part of our lives. it’s something we have wrestled with for years.
You ensure that all your users know about it, you plan for it, and you depend on it for the well being of your environments. The same is true for Microsoft Azure. We need to maintain the underlying fabric on which all our Azure Services rest. Planned maintenance are periodic updates made by Microsoft to the underlying Azure platform to improve overall reliability, performance, and security of the platform infrastructure that your virtual machines run on. The majority of these updates are performed without any impact upon your virtual machines or cloud services. However, there are instances where these updates require a reboot of your virtual machine to apply the required updates to the platform infrastructure.
How do you know if the VM reboot was because of a fault in the VM or was it due to a Planned Maintenance event? So far the experience has not been optimal. But now, in order to make it easier for you to understand if your VM reboot due to a planned maintenance or not, we’ve made a few improvements.
First, I want to suggest a couple of Microsoft Virtual Academy free courses.
Single-Instance VMs
If you are running Single-instance virtual machines, we send email communication at least one week in advance in order to alert you of the upcoming planned maintenance. This email will be sent to the primary email account provided by the subscription. so you need to tell that person if it’s not you to forward those emails.
Multi-Instance VMs
For virtual machines in a multi-instance configuration, virtual machines are updated in way that preserves availability throughout the process, assuming each machine serves a similar function as the others in the set. Each virtual machine in your Availability Set is assigned an Update Domain (UD) and a Fault Domain (FD) by the underlying Azure platform. Each UD is a group of virtual machines that will be rebooted in the same time window. Each FD is a group of virtual machines that share a common power source and network switch.
Microsoft Azure guarantees that no planned maintenance event will cause virtual machines from two different UDs to go offline at the same time. therefore maintaining your service\application up-time. The maintenance is performed by shutting down each virtual machine, applying the update to the host machines, restarting the virtual machine, and moving on to the next UD.
Today, no advance notification of planned maintenance is provided for virtual machines in the multi-instance configuration.
Reboot History
You can find out if any reboots have occurred in 2 easy ways:
1- in the Azure Portal, in the cloud service dashboard. There is a link to the reboot logs for the machines in that cloud service.
2- In the Reboot history wizard window, enter the start day and time and the end day and time of the period you want to examine and click the search button.
(All my cloud services are test environment that have not been around long enough to experience any reboot events.)
3- Using PowerShell to extract the reboot events. use the following command to list the reboot events
Get-AzureDeploymentEvent -EndTime 2015-03-09T16:30:00Z -ServiceName CanITProCamp -StartTime 2014-12-10T04:30:00Z
the response should be something like the following example.
Here you go. No more guessing games.
Next week I’ll take a look at configuring multiple virtual machines in an Availability Set for redundancy.
Until then,
Cheers!
