Обновление среды выполнения кластера из Azure CLI

Статья
12/18/2024

В этом руководстве описаны шаги по установке необходимых модулей командной строки Azure и расширений, необходимых для взаимодействия с Оператором Nexus.

Необходимые компоненты

Необходимо установить Azure CLI .
networkcloud Требуется расширение CLI. networkcloud Если расширение не установлено, его можно установить, выполнив указанные здесь действия.
Доступ к портал Azure для обновления целевого кластера.
Необходимо войти в ту же подписку, что и целевой кластер через az login
Целевой кластер должен находиться в состоянии выполнения, при этом все узлы уровня управления работоспособны и 80+% вычислительных узлов в работающем и работоспособном состоянии.

Проверка текущей версии среды выполнения

Проверьте текущую версию среды выполнения кластера перед обновлением: как проверить текущую версию среды выполнения кластера.

Поиск доступных версий среды выполнения

С помощью портала Azure

Чтобы найти доступные обновляемые версии среды выполнения, перейдите в целевой кластер в портал Azure. В области обзора кластера перейдите на вкладку "Доступные версии обновления".

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

С помощью Azure CLI

Доступные обновления можно получить с помощью Azure CLI:

az networkcloud cluster show --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--subscription <subscriptionID>

В выходных данных можно найти availableUpgradeVersions свойство и посмотреть targetClusterVersion на поле:

  "availableUpgradeVersions": [
    {
      "controlImpact": "True",
      "expectedDuration": "Upgrades may take up to 4 hours + 2 hours per rack",
      "impactDescription": "Workloads will be disrupted during rack-by-rack upgrade",
      "supportExpiryDate": "2023-07-31",
      "targetClusterVersion": "3.3.0",
      "workloadImpact": "True"
    }
  ],

Если нет доступных обновлений кластера, список пуст.

Настройка параметров порогового значения вычислений для обновления среды выполнения с помощью обновления кластера updateStrategy

Следующая команда Azure CLI используется для настройки параметров порогового значения вычислений для обновления среды выполнения:

az networkcloud cluster update /
--name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" /
threshold-value="<thresholdValue>" max-unavailable=<maxNodesOffline> /
wait-time-minutes=<waitTimeBetweenRacks> /
--subscription <subscriptionID>

Ниже перечислены необходимые параметры:

тип стратегии: определяет стратегию обновления. Это может быть "Rack" (стойка по стойке) ИЛИ "PauseAfterRack" (обновление одной стойки за раз, а затем дождитесь подтверждения, прежде чем перейти к следующей стойке. Значение по умолчанию — Rack. Чтобы выполнить обновление среды выполнения кластера с помощью стратегии "PauseRack", выполните действия, описанные в разделе "Обновление среды выполнения кластера" с помощью стратегии приостановки стоек
пороговый тип: определяет, как следует оценивать пороговое значение, применяемое в единицах, определенных стратегией. Это может быть "PercentSuccess" ИЛИ "CountSuccess". Значение по умолчанию — PercentSuccess.
пороговое значение: числовое пороговое значение, используемое для оценки обновления. Значение по умолчанию — 80.

Необязательные параметры

max-недоступен: максимальное количество рабочих узлов, которые могут быть автономными, то есть обновляемой стойкой за раз. Значение по умолчанию — 32767.
время ожидания: период задержки или ожидания перед обновлением стойки. Значение по умолчанию — 15.

В следующем примере клиент использует стратегию Rack by Rack с процентом успеха 60% и 1-минутной приостановкой.

az networkcloud cluster update --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" /
threshold-value=60 wait-time-minutes=1 /
--subscription <subscriptionID>

Проверьте обновление:

az networkcloud cluster show --resource-group "<resourceGroup>" /
--name "<clusterName>" /
--subscription <subscriptionID>| grep -a5 updateStrategy

      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 60,
      "waitTimeMinutes": 1

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

В следующем примере клиент использует стратегию Rack by Rack с типом CountSuccess из 10 узлов на стойку и 1-минутную паузу.

az networkcloud cluster update --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="CountSuccess" /
threshold-value=10 wait-time-minutes=1 /
--subscription <subscriptionID>

Проверьте обновление:

az networkcloud cluster show --resource-group "<resourceGroup>" /
--name "<clusterName>" /
--subscription <subscriptionID>| grep -a5 updateStrategy

      "strategyType": "Rack",
      "thresholdType": "CountSuccess",
      "thresholdValue": 10,
      "waitTimeMinutes": 1

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

Примечание.

update-strategy невозможно изменить после запуска обновления среды выполнения кластера. Если пороговое значение ниже 100 % задано, возможно, что любые неработоспособные узлы могут быть не обновлены, но состояние "Кластер" по-прежнему может указывать на то, что обновление выполнено успешно. Сведения об устранении неполадок с компьютерами без операционной системы см. в статье "Устранение неполадок с сервером Оператора Azure Nexus"

Обновление среды выполнения кластера с помощью CLI

Чтобы выполнить обновление среды выполнения, используйте следующую команду Azure CLI:

az networkcloud cluster update-version --cluster-name "<clusterName>" /
--target-cluster-version "<versionNumber>" /
--resource-group "<resourceGroupName>" /
--subscription <subscriptionID>

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

Обновление всех узлов занимает несколько часов в зависимости от количества стоек для кластера. Из-за длительности процесса обновления состояние сведений кластера должно периодически проверяться для текущего состояния обновления. Чтобы проверить состояние обновления, просмотрите подробное состояние кластера. Эту проверку можно выполнить с помощью портала или az CLI.

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

Обновление кластера выполняется, когда для объекта detailedStatus задано Updating значение и подробное значениеStatusMessage показывает ход обновления. Ниже приведены некоторые примеры хода выполнения обновления, показанные в подробных данныхStatusMessage Waiting for control plane upgrade to complete..., Waiting for nodepool "<rack-id>" to finish upgrading...и т. д.

Обновление кластера будет завершено, когда для подробных данныхStatusMessage задано Running значение и подробный отчет Cluster is up and running

Чтобы просмотреть состояние обновления с помощью Azure CLI, используйте az networkcloud cluster show.

az networkcloud cluster show --cluster-name "<clusterName>" /
--resource-group "<resourceGroupName>" /
--subscription <subscriptionID>

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

Вопросы и ответы

Определение остановленного или зависающего обновления кластера

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

Мы можем определить ситуацию indefinitely attempting to upgrade , просмотрев журналы кластера, подробное сообщение и подробное сообщение о состоянии. Если происходит время ожидания, мы бы заметили, что кластер постоянно сверяется с тем же неопределенным сроком и не перемещается вперед. Здесь рекомендуется проверить журналы кластера или настроить LAW, чтобы узнать, возникает ли сбой или определенное обновление, вызывающее отсутствие прогресса.

Сбой оборудования не требует повторного выполнения обновления

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

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

После обновления среды выполнения в кластере отображается состояние подготовки "Сбой"

Во время обновления среды выполнения кластер входит в состояние Upgrading. Если обновление среды выполнения завершается сбоем, кластер переходит в Failed состояние подготовки. Компоненты инфраструктуры (например, устройство хранилища) могут привести к сбоям во время обновления. В некоторых сценариях может потребоваться диагностировать сбой с поддержкой Майкрософт.

Поделиться через