Azure Operator Service Manager の基本的な概念

この記事では、Azure Operator Service Manager を使用してネットワーク関数 (NSG) をオンボードおよびデプロイするためのベスト プラクティスの推奨事項について説明します。 これらの基本的なガイドラインに従って、ベンダー、オペレーター、およびそのパートナーは、Azure Operator Nexus にデプロイされたネットワーク サービスを最適化できます。 ネットワーク機能オンボーディング計画プロセスの開始時に、これらの概念を検討してください。

一般的な考慮事項

最初に、クイックスタートを使用して最も単純な NF (1 つまたは 2 つのグラフ) をオンボードしてデプロイし、フロー全体を理解することをお勧めします。 後続のイテレーションで必要な構成の詳細を追加できます。 クイックスタートを進める際には、次の点を考慮してください。

• 計画的な使用に合わせてアーティファクトを構成します。 サイトまたはインスタンスごとに変更したいアーティファクトと、グローバル アーティファクトを分離することを検討してください。
• ネットワークのニーズに一致する一連のパラメーターを持つ複数の NF のサービス構成を確認します。 たとえば、1000 個の値を持つグラフのうち 100 個の値をカスタマイズするとします。 この場合、コンフィギュレーション グループ スキーマ (CGS) レイヤー (以降のセクションで詳しく説明) で、100 個のみを公開するようにします。
• インフラストラクチャ (クラスターなど) またはアーティファクト ストアを分離し、(特に 1 つのサービス内の) サプライヤー間でアクセスする方法について、早い段階で検討してください。 パブリッシャー リソースのセットをこのモデルと一致させます。
• Azure Operator Service Manager サイトは、デプロイ先を表す論理的な概念です。 たとえば、コンテナー化されたネットワーク機能 (CNF) 用の Kubernetes クラスターや、仮想化されたネットワーク機能 (VNF) 用の Azure Operator Nexus 拡張カスタムの場所などがあります。 これは物理エッジ サイトの表現ではないので、複数のサイトが同じ物理的な場所を共有するユース ケースがあります。
• Azure Operator Service Manager には、Azure DevOps やその他のパイプライン ツールと組み合わせるのに役立つさまざまな API が用意されています。
• Azure Operator Service Manager コマンド ライン インターフェイス (CLI) 拡張機能は、ネットワーク関数定義 (NFD) と NSD の発行を支援します。 このツールは、新しい NFD と NSD を作成するための開始点として使用します。 CLI を使用して初期ファイルを作成することを検討してください。 次に、それらを編集して、発行する前にインフラストラクチャ コンポーネントを組み込みます。

パブリッシャーに関する考慮事項

• NF サプライヤーごとに、または NF サプライヤーが複数の NF の種類を提供する場合にはその種類ごとに、1 つの発行元を作成することをお勧めします。 このプラクティス。
  • 発行元の急増を防ぐことで、最適なサポート、メンテナンス、ガバナンスのエクスペリエンスを提供します。 特に、同じアクションが多くの NSG で実行されるアップグレード アクティビティ中に特に発生します。
  • Azure Container Registry (ACR) やストレージ アカウントなどのパブリッシャー バッキング リソースの数を減らすことで、総運用コストを削減します。
  • ネットワーク サービス設計 (NSD) が簡素化され、複数のベンダーの複数の NSG で構成される場合があります。
• 運用環境で使用するために必要な Azure Operator Service Manager パブリッシャー リソースのセットをテストして承認した後、セット全体を変更不可としてマークすることをお勧めします。 セットを不変としてマークすると、偶発的な変更を防ぎ、一貫したデプロイ エクスペリエンスを確保できます。 不変性のマーキングは、次の区別に役立ちます。
  • 運用環境で使用されるリソースとアーティファクト
  • テスト環境と開発環境で使用されるリソースとアーティファクト

パブリッシャー リソースとアーティファクト マニフェストの状態に対してクエリを実行し、変更不可としてマークされているものを特定できます。 詳細については、「パブリッシャー リソース プレビュー管理機能」を参照してください。

次のロジックに留意してください。

• ネットワーク サービス設計バージョン (NSDV) が変更不可としてマークされている場合は、CGS も変更不可としてマークする必要があります。 それ以外の場合、デプロイ呼び出しは失敗します。
• ネットワーク機能定義バージョン (NFDV) が変更不可としてマークされている場合は、アーティファクト マニフェストも変更不可としてマークする必要があります。 それ以外の場合、デプロイ呼び出しは失敗します。
• アーティファクト マニフェストまたは CGS のみが変更不可としてマークされている場合、NFDV と NSDV が変更不可としてマークされているかどうかに関係なく、デプロイの呼び出しは成功します。
• アーティファクト マニフェストを変更不可としてマークすると、そのマニフェストに一覧表示されているすべてのアーティファクトも、アーティファクト ストアに必要なアクセス許可を適用することで変更不可としてマークされます。 一覧表示されるアーティファクトには、通常、グラフ、イメージ、Azure Resource Manager テンプレート (ARM テンプレート) が含まれます。
• 残りのギャップに対処するために、合意に基づく名前付け規則とガバナンス手法を使用することを検討してください。

パブリッシャーの高可用性とディザスター リカバリー

Azure Operator Service Manager パブリッシャーは、サポートされているリージョンのローカル可用性ゾーン全体にデプロイされるリージョン サービスです。 パブリッシャーの高可用性とディザスター リカバリーには、次の要件を考慮してください。

• geo 冗長性を提供するには、NF のデプロイを計画しているすべてのリージョンにパブリッシャーがあることを確認します。 リージョン間でパブリッシャーのアーティファクトとリソースの同期状態を維持するために、パイプラインの使用を検討してください。
• パブリッシャー名は、各リージョンの Microsoft Entra テナントごとに一意である必要があります。

NFDG と NFDV に関する考慮事項

ネットワーク機能定義グループ (NFDG) は、複数のサービス間で個別に再利用する予定の最小コンポーネントを表します。 NFDG のすべての部分は、常に一緒にデプロイされます。 これらの部分は networkFunctionApplications 項目と呼ばれます。 たとえば、これらのコンポーネントを常に一緒にデプロイする場合、複数の Helm チャートとイメージで構成される 1 つの NF を 1 つの NFDG としてオンボードするのは自然です。 複数の NF が常に一緒にデプロイされる場合は、それらすべてに対して 1 つの NFDG を用意するのが妥当です。 1 つの NFDG に複数の NFDV を含めることができます。

• CNF NFDV の場合、networkFunctionApplications リストには Helm パッケージのみを含めることができます。
  • 複数の Helm パッケージが常に一緒にデプロイおよび削除される場合は、複数の Helm パッケージを含めるのが妥当です。
• VNF NFDV の場合、networkFunctionApplications リストには少なくとも 1 つの VhdImageFile 値と 1 つの ARM テンプレートが含まれている必要があります。
  • 1 つの 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 成果物を更新する。
• deployParametersMappingRuleProfileを変更する CGS または構成グループ値 (CGV) の更新。
• NFDV にハードコーディングされた既定値を更新する。
• コンポーネントの有効化を更新して、 applicationEnablement: Disabled経由で展開されないようにします。

NSDG と NSDV に関する考慮事項

ネットワーク サービス設計グループ (NSDG) は、1 つ以上の NFDG と、同時にデプロイされたインフラストラクチャ コンポーネントの複合です。 これらのコンポーネントには、Nexus Kubernetes または Azure Kubernetes Service (AKS) のクラスターと VM が含まれる場合があります。 サイト ネットワーク サービス (SNS) は、単一の NSDV を指します。 このような設計により、1 つの SNS PUT 呼び出しから特定のサイトへのネットワーク サービスの一貫性のある反復可能なデプロイが提供されます。

NSDG の例を次に示します。

• 認証サーバー機能 (AUSF) NF
• 統合データ管理 (UDM) NF
• AUSF または UDM をサポートする管理 VM
• Unity Cloud セッション管理機能 (SMF) NF
• AUSF、UDM、および SMF がデプロイされる Nexus Kubernetes クラスター

これら 5 つのコンポーネントは、単一の NSDG を形成します。 1 つの NSDG に複数の NSDV を含めることができます。

NSDV のマイナーまたはメジャー更新プログラム

NSDV は、ベース NSD のリリースを表し、一意のバージョンに関連付けられています。 NSDV の変更は NFDV の変更よりも頻度が低く、場合によっては、単一の NSDV がサイト ネットワーク サービスのライフサイクル全体をサポートします。 ただし、次のサービスの変更には新しい NSDV が必要です。

• CGS での値の作成、削除、または追加。
• 展開されたサイト ネットワーク サービス リソースによって使用される NF ARM テンプレートを変更する。
• デプロイ サイト リソースによって使用されるインフラストラクチャ ARM テンプレートを変更する。

SNS に関する考慮事項

インフラストラクチャを含め、サイト全体に対して 1 つの SNS を使用することをお勧めします。 SNS では、必要なインフラストラクチャ (たとえば、Nexus Kubernetes または AKS のクラスターと VM) をデプロイし、その上に必要な NF をデプロイする必要があります。 このような設計により、1 つの SNS PUT 呼び出しから特定のサイトへのネットワーク サービスの一貫性のある反復可能なデプロイが提供されます。

すべての SNS は、システム割り当てマネージド ID ではなく、ユーザー割り当てマネージド ID を使用してデプロイすることをお勧めします。 このユーザー割り当てマネージド ID には、NFDV にアクセスするためのアクセス許可が必要であり、マネージド ID オペレーターの役割自体が必要です。 詳細については、「ユーザー割り当てマネージド ID を作成して割り当てる」を参照してください。

リソース スキームに関する考慮事項

次の 2 つのシナリオは、Azure Operator Service Manager のリソース マッピングを示しています。

シナリオ: 単一ネットワーク機能

1 つまたは 2 つのアプリケーション コンポーネントを含む NF を Nexus Kubernetes クラスターにデプロイします。 リソースの内訳を以下に示します。

• NFDG: コンポーネントを個別に使用できる場合は、コンポーネントごとに 1 つを持つ 2 つの NFDG。 コンポーネントが常に一緒に展開される場合は、1 つの NFDG を使用します。
• NFDV: 必要に応じて (NFDV のマイナーまたはメジャー バージョンの更新をトリガーするユース ケースに基づく)。
• NSDG: 1 つ。 NF と Kubernetes クラスターの定義を結合します。
• NSDV: 必要に応じて (NSDV のマイナーまたはメジャー バージョンの更新をトリガーするユース ケースに基づく)。
• CGS: 1 つ。 管理を容易にするために、CGS には、デプロイするコンポーネントとインフラストラクチャごとにサブセクションを用意することをお勧めします。 CGS には NFD のバージョンも含めることをお勧めします。
• CGV: CGS の数に基づき 1 つ。
• SNS: NSDV ごとに 1 つ。

シナリオ: 複数のネットワーク機能

一部の共有コンポーネントと独立したコンポーネントを持つ複数の NF を 1 つの Nexus Kubernetes クラスターにデプロイします。 リソースの内訳を以下に示します。

• NFDG:
  • すべての共有コンポーネントに対して 1 つ。
  • 独立したコンポーネントまたは NF ごとに 1 つ。
• NFDV: NFDV マイナーまたはメジャー バージョンの更新をトリガーするユース ケースごとに、それぞれの NFDG に複数。
• NSDG: 1 つ。 すべての NF、共有コンポーネントおよび独立したコンポーネント、インフラストラクチャ (Kubernetes クラスターまたはサポート VM) を結合します。
• NSDV: 必要に応じて (NSDV のマイナーまたはメジャー バージョンの更新をトリガーするユース ケースに基づく)。
• CGS:
  • 1 つ。 すべてのコンポーネントに対するグローバル設定。
  • NF ごとに 1 つ (NFD のバージョンを含める)。
  • パラメーターの総数に応じて、すべての CGSを 1 つの CGS にまとめることを検討してください。
• CGV: CGS の数に等しい。
• SNS: NSDV ごとに 1 つ。

アップグレードの考慮事項

NF がインプレースとインサービスのアップグレードをサポートしていることを前提として、CMF には次の考慮事項が適用されます。

• 新しいグラフとイメージを追加すると、Azure Operator Service Manager によって新しいグラフがインストールされます。
• 一部のグラフとイメージを削除すると、Azure Operator Service Manager は NFDV で宣言されなくなったグラフを削除します。
• Azure Operator Service Manager は、NFDV/NSDV が同じ NFDG/NSDG から生成されたこと、つまり同じパブリッシャーであることを検証します。 クロスパブリッシャー アップグレードはサポートされていません。

VNF には次の考慮事項が適用されます。

• インプレース アップグレードは現在サポートされていません。 更新されたイメージを左右に並べて表示して、新しい VNF をインスタンス化する必要があります。 次に、SNS を削除して古い VNF を削除します。
• 高可用性のために VNF が VM のペアとしてデプロイされている場合は、VM を 1 つずつ削除してアップグレードできるようにネットワーク サービスを設計できます。 個々の VM の削除とアップグレードを許可するには、次の設計をお勧めします。
  • 専用の ARM テンプレートを使用して各 VM をデプロイします。
  • ARM テンプレートから、CGS を介して 2 つのパラメーターを公開する必要があります。
    • 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>

クリーンアップに関する考慮事項

リソースをクリーンアップするときは、順序が重要です。 違う順序でリソースを削除すると、孤立したリソースが残ってしまう場合があります。

オペレーター リソース

デプロイされた環境をクリーンアップするための最初の手順として、オペレーター リソースを次の順序で削除します。

1. SNS
2. サイト
3. CGV

これらのオペレーター リソースを正常に削除してからでなければ、Nexus Kubernetes クラスターなどの他の環境リソースの削除に進むことはできません。

パブリッシャー リソース

オンボード環境をクリーンアップするための最初の手順として、次の順序でパブリッシャー リソースを削除します。

1. NSDV
2. NSDG
3. NFDV
4. NFDG
5. アーティファクト マニフェスト
6. アーティファクト ストア
7. パブリッシャー

Azure Operator Service Manager は、削除操作の一部として名前空間を削除しません。 そのため、すべてのリソースが削除された後、一部のアーティファクトがクラスター上に残る可能性があります。 残りのアーティファクトを削除するには、クラスターに作成されたすべてのワークロード名前空間を削除する必要があります。 アクションを自動化するには、ワークフロー パイプラインの一部として名前空間の削除操作を含めることをお勧めします。

Azure グローバル制限に関する考慮事項

Azure では、すべての Azure サービスに特定のグローバル サービスの制限と制約が適用されます。 Azure Operator Service Manager を使用してワークロードをオンボード、設計、または運用する際に考慮する必要がある制限の一覧を次に示します。

ARM テンプレートの制限

これらの制限は、Azure Operator Service Manager で使用されるレンダリングされた ARM テンプレートに適用されます。

AZURE RBAC の制限

これらの制限は、Azure Operator Service Manager のデプロイに使用されるターゲット サブスクリプションに適用されます。

一般に、AOSM では、ターゲット サブスクリプションに対する同時 SNS 操作の数が 8 倍必要です。

その他の制限

これらの制限は、実際の特定のユース ケースで確認されています。

包括的な一覧については、 Azure サブスクリプションとサービスの制限、クォータ、制約に関する記事を参照してください。