Azure 電信業者服務管理員的基本概念

本文擷取使用 Azure 操作員服務管理員上線和部署網路函式（NF）的最佳做法建議。遵循這些基本指導方針，廠商、操作員及其合作夥伴可以優化部署至 Azure 操作員連接點的網路服務。在任何網路功能上線規劃流程開始時，請考慮這些概念。

一般考量

我們的建議是，先使用快速入門來熟悉整體流程，將最簡單的 NF (一或兩個圖表) 進行上線和部署。在後續反覆進行時，再新增必要設定的詳細資料。在進行快速入門的過程中，請考慮下列幾點：

建構符合計劃用途的成品。考慮將全域成品與您想要隨網站或執行個體而異的成品區隔開來。
確保服務是由多個 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 Container Registry （ACR）或儲存體帳戶，來降低總營運成本。
- 簡化網路服務設計（NSD），其中網路服務設計可能由來自多個供應商的多個 NF 組成。
在您測試並核准所需的一組 Azure 操作員服務管理員發行者資源以供生產環境使用之後，建議將整個集合標示為不可變。將集合標記為不可變有助於防止意外變更並確保一致的部署體驗。不變性標記有助於區分：
- 生產環境中所使用的資源和成品
- 用於測試和開發的資源和成品

您可以查詢發行者資源和成品資訊清單的狀態，以判斷哪些項目標記為不可變。如需詳細資訊，請參閱發行者資源預覽管理功能。

請記住下列邏輯：

如果網路服務設計版本 (NSDV) 標示為不可變，CGS 也必須標示為不可變。否則，部署呼叫會失敗。
如果網路功能定義版本 (NFDV) 標記為不可變，成品資訊清單也必須標記為不可變。否則，部署呼叫會失敗。
如果只有成品資訊清單或 CGS 標記為不可變，則不論 NFDV 和 NSDV 是否標記為不可變，部署呼叫都會成功。
將成品資訊清單標示為不可變，可確保該資訊清單中列出的所有成品也會藉由強制執行成品存放區的必要權限來標示為不可變。列出的成品通常包括圖表、影像和 Azure Resource Manager 範本 (ARM 範本)。
請考慮使用各方同意的命名慣例和治理技術，來協助弭平任何剩餘缺口。

發行者高可用率和災害復原

Azure 電信業者服務管理員發行者是僅部署在支援區域中本機可用性區域的區域服務。請考慮發行者高可用性和災難復原的下列需求：

若要提供異地備援，請確定在您打算部署 NF 的每個區域中都有發行者。請考慮使用管線，讓發行者成品和資源跨區域保持同步。
每個區域中每個 Microsoft Entra 租用戶都必須有唯一的發行者名稱。

NFDG 和 NFDV 考量

網路功能定義群組 (NFDG) 代表您打算跨多個服務獨立重複使用的最小元件。 NFDG 的所有組件一律會一起部署。這些組件稱為 networkFunctionApplications 項目。例如，在一律會一起部署的情況下，將包含多個 Helm 圖表和影像的單一 NF 以單一 NFDG 的形式上線是再自然不過的事了。如果一律會一起部署多個 NF，則讓所有 NF 共用單一 NFDG 是合理的做法。單一 NFDG 可以有多個 NFDV。

對於 CNF NFDV，networkFunctionApplications 清單只能包含 Helm 套件。
- 在一律會一起部署和刪除的情況下，納入多個 Helm 套件是合理的做法。
針對 VNF NFDV，networkFunctionApplications 清單必須至少包含一個 VhdImageFile 值和一個 ARM 範本。
- 若要為單一 VNF 部署多個虛擬機器（VM），請確保為每個 VM 使用單獨的 ARM 範本。

ARM 範本只能部署來自下列資源提供者的 Resource Manager 資源：

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

針對包含上述清單以外任何項目的 ARM 範本，對 VNF 結果的所有 PUT 呼叫都會導致驗證錯誤。

NFDV 次要或主要更新

NFDV 代表基本 NFDG 的版本，並與唯一版本相關聯。隨著 NF 隨時間逐漸變化，許多 NFDV 被用來在任何指定時間點擷取功能。觸發新 NFDV 的典型變更可能包括：

更新 NF 構件，例如新圖表或映像版本。
更新 CGS 或變更 deployParametersMappingRuleProfile 的設定群組值 (CGV)。
更新 NFDV 中硬性編碼的任何預設值。
更新元件的啟用狀態，以防止透過 applicationEnablement: Disabled 來部署。

附註

未公開新 CGS 參數的 NF 版本只需要更新成品資訊清單、推送新的影像和圖表，以及更改 NFDV。

NSDG 和 NSDV 考量

網路服務設計群組 (NSDG) 是一或多個 NFDG 的複合，以及同時部署的任何基礎結構元件。這些元件可能包含連接點 Kubernetes 或 Azure Kubernetes Service (AKS) 中的叢集和 VM。網站網路服務 (SNS) 指的是單一 NSDV。這類設計提供以一致且可重複的方式，從單一 SNS PUT 呼叫將網路服務部署至網站。

NSDG 範例可能包含：

驗證伺服器功能 (AUSF) NF
整合資料管理 (UDM) NF
支援 AUSF 或 UDM 的系統管理 VM
Unity Cloud 工作階段管理功能 (SMF) NF
作為 AUSF、UDM 和 SMF 部署目的地的連接點 Kubernetes 叢集

這五個元件會構成單一 NSDG。單一 NSDG 可以有多個 NSDV。

NSDV 小更新或重大更新

NSDV 代表基本 NSD 的版本，並與唯一版本相關聯。 NSDV 變更的頻率低於 NFDV 變更，在某些情況下，單一 NSDV 會支援網站網路服務的整個生命週期。不過，下列服務變更確實需要新的 NSDV：

在 CGS 中建立、刪除或新增值。
變更已部署站點網路服務資源所使用的 NF ARM 範本。
變更部署站點資源所使用的基礎結構 ARM 範本。

附註

將 NFDV 公開為 CGS 中的參數，以便操作員可以使用 CGV 控制要部署的內容，從而進一步降低 NSDV 變更頻率。

建議您讓整個網站 (包括基礎結構) 使用單一 SNS。 SNS 應該部署任何必要的基礎結構 (例如，連接點 Kubernetes 或 AKS 中的叢集和 VM)，然後在其上部署所需的 NF。這類設計提供以一致且可重複的方式，從單一 SNS PUT 呼叫將網路服務部署至網站。

建議您使用使用者指派的受控識別 (而非系統指派的受控識別) 來部署每個 SNS。這個使用者指派的受控識別必須具有存取 NFDV 的權限，而且必須具備其上受控識別運算子的角色。如需詳細資訊，請參閱建立和指派使用者指派的受控識別 (部分機器翻譯)。

資源配置考量

下列兩個案例可說明 Azure 運算子服務管理員的資源對應。

案例：單一網路功能

具有一或兩個應用程式元件的 NF 部署到連接點 Kubernetes 叢集。以下是資源的明細：

NFDG：如果元件可以獨立使用，則兩個 NFDG，每個元件各一個。如果元件一律會一起部署，則單一 NFDG。
NFDV：視需要根據觸發 NFDV 次要或主要版本更新的使用案例而定。
NSDG：單一。合併 NF 和 Kubernetes 叢集定義。
NSDV：視需要根據觸發 NSDV 次要或主要版本更新的使用案例而定。
CGS：單一。為了更容易管理，我們建議 CGS 針對您要部署的每個元件和基礎結構都有子區段。我們也建議 CGS 包含 NFD 的版本。
CGV：單一，根據 CGS 的數目。
SNS：每個 NSDV 一個。

案例：多個網路功能

具有一些共用和獨立元件的多個 NF 部署到連接點 Kubernetes 叢集。以下是資源的明細：

NFDG：
- 所有共用元件一個。
- 每個獨立元件或 NF 一個。
NFDV：觸發 NFDV 次要或主要版本更新的每個使用案例中每個 NFDG 多個。
NSDG：單一。合併所有 NF、共用和獨立元件，以及基礎結構 (Kubernetes 叢集或任何支援 VM)。
NSDV：視需要根據觸發 NSDV 次要或主要版本更新的使用案例而定。
CGS：
- 單一。全域適用於所有元件。
- 每個 NF 一個，包括 NFD 的版本。
- 根據參數總數，請考慮將所有 CGS 合併成單一 CGS。
CGV：等於 CGS 的數目。
SNS：每個 NSDV 一個。

升級時的考量

假設 NF 支援就地和服務內升級，則 CNN 適用下列考量：

如果您新增圖表和影像，Azure 操作員服務管理員會安裝新的圖表。
如果您移除某些圖表和影像，Azure 操作員服務管理員會刪除 NFDV 中不再宣告的圖表。
Azure 運算子服務管理員會驗證源自相同 NFDG/NSDG、以及因此源自相同發行者的 NFDV/NSDV。不支援跨發行者來升級。

下列考量適用於 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

您只能在成功刪除這些操作員資源之後，才能繼續刪除其他環境資源，例如連接點 Kubernetes 叢集。

發行者資源

在清除已上線環境的第一個步驟中，請依照下列順序刪除發行者資源：

NSDV
NSDG
NFDV
NFDG
成品資訊清單
成品存放區
發行者