This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
Summary:
Roughly Microsoft releases a new Guest OS version for azure cloud service monthly to make cloud service more secure and robust. This blog will introduce azure cloud service guest OS details, upgrade impact, procedures and detection ways.
The following parts will be discussed in this blog:
- Cloud Service Guest OS Introduction
- Guest OS upgrades Impact
- How Cloud Service Upgrades Proceeds
- How To Track Guest OS Upgrade Via RHC
1.Cloud Service Guest OS Introduction
The cloud service guest OS upgrade happens monthly, there is os Version and os Family settings in cloud service cscfg file. Configuration sampe as below:
<ServiceConfiguration serviceName="AzureCloudService11" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="6"
osVersion="*"
schemaVersion="2015-04.2.6">
OS family is to configure the windows server, bellowing are the os family mapping , OsFamily can be value from 2 to 6. Then corresponding windows server os will be used for the cloud service.
- Family 2 - Windows Server 2008 R2 SP1
- Family 3 - Windows Server 2012
- Family 4 - Windows Server 2012 R2
- Family 5 - Windows Server 2016
- Family 6 - Windows Server 2019
OSversion is recommended to set * (default value ) in the cscfg file. It will always pick up the latest guest os version. The schedule release date and history version can be seen at azure Guest OS. , and release details can be seen at release details.
2. Guest OS Upgrade Impact
Guest OS patch will be applied by reimaging with latest os image per the upgrade domian monthly. Therefore, if your cloud service have below situation, your service would be impacted during the guest os upgrade.
Scenario 1: If there is the manual changes or customized setting in the cloud service role instances.
Since the role instance will be reimaged with latest OS image, so manual changes or customized setting will be gone after the guest os upgrade. In order to keep customized settings, we suggest to use the startup tasks to apply the cusomized settings to the role instances. you can ref more details about startup task via link.
Scenario 2: Single role instance cloud service.
The service SLA cannot be guareenteed and the service will become unavailable during the guest OS upgrade due to single role instance.
For the production and important environment, we strongly recommend to have at least 2 or more role instances. You can also find a SLA summary in this link for single role instance.
3. How Cloud Service Upgrades Proceeds
Azure organizes your role instances into logical groupings called upgrade domains （UD. Upgrade domains （UD） are logical sets of role instances that are updated as a group. Azure updates a cloud service one UD at a time, which allows instances in other UDs to continue serving traffic.
Usually, the default number of upgrade domains is 5. You can specify a different number of upgrade domains by including the upgradeDomainCount attribute in the service’s definition file (.csdef). For more information about the upgradeDomainCount attribute, see Azure Cloud Services Definition Schema (.csdef File).
You can decide whether you want to update all of the roles in your service or a single role in the service. In either case, all instances of each role that is being upgraded and belong to the first upgrade domain are stopped, upgraded, and brought back online. Once they are back online, the instances in the second upgrade domain are stopped, upgraded, and brought back online. A cloud service can have at most one upgrade active at a time. The upgrade is always performed against the latest version of the cloud service.
The following diagram illustrates how the upgrade proceeds if you are upgrading all of the roles in the service:
This next diagram illustrates how the update proceeds if you are upgrading only a single role:
For the details about UD and Cloud Service upgrade, please refer to this link: https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-update-azure-service#how-an-upgrade-proceeds
4. Using RHC （Resource Health Check） to track the Guest OS upgrade
Although users can’t control the Guest OS upgrade time, Users can use Azure Resource Health for cloud services to help diagnose and get support for service problems that affect your Cloud Service deployment, Roles & Role Instances. It reports on the current and past health of your cloud services at Deployment, Role & Role Instance level.
Azure status reports on problems that affect a broad set of Azure customers. Resource Health gives you a personalized dashboard of the health of your resources. Resource Health shows all the times that your resources have been unavailable because of Azure service problems. This data makes it easy for you to see if an SLA was violated.
For the details about Cloud Service RHC, please refer to this Q&A section in this document:
https://docs.microsoft.com/en-us/azure/cloud-services/resource-health-for-cloud-services