Use Azure availability sets for patching to achieve the best uptime
Ops' responsibility doesn't end once in a public cloud; in fact, it can get more confounding. Learn the best route to update Azure cloud instances and what mistakes to avoid.
Operations teams still patch and update deployments on public cloud-based infrastructure, and they must work around the fact that they can't control the bottom of the stack. On Microsoft's cloud, an admin can fight unexpected downtime with Azure availability sets and a cloud-aware patching methodology.
An Azure cloud deployment goes offline for software updates, as well as changes to the underlying hypervisor, which is managed by Microsoft. By default, Azure VMs are subject to several brief -- less than 30 seconds -- outages throughout the year for Microsoft's updates. Application and business requirements could make this downtime unacceptable to an enterprise cloud user, but it is unavoidable.
Plan around cloud restarts
For this reason, administrators should use availability sets when they create deployments in Azure cloud infrastructure. Azure availability sets are logically grouped VMs that perform the same function, such as a database set or web server set. These sets ensure a predetermined number of VMs, at minimum, run at any given time on different stamps. Stamp is a Microsoft term for alternate hosts on machines in separate failure domains.
Azure availability sets serve two purposes. VMs in the availability set are never all updated or rebooted by Microsoft at the same time in the event of hypervisor changes, which ensures service availability. Perhaps more importantly, an availability set enables the administrator to better manage the OS update process. An admin can remove one or multiple VMs from the load balancer for updates, then return the systems without disrupting the overall service.
Azure availability sets are easy to use and have significant benefits for IT admins.
What qualifies for an Azure availability set?
There are requirements and exceptions to take into account when you deploy Azure availability sets. They require a load balancer at the front end to function. Not all virtual machines in Azure support this scheme; for example, several of the A series do not work with availability sets and load balancing. This is likely due to the fact that this class of machines is designed as test, rather than production, infrastructure.
Administrators can add new VMs to an existing set, or create a new set as needed. However, you cannot add already-built VMs to Azure availability sets. To get a VM into an availability set, take it down and rebuild it.
Patch cloud VMs without taxing resources
The best way to perform updates on Azure VMs is dictated by the size of the environment.
The best way to perform updates on Azure VMs is dictated by the size of the environment.
Azure users, for example, can use built-in Windows update mechanisms straight from the VM to consume Microsoft-owned update servers. Many small companies choose this option. Alternatively, the administrator can build an update server in the cloud and point servers to it.
Larger companies place update-strategic satellite servers in the public cloud as an extension of the on-site deployment, optimized to support those Azure-based servers. This setup reduces the network bandwidth traffic of a hybrid cloud system, because the update servers are local to the Azure machines. It also is much faster than dragging updates across several networks.
Enterprise cloud admins also can create custom images, with all the required base applications and configurations, to deploy in Azure, rather than use Microsoft's images. Microsoft frequently updates its images and keeps a back catalog of recent releases that admins can select as deployment images. However, with a custom image, you know the patch level the VM started on and keep it consistent in deployment, so all machines are identical.
Pair custom image deployments with a well-managed update policy, as demonstrated in this example enterprise. A particular workload has three base images: the database, web and app servers. The admins deploy from these base images into Azure availability sets. Each server is identical and already configured for its purpose. The enterprise bolsters this methodology with a well-defined and tested update group for each VM type. It's also a best practice to spend time in user acceptance testing before you move to production. Things can -- and do -- go wrong.
Always review the existing on-premises update policy before applying it. Cloud is a whole new way of doing things. If you treat the cloud deployment and groups of VMs in it as separate entities from the on-premises VMs, it will engender a smart patching strategy for both locations.
Next Steps
Author Stuart Burns noted that Microsoft's cloud-native Operations Management Suite (OMS) is a tool with fine-grained management and control of Azure items, as well as on-premises workloads. Administrators should take a close look at the GUI, which combines management with log analysis, compliance and other useful tools. If it lives up to its promises, OMS will prove valuable on diverse cloud setups.
Dig Deeper on Systems automation and orchestration
