Автоматическое обновление образа ОС в масштабируемом наборе виртуальных машин Azure

Если включить автоматические обновления образа ОС в масштабируемом наборе, управление обновлениями будет осуществляться намного проще благодаря безопасным автоматическим обновлениям диска ОС для всех экземпляров в масштабируемом наборе.

Автоматическое обновление ОС имеет следующие характеристики:

• После настройки последний образ ОС, опубликованный издателем, автоматически применяется к масштабируемому набору без вмешательства пользователя.
• Пакеты экземпляров последовательно обновляются каждый раз, когда издатель публикует новый образ.
• Интегрируется с пробами работоспособности приложения и расширения работоспособности приложения.
• Работает для виртуальных машин всех размеров, а также для образов Windows и Linux, включая пользовательские образы, через коллекцию вычислений Azure.
• Автоматические обновления можно в любое время отключить (обновление ОС также можно инициировать вручную).
• Диск ОС виртуальной машины заменяется новым диском ОС с последней версией образа. Запускаются настраиваемые расширения и сценарии пользовательских данных, а сохраненные диски данных сохраняются.
• Поддерживается расширение виртуализации.
• Можно включить в масштабируемом наборе любого размера.

Как работает автоматическое обновление образа ОС?

Обновление выполняется путем замены диска ОС виртуальной машины новым диском, созданным с помощью версии образа. Настроенные расширения и скрипты пользовательских данных выполняются на диске ОС, а диски данных сохраняются. Чтобы свести к минимуму время простоя приложений, обновления выполняются для пакетов и в любое время обновляется не более чем 20 % масштабируемого набора.

Чтобы отслеживать работоспособность приложения после обновления, необходимо интегрировать пробу работоспособности приложения Azure Load Balancer или расширение "Работоспособность приложений". Это позволяет платформе проверять работоспособность виртуальной машины, чтобы обеспечить безопасное применение обновлений. Рекомендуется включить пульс приложения, чтобы проверить успешность обновления.

Установка обновлений по приоритету доступности

Описанная ниже модель выполнения операций по приоритету доступности для запланированных на платформе обновлений гарантирует, что конфигурации доступности в Azure будут соблюдаться на нескольких уровнях доступности.

Между регионами:

• Обновление будет выполняться в Azure глобально поэтапно, чтобы предотвратить сбои развертывания в масштабах всей среды Azure.
• Один этап может охватывать один или несколько регионов, и обновление выполняется поэтапно только в том случае, если подходящие виртуальные машины в предыдущем этапе были успешно обновлены.
• Геопарные регионы не будут обновляться одновременно и не могут находиться в одном этапе обновления регионов.
• Успешность обновления измеряется путем отслеживания работоспособности виртуальной машины после обновления.

В пределах региона:

• Виртуальные машины в разных зонах доступности не обновляются одновременно.

В наборе:

• Все виртуальные машины, находящиеся в общем масштабируемом наборе, обновляются в разное время.
• Виртуальные машины в общем масштабируемом наборе виртуальных машин группируются в пакетах и обновляются в пределах границ домена обновления, как описано ниже.

Процесс установки запланированных на платформе обновлений выполняется каждый месяц для развертывания обновлений образа платформы поддерживаемой операционной системы. В случае пользовательских образов через коллекцию вычислений Azure обновление образа запускается только для определенного региона Azure при публикации и репликации нового образа в регион этого масштабируемого набора.

Обновление виртуальных машин в масштабируемом наборе

Регион масштабируемого набора получает право на получение обновлений образа либо с помощью модели выполнения операций по приоритету доступности для образов платформы, либо с помощью репликации новых версий пользовательского образа для Общей коллекции образов. Затем обновление образа в пакетном режиме применяется к отдельному набору масштабирования следующим образом.

1. Перед началом процесса обновления оркестратор убедится, что не более чем 20 % экземпляров во всем масштабируемом наборе являются неработоспособными (по любой причине).
2. Этот оркестратор обновления определяет пакет экземпляров виртуальных машин для обновления. При этом любой пакет должен содержать не более 20% от общего количества экземпляров при условии минимального размера пакета одной виртуальной машины. Требование к минимальному размеру масштабируемого набора отсутствует, и масштабируемые наборы с 5 экземплярами или менее будут иметь 1 виртуальную машину на пакет обновлений (минимальный размер пакета).
3. Диск ОС каждой виртуальной машины в выбранном пакете обновления заменяется новым диском ОС, созданным на основе образа. Все указанные расширения и конфигурации в модели масштабируемого набора применяются к обновленному экземпляру.
4. Если масштабируемые наборы настроены с помощью проверок работоспособности приложения или расширения работоспособности приложения, обновление останавливается на 5 минут, чтобы экземпляр стал работоспособным, прежде чем перейти к обновлению нового пакета. Если экземпляр не восстанавливает работоспособность в течение 5 минут после обновления, по умолчанию восстанавливается предыдущий диск ОС для этого экземпляра.
5. Оркестратор обновления также отслеживает процент экземпляров, которые становятся неработоспособными после обновления. Обновление будет прервано, если более чем 20 % обновленных экземпляров утрачивают работоспособность во время обновления.
6. Описанный выше процесс продолжается, пока все экземпляры в масштабируемом наборе не будут обновлены.

Оркестратор обновления ОС масштабируемого набора проверяет общее состояние работоспособности масштабируемого набора перед обновлением каждого пакета. При обновлении пакета может быть выполнено другое параллельное плановое или внеплановое обслуживание, которое может повлиять на работоспособность экземпляров масштабируемого набора. В таких случаях более 20 % экземпляров масштабируемого набора становятся неработоспособными, обновление масштабируемого набора останавливается в конце текущего пакета.

Чтобы изменить параметры по умолчанию, связанные с последовательными обновлениями, просмотрите политику последовательного обновления Azure.

Обновление образа ОС и повторное представление

Обновление образа ОС и повторное создание образов — это методы, используемые для обновления виртуальных машин в масштабируемом наборе, но они служат различным целям и имеют различные последствия.

Обновление образа ОС включает обновление базового образа операционной системы, используемого для создания новых экземпляров в масштабируемом наборе. При обновлении образа ОС Azure создаст новые экземпляры виртуальных машин с обновленным образом ОС и постепенно замените старые экземпляры виртуальных машин в масштабируемом наборе новыми. Обычно этот процесс выполняется на этапах, чтобы обеспечить высокий уровень доступности. Обновления образов ОС — это неразрушительный способ применения обновлений или изменений к базовой ОС виртуальных машин в масштабируемом наборе. Существующие экземпляры виртуальных машин не затрагиваются, пока они не будут заменены новыми экземплярами.

Повторное создание экземпляра виртуальной машины в масштабируемом наборе является более непосредственным и разрушительным действием. При повторном создании экземпляра виртуальной машины Azure остановит выбранный экземпляр виртуальной машины, выполните операцию повторного создания образов, а затем перезапустите виртуальную машину с помощью того же образа ОС. Это эффективно переустановит ОС на этом конкретном экземпляре виртуальной машины. Повторное создание образа обычно используется при необходимости устранения неполадок или сброса конкретного экземпляра виртуальной машины из-за проблем с этим экземпляром.

Основные различия:

• Обновление образа ОС — это постепенный и неразрушительный процесс, который обновляет образ ОС для всего масштабируемого набора виртуальных машин со временем, обеспечивая минимальное влияние на выполнение рабочих нагрузок.
• Повторное создание образа — это более немедленное и разрушительное действие, которое влияет только на выбранный экземпляр виртуальной машины, остановив его временно и переустановив ОС.

Когда следует использовать каждый метод:

• Используйте обновление образа ОС, если требуется обновить образ ОС для всего масштабируемого набора, сохраняя высокий уровень доступности.
• Используйте reimage, если необходимо устранить неполадки или сбросить определенный экземпляр виртуальной машины в масштабируемом наборе виртуальных машин.

Необходимо тщательно планировать и выбирать подходящий метод на основе конкретных требований, чтобы свести к минимуму любые нарушения работы приложений и служб, работающих в масштабируемом наборе виртуальных машин.

Поддерживаемые образы ОС

В настоящее время поддерживаются только определенные образы платформ ОС. Пользовательские образы поддерживаются, если масштабируемый набор использует пользовательские образы с помощью коллекции вычислений Azure.

В настоящее время поддерживаются следующие номера SKU (и периодически будут добавляться дополнительные):

Publisher	Предложение ОС	Sku
Canonical	UbuntuServer	18.04-LTS
Canonical	UbuntuServer	18_04-LTS-Gen2
Canonical	0001-com-ubuntu-server-focal	20_04-LTS
Canonical	0001-com-ubuntu-server-focal	20_04-LTS-Gen2
Canonical	0001-com-ubuntu-server-jammy	22_04-LTS
Canonical	0001-com-ubuntu-server-jammy	22_04-LTS-Gen2
MicrosoftCblMariner	Cbl-Mariner	cbl-mariner-1
MicrosoftCblMariner	Cbl-Mariner	1-Gen2
MicrosoftCblMariner	Cbl-Mariner	cbl-mariner-2
MicrosoftCblMariner	Cbl-Mariner	cbl-mariner-2-Gen2
MicrosoftSqlServer	Sql2017-ws2019	корпоративный
MicrosoftWindowsServer	WindowsServer	2012-R2-Datacenter
MicrosoftWindowsServer	WindowsServer	2016-Datacenter
MicrosoftWindowsServer	WindowsServer	2016-Datacenter-gensecond
MicrosoftWindowsServer	WindowsServer	2016-Datacenter-gs
MicrosoftWindowsServer	WindowsServer	2016-Datacenter-smalldisk
MicrosoftWindowsServer	WindowsServer	2016-Datacenter-with-Containers
MicrosoftWindowsServer	WindowsServer	2016-Datacenter-with-containers-gs
MicrosoftWindowsServer	WindowsServer	2019-Datacenter
MicrosoftWindowsServer	WindowsServer	2019-Datacenter-Core
MicrosoftWindowsServer	WindowsServer	2019-Datacenter-Core-with-Containers
MicrosoftWindowsServer	WindowsServer	2019-Datacenter-gensecond
MicrosoftWindowsServer	WindowsServer	2019-Datacenter-gs
MicrosoftWindowsServer	WindowsServer	2019-Datacenter-smalldisk
MicrosoftWindowsServer	WindowsServer	2019-Datacenter-with-Containers
MicrosoftWindowsServer	WindowsServer	2019-Datacenter-with-Containers-gs
MicrosoftWindowsServer	WindowsServer	2022-Datacenter
MicrosoftWindowsServer	WindowsServer	2022-Datacenter-smalldisk
MicrosoftWindowsServer	WindowsServer	2022-Datacenter-smalldisk-g2
MicrosoftWindowsServer	WindowsServer	2022-Datacenter-core
MicrosoftWindowsServer	WindowsServer	2022-Datacenter-core-smalldisk
MicrosoftWindowsServer	WindowsServer	2022-Datacenter-g2
MicrosoftWindowsServer	WindowsServer	Datacenter-core-20h2-with-containers-smalldisk-gs
MicrosoftWindowsServer	WindowsServer	2022-Datacenter-azure-edition
MicrosoftWindowsServer	WindowsServer	2022-Datacenter-azure-edition-smalldisk
Мирантис	Windows_with_Mirantis_Container_Runtime_2019	win_2019_mcr_23_0
Мирантис	Windows_with_Mirantis_Container_Runtime_2019	win_2019_mcr_23_0_gen2

Требования к настройке автоматического обновления образа ОС

• Для свойства версии образа должно быть задано последнее значение.
• Необходимо использовать пробы работоспособности приложений или расширение работоспособности приложения для масштабируемых наборов, не связанных с Service Fabric. Дополнительные сведения см. в разделе Требования к Service Fabric.
• Используйте API Вычислений версии 2018-10-01 или более поздней.
• Убедитесь, что внешние ресурсы, указанные в модели масштабируемого набора, доступны и обновлены. Примеры включают универсальный код ресурса (URI) SAS для начальной загрузки полезных данных в свойствах расширения виртуальной машины, полезные данные в учетной записи хранения, ссылки на секреты в модели и многое другое.
• Для масштабируемых наборов с помощью виртуальных машин Windows, начиная с API вычислений версии 2019-03-01, свойство virtualMachineProfile.osProfile.windowsConfiguration.enableAutomaticUpdates должно иметь значение false в определении модели масштабируемого набора. Свойство enableAutomaticUpdates позволяет выполнять исправления в виртуальной машине, когда Центр обновления Windows применяет исправления операционной системы без замены диска ОС. При автоматическом обновлении образа ОС в масштабируемом наборе, который можно выполнить, установив для параметра automaticOSUpgradePolicy.enableAutomaticOSUpgrade значение true, дополнительный процесс исправления через Обновл. Windows не требуется.
• Режим оркестрации исправлений не должен быть задан AutomaticByPlatform в определении модели масштабируемого набора. При автоматическом обновлении образа ОС, включенных в масштабируемом наборе, процесс исправления оркестрации платформы не требуется.

Требования к Service Fabric

При использовании Service Fabric убедитесь, что выполняются следующие условия.

• Уровень устойчивости Service Fabric должен быть Silver или Gold. Если устойчивость Service Fabric является бронзовой, только типы узлов без отслеживания состояния поддерживают автоматическое обновление образа ОС).
• Расширение Service Fabric в определении модели масштабируемого набора должно иметь версию TypeHandlerVersion 1.1 или более позднюю.
• В определении модели масштабируемого набора должен быть задан одинаковый уровень устойчивости для кластера Service Fabric и расширения Service Fabric.
• В случае устойчивости Silver или Gold дополнительная проба работоспособности или использование расширения работоспособности приложений не требуется. Устойчивость Bronze с узлами только без отслеживания состояния требует дополнительной пробы работоспособности.
• Свойство virtualMachineProfile.osProfile.windowsConfiguration.enableAutomaticUpdates должно иметь значение false в определении модели масштабируемого набора. Свойство enableAutomaticUpdates включает установку исправлений в виртуальной машине с помощью Центра обновления Windows и не поддерживается в масштабируемых наборах Service Fabric. Вместо этого следует использовать свойство automaticOSUpgradePolicy.enableAutomaticOSUpgrade .

Убедитесь, что отсутствуют несоответствия параметров устойчивости в кластере Service Fabric и расширении Service Fabric, так как несоответствие приведет к ошибкам обновления. Уровни устойчивости можно изменять в соответствии с рекомендациями, приведенными на этой странице.

Автоматическое обновление образа ОС для пользовательских образов

Автоматическое обновление образа ОС поддерживается для пользовательских образов, развернутых с помощью коллекции вычислений Azure. Другие пользовательские образы в автоматическом обновлении образа ОС не поддерживаются.

Дополнительные требования для пользовательских образов

• Процесс установки и настройки автоматического обновления образа ОС одинаков для всех масштабируемых наборов, как описано в разделе "Конфигурация" этой страницы.
• Экземпляры масштабируемых наборов, настроенные для автоматического обновления образов ОС, будут обновлены до версии образа коллекции вычислений Azure при публикации и репликации в регион масштабируемого набора. Если новый образ не реплицируется в регион, где развернут масштаб, экземпляры масштабируемого набора не будут обновлены до версии. Региональная репликация образов позволяет управлять выпуском нового образа для масштабируемых наборов.
• Новая версия образа не должна быть исключена из версии для этого образа коллекции. Версии образа, исключенные из версии образа коллекции, не развертываются в масштабируемом наборе с помощью автоматического обновления образа ОС.

Настройка автоматического обновления образа ОС

Чтобы настроить автоматическое обновление образа ОС, убедитесь, что свойство automaticOSUpgradePolicy.enableAutomaticOSUpgrade установлено как true в определении модели масштабируемого набора.

REST API

В следующем примере описано, как настроить автоматические обновления ОС в модели масштабируемого набора.

PUT or PATCH on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet?api-version=2021-03-01`

{
  "properties": {
    "upgradePolicy": {
      "automaticOSUpgradePolicy": {
        "enableAutomaticOSUpgrade":  true
      }
    }
  }
}

Azure PowerShell

Используйте командлет New-AzVmss, чтобы настроить автоматическое обновление образа ОС для масштабируемого набора во время подготовки. В следующем примере настраиваются автоматические обновления масштабируемого набора myScaleSet в группе ресурсов myResourceGroup.

New-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -AutomaticOSUpgrade $true

Используйте командлет Update-AzVmss, чтобы настроить автоматическое обновление образа ОС для существующего масштабируемого набора. В следующем примере настраиваются автоматические обновления масштабируемого набора myScaleSet в группе ресурсов myResourceGroup.

Update-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -AutomaticOSUpgrade $true

Azure CLI 2.0

Используйте az vmss create , чтобы настроить автоматическое обновление образа ОС для масштабируемого набора во время подготовки. Использование Azure CLI 2.0.47 или более поздней версии В следующем примере настраиваются автоматические обновления масштабируемого набора myScaleSet в группе ресурсов myResourceGroup.

az vmss create --name myScaleSet --resource-group myResourceGroup --enable-auto-os-upgrade true --upgrade-policy-mode Rolling

Используйте az vmss update , чтобы настроить автоматическое обновление образа ОС для существующего масштабируемого набора. Использование Azure CLI 2.0.47 или более поздней версии В следующем примере настраиваются автоматические обновления масштабируемого набора myScaleSet в группе ресурсов myResourceGroup.

az vmss update --name myScaleSet --resource-group myResourceGroup --enable-auto-os-upgrade true --upgrade-policy-mode Rolling

Шаблоны ARM

В следующем примере описывается настройка автоматического обновления ОС в модели масштабируемого набора с помощью шаблонов Azure Resource Manager (шаблоны ARM):

"properties": {
   "upgradePolicy": {
     "mode": "Automatic",
     "RollingUpgradePolicy": {
         "BatchInstancePercent": 20,
         "MaxUnhealthyInstancePercent": 25,
         "MaxUnhealthyUpgradedInstancePercent": 25,
         "PauseTimeBetweenBatches": "PT0S"
     },
    "automaticOSUpgradePolicy": {
      "enableAutomaticOSUpgrade": true,
        "useRollingUpgradePolicy": true,
        "disableAutomaticRollback": false
    }
  },
  },
"imagePublisher": {
   "type": "string",
   "defaultValue": "MicrosoftWindowsServer"
 },
 "imageOffer": {
   "type": "string",
   "defaultValue": "WindowsServer"
 },
 "imageSku": {
   "type": "string",
   "defaultValue": "2022-datacenter"
 },
 "imageOSVersion": {
   "type": "string",
   "defaultValue": "latest"
 }

Bicep

В следующем примере описывается настройка автоматического обновления ОС в модели масштабируемого набора с помощью Bicep:

properties: {
    overprovision: overProvision
    upgradePolicy: {
      mode: 'Automatic'
      automaticOSUpgradePolicy: {
        enableAutomaticOSUpgrade: true
      }
    }
}

Использование расширения работоспособности приложений

Во время обновления ОС экземпляры виртуальных машин в масштабируемом наборе обновляются по одному пакету. Обновление должно продолжаться, только если приложение клиента работоспособно на обновленных экземплярах виртуальных машин. Мы рекомендуем настроить приложение таким образом, чтобы оно сообщало о работоспособности в модуль обновления ОС масштабируемого набора. По умолчанию при обновлении ОС платформа анализирует состояние энергопотребления виртуальной машины и состояние подготовки расширений, чтобы определить, является ли экземпляр виртуальной машины работоспособным после обновления. Во время обновления ОС экземпляра виртуальной машины диск ОС экземпляра заменяется новым диском на основе последней версии образа. После обновления ОС настроенные расширения запускаются на этих виртуальных машинах. Приложение считается работоспособным, только если все расширения в экземпляре успешно подготовлены.

Для масштабируемого набора можно дополнительно настроить проверки работоспособности приложений, с помощью которых платформа сможет получать точную информацию о текущем состоянии приложения. Проверки работоспособности приложения — это проверки пользовательского балансировщика нагрузки, которые используются в качестве сообщения о работоспособности. Приложение, работающее на экземпляре виртуальной машины из масштабируемого набора, может отвечать на внешние HTTP- или TCP-запросы, указывающие на его работоспособность. Дополнительные сведения о работе проверок пользовательского балансировщика нагрузки см. в статье Проверки балансировщика нагрузки. Пробы работоспособности приложений не поддерживаются для масштабируемых наборов Service Fabric. Для не связанных с Service Fabric масштабируемых наборов требуются или проверки работоспособности приложения Load Balancer, или расширение работоспособности приложения.

Если масштабируемый набор настроен для использования нескольких групп размещения, необходимо использовать проверки с балансировщиком нагрузки уровня "Стандартный".

Настройка пользовательской проверки балансировщика нагрузки в качестве проверки работоспособности приложения в масштабируемом наборе

Мы рекомендуем явно создать проверку балансировщика нагрузки на работоспособность масштабируемого набора. Вы можете использовать одну конечную точку для имеющейся пробы HTTP или TCP, но для пробы работоспособности может потребоваться подход, отличный от традиционного для пробы подсистемы балансировки нагрузки. Например, при традиционной проверке подсистемы балансировки нагрузки может вернуться сообщение о нерабочем состоянии, если нагрузка на экземпляр слишком высока. Такая проверка может оказаться непригодной для определения работоспособности экземпляра во время автоматического обновления ОС. Настройте для проверки высокую частоту (менее двух минут).

Проверка балансировщика нагрузки может быть указана в параметре networkProfile масштабируемого набора и может быть связана либо с внутренним, либо с общедоступным балансировщиком нагрузки следующим образом:

"networkProfile": {
  "healthProbe" : {
    "id": "[concat(variables('lbId'), '/probes/', variables('sshProbeName'))]"
  },
  "networkInterfaceConfigurations":
  ...
}

Использование расширения "Работоспособность приложения"

Расширение "Работоспособности приложений" развертывается в экземпляре масштабируемого набора виртуальных машин и сообщает о работоспособности виртуальной машины из экземпляра масштабируемого набора. Вы можете настроить расширение так, чтобы оно проверяло конечную точку приложения и обновляло состояние приложения на этом экземпляре. Azure проверяет состояние этого экземпляра, чтобы определить, подходит ли экземпляр для операций обновления.

Так как расширение сообщает о состоянии работоспособности из виртуальной машины, это расширение можно применять в ситуациях, когда внешние пробы, например, пробы работоспособности приложений (использующие пользовательские пробы Azure Load Balancer), не могут использоваться.

Существует несколько способов развертывания расширения "Работоспособность приложения" в масштабируемые наборы, которые описаны в этой статье.

Получение журнала автоматического обновления образа ОС

Вы можете проверить журнал последнего обновления ОС масштабируемого набора с помощью Azure PowerShell, Azure CLI 2.0 или интерфейсов REST API. Можно просмотреть журнал для последних пяти попыток обновлений операционной системы в течение последних двух месяцев.

Поддержание актуальности учетных данных

Если ваш масштабируемый набор использует какие-либо учетные данные для доступа к внешним ресурсам, например, если в расширении VM настроено использование маркера SAS для учетной записи хранения, убедитесь, что учетные данные обновлены. Если срок действия всех учетных данных, в том числе сертификатов и маркеров, истек, обновление завершится сбоем, и первый пакет виртуальных машин останется в состоянии сбоя.

В случае сбоя аутентификации ресурса рекомендуем выполнить следующие шаги по восстановлению виртуальных машин и повторному включению автоматического обновления ОС.

• Повторно создайте маркер (или любые другие учетные данные), переданный в ваши расширения.
• Убедитесь, что все учетные данные, используемые внутри виртуальной машины для взаимодействия с внешними сущностями, обновлены.
• Обновите расширения в модели масштабируемого набора с новыми маркерами.
• Разверните обновленный масштабируемый набор, в котором будут обновлены все экземпляры виртуальных машин, включая сбойные.

REST API

В следующем примере используется REST API для проверки состояния масштабируемого набора myScaleSet в группе ресурсов myResourceGroup.

GET on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet/osUpgradeHistory?api-version=2021-03-01`

Вызов GET возвращает подобные свойства:

{
	"value": [
		{
			"properties": {
        "runningStatus": {
          "code": "RollingForward",
          "startTime": "2018-07-24T17:46:06.1248429+00:00",
          "completedTime": "2018-04-21T12:29:25.0511245+00:00"
        },
        "progress": {
          "successfulInstanceCount": 16,
          "failedInstanceCount": 0,
          "inProgressInstanceCount": 4,
          "pendingInstanceCount": 0
        },
        "startedBy": "Platform",
        "targetImageReference": {
          "publisher": "MicrosoftWindowsServer",
          "offer": "WindowsServer",
          "sku": "2016-Datacenter",
          "version": "2016.127.20180613"
        },
        "rollbackInfo": {
          "successfullyRolledbackInstanceCount": 0,
          "failedRolledbackInstanceCount": 0
        }
      },
      "type": "Microsoft.Compute/virtualMachineScaleSets/rollingUpgrades",
      "location": "westeurope"
    }
  ]
}

Azure PowerShell

Используйте командлет Get-AzVmss, чтобы проверить журнал обновлений ОС для масштабируемого набора. В следующем примере показано, как проверить состояние обновления ОС масштабируемого набора myScaleSet в группе ресурсов myResourceGroup:

Get-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -OSUpgradeHistory

Azure CLI 2.0

Используйте командлет az vmss get-os-upgrade-history, чтобы проверить журнал обновления ОС масштабируемого набора. Использование Azure CLI 2.0.47 или более поздней версии В следующем примере показано, как проверить состояние обновления ОС масштабируемого набора myScaleSet в группе ресурсов myResourceGroup:

az vmss get-os-upgrade-history --resource-group myResourceGroup --name myScaleSet

Как получить последнюю версию образа платформы ОС?

Вы можете получить доступные версии образов для автоматического обновления ОС (для поддерживаемых номеров SKU), используя приведенные ниже примеры.

REST API

GET on `/subscriptions/subscription_id/providers/Microsoft.Compute/locations/{location}/publishers/{publisherName}/artifacttypes/vmimage/offers/{offer}/skus/{skus}/versions?api-version=2021-03-01`

Azure PowerShell

Get-AzVmImage -Location "westus" -PublisherName "Canonical" -offer "0001-com-ubuntu-server-jammy" -sku "22_04-lts"

Azure CLI 2.0

az vm image list --location "westus" --publisher "Canonical" --offer "0001-com-ubuntu-server-jammy" --sku "22_04-lts" --all

Активация обновления образа ОС вручную

Если в масштабируемом наборе включено автоматическое обновление образа ОС, вам не нужно вручную активировать обновления образов в масштабируемом наборе. Оркестратор обновлений ОС автоматически применит последнюю доступную версию образа к экземплярам масштабируемого набора, не требуя ручного вмешательства.

В особых случаях, когда вы не хотите ждать, пока оркестратор применит последнюю версию образа, можно активировать обновление образа ОС вручную, используя приведенные ниже примеры.

REST API

Вызов API обновления начальной ОС используется для запуска последовательного обновления для перемещения всех экземпляров масштабируемого набора виртуальных машин в последнюю доступную версию ОС образа. Экземпляры, которые уже используют последнюю доступную версию ОС, не затрагиваются. В следующем примере показано, как запустить последовательное обновление ОС масштабируемого набора с именем myScaleSet в группе ресурсов myResourceGroup:

POST on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet/osRollingUpgrade?api-version=2021-03-01`

Azure PowerShell

Чтобы проверить журнал обновлений ОС для масштабируемого набора, используйте командлет Start-AzVmssRollingOSUpgrade. В следующем примере показано, как запустить последовательное обновление ОС масштабируемого набора с именем myScaleSet в группе ресурсов myResourceGroup:

Start-AzVmssRollingOSUpgrade -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet"

Azure CLI 2.0

Чтобы проверить журнал обновлений ОС для масштабируемого набора, используйте команду az vmss rolling-upgrade start. Использование Azure CLI 2.0.47 или более поздней версии В следующем примере показано, как запустить последовательное обновление ОС масштабируемого набора с именем myScaleSet в группе ресурсов myResourceGroup:

az vmss rolling-upgrade start --resource-group "myResourceGroup" --name "myScaleSet" --subscription "subscriptionId"

Использование журналов действий для уведомлений об обновлении и аналитики

Журнал действий — это журнал подписки, который содержит сведения о событиях уровня подписки, произошедших в Azure. Клиенты могут:

• Сведения о событиях, связанных с операциями, выполняемыми в портал Azure
• Создание групп действий для настройки методов уведомлений, таких как электронная почта, sms, веб-перехватчики или ITSM
• Настройка подходящих оповещений с помощью различных критериев с помощью портала, шаблона ресурсов ARM, PowerShell или CLI для отправки в группы действий

Клиенты получат три типа уведомлений, связанных с операцией автоматического обновления ОС:

• Отправка запроса на обновление для определенного ресурса
• Результат запроса на отправку вместе с любыми сведениями об ошибке
• Результат завершения обновления вместе с любыми сведениями об ошибке

Настройка групп действий для оповещений журнала действий

Группа действий — это коллекция параметров уведомлений, которые определены владельцем подписки Azure. Оповещения служб Azure Monitor и "Работоспособность служб" используют группы действий для уведомления пользователей о том, что оповещение активировано.

Группы действий можно создавать и управлять ими с помощью:

• ARM Resource Manager
• Портал
• PowerShell:
  • New-AzActionGroup
  • Get-AzActionGroup
  • Remove-AzActionGroup
• CLI

Клиенты могут настроить следующие группы действий:

• Sms и (или) Уведомления по электронной почте
• Веб-перехватчики — клиенты могут присоединять веб-перехватчики к модулям Runbook службы автоматизации и настраивать их группы действий для активации модулей Runbook. Модуль Runbook можно запустить из веб-перехватчика.
• ПОДКЛЮЧЕНИЯ ITSM

Изучение и устранение ошибок автоматического обновления

Платформа может возвращать ошибки на виртуальных машинах при выполнении автоматического обновления образа с помощью политики последовательного обновления. Представление экземпляра виртуальной машины содержит подробное сообщение об ошибке для исследования и устранения ошибки. Последовательное обновление — получение последних сведений может предоставить дополнительные сведения о конфигурации и состоянии последовательного обновления. Журнал обновления ОС получает сведения о последней операции обновления образа в масштабируемом наборе. Ниже приведены самые верхние ошибки, которые могут привести к последовательному обновлению.

RollingUpgradeInProgressWithFailedUpgradedVMs

• Ошибка активируется для сбоя виртуальной машины.
• Подробное сообщение об ошибке указывает, будет ли развертывание продолжаться или приостановиться на основе заданного порогового значения.

MaxUnhealthyUpgradedInstancePercentExceededInRollingUpgrade

• Ошибка активируется, когда процент обновленных виртуальных машин превышает максимальное пороговое значение, допустимое для неработоспособных виртуальных машин.
• Подробное сообщение об ошибке объединяет наиболее распространенную ошибку, способствующую неработоспособным виртуальным машинам. См. раздел MaxUnhealthyUpgradedInstancePercent.

MaxUnhealthyInstancePercentExceededInRollingUpgrade

• Ошибка активируется, когда процент неработоспособных виртуальных машин превышает максимальное пороговое значение, допустимое для неработоспособных виртуальных машин во время обновления.
• Подробное сообщение об ошибке отображает текущий неработоспособный процент и настроенный допустимый процент неработоспособной виртуальной машины. См . maxUnhealthyInstancePercent.

MaxUnhealthyInstancePercentExceededBeforeRollingUpgrade

• Ошибка активируется, когда процент неработоспособных виртуальных машин превышает максимальное пороговое значение, допустимое для неработоспособных виртуальных машин перед обновлением.
• Подробное сообщение об ошибке отображает текущий неработоспособный процент и настроенный допустимый процент неработоспособной виртуальной машины. См . maxUnhealthyInstancePercent.

InternalExecutionError

• Ошибка активируется, когда необработанная, неформатированная или непредвиденная возникает во время выполнения.
• Подробное сообщение об ошибке отображает причину ошибки.

RollingUpgradeTimeoutError

• Ошибка активируется при истечении времени ожидания процесса последовательного обновления.
• Подробное сообщение об ошибке отображает время ожидания системы после попытки обновления.

Следующие шаги