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

  • Статья

Важно!

С 30 апреля 2019 г. приложение Patch Orchestration Application версии 1.2.* больше не поддерживается. Проведите обновление до последней версии.

Приложение Patch Orchestration Application (POA) — это оболочка для службы "Диспетчер восстановления Azure Service Fabric", которая позволяет планировать график проведения исправлений ОС на основе конфигурации для кластеров, не размещаемых в Azure. POA не является обязательным приложением для кластеров, не размещаемых в Azure, но планирование установки исправлений доменами обновления обязательно, так как обеспечивает проведение исправлений в узлах кластеров Service Fabric без остановки работы.

POA — это приложение Service Fabric, которое автоматизирует установку исправлений операционной системы в кластере Service Fabric без остановки работы.

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

  • Автоматическая установка обновлений операционной системы. Обновления операционной системы автоматически загружаются и устанавливаются. Узлы кластера перезагружаются без остановки работы кластера (активируется при необходимости).

  • Исправление с учетом состояния кластера и интеграция функций работоспособности. Пока POA применяет обновления, он одновременно отслеживает работоспособность узлов кластера. Узлы кластера обновляются поочередно или по одному домену обновления за раз. Если из-за установки исправлений работоспособность кластера понижается, процесс останавливается, чтобы проблема не усугублялась.

Сведения о внутренней организации приложения POA

POA состоит из следующих компонентов:

  • Служба координатора — эта служба с отслеживанием состояния отвечает за следующие задачи:

    • координация задания обновления Windows во всем кластере;
    • хранение результатов завершенных операций обновления Windows.

  • Служба агента узла — это служба без отслеживания состояния, которая выполняется на всех узлах кластера Service Fabric. Она отвечает за следующие задачи:

    • начальная загрузка NTService агента узла;
    • мониторинг службы NTService агента узла.

  • Служба NTService агента узла — служба Windows NT, которая выполняется с разрешением высокого уровня (СИСТЕМА). Для сравнения служба агента узла и служба координатора выполняются с разрешением более низкого уровня (СЕТЕВАЯ СЛУЖБА). Служба отвечает за выполнение следующих заданий обновления Windows на всех узлах кластера:

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

Примечание

Приложение POA использует для включения и выключения узла, а также для проверки работоспособности, системную службу Service Fabric, которая называется "Диспетчер восстановления". Задание восстановления, созданное POA, отслеживает ход обновления Windows по каждому узлу.

Предварительные требования

Примечание

Требуемая версия .NET Framework — 4.6 (минимум).

Включение службы "Диспетчер восстановления" (если она еще не запущена)

Приложению POA необходимо, чтобы в кластере был включен "Диспетчер восстановления".

Кластеры Azure

В кластерах Azure на "серебряном" уровне надежности служба "Диспетчер восстановления" включена по умолчанию. В кластерах Azure на "золотом" уровне надежности служба "Диспетчер восстановления" может быть не включена; зависит от того, когда были созданы кластеры. В кластерах Azure на "бронзовом" уровне надежности служба "Диспетчер восстановления" по умолчанию не включена. Если служба уже включена, сведения о ее работе отображаются в разделе системных служб в Service Fabric Explorer.

Портал Azure

Вы можете включить "Диспетчер восстановления" из портала Azure, при настройке кластера. При настройке кластера выберите параметр включить "Диспетчер восстановления" в разделе Дополнительные возможности.

Изображение с подключением

Модель развертывания с помощью Azure Resource Manager

Также, службу "Диспетчер восстановления" для новых и существующих кластеров Service Fabric можно включить с помощью модели развертывания Azure Resource Manager. Получите шаблон для кластера, который требуется развернуть. Можно использовать примеры шаблонов или создать пользовательский шаблон модели развертывания Azure Resource Manager.

Чтобы включить службу "Диспетчер восстановления" с помощью Шаблона модели развертывания Azure Resource Manager, сделайте следующее:

  1. Убедитесь, что для ресурса Microsoft. ServiceFabric/Clusters параметр apiVersionустановлен на 2017-07-01-Preview. Если это не так, необходимо выполнить обновление apiVersion до 2017-07-01-Preview или более поздней версии.

    {
    "apiVersion": "2017-07-01-preview",
    "type": "Microsoft.ServiceFabric/clusters",
    "name": "[parameters('clusterName')]",
    "location": "[parameters('clusterLocation')]",
    ...
}

  2. Включите службу "Диспетчер восстановления", добавив следующий раздел addonFeatures после раздела fabricSettings:

    "fabricSettings": [
    ...      
],
"addonFeatures": [
    "RepairManager"
],

  3. После обновления вашего шаблона кластера примените все эти изменения и дождитесь завершения обновления. Теперь вы видите, что в вашем кластере работает служба "Диспетчер восстановления". В разделе системных служб Service Fabric Explorer она именуется как fabric:/System/RepairManagerService.

Автономные локальные кластеры

Чтобы включить службу "Диспетчер восстановления" в новых и существующих кластерах Service Fabric, можно использовать Параметры конфигурации для автономного кластера Windows.

Чтобы включить службу "Диспетчер восстановления":

  1. Убедитесь, что apiVersion в разделе Общие конфигурации кластера установлено значение 04-2017 или более поздняя версия, как показано ниже:

    {
    "name": "SampleCluster",
    "clusterConfigurationVersion": "1.0.0",
    "apiVersion": "04-2017",
    ...
}

  2. Включите службу "Диспетчер восстановления", добавив раздел addonFeatures после раздела fabricSettings, как показано ниже.

    "fabricSettings": [
    ...      
],
"addonFeatures": [
    "RepairManager"
],

  3. Обновите манифест кластера, добавив эти изменения с помощью обновленного манифеста кластера Создание кластера или Обновление конфигурации кластера.

    После того как кластер станет работать с обновленным манифестом, вы увидите службу "Диспетчер восстановления", работающую в вашем кластере. В разделе системных служб Service Fabric Explorer она именуется как fabric:/System/RepairManagerService.

Настройка обновлений Windows для всех узлов

Автоматическое обновление Windows может привести к потере доступности из-за одновременного перезапуска нескольких узлов кластера. По умолчанию POA попытается выключить автоматическое обновление Windows на каждом узле кластера. Таким образом, если параметры задаются администратором или групповой политикой, в политике Центра обновления Windows советуем обязательно настроить параметр "Оповещать перед скачиванием".

Скачивание пакета приложения

Чтобы скачать пакет приложения, перейдите на страницу Patch Orchestration Application release в репозитории GitHub.

Настройка поведения POA

Вы можете настроить поведение POA в соответствии с вашими потребностями. Переопределите значения по умолчанию, передав параметры приложения во время создания или обновления данного приложения. Параметры приложения можно задать, указав ApplicationParameter в командлете Start-ServiceFabricApplicationUpgrade или New-ServiceFabricApplication.

Параметр Тип Сведения
MaxResultsToCache Long Максимальное количество результатов обновления Windows, которые необходимо кэшировать.

Значение по умолчанию — 3000 при условии, что:
  - количество узлов — 20.
  - количество обновлений на одном узле в месяц — 5;
  - количество результатов на операцию может быть 10;
  - результаты сохраняются за последние три месяца.
TaskApprovalPolicy Перечисление
{ NodeWise, UpgradeDomainWise }		 TaskApprovalPolicy указывает политику, которая будет использоваться службой координатора для установки обновлений Windows на узлы кластера Service Fabric.

Допустимые значения:
NodeWise: обновления Windows устанавливаются на один узел за раз.
UpgradeDomainWise: обновления Windows устанавливаются по одному домену обновления за раз. (как максимум на всех узлах, принадлежащих домену обновления, может пройти обновление Windows).

Чтобы решить, какая политика лучше всего подходит для кластера, см. раздел Часто задаваемые вопросы.
LogsDiskQuotaInMB Long
(По умолчанию: 1024)		 Максимальный размер журналов приложений для оркестрации исправлений, остающихся локально на узле (в мегабайтах).
WUQuery строка
(По умолчанию: IsInstalled=0)		 Запрос на получение обновлений Windows. Дополнительные сведения см. в разделе WuQuery.
InstallWindowsOSOnlyUpdates Boolean
(значение по умолчанию — false)		 Используйте этот флаг, чтобы контролировать, какие обновления следует скачать и установить. Допустимы следующие значения:
true — устанавливает только обновления операционной системы Windows;
false — устанавливает все доступные обновления на компьютере.
WUOperationTimeOutInMinutes Int
(По умолчанию: 90)		 Указывает время ожидания для любой операции обновления Windows (поиск, скачивание или установка). Если операция не завершена по истечении заданного времени ожидания, она будет прервана.
WURescheduleCount Int
(По умолчанию: 5)		 Максимальное количество изменений графика обновления Windows в случае постоянных сбоев операции.
WURescheduleTimeInMinutes Int
(По умолчанию: 30)		 Интервал, с которым служба будет изменять график обновления Windows, если сбой продолжает происходить.
WUFrequency Строка с разделителями-запятыми (по умолчанию: Weekly, Wednesday, 7:00:00) Частота установки обновлений Windows. Формат и возможные значения:
- Ежемесячно, ДД, ЧЧ:ММ:СС (пример: Monthly, 5, 12:22:32); Допустимыми значениями для поля DD (день) являются числа от 1 до 28 и last(последняя).
- Еженедельно, День, ЧЧ:ММ:СС (например: Weekly, Tuesday, 12:22:32);
- Ежедневно, ЧЧ:ММ:СС (например: Daily, 12:22:32);
-MonthlyByWeekAndDay, неделя, день, ЧЧ:ММ:СС (например: MonthlyByWeekAndDay, 2, Friday, 21:00:00, что означает 9:00 по Гринвичу, по пятницам, каждую вторую неделю, каждый месяц)
- None — указывает на то, что обновление Windows выполнять не следует.

Все значения времени указаны в формате UTC.
AcceptWindowsUpdateEula Логическое
(По умолчанию: true)		 Если этот флажок установлен, приложение принимает условия лицензионного соглашения Центра обновления Windows от имени владельца компьютера.

Совет

Чтобы обновление Windows началось сразу, установите WUFrequency в соответствии с временем развертывания приложения. Например, у вас тестовый кластер с пятью узлами и вы планируете развернуть приложение около 17:00 UTC. Если предположить, что обновление или развертывание приложения занимает не более 30 минут, задайте для WUFrequency значение Daily, 17:30:00 (ежедневно, 17:30:00).

Развертывание POA

  1. Завершите все предварительные шаги, чтобы подготовить кластер.

  2. Произведите развертывание POA, также как для любого приложения Service Fabric. О том как произвести развертывание с помощью PowerShell см. в статье Развертывание и удаление приложений с помощью PowerShell.

  3. Чтобы настроить приложение во время развертывания, передайте ApplicationParameter для командлета New-ServiceFabricApplication. Для вашего удобства мы сопроводили приложение сценарием Deploy.ps1. Использование сценария

    • Подключитесь к кластеру Service Fabric при помощи Connect-ServiceFabricCluster.
    • Выполните сценарий PowerShell Deploy.ps1 с соответствующим значением ApplicationParameter.

Примечание

Сохраните сценарий и папку приложения PatchOrchestrationApplication в одном каталоге.

Обновление POA

Чтобы обновить вашу версию POA при помощи PowerShell, выполните инструкции из статьи Обновление приложения Service Fabric с помощью PowerShell.

Удаление POA

Чтобы удалить это приложение, выполните инструкции из статьи Развертывание и удаление приложений с помощью PowerShell.

Для удобства, вместе с приложением мы предоставляем скрипт Undeploy.ps1. Использование сценария

  • Подключитесь к кластеру Service Fabric при помощи Connect-ServiceFabricCluster.
  • Выполните сценарий PowerShell Undeploy.ps1.

Примечание

Сохраните сценарий и папку приложения PatchOrchestrationApplication в одном каталоге.

Просмотр результатов обновления Windows

Приложение POA предоставляет пользователям REST API для отображения исторических результатов. Вот пример результата в формате JSON:

[
  {
    "NodeName": "_stg1vm_1",
    "WindowsUpdateOperationResults": [
      {
        "OperationResult": 0,
        "NodeName": "_stg1vm_1",
        "OperationTime": "2019-05-13T08:44:56.4836889Z",
        "OperationStartTime": "2019-05-13T08:44:33.5285601Z",
        "UpdateDetails": [
          {
            "UpdateId": "7392acaf-6a85-427c-8a8d-058c25beb0d6",
            "Title": "Cumulative Security Update for Internet Explorer 11 for Windows Server 2012 R2 (KB3185319)",
            "Description": "A security issue has been identified in a Microsoft software product that could affect your system. You can help protect your system by installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system.",
            "ResultCode": 0,
            "HResult": 0
          }
        ],
        "OperationType": 1,
        "WindowsUpdateQuery": "IsInstalled=0",
        "WindowsUpdateFrequency": "Daily,10:00:00",
        "RebootRequired": false
      }
    ]
  },
  ...
]

Описание полей JSON приводится в следующей таблице:

Поле Значения Сведения
OperationResult 0 — успешно
1 — выполнено с ошибками
2 — сбой
3 — прервано
4 — прервано с временем ожидания		 Указывает результат общей операции, которая обычно включает в себя установку одного или нескольких обновлений.
ResultCode Как и для OperationResult Это поле указывает результат операции установки отдельного обновления.
OperationType 1 — установка
0 — поиск и скачивание		 По умолчанию в результатах по типу операции (OperationType) отображается только "установка".
WindowsUpdateQuery Значение по умолчанию: IsInstalled=0 Запрос в Центр обновлений Windows, который использовался для поиска обновлений. Дополнительные сведения см. в разделе WuQuery.
RebootRequired true — требовалась перезагрузка
false — перезагрузка не требовалась		 Указывает, требовалась ли перезагрузка для завершения установки обновлений.
OperationStartTime Дата и время Указывает время запуска операции (загрузки/установки).
OperationTime Дата и время Указывает время завершения операции (загрузки/установки).
HResult 0 — Успешно
other — сбой		 Указывает причину сбоя обновления Windows с помощью updateID "7392acaf-6a85-427c-8a8d-058c25beb0d6".

Если обновление еще не запланировано, поле результата JSON будет пустым.

Для запроса результатов обновления Windows необходимо войти в кластер. Найдите IP-адрес реплики для первичной службы координатора и перейдите по этому URL-адресу в браузере: http://<REPLICA-IP>:<ApplicationPort>/PatchOrchestrationApplication/v1/GetWindowsUpdateResults.

Конечная точка REST для службы координатора имеет динамический порт. Чтобы узнать точный URL-адрес, см. Service Fabric Explorer. Например, результаты доступны в http://10.0.0.7:20000/PatchOrchestrationApplication/v1/GetWindowsUpdateResults.

Изображение конечной точки REST

Если в кластере включен обратный прокси-сервер, вы тоже можете получить доступ к URL-адресу за пределами кластера.

Конечная точка, к которой нужно перейти: http://<SERVERURL>:<REVERSEPROXYPORT>/PatchOrchestrationApplication/CoordinatorService/v1/GetWindowsUpdateResults.

Чтобы включить обратный прокси-сервер в кластере, следуйте инструкциям в разделе Обратный прокси-сервер в Azure Service Fabric.

Предупреждение

Настройка обратного прокси-сервера обеспечит адресацию извне этого кластера для всех микрослужб, предоставляющих конечную точку HTTP.

Диагностика и события проверки работоспособности

В этом разделе описывается отладка и диагностика проблем с обновлениями исправлений через POA на кластерах Service Fabric.

Примечание

Для того чтобы получить многие из следующих далее вызываемых обновлений (усовершенствования самодиагностики) необходимо установить POA версии 1.4.0 или более поздней версии.

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

Чтобы понять, как происходит процесс обновления на узле, давайте пройдем его шаг за шагом:

  1. Агент NodeAgentNTService, работающий на каждом узле, ищет доступные обновления Windows в запланированное по графику время. Если обновления доступны, он загружает их в узел.

  2. После загрузки обновлений Агент узла служба NTService создает соответствующую задачу восстановления для узла с именем POS___<уникальный_ID>. Данные задачи восстановления можно просмотреть с помощью командлета Get-ServiceFabricRepairTask или с помощью SFX в разделе сведений об узле. Как только задача восстановления создается, она быстро переходит в состояние Затребован.

  3. Служба координатора периодически ищет задачи восстановления в состоянии Затребован, а затем обновляет их до состоянияПодготовки согласно политике TaskApprovalPolicy. Если TaskApprovalPolicy настроена на NodeWise (по узлам), то задача восстановления, соответствующая узлу, подготавливается только в том случае, если в настоящее время на Подготовке, Утверждении, Исполненииили Восстановлении отсутствует какая-либо задача восстановления.

    Аналогично, в случае когда TaskApprovalPolicy настроена на UpgradeWise (по домену обновления), задачи в вышеупомянутых состояниях имеются только для узлов, принадлежащих одному домену обновления. После перемещения задачи восстановления в состояние Подготовки соответствующий узел Service Fabric отключается с намерением на Перезапуск.

    POA версии 1.4.0 и более поздних версий передают события с помощью свойства ClusterPatchingStatus на CoordinatorService для отображения обновляемых узлов. Обновления устанавливаются на узле _poanode_0, как показано на следующем рисунке:

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

  4. После отключения узла задача восстановления перемещается в состояние Выполнение.

    Примечание

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

  5. Когда задача восстановления оказывается в состоянии Выполнение, начинается установка исправления на этом узле. После установки исправления, узел может быть перезапущен или не перезапущен, в зависимости от характера самого исправления. Затем задача восстановления перемещается в состояние Восстановление, что повторно активирует узел. После этого задача восстановления помечается как завершенная.

    В POA Versions 1.4.0 и более поздних версий узнать состояние обновления можно просмотрев события проверки работоспособности на NodeAgentService с помощью свойства WUOperationStatus-<NodeName>. В выделенных строках на следующих изображениях показано состояние обновлений Windows на узлах poanode_0 и poanode_2.

    На снимке экрана отображается окно статусов операций Центра обновления Windows, выделен узел poanode_0.

    На снимке экрана отображается окно статусов операций Центра обновления Windows, выделен узел poanode_1.

    Также дополнительные сведения можно получить с помощью PowerShell. Для этого подключитесь к кластеру и извлеките состояние задачи восстановления с помощью команды Get-ServiceFabricRepairTask.

    В следующем примере задача "POS__poanode_2_125f2969-933c-4774-85d1-ebdf85e79f15" находится в состоянии DownloadComplete. Это означает, что обновления на узле poanode_2 были скачаны, и при переходе задачи в состояние Выполнение будет предпринята попытка установки.

     D:\service-fabric-poa-bin\service-fabric-poa-bin\Release> $k = Get-ServiceFabricRepairTask -TaskId "POS__poanode_2_125f2969-933c-4774-85d1-ebdf85e79f15"

 D:\service-fabric-poa-bin\service-fabric-poa-bin\Release> $k.ExecutorData
 {"ExecutorSubState":2,"ExecutorTimeoutInMinutes":90,"RestartRequestedTime":"0001-01-01T00:00:00"}

    Если остались еще проблемы, войдите в виртуальную машину (или виртуальные машины) и изучите эти проблемы в журналах событий Windows. Ранее упомянутая задача восстановления может существовать только в следующих состояниях исполнителя:

    ExecutorSubState Описание
    None = 1 Подразумевает, что на узле не выполнялась какая-либо текущая операция. Может находиться в состоянии перехода.
    DownloadCompleted=2 Подразумевает, что операция загрузки была выполнена успешно, частично или неудачно.
    InstallationApproved=3 Подразумевает, что операция загрузки была выполнена ранее и "Диспетчер восстановления" утвердил установку.
    InstallationInProgress=4 Соответствует состоянию выполнения задачи восстановления.
    InstallationCompleted=5 Подразумевает, что установка была выполнена успешно, частично или неудачно.
    RestartRequested=6 Подразумевает, что установка исправления завершена, а на узле есть ожидающее действие перезагрузки.
    RestartNotNeeded=7 Подразумевает, что после завершения установки исправления перезагрузка не требовалась.
    RestartCompleted=8 Подразумевает, что перезагрузка была выполнена успешно.
    OperationCompleted=9 Операция Центра обновления Windows выполнена успешно.
    OperationAborted=10 Подразумевает, что операция Центра обновления Windows была прервана.

  6. В POA версии 1.4.0 и более поздних версий, при попытке обновления узла, в службы агента узла будет отправлено событие со свойством "WUOperationStatus-[NodeName]", уведомляющее о том, когда начнется следующая попытка загрузки и установки обновлений Windows. Это показано на следующем изображении:

    На снимке экрана отображается окно статусов операций Центра обновления Windows, по службе NodeAgentService.

Раздел "Журналы диагностики"

Журналы Приложения для оркестрации исправлений собираются как часть журналов Service Fabric.

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

  • e39b723c-590c-4090-abb0-11e3e6616346
  • fc0028ff-bfdc-499f-80dc-ed922c52c5e9
  • 24afa313-0d3b-4c7c-b485-1047fd964b60
  • 05dc046c-60e9-4ef7-965e-91660adffa68

Отчеты о работоспособности

POA также публикует отчеты о работоспособности для Службы координатора или Службы агента узла в указанных ниже сценариях:

  • Служба NTService агента узла не работает

    Если на узле не работает служба NTService агента узла, генерируется отчет о работоспособности уровня предупреждения для службы агента узла.

  • Служба "Диспетчер восстановления" не актирована

    Если служба "Диспетчер восстановления" не найдена в кластере, для Службы координатора создается отчет уровня предупреждения.

Часто задаваемые вопросы

Вопрос. Почему кластер находится в состоянии ошибки, при этом POA работает?

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

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

По завершению установки обновлений Windows узлы будут активированы повторно, после перезагрузки.

В примере ниже кластер временно перешел в состояние ошибки, так как два узла вышли из строя и политика MaxPercentageUnhealthNodes была нарушена. Это временная ошибка. Она исчезнет, как только установка исправлений будет завершена.

Представление неработоспособного кластера

Если проблема не будет устранена, см. сведения в разделе об устранении неполадок.

Вопрос. Что можно сделать, если POA находится в состоянии предупреждения?

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

Вопрос. Что делать, если нужно срочно обновить операционную систему, а кластер неработоспособен?

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

Вопрос. Какое значение политики TaskApprovalPolicy, NodeWise или UpgradeDomainWise нужно выбрать для моего кластера?

Ответ. Параметр "UpgradeDomainWise" ускоряет общее восстановление кластера путем установки исправлений параллельно на всех узлах, принадлежащих домену обновления. Во время процесса, узлы, принадлежащие к целому домену обновления, недоступны (в состоянииОтключен).

В отличие от этого варианта, параметр "NodeWise" выполняет исправление только одного узла за раз, что означает, что установка всего исправления кластера может занять больше времени. При этом, будет недоступен максимум один узел (в состоянии Отключен) в течение процесса исправления.

Если ваш кластер допускает работу на N-1 доменах обновления в ходе цикла установки исправлений (где N — общее число доменов обновления в кластере), то можно задать политику как UpgradeDomainWise. В противном случае выберите вариант NodeWise.

Вопрос. Сколько времени уходит на установку исправлений одного узла?

Ответ. Установка исправлений на одном узле может занять от нескольких минут (например, для обновления определений Windows Defender) до нескольких часов (например, для накопительных обновлений Windows). Время, необходимое для исправлений на одном узле, главным образом, зависит от следующих факторов:

  • размер обновлений;
  • количество обновлений, которые должны быть применены за период исправления;
  • времени, необходимого для установки обновлений, перезагрузки узла (при необходимости) и завершения действий по установке после перезагрузки;
  • производительность виртуальной машины или компьютера, а также состояния сети.

Вопрос. Сколько времени уходит на исправление всего кластера?

Ответ. Время, необходимое для исправления всего кластера, зависит от следующих факторов:

  • Время, необходимое для установки исправлений на одном узле.

  • Политика службы координатора. Политика по умолчанию "NodeWise" направлена на исправление только одного узла за раз, этот подход медленнее, чем использование "UpgradeDomainWise".

    Например, если исправление узла занимает примерно 1 час, для применения исправлений к кластеру из 20 узлов (одного типа) с пятью доменами обновления, каждый из которых содержит 4 узла, требуется:

    • Для "NodeWise": ~ 20 часов.
    • Для "UpgradeDomainWise": ~ 5 часов.

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

  • Сбои работоспособности кластера во время установки исправлений. Любое снижениеработоспособности кластера приведет к прерыванию процесса исправления. Соответственно, увеличится общее время, необходимое для исправления всего кластера.

Вопрос. Почему некоторые обновления отображаются в результатах Центра обновления Windows, полученных через REST API, а не в журнале Центра обновлений Windows на компьютере?

Ответ. Некоторые обновления продукта отображаются только в журнале обновлений или исправлений. Например, сведения об обновлении Защитника Windows могут не отображаться в журнале Центра обновлений Windows в Windows Server 2016.

Вопрос. Можно ли с помощью POA решать проблемы в dev-кластере (одноузловой кластер)?

Ответ. Нет, POA нельзя использовать для исправлений в одноузловом кластере. Это ограничение обусловлено конструктивными особенностями, поскольку системные службы Service Fabric или другие клиентские приложения будут вынуждены простаивать. Таким образом, задания по восстановлению в режиме исправлений не будут утверждены "Диспетчером восстановления".

Вопрос. Как проводить установку исправлений на узлах кластера в Linux?

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

Вопрос. Почему цикл обновления занимает столько много времени?

Ответ. Направьте запрос к результирующему JSON, введите цикл обновления для всех узлов, а затем попробуйте узнать время, затрачиваемое на установку обновлений на каждом узле, с помощью OperationStartTime и OperationTime (OperationCompletionTime).

Если имеется большое временное окно, в котором не происходит обновление, кластер может находиться в состоянии ошибки и, следовательно, "Диспетчер восстановления" не может утвердить какие-либо задачи восстановления POA. Если установка обновления на любом узле занимает длительное время, возможно этот узел не обновлялся в течение определенного времени. Возможно, ожидается установка большого количества обновлений, что может привести к задержкам.

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

Вопрос. Зачем следует отключать узел при установке исправления POA?

Ответ. POA отключает узел с намерением Перезапуска, который останавливает или перераспределяет все службы Service Fabric, запущенные на узле. POA делает это для того, чтобы приложения не завершались из-за смешивания новых и старых DLL, поэтому мы рекомендуем не проводить установку исправлений на узле, не отключив его.

Вопрос. Какое максимальное количество узлов, которое можно обновить с помощью POA?

Ответ. POA использует "Диспетчер восстановления" Service Fabric для создания задач восстановления узлов с целью проведения обновлений. Однако в одно и то же время могут работать не более 250 задач восстановления. В настоящее время POA создает задачи восстановления для каждого узла одновременно, поэтому POA может обновлять не более 250 узлов в кластере.

Заявления об отказе от ответственности

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

  • Приложение для оркестрации исправлений собирает данные телеметрии для отслеживания использования и производительности. Телеметрия приложения выполняется в соответствии с настройкой телеметрии в среде выполнения Service Fabric (которая включена по умолчанию).

Устранение неполадок

В этом разделе приводятся возможные решения по устранению неполадок с узлами во время исправлений.

Узел не возвращается в рабочее состояние

  • Возможно узел завис состоянии Отключение, так как:

    • Проверка безопасности находится в состоянии ожидания. В этом случае необходимо убедиться, что достаточное количество узлов находятся в работоспособном состоянии.

  • Возможно узел завис состоянии Отключение, так как:

    • Он был отключен вручную.
    • Он был отключен в связи с текущим заданием в инфраструктуре Azure.
    • Он был отключен приложением POA для установки исправлений на узле.

  • Возможная причина, по которой узел остался в отключенном состоянии

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

Обновления на некоторых узлах пропущены

Приложение для оркестрации исправлений пытается установить обновление Windows согласно политике перепланирования. Служба пытается восстановить узел и пропустить обновление в соответствии с политикой приложения.

В этом случае для службы агента узла будет создан отчет о работоспособности уровня предупреждения. Результат обновления Windows также содержит возможные причины сбоя.

При установке обновления кластер перешел в неработоспособное состояние

Некорректное обновление Windows может привести к потере работоспособности приложения или кластера в определенном узле или домене обновления. Приложение для оркестрации исправлений останавливает любые последующие операции Центра обновления Windows, пока работоспособность кластера не восстановится.

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

Заметки о выпуске POA

Примечание

В POA версии 1.4.0 и более поздних версий заметки о выпуске и сами выпуски можно найти на странице Patch Orchestration Application release в репозитории GitHub.

Версия 1.1.0

  • Общедоступный выпуск

Версии 1.1.1

  • Исправлена ошибка в SetupEntryPoint службы агента узла, которая препятствовала установке службы NTService агента узла.

Версии 1.2.0

  • Исправлены ошибки, связанные с рабочим процессом перезапуска системы.
  • Исправлена ошибка при создании задач службы управления правами, из-за которой проверка работоспособности не выполнялась должным образом во время подготовки задач восстановления.
  • Режим автоматического запуска службы Windows POANodeSvc изменен на отложенный автоматический запуск.

Версия 1.2.1

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

Версия 1.2.2

  • Прочие исправления ошибок.
  • Теперь двоичные файлы подписаны.
  • Добавлена ссылка на sfpkg для приложения.

Версия 1.3.0

  • Заданное параметру InstallWindowsOSOnlyUpdates значение false теперь устанавливает все доступные обновления.
  • Изменена логика отключения автоматических обновлений. Благодаря этому ошибка, когда автоматические обновления не были отключены на Server 2016 и более поздних версий, была исправлена.
  • Параметризованное ограничение размещения как для микрослужб POA, так и для расширенных вариантов использования.

Версия 1.3.1

  • Исправление регрессии, где POA 1.3.0 не работал в пакете Windows Server 2012 R2 или более старых версиях из-за сбоя при отключении автоматических обновлений.
  • Исправлена ошибка, при которой для конфигурации InstallWindowsOSOnlyUpdates всегда выбирается значение True.
  • Значения по умолчанию InstallWindowsOSOnlyUpdates изменилось на False.

Версия 1.3.2

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