Microsoft periodically perform updates to improve the reliability, performance, and security of their global cloud platform. Most of the updates that Microsoft apply have no impact on the hosted virtual machines and go unnoticed. However, there are some instances where the running virtual machines are affected, the most recent example of this being the Spectre and Meltdown CPU vulnerability.
When an update like this is applied, depending if the maintenance requires a rebooted or not, it can affect running virtual machines in one of two ways:
- In-place migration – During an in-place migration the affected Azure virtual machine is paused (typically for 30 seconds or less) to preserve memory in RAM while the host environment is updated. Once the upgrade is complete the virtual machine is resumed and the system clocks synchronised
- Maintenance requiring a reboot – During reboot maintenance, the virtual machine is moved to a node that has already been patched and then powered back on.
Under normal circumstances, when a virtual machine needs rebooting, you are notified in advance and given the option to start the maintenance at a preferred time during the initial self-service window. If the self-service window is missed, the scheduled maintenance window begins and it is no longer possible to manage the process.
NOTE: Datacentre in paired regions will not have maintenance performed at the same time; therefore, workloads balanced across paired regions will be unaffected.
Azure Service Health
Azure Service Health (in public preview at the time of writing) can be used to view problems with Azure services that may impact any of your cloud services. Service Health monitors three types of health event:
- Service issues – Azure services that are currently experiencing problems
- Planned maintenance – Any known future maintenance that may affect the availability of your services
- Health advisories – Changes in services, for example, deprecated features or exceeded quota usage.
Using the Service Heath service, it is not only possible to view in one location any service problems but also setup Health alerts which are a vast improvement on the basic email notification. Service alerts can be configured to:
- Send Email/SMS/Push/Voice notification
- Send Webhooks to third party app i.e. ServiceNow or Azure Logic App
- Send an IT Service Management Ticket
- Trigger an Automation Runbook.
Creating planned maintenance alerts using Azure Service Health
To demonstrate the alerting capabilities of the Health Service, the rest of this article steps through the process involved in configuring a basic email alert to notify of any planned maintenance events.
1. Login into the Azure portal and select Service Health.
2. Select Health alerts followed by + Create service health alert from the top of the window on the right.
3. In the Edit Alert blade, give the alert a Name, Description, check the subscription is correct and choose a resource group.
4. The next step is to work through the Criteria section choosing which services, regions and types of event alerts should be monitored. For the purpose of this article all services and regions have been checked but only planned maintenance events.
5. Select or create an Action group. (An Action group is a group of actions to be taken, should an event be logged.)
6. Configure the actions to be taken. We are only configuring an email alert, so we first name the action, then chose Email/SMS/Push/Voice from the drop down list.
7. Enter the name and email address of the person who will be sent the notification. Then finally click OK twice to add the activity log alert.
It should now be possible to see the newly created alert, listed in the Health alerts blade.
Should action groups need to be edited or new actions added, either click on Edit this action group from the lower half of the Health alerts blade or browse to the Monitor service and select the Action groups tab.
For more details checkout the Microsoft document site https://docs.microsoft.com/en-us/azure/service-health/service-health-overview