你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

从 Azure CLI 升级群集运行时

项目
03/03/2024

本操作指南介绍了安装与运营商关系交互所需的 Azure CLI 和扩展所需的步骤。

先决条件

必须安装 Azure CLI。
需要 networkcloud CLI 扩展。如果未安装 networkcloud 扩展，则可以按照此处列出的步骤安装它。
对 Azure 门户的访问权限，以便升级目标群集。
必须通过 az login 登录到与目标群集相同的订阅
目标群集必须处于运行状态，所有控制平面节点都处于正常状态，并且计算节点的 80+% 处于运行状态和正常状态。

查找可用的运行时版本

通过门户

若要查找可用、可升级的运行时版本，请导航到 Azure 门户中的目标群集。在群集的概述窗格中，导航到“可用的升级版本”选项卡。

从“可用的升级版本”选项卡中，可以看到当前可用于升级的不同群集版本。运营商可以从列出的目标运行时版本中进行选择。选择后，继续升级群集。

通过 Azure CLI

可通过 Azure CLI 检索可用的升级：

az networkcloud cluster show --name "clusterName" --resource-group "resourceGroup"

在输出中，可以找到 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"
    }
  ],

如果没有可用的群集升级，则列表将为空。

使用 CLI 升级群集运行时

若要执行运行时升级，请使用以下 Azure CLI 命令：

az networkcloud cluster update-version --cluster-name "clusterName" --target-cluster-version
  "versionNumber" --resource-group "resourceGroupName"

运行时升级是一个漫长的过程。升级过程首先会升级管理节点，然后逐个机架按顺序为工作器节点升级。如果每个机架 80% 的工作器节点和 100% 的管理节点已成功升级，则升级被视为已完成。当机架中的工作器节点正在升级的过程中，工作负载可能会受到影响，但所有其他机架中的工作负载不会受到影响。建议根据此实现设计考虑工作负载的放置。

升级所有节点需要几个小时，但如果其他进程（如固件更新）也是升级的一部分，则可能需要更多时间。由于升级过程的长度，建议定期检查群集的详细状态，了解升级的当前状态。若要检查升级的状态，请观察群集的详细状态。可以通过门户或 az CLI 完成此检查。

若要通过 Azure 门户查看升级状态，请导航到目标群集资源。在群集的“概述”屏幕中，提供了详细状态以及详细的状态消息。

当 detailedStatus 设置为 Updating 并且 detailedStatusMessage 显示升级进度时，群集升级正在进行中。 detailedStatusMessage 中显示的升级进度的一些例子包括 Waiting for control plane upgrade to complete...、Waiting for nodepool "<rack-id>" to finish upgrading... 等等。

当 detailedStatus 设置为 Running 且 detailedStatusMessage 显示消息 Cluster is up and running 时，群集升级已完成

若要通过 Azure CLI 查看升级状态，请使用 az networkcloud cluster show。

az networkcloud cluster show --cluster-name "clusterName" --resource-group "resourceGroupName"

输出应是目标群集的信息，群集的详细状态和详细状态消息应存在。有关升级进度的更详细见解，可以检查每个机架中各个 BMM 的状态。裸机角色下的参考部分提供了这方面的示例。

使用群集 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>

必需参数：

strategy-type：定义更新策略。在这种情况下，“Rack”表示按机架逐个更新。默认值为“Rack”
threshold-type：确定阈值的评估方式，按策略定义的单位应用。默认值为“PercentSuccess”。
threshold-value：用于评估更新的数字阈值。默认值为 80。

可选参数：

max-unavailable：可以脱机的最大工作器节点数，即一次升级的机架。默认值为 32767。
wait-time-minutes：更新机架之前的延迟或等待期。默认值为 15。

该命令的一个示例用法如下所示：

az networkcloud cluster update --name "cluster01" --resource-group "cluster01-rg" --update-strategy strategy-type="Rack" threshold-type="PercentSuccess" threshold-value=70 max-unavailable=16 wait-time-minutes=15

成功执行命令后，指定的 updateStrategy 值将应用于群集：

  "updateStrategy": {
      "maxUnavailable": 16,
      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 70,
      "waitTimeMinutes": 15,
    },

常见问题

识别停滞/卡住的群集升级

在运行时升级期间，升级可能无法继续前进，但详细状态反映升级仍在进行中。 由于运行时升级可能需要很长时间才能成功完成，因此当前未指定任何设置的超时长度。因此，建议定期检查群集的详细状态和日志，以确定升级是否无限期地尝试升级。

我们可以通过查看群集的日志、详细消息和详细状态消息来确定此情况。如果发生超时，我们会发现群集持续无限地进行同一协调，而不会前进。在此处，我们建议检查群集日志或配置的 LAW，以查看是否存在故障或导致进度不足的特定升级。

硬件故障不需要升级重新执行

如果在升级期间发生硬件故障，则只要满足计算和管理/控制节点的设定阈值，运行时升级就会继续。修复或替换计算机后，它会预配当前平台运行时的 OS，其中包含运行时的目标版本。

如果发生硬件故障，并且运行时升级失败，因为计算和控制节点未满足阈值，则可能需要重新执行运行时升级，具体取决于故障发生的时间以及机架中各个服务器的状态。如果在发生故障之前更新了机架，则在重新预配节点时，将使用升级后的运行时版本。如果在硬件故障之前机架规格未更新到升级后的运行时版本，则会使用以前的运行时版本预配计算机。若要升级到新的运行时版本，请提交新的群集升级请求，只有具有以前运行时版本的节点才会升级。在上一个升级操作中成功的主机不会升级。

在运行时升级后，群集会显示“失败”预配状态

在运行时升级期间，群集将进入“Upgrading”状态；运行时升级失败时，由于与资源相关的原因，群集将进入“Failed”预配状态。此状态可以链接到与群集（例如 StorageAppliance）相关的组件的生命周期，并且可能需要通过 Microsoft 支持来诊断故障。

Share via