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

用于载入和部署网络函数的 Azure 操作员服务管理器最佳做法

项目
12/21/2023

Microsoft 开发了许多经过验证的做法，用于使用 Azure 操作员服务管理器管理网络功能（NFs）。本文提供了 NF 供应商、电信运营商及其合作伙伴可以遵循的准则来优化设计。载入和部署 NF 时，请记住这些做法。

一般注意事项

建议先载入和部署最简单的 NF（一两个图表），方法是使用快速入门自行熟悉整体流程。可以在后续迭代中添加必要的配置详细信息。完成快速入门时，请考虑以下几点：

构建项目，使其与计划内使用保持一致。请考虑将全局项目与要因站点或实例而异的项目分开。
确保多个 NF 的服务组合，其中包含一组与网络需求匹配的参数。例如，你可能有一个包含 1,000 个值的图表，并且只自定义其中 100 个值。请确保在配置组架构（CGS）层（后续部分更广泛地涵盖）中，仅公开 100。
请尽早考虑如何分离基础结构（例如群集）或项目存储以及供应商之间的访问，特别是在单个服务中。使一组发布者资源与此模型匹配。
Azure 操作员服务管理器站点是一个逻辑概念，它是部署目标的表示形式。例如用于容器化网络函数的 Kubernetes 群集或用于虚拟化网络函数的 Azure 操作员 Nexus 扩展自定义位置（VNF）。它不是物理边缘站点的表示形式，因此存在多个站点共享同一物理位置的用例。
Azure 操作员服务管理器提供了各种 API，使与 ADO 或其他管道工具结合使用变得简单。

发布者注意事项

建议为每个 NF 供应商创建一个发布者。这种做法在所有供应商之间提供最佳支持、维护和治理体验，并在由多个供应商提供的多个 NF 组成时简化网络服务设计。
在测试并批准生产使用所需的 Azure 操作员服务管理器发布服务器资源和项目集后，建议将整个集标记为不可变，以防止意外更改并确保部署体验一致。请考虑依赖不可变功能来区分生产中使用的资源和项目，而不是用于测试和开发目的的资源和项目。可以查询发布服务器资源和项目清单的状态，以确定哪些资源标记为不可变。有关详细信息，请参阅发布服务器租户、订阅、区域和预览版管理。

请记住以下逻辑：
- 如果网络服务设计函数（NSDV）标记为不可变，则 CGS 也必须标记为不可变。否则，部署调用将失败。
- 如果网络函数设计版本（NFDV）标记为不可变，则项目清单也必须标记为不可变。否则，部署调用将失败。
- 如果仅将项目清单或 CGS 标记为不可变，则无论 NFDV 和 NSDV 是否标记为不可变，部署调用都会成功。
- 将项目清单标记为不可变可确保清单中列出的所有项目（通常是图表、图像和 Azure 资源管理器模板 [ARM 模板]）通过强制对项目存储强制实施必要的权限来标记不可变。
请考虑使用商定的命名约定和治理技术来帮助解决任何剩余的差距。

网络函数定义组和版本注意事项

网络函数定义组（NFDG）表示计划跨多个服务独立重复使用的最小组件。 NFDG 的所有部分始终一起部署。这些部分称为 networkFunctionApplications。例如，如果始终将这些组件一起部署在一起，则自然会载入由多个 Helm 图表和图像组成的单个 NF。如果始终将多个 NF 一起部署在一起，则所有 NF 都有一个 NFDG 是合理的。单个 NFDG 可以有多个 NFDV。

对于容器化网络函数定义版本（CNF NFDV）， networkFunctionApplications 列表只能包含 helm 包。如果始终一起部署和删除多个 helm 包，则包含多个 helm 包是合理的。

对于虚拟化网络函数定义版本（VNF NF NFDV）， networkFunctionApplications 列表必须至少包含一 VhdImageFile 个和一个 ARM 模板。 ARM 模板应部署单个虚拟机（VM）。若要为单个 VNF 部署多个 VM，请确保为每个 VM 使用单独的 ARM 模板。

ARM 模板只能从以下资源提供程序部署资源管理器资源：

Microsoft.Compute
Microsoft.Network
Microsoft.NetworkCloud
Microsoft.Storage
Microsoft.NetworkFabric
Microsoft.Authorization
Microsoft.ManagedIdentity

注意

对于包含上述列表以外的任何内容的 ARM 模板，VNF 上的所有 PUT 调用和重新 PUT 都会导致验证错误。

触发网络函数设计版本次要或主要版本更新的常见用例

为触发更改更改 deployParametersMappingRuleProfile的现有版本更新 CGS/配置组值（CGV）。
更新在 NFDV 中硬编码的值。
标记组件处于非活动状态，以防止通过 applicationEnablement: Disabled部署组件。
新的 NF 版本，如图表和图像。

注意

每次给定 NF 的有效负载更改时所需的最小更改数。不公开新 CGS 参数的次要版本或主要 NF 版本只需更新项目清单、推送新映像和图表以及提升 NFDV 版本。

网络服务设计组和版本注意事项

网络服务设计组（NSDG）是同时部署的一个或多个 NFDG 和任何基础结构组件（如 Nexus Azure Kubernetes 服务 [NAKS]/Azure Kubernetes 服务 [AKS] 群集和虚拟机）的组合。站点网络服务（SNS）是指单个 NSDV。这种设计保证从单个 SNS PUT 将网络服务一致且可重复地部署到给定站点。

NSDG 的示例如下：

身份验证服务器函数（AUSF） NF
统一数据管理（UDM） NF
管理员支持 AUSF/UDM 的 VM
Unity Cloud （UC）会话管理功能（SMF） NF
将 AUSF、UDM 和 SMF 部署到的 NAKS 群集

这五个组件构成单个 NSDG。单个 NSDG 可以有多个 NSDV。

触发网络服务设计版本次要版本或主要版本更新的常见用例

创建或删除 CGS。
与要部署的其中一个 NF 关联的 NF ARM 模板中的更改。
基础结构 ARM 模板中的更改，例如 AKS/NAKS 或 VM。

注意

NFDV 中的更改不应触发 NSDV 更新。 NFDV 值应作为 CGS 中的参数公开，以便操作员可以使用 CGV 控制要部署的内容。

配置组架构注意事项

建议始终从整个 NF 的单个 CGS 开始。如果存在特定于站点的参数或特定于实例的参数，我们仍建议将它们保留在单个 CGS 中。当有多个组件（很少是 NF、更常见的基础结构）或跨多个 NF 共享的配置时，我们建议拆分为多个 CGS。 CGS 的数量定义 CGV 的数量。

方案

FluentD、Kibana 和 Splunk（常见的第三方组件）始终为 NSD 中的所有 NF 部署。建议将这些组件分组到单个 NFDG 中。
NSD 有多个 NF，这些 NF 共享几个配置（部署位置、发布服务器名称和几个图表配置）。

在此方案中，我们建议使用单个全局 CGS 公开常见的 NF 和第三方组件配置。可以根据需要定义特定于 NF 的 CGS。

选择要公开的参数

CGS 应仅具有 NF（第 0 天/N 配置）或共享组件使用的参数。
很少配置的参数应定义默认值。
如果使用多个 CGS，建议在参数之间几乎没有重叠。如果需要重叠，请确保参数名称可以清楚地区分 CGS。
对于 CGS，应考虑通过 API（Azure Operator Nexus、Azure 操作员服务管理器）定义的内容。例如，通过 CloudInit 文件定义这些配置值，而不是定义这些配置值。
不确定时，良好的起点是公开参数，并在 CGS 中指定了合理的默认值。以下示例演示示例 CGS 和相应的 CGV 有效负载。
应在所有 NF ARM 模板中使用单个用户分配的托管标识，并且应通过 CGS 公开。

CGS 有效负载：

{ 
  "type": "object", 
  "properties": { 
    "abc": { 
    "type": "integer", 
    "default": 30
    }, 
    "xyz": { 
    "type": "integer", 
    "default": 40
    },
    "qwe": {
    "type": "integer" //doesn't have defaults
    }
  }
  "required": "qwe"
}

操作员传递的相应 CGV 有效负载：

{
"qwe": 20
}

Azure 操作员服务管理器生成的 CGV 有效负载：

{
"abc": 30,
"xyz": 40,
"qwe": 20
}

配置组值注意事项

在提交 CGV 资源创建之前，可以验证基础 YAML 或 JSON 文件的架构和值是否符合相应的 CGS 预期。为此，一个选项是使用适用于 Visual Studio Code 的 YAML 扩展。

CLI 注意事项

Azure 操作员服务管理器 CLI 扩展有助于发布 NFD 和 NSD。使用此工具作为创建新 NFD 和 NSD 的起点。请考虑使用 CLI 创建初始文件。然后编辑它们以在发布之前合并基础结构组件。

站点网络服务注意事项

建议为整个站点使用单个 SNS，包括基础结构。 SNS 应部署所需的任何基础结构（例如 NAKS/AKS 群集和虚拟机），然后部署所需的 NF。这种设计保证从单个 SNS PUT 将网络服务一致且可重复地部署到给定站点。

我们建议每个 SNS 都部署有用户分配的托管标识，而不是系统分配的托管标识。此用户分配的托管标识必须有权访问 NFDV，并且需要自己具有托管标识操作员的角色。有关详细信息，请参阅创建和分配用户分配的托管标识。

每个用例的 Azure 操作员 Service Manager 资源映射

以下两种方案说明了 Azure 操作员服务管理器资源映射。

方案：单一网络功能

一个包含一个或两个应用程序组件的 NF 部署到 NAKS 群集。

资源细分：

NFDG：如果组件可以独立使用，则可以使用两个 NFDG，每个组件一个。如果组件始终一起部署，则为单个 NFDG。
NFDV：根据需要根据前面触发 NFDV 次要或主要版本更新的“常见用例”部分中提及的用例。
NSDG：单个。合并 NF 和 Kubernetes 群集定义。
NSDV：根据需要根据前面触发 NSDV 次要或主要版本更新的“常见用例”部分中提及的用例。
CGS：单个。我们建议 CGS 为部署的每个组件和基础结构提供子节，以便于管理，并包括 NFD 的版本。
CGV：基于 CGS 的数量进行单一。
SNS：每个 NSDV 单个。

方案：多个网络功能

具有一些共享和独立组件的多个 NF 部署到 NAKS 群集。

资源细分：

NFDG：
- 所有共享组件的 NFDG。
- 每个独立组件或 NF 的 NFDG。
NFDV：每个用例每个 NFDG 的倍数提及在上述触发 NFDV 次要或主要版本更新的“常见用例”部分中。
NSDG：单个。合并所有 NF、共享组件和独立组件以及基础结构（Kubernetes 群集或任何受支持的 VM）。
NSDV：根据需要根据前面触发 NSDV 次要或主要版本更新的“常见用例”部分中提及的用例。
CGS：
- 未婚。具有共享配置值的所有组件的全局。
- 每个 NF 的 NF CGS，包括 NFD 的版本。
- 根据参数总数，请考虑将所有 CGS 合并为单个 CGS。
CGV：等于 CGS 的数量。
SNS：每个 NSDV 单个。

软件升级注意事项

假设 NF 支持就地/服务内升级，则为 CNF：

如果添加了新的图表和映像，Azure 操作员服务管理器将安装新图表。
如果删除了某些图表和映像，Azure 操作员服务管理器将删除 NFDV 中不再声明的图表。
Azure 操作员服务管理器验证 NFDV/NSDV 是否源自同一 NFDG/NSDG，因此是同一发布者。不支持跨发布服务器升级。

对于 VNF：

目前不支持就地升级。需要并行实例化具有更新映像的新 VNF。然后，通过删除 SNS 删除较旧的 VNF。
如果将 VNF 部署为一对 VM 以实现高可用性，则可以以这样的方式设计网络服务，以便逐个删除和升级 VM。建议使用以下设计来允许删除和升级单个 VM：
- 每个 VM 都使用专用 ARM 模板进行部署。
- 从 ARM 模板中，需要通过 CGS 公开两个参数：VM 名称，以允许指示哪个实例是主/辅助实例，以及部署策略，控制是否允许 VM 部署。
- 在 NFDV 中， deployParameterstemplateParameters 需要以这样的方式进行参数化，以便你可以为每个值使用 CGV 提供唯一值。

高可用性和灾难恢复注意事项

Azure 操作员服务管理器是在支持这些区域的区域跨可用性区域部署的区域服务。有关 Azure 操作员服务管理器可用的所有区域，请参阅 Azure 产品（按区域）。有关具有可用性区域的 Azure 区域列表，请参阅 “为你选择正确的 Azure 区域”。

请考虑以下高可用性和灾难恢复要求：

若要提供异地冗余，请确保在计划部署 NF 的每个区域中都有发布者。请考虑使用管道来确保发布者项目和资源跨区域保持同步。
每个 Microsoft Entra 租户的每个区域必须唯一发布者名称。

注意

如果某个区域不可用，则可以在另一区域中使用发布服务器资源部署 NF（但不能升级）。假设项目和资源在发布者之间是相同的，则只需更改 networkServiceDesignVersionOfferingLocation SNS 资源有效负载中的值。

resource sns 'Microsoft.HybridNetwork/sitenetworkservices@2023-09-01’ = {
 name: snsName
 location: location
 identity: {
  type: 'SystemAssigned'
 }
 properties: {
   publisherName: publisherName
   publisherScope: 'Private'
   networkServiceDesignGroupName: nsdGroup
   networkServiceDesignVersionName: nsdvName
   networkServiceDesignVersionOfferingLocation: location

疑难解答注意事项

默认情况下，安装和升级期间，原子和等待选项设置为 true，操作超时设置为 27 minutes。在载入期间，建议设置原子标志以防止 false Helm 故障后回滚。在 NF 的 ARM 模板中实现此目的的最佳方法。

在 ARM 模板中，添加以下部分：

"roleOverrideValues": [
    "{\"name\":\"NF_component_name>\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"false\",\"wait\":\"true\",\"timeout\":\"100\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"4\"}}}}}"
]

组件名称在 NFDV 中定义：

     networkFunctionTemplate: {
      nfviType: 'AzureArcKubernetes'
      networkFunctionApplications: [
        {
          artifactType: 'HelmPackage'
          name: 'fed-crds'
          dependsOnProfile: null
          artifactProfile: {
            artifactStore: {
              id: acrArtifactStore.id
            }

清理注意事项

按以下顺序删除操作员资源，以确保不会留下孤立的资源：

Sns
站点
CGV

重要

在删除 NFDV 之前，请确保删除 SNS。

按以下顺序删除发布者资源，以确保不会留下孤立的资源：

Cgs
NSDV
NSDG
NFDV
NFDG
项目清单
项目存储
发布者