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

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

一般注意事项

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

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

发布者注意事项

• 建议为每个 NF 供应商创建一个发布者。 这种做法在所有供应商中提供最佳支持、维护和治理体验。 当设计包含来自多个供应商的多个 NF 时，它还简化了网络服务设计（NSD）。

• 测试并批准所需的 Azure 操作员服务管理器发布者资源集以供生产使用后，建议将整个集标记为不可变。 将集标记为不可变有助于防止意外更改并确保部署体验一致。 请考虑依赖不可变功能来区分：

  • 生产中使用的资源和项目
  • 用于测试和开发的资源和项目

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

  请注意以下逻辑：

  • 如果网络服务设计版本（NSDV）标记为不可变，则 CGS 还必须标记为不可变。 否则，部署调用将失败。
  • 如果网络函数定义版本 （NFDV） 标记为不可变，则项目清单也必须标记为不可变。 否则，部署调用将失败。
  • 如果仅将项目清单或 CGS 标记为不可变，则无论 NFDV 和 NSDV 是否标记为不可变，部署调用都会成功。
  • 将项目清单标记为不可变可确保该清单中列出的所有项目也通过对项目存储强制实施必要的权限来标记为不可变。 列出的项目通常包括图表、映像和 Azure 资源管理器模板（ARM 模板）。

• 请考虑使用已达成共识的命名约定和治理技术来帮助解决任何剩余的缺口。

NFDG 和 NFDV 注意事项

网络函数定义组（NFDG）表示你计划跨多个服务独立重复使用的最小组件。 NFDG 的所有部分始终一起部署。 这些部分称为 networkFunctionApplications 项。

例如，如果始终将这些组件一起部署在一起，则载入包含多个 Helm 图表和图像的单个 NF，这很自然。 如果始终将多个 NF 一起部署在一起，则所有 NF 都有一个 NFDG 是合理的。 单个 NFDG 可以有多个 NFDV。

对于 CNF NFDV， networkFunctionApplications 列表只能包含 Helm 包。 如果始终在一起部署和删除多个 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 调用都会导致验证错误。

触发 NFDV 次要版本或主要版本更新的常见用例

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

NSDG 和 NSDV 注意事项

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

NSDG 示例可能包括：

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

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

触发 NSDV 次要版本或主要版本更新的常见用例

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

CLI 注意事项

Azure 操作员服务管理器命令行接口 （CLI） 扩展可帮助发布网络函数定义（NFD）和 NSD。 使用此工具作为创建新 NFD 和 NSD 的起点。

请考虑使用 CLI 创建初始文件。 然后编辑它们以在发布之前整合基础结构组件。

SNS 注意事项

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

建议使用用户分配的托管标识（而不是系统分配的托管标识）部署每个 SNS。 此用户分配的托管标识必须有权访问 NFDV，并且必须具有托管标识操作员本身的角色。 有关详细信息，请参阅创建并分配用户分配的托管标识。

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

以下两种方案阐明了 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 提供唯一值。

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

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
  

疑难解答注意事项

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

• 选项atomicwait设置为 true。
• 作超时设置为 27 minutes。

在初始载入期间，只有在仍在调试和开发项目时，我们建议将标志false设置为 atomic 。 此设置可防止 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
            }

清理注意事项

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

操作员资源

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

1. 社交网络服务
2. 站点
3. CGV

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

发布者资源

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

1. NSDV
2. NSDG
3. NFDV
4. NFDG
5. 项目清单
6. 项目存储
7. 发布者

Azure 操作员服务管理器不会删除命名空间作为任何删除作的一部分。 因此，删除所有资源后，某些项目可能保留在群集上。 若要删除任何剩余的项目，应删除在群集上创建的任何工作负荷命名空间。 建议将命名空间删除作作为工作流管道的一部分进行自动化。

CNF 应用程序的顺序排序行为

默认情况下，CNF 应用程序会根据它们在 NFDV 中显示的顺序进行安装或更新。 对于删除作，CNF 应用程序按指定的反向顺序删除。 如果需要定义与默认值不同的 CNF 应用程序的特定顺序，请使用 dependsOnProfile 它来定义安装、更新和删除作的唯一序列。

如何使用 dependsOnProfile

可以在 NFDV 中使用 dependsOnProfile 来控制 CNF 应用程序的 Helm 执行序列。 在下面的示例中：

• 在安装作期间，CNF 应用程序按以下顺序进行部署：dummyApplication1， 。 dummyApplication2dummyApplication
• 在更新作期间，CNF 应用程序按以下顺序进行更新：dummyApplication2， dummyApplication1。 dummyApplication
• 在删除作期间，CNF 应用程序按以下顺序删除：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"
    }
}

常见错误

目前，如果 dependsOnProfile NFDV 中提供的代码无效，则 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 注意事项

在某些情况下，第三方 Helm 图表可能不符合 Azure 操作员服务管理器的要求 registryURL。 在这种情况下，可以使用 injectArtifactStoreDetails 该功能来避免对 Helm 包进行更改。

若要使用 injectArtifactStoreDetails，请将 installOptions NF 资源的 roleOverrides 节中的参数设置为 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"}}}}}'
    ]
  }
}