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

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

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

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

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

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

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

Обновления с приоритетом доступности

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

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

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

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

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

В наборе:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Для свойства версии образа должно быть задано последнее значение.
• Необходимо использовать пробы работоспособности приложений или расширение работоспособности приложения для масштабируемых наборов, не связанных с 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 не требуется.
• Режим оркестрации исправлений не должен быть задан в определении модели масштабируемого набора. При автоматическом обновлении образа ОС, включенных в масштабируемом наборе, процесс исправления оркестрации платформы не требуется.

Требования к 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 Update и не поддерживается в масштабируемых наборах Service Fabric. Вместо этого следует использовать свойство automaticOSUpgradePolicy.enableAutomaticOSUpgrade .

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

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

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

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

• Процесс установки и настройки автоматического обновления образа ОС одинаков для всех масштабируемых наборов, как описано в разделе "Конфигурация" этой страницы.
• Экземпляры масштабируемых наборов, настроенные для автоматического обновления образов ОС, обновляются до версии образа из Галереи Compute 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, или Application Health extension.

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

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

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

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

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

Использование расширения Application Health

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

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

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

Настройка пользовательских метрик для «поэтапного обновления» в масштабируемых наборах виртуальных машин (предварительный просмотр)

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

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

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

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

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

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

Если масштабируемый набор использует любые учетные данные для доступа к внешним ресурсам, например расширение виртуальной машины, настроенное для использования маркера 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 Start OS Upgrade используется для запуска последовательного обновления всех экземпляров масштабируемого набора виртуальных машин до последней доступной версии образа ОС. Экземпляры, которые уже используют последнюю доступную версию ОС, не затрагиваются. В следующем примере показано, как начать поочередное обновление ОС в масштабируемом наборе с именем 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 и Service Health используют группы действий для уведомления пользователей о том, что сработало оповещение.

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

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

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

• Sms и (или) Уведомления по электронной почте
• Веб-перехватчики — клиенты могут присоединять веб-перехватчики к модулям Runbook службы автоматизации и настраивать их группы действий для активации модулей Runbook. Вы можете запустить runbook из вебхука.
• Подключения ITSM

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

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

Постепенное обновление в процессе с ошибками при обновлении ВМ

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

Максимальный процент нерабочих обновленных экземпляров превышен в пошаговом обновлении

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

MaxUnhealthyInstancePercentExceededInRollingUpgrade

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

MaxUnhealthyInstancePercentExceededBeforeRollingUpgrade Превышен максимальный процент нездоровых экземпляров перед обновлением без остановки.

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

InternalExecutionError

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

RollingUpgradeTimeoutError

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

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