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

使用 Azure 运营商服务管理器加入和部署网络功能的最佳做法

项目
11/12/2024

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

一般注意事项

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

使你的工件的结构与计划内的使用保持一致。请考虑将全局工件与因站点或实例而异的工件分开。
确保多个 NF 的服务组成，其中包含一组与你的网络需求匹配的参数。例如，你可能有一个包含 1,000 个值的图表，并且只自定义其中的 100 个。请确保在配置组架构 (CGS) 层（后续部分有更广泛地介绍）中，仅公开 100。
请尽早考虑如何分离基础结构（例如群集）或工件存储以及供应商之间的访问，特别是在单个服务中。使你的发布者资源组与此模型匹配。
Azure 运营商服务管理器站点是一个逻辑概念，它是部署目标的表示形式。例子包括用于容器化网络功能 (CNF) 的 Kubernetes 群集，或用于虚拟化网络功能 (VNF) 的 Azure 运营商关系扩展自定义位置。它不是物理边缘站点的表示形式，因此会有多个站点共享同一物理位置的用例。
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 包，则包含它们是合理的。

对于虚拟化网络功能定义版本 (VNF 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 调用和 Re-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。
可通过 API 定义的内容（Azure 运营商关系、Azure 运营商服务管理器）应考虑用于 CGS。而不是，例如，通过 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 运营商服务管理器资源映射

以下两种方案阐明了 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 中，对 deployParameters 和 templateParameters 进行参数化的方式需要让你可以提供唯一值，方法是为每个项使用 CGV。

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

Azure 运营商服务管理器是在支持可用性区域的区域中跨可用性区域部署的区域服务。有关 Azure 运营商服务管理器可用的所有区域，请参阅 Azure 产品（按区域）。如需具有可用性区域的 Azure 区域列表，请参阅为你选择合适的 Azure 区域。

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

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

注意

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

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
            }

重要

请确保在初始加入完成后将原子和等待设置回 true。

清理注意事项

操作员资源

作为清理已部署环境的第一步，请首先按以下顺序删除操作员资源：

SNS
场所
CGV

只有在这些运营商资源成功删除后，用户才应继续删除其他环境资源，例如 NAKS 群集。

重要

删除无序资源可能会导致孤立的资源被抛在脑后。

发布者资源

作为清理已加入环境的第一步，请首先按以下顺序删除发布者资源：

NSDV
NSDG

重要

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

NFDV
NFDG
项目清单
项目存储
发布者

重要

删除无序资源可能会导致孤立的资源被抛在脑后。

NfApp 顺序排序行为

概述

默认情况下，容器化网络函数应用程序 (NfApp) 是根据网络函数设计版本 (NFDV) 中显示的顺序安装或更新的。对于删除，将按指定的反向顺序删除 NfApp。如果发布者需要定义与默认值不同的特定 NfApp 排序，则可以使用 dependsOnProfile 来定义用于安装、更新和删除操作的唯一序列。

如何使用 dependsOnProfile

发布者可以使用 NFDV 中的 dependsOnProfile 来控制 NfApp 的 helm 执行序列。对于以下示例，在安装操作中，NfApp 将按以下顺序部署：dummyApplication1、dummyApplication2，然后是 dummyApplication。在更新操作中，NfApp 将按以下顺序更新：dummyApplication2、dummyApplication1，然后是 dummyApplication。在删除操作中，NfApp 将按以下顺序删除：dummyApplication2、dummyApplication1，然后是 dummyApplication。

{
    "location": "eastus",
    "properties": {
        "networkFunctionTemplate": {
            "networkFunctionApplications": [
                {
                  "dependsOnProfile": {
                        "installDependsOn": [
                            "dummyApplication1",
                            "dummyApplication2"
                        ],
                        "uninstallDependsOn": [
                            "dummyApplication1"
                        ],
                        "updateDependsOn": [
                            "dummyApplication1"
                        ]
                    },
                    "name": "dummyApplication"
                },
                {
                  "dependsOnProfile": {
                        "installDependsOn": [
                        ],
                        "uninstallDependsOn": [
                            "dummyApplication2"
                        ],
                        "updateDependsOn": [
                            "dummyApplication2"
                        ]
                    },
                    "name": "dummyApplication1"
                },
                {
                    "dependsOnProfile": null,
                    "name": "dummyApplication2"
                }
            ],
            "nfviType": "AzureArcKubernetes"
        },
        "networkFunctionType": "ContainerizedNetworkFunction"
    }
}

常见错误

目前，如果 NFDV 中提供的 dependsOnProfile 无效，则 NF 操作将失败并出现验证错误。验证错误消息显示在操作状态资源中，类似于以下示例。

 {
  "id": "/providers/Microsoft.HybridNetwork/locations/EASTUS2EUAP/operationStatuses/ca051ddf-c8bc-4cb2-945c-a292bf7b654b*C9B39996CFCD97AB3A121AE136ED47F67BB13946C573EF90628C47628BC5EF5F",
  "name": "ca051ddf-c8bc-4cb2-945c-a292bf7b654b*C9B39996CFCD97AB3A121AE136ED47F67BB13946C573EF90628C47628BC5EF5F",
  "resourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/xinrui-publisher/providers/Microsoft.HybridNetwork/networkfunctions/testnfDependsOn02",
  "status": "Failed",
  "startTime": "2023-07-17T20:48:01.4792943Z",
  "endTime": "2023-07-17T20:48:10.0191285Z",
  "error": {
    "code": "DependenciesValidationFailed",
    "message": "CyclicDependencies: Circular dependencies detected at hellotest."
  }
}

injectArtifactStoreDetails considerations

在某些情况下，第三方 helm chart 可能不完全符合 registryURL 的 AOSM 要求。在这种情况下，injectArtifactStoreDetails 功能可用于避免更改 helm 包。

如何启用

若要使用 injectArtifactStoreDetails，请将 NF 资源 roleOverrides 节中的 installOptions 参数设置为 true，然后使用所需的任何 registryURL 值使注册表 URL 保持有效。请参阅已启用 injectArtifactStoreDetails 参数的以下示例。

resource networkFunction 'Microsoft.HybridNetwork/networkFunctions@2023-09-01' = {
  name: nfName
  location: location
  properties: {
    nfviType: 'AzureArcKubernetes'
    networkFunctionDefinitionVersionResourceReference: {
      id: nfdvId
      idType: 'Open'
    }
    allowSoftwareUpdate: true
    nfviId: nfviId
    deploymentValues: deploymentValues
    configurationType: 'Open'
    roleOverrideValues: [
      // Use inject artifact store details feature on test app 1
      '{"name":"testapp1", "deployParametersMappingRuleProfile":{"helmMappingRuleProfile":{"options":{"installOptions":{"atomic":"false","wait":"false","timeout":"60","injectArtifactStoreDetails":"true"},"upgradeOptions": {"atomic": "false", "wait": "true", "timeout": "100", "injectArtifactStoreDetails": "true"}}}}}'
    ]
  }
}

通过

使用 Azure 运营商服务管理器加入和部署网络功能的最佳做法

一般注意事项

发布者注意事项

网络功能定义组和版本注意事项

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

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

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

配置组架构注意事项

场景

选择要公开的参数

配置组值注意事项

CLI 注意事项

站点网络服务注意事项

每个用例的 Azure 运营商服务管理器资源映射

方案：单一网络功能

方案：多个网络功能

软件升级注意事项

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

疑难解答注意事项

清理注意事项

操作员资源

发布者资源

NfApp 顺序排序行为

概述

如何使用 dependsOnProfile

常见错误

injectArtifactStoreDetails considerations

如何启用

反馈

其他资源