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

Azure 操作员服务管理器的基本概念

本文收集了关于使用 Azure Operator Service Manager （Azure 操作员服务管理器）引入和部署网络功能（NFs）的最佳实践建议。遵循这些基本准则，供应商、运营商及其合作伙伴可以优化部署到 Azure 操作员 Nexus 的网络服务。请在任何网络功能载入规划过程的开头考虑这些概念。

一般注意事项

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

使你的工件的结构与计划内的使用保持一致。请考虑将全局工件与因站点或实例而异的工件分开。
确保多个 NF 的服务组成，其中包含一组与你的网络需求匹配的参数。例如，你可以在包含 1,000 个值的图表中自定义 100 个值。请确保在配置组架构 (CGS) 层（后面的部分有更详细的介绍）中，仅公开 100 个。
请尽早考虑如何分离基础结构（例如群集）或工件存储以及供应商之间的访问，特别是在单个服务中。使你的发布者资源组与此模型匹配。
Azure 运营商服务管理器站点是一个逻辑概念，它是部署目标的表示形式。例子包括用于容器化网络功能 (CNF) 的 Kubernetes 群集，或用于虚拟化网络功能 (VNF) 的 Azure 运营商关系扩展自定义位置。它不是物理边缘站点的表示形式，因此会有多个站点共享同一物理位置的用例。
Azure 运营商服务管理器提供了各种 API，可帮助你将其与 Azure DevOps 或其他管道工具相结合。
Azure 运营商服务管理器命令行接口 (CLI) 扩展可帮助发布网络功能定义 (NFD) 和 NSD。使用此工具作为创建新 NFD 和 NSD 的起点。请考虑使用 CLI 创建初始文件。然后编辑它们以在发布之前整合基础结构组件。

发布者注意事项

建议为每个 NF 供应商创建一个发布者，或者为每个 NF 供应商的每个 NF 类型创建一个发布者，其中 NF 供应商可以提供多个 NF 类型。这种做法;
- 通过防止发布者激增，提供最佳的支持、维护和治理体验。尤其是在升级活动期间，通常在多个网络功能 (NF) 上执行相同的操作。
- 通过减少发布者支持资源（例如 Azure 容器注册表（ACR）或存储帐户的数量来降低总运营成本。
- 简化网络服务设计 (NSD)，其中可能包含来自多个供应商的多个 NF。
测试并批准所需的 Azure 运营商服务管理器发布者资源集以供生产使用后，建议将整个集标记为不可变。将集标记为不可变有助于防止意外更改并确保部署体验一致。不可变标记有助于区分：
- 生产中使用的资源和工件
- 用于测试和开发的资源和工件

你可以查询发布者资源和工件清单的状态，以确定哪些被标记为不可变。有关详细信息，请参阅发布者资源预览管理功能。

请注意以下逻辑：

如果网络服务设计版本 (NSDV) 被标记为不可变，则 CGS 也必须被标记为不可变。否则，部署调用将失败。
如果网络功能定义版本 (NFDV) 被标记为不可变，则工件清单也必须被标记为不可变。否则，部署调用将失败。
如果只有工件清单或 CGS 被标记为不可变，则无论 NFDV 和 NSDV 是否被标记为不可变，部署调用都会成功。
将工件清单标记为不可变后，可通过对工件存储强制实施必要的权限来确保清单中列出的所有工件也被标记为不可变。列出的工件通常包括图表、映像和 Azure 资源管理器模板（ARM 模板）。
请考虑使用已达成共识的命名约定和治理技术来帮助解决任何剩余的缺口。

发布者高可用性和灾难恢复

Azure Operator 服务管理器的发布者是一个区域性服务，仅在受支持区域的本地可用区内进行部署。请考虑发布者高可用性和灾难恢复的以下要求：

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

NFDG 和 NFDV 注意事项

网络功能定义组 (NFDG) 表示你计划跨多个服务独立重复使用的最小组件。 NFDG 的所有部分始终一起部署。这些部分称为 networkFunctionApplications 项。例如，如果始终将这些组件一起部署，则自然会作为单个 NFDG 加入由多个 Helm 图表和图像组成的单个 NF。如果始终将多个 NF 一起部署，则为所有 NF 设置一个 NFDG 是合理的。单个 NFDG 可以有多个 NFDV。

对于 CNF NFDV，networkFunctionApplications 列表只能包含 Helm 包。
- 如果始终一起部署和删除多个 Helm 包，则包含它们是合理的。
对于 VNF NFDV，networkFunctionApplications 列表必须至少包含一个 VhdImageFile 值和一个 ARM 模板。
- 若要为单个 VNF 部署多个虚拟机（VM），请确保为每个 VM 使用单独的 ARM 模板。

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

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

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

NFDV 次要更新或主要更新

NFDV 代表基础 NFDG 的发布版本，与唯一版本相关联。随着 NF 随时间推移而变化，许多 NFDV 被用于捕获任何给定时间点的功能。触发新 NFDV 的典型更改可能包括：

更新 NF 构件，例如新的图表或映像版本。
更新那些会更改 deployParametersMappingRuleProfile 的 CGS 或配置组值 (CGV)。
将任何默认值硬编码更新到 NFDV 中。
更新组件启用情况，防止通过 applicationEnablement: Disabled 部署它们。

注意

不公开新 CGS 参数的 NF 版本只需更新项目清单、推送新图像和图表以及提升 NFDV。

NSDG 和 NSDV 注意事项

网络服务设计组 (NSDG) 是同时部署的一个或多个 NFDG 及任意基础结构组件的组合。这些组件可以包括 Nexus Kubernetes 或 Azure Kubernetes 服务 (AKS) 中的群集和 VM。站点网络服务 (SNS) 是指单个 NSDV。这种设计可从单个 SNS PUT 调用将网络服务一致且可重复地部署到某个站点。

NSDG 示例可能包括：

身份验证服务器功能 (AUSF) NF
统一数据管理 (UDM) NF
支持 AUSF 或 UDM 的管理 VM
Unity Cloud 会话管理功能 (SMF) NF
AUSF、UDM 和 SMF 部署到的 Nexus Kubernetes 群集

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

NSDV 次要更新或主要更新

NSDV 代表基础 NSD 的发布版本，与唯一版本相关联。 NSDV 更改频率低于 NFDV 更改的频率，在某些情况下，单个 NSDV 支持站点网络服务的整个生命周期。但是，以下服务更改确实需要新的 NSDV：

在 CGS 中创建、删除或添加值。
更改部署的站点网络服务资源使用的 NF ARM 模板。
更改部署站点资源使用的基础结构 ARM 模板。

注意

将 NFDV 公开为 CGS 中的参数，以便操作员可以控制使用 CGV 部署的内容，进一步降低 NSDV 更改频率。

建议为整个站点使用单个 SNS，包括基础结构。 SNS 应部署任何必需的基础结构（例如，Nexus Kubernetes 或 AKS 中的群集和 VM），然后部署所需的 NF。这种设计可从单个 SNS PUT 调用将网络服务一致且可重复地部署到某个站点。

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

资源方案注意事项

以下两种方案阐明了 Azure 运营商服务管理器资源映射。

方案：单一网络功能

包含一个或两个应用程序组件的 NF 被部署到了 Nexus Kubernetes 群集。下面是资源的细目：

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

场景：多个网络功能

具有一些共享和独立组件的多个 NF 被部署到 Nexus Kubernetes 群集。下面是资源的细目：

NFDG：
- 所有共享组件一个。
- 每个独立组件或 NF 一个。
NFDV：触发 NFDV 次要或主要版本更新的每个用例的每个 NFDG 多个。
NSDG：单个。合并所有 NF、共享和独立组件以及基础结构（Kubernetes 群集或任何受支持的 VM）。
NSDV：根据触发 NSDV 次要或主要版本更新的用例的需要而定。
CGS：
- 单个。全局，适用于所有组件。
- 每个 NF 一个，包括 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：
- 使用专用 ARM 模板部署每个 VM。
- 在 ARM 模板中，需要通过 CGS 公开两个参数：
  - VM 名称，用于指示哪个实例是主实例或辅助实例
  - 部署策略，用于控制是否允许 VM 部署
- 在 NFDV 中，对 deployParameters 和 templateParameters 进行参数化的方式需要让你可以提供唯一值，方法是为每个项使用 CGV。

疑难解答注意事项

在安装和升级期间，默认情况下：

atomic 和 wait 选项设置为 true。
操作超时设置为 27 minutes。

在初始加入期间，仅当你仍在调试和开发工件时，我们才建议将 atomic 标志设置为 false。此设置可防止 Helm 在失败时回滚，并保留可能丢失的任何日志或错误。实现这一点的最佳方法是在 NF 的 ARM 模板中操作。在 ARM 模板中，添加以下部分：

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

组件名称在 NFDV 中定义：

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

重要说明

请确保在初始加入完成后将 atomic 和 wait 设置回 true。

清理注意事项

清理资源时，顺序非常重要。删除无序资源可能会导致孤立的资源被抛在脑后。

运营商资源

作为清理已部署环境的第一步，请按以下顺序删除运营商资源：

社交网络服务
站点
CGV

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

发布者资源

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

NSDV
NSDG
NFDV
NFDG
工件清单
工件存储
发布者