ネットワーク機能のオンボードとデプロイに関する Azure Operator Service Manager のベストプラクティス

[アーティクル]
08/13/2024

Microsoft は、Azure Operator Service Manager を使用してネットワーク機能 (NF) を管理するための多くの実証済みプラクティスを開発しました。この記事では、NF ベンダー、電話会社、およびそのパートナーが設計を最適化するために従うことができるガイドラインを提供します。これらのプラクティスは、NF をオンボードしてデプロイする際に念頭に置いておく必要があります。

一般的な考慮事項

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

計画的な使用に合わせてアーティファクトを構成します。サイトまたはインスタンスによって異なるアーティファクトからグローバルアーティファクトを分離することを検討してください。
ネットワークのニーズに一致する一連のパラメーターを持つ複数の NF のサービス構成を確認します。たとえば、1,000 個の値を持つグラフがあり、そのうちの 100 個だけをカスタマイズするとします。コンフィギュレーショングループスキーマ (CGS) レイヤー (以降のセクションで詳しく説明) で、100 個のみを公開していることを確認します。
インフラストラクチャ (クラスターなど) またはアーティファクトストアを分離し、(特に 1 つのサービス内の) サプライヤー間でアクセスする方法について、早い段階で検討してください。パブリッシャーリソースのセットをこのモデルと一致させます。
Azure Operator Service Manager サイトは、デプロイ先を表す論理的な概念です。たとえば、コンテナー化されたネットワーク機能 (CNF) 用の Kubernetes クラスターや、仮想化されたネットワーク機能 (VNF) 用の Azure Operator Nexus 拡張カスタムの場所などがあります。これは物理エッジサイトの表現ではないので、複数のサイトが同じ物理的な場所を共有するユースケースがあります。
Azure Operator Service Manager にはさまざまな API が用意されているため、ADO やその他のパイプラインツールと簡単に組み合わせることができます。

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

NF サプライヤーごとに 1 つのパブリッシャーを作成することをお勧めします。このプラクティスにより、すべてのサプライヤーに最適なサポート、メンテナンス、ガバナンスエクスペリエンスが提供され、複数のベンダーから成る複数の NF で構成されている場合、ネットワークサービスの設計が簡素化されます。
目的の Azure Operator Service Manager パブリッシャーリソースとアーティファクトのセットがテストされ、運用環境での使用が承認されたら、セット全体を変更不可としてマークして、偶発的な変更を防ぎ、一貫したデプロイエクスペリエンスを確保することをお勧めします。変更不可機能を使用して、運用環境で使用されるリソースおよびアーティファクトと、テストおよび開発目的で使用されるリソースおよびアーティファクトを区別することを検討してください。パブリッシャーリソースとアーティファクトマニフェストの状態に対してクエリを実行し、変更不可としてマークされているものを特定できます。詳細については、「テナント、サブスクリプション、リージョン、プレビュー管理」を参照してください。

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

ネットワーク機能定義のグループとバージョンに関する考慮事項

ネットワーク機能定義グループ (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 テンプレートが含まれている必要があります。 ARM テンプレートでは、単一の仮想マシン (VM) をデプロイする必要があります。 1 つの VNF に複数の VM をデプロイするには、VM ごとに個別の ARM テンプレートを使用してください。

ARM テンプレートは、次のリソースプロバイダーからの Resource Manager リソースのみをデプロイできます。

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

Note

上記の一覧以外のリソースを含む ARM テンプレートの場合、VNF でのすべての PUT 呼び出しと再 PUT で検証エラーが発生します。

ネットワーク機能設計バージョンのマイナーまたはメジャーバージョンの更新をトリガーする一般的なユースケース

deployParametersMappingRuleProfile の変更をトリガーする既存のリリースの CGS/コンフィギュレーショングループの値 (CGV) の更新。
NFDV でハードコーディングされた値の更新。
コンポーネントを非アクティブにして、applicationEnablement: Disabled 経由でデプロイされないようにする。
グラフやイメージなどの新しい NF リリース。

Note

特定の NF のペイロードが変更されるたびに必要な変更の最小数。新しい CGS パラメーターを公開しないマイナーまたはメジャーの NF リリースでは、アーティファクトマニフェストを更新し、新しいイメージとグラフをプッシュし、NFDV バージョンをバンプするだけで済みます。

ネットワークサービス設計のグループとバージョンに関する考慮事項

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

NSDG の例を次に示します。

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

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

ネットワークサービス設計バージョンのマイナーまたはメジャーバージョンの更新をトリガーする一般的なユースケース

CGS の作成または削除。
展開されているいずれかの NF に関連付けられている NF ARM テンプレートの変更。
インフラストラクチャ ARM テンプレートの変更 (AKS/NAKS や VM など)。

Note

NFDV の変更によって NSDV 更新がトリガーされることはありません。 NFDV 値は CGS 内のパラメーターとして公開されるため、オペレーターは CGV を使用して展開する内容を制御できます。

コンフィギュレーショングループスキーマに関する考慮事項

NF 全体の CGS は常に 1 つから開始することをお勧めします。サイト固有またはインスタンス固有のパラメーターがある場合でも、それらを 1 つの CGS に保持することをお勧めします。複数のコンポーネント (まれに NF、より一般的にはインフラストラクチャ) または複数の NF 間で共有される構成がある場合は、複数の CGS に分割することをお勧めします。 CGS の数によって、CGV の数が定義されます。

シナリオ

FluentD、Kibana、Splunk (一般的なサードパーティコンポーネント) は、NSD 内のすべての NF に対して常にデプロイされます。これらのコンポーネントを 1 つの NFDG にグループ化することをお勧めします。
NSD には複数の NF があり、すべてがいくつかの構成 (展開場所、パブリッシャー名、およびいくつかのグラフ構成) を共有します。

このシナリオでは、1 つのグローバル CGS を使用して、一般的な NF およびサードパーティコンポーネントの構成を公開することをお勧めします。 NF 固有の CGS は必要に応じて定義できます。

公開するパラメーターを選択する

CGS には、NF (day 0/N 構成) または共有コンポーネントによって使用されるパラメーターのみを含める必要があります。
めったに構成されないパラメーターには、既定値が定義されている必要があります。
複数の CGS を使用する場合は、パラメーター間の重複をほとんどまたはまったくなくすことをお勧めします。重複が必要な場合は、パラメーター名が CGS 間で明確に区別できることを確認します。
CGS では、API (Azure Operator Nexus、Azure Operator Service Manager) を使用して定義できる内容を考慮する必要があります。たとえば、CloudInit ファイルを使用してこれらの構成値を定義するのとは対照的です。
不明な場合は、パラメーターを公開し、CGS で適切な既定値を指定することをお勧めします。次の例は、サンプルの CGS と対応する CGV ペイロードを示しています。
1 つのユーザー割り当てマネージド ID がすべての 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 Operator Service Manager によって生成された CGV ペイロード:

{
"abc": 30,
"xyz": 40,
"qwe": 20
}

コンフィギュレーショングループの値に関する考慮事項

CGV リソースの作成を送信する前に、基になる YAML または JSON ファイルのスキーマと値が、対応する CGS で想定されているものと一致していることを検証できます。これを実行するには、Visual Studio Code の YAML 拡張機能を使用する方法があります。

CLI の考慮事項

Azure Operator Service Manager CLI 拡張機能は、NFD と NSD の発行を支援します。このツールは、新しい NFD と NSD を作成するための開始点として使用します。 CLI を使用して初期ファイルを作成することを検討してください。次に、それらを編集して、発行する前にインフラストラクチャコンポーネントを組み込みます。

サイトネットワークサービスに関する考慮事項

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

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

ユースケースごとの Azure Operator Service Manager リソースマッピング

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

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

1 つまたは 2 つのアプリケーションコンポーネントを含む NF を NAKS クラスターにデプロイします。

リソースの内訳:

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

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

一部の共有コンポーネントと独立したコンポーネントを持つ複数の NF を 1 つの NAKS クラスターにデプロイします。

リソースの内訳:

NFDG:
- すべての共有コンポーネントの NFDG。
- すべての独立したコンポーネントまたは NF の NFDG。
NFDV: NFDV のマイナーバージョンまたはメジャーバージョンの更新をトリガーする前述の「一般的なユースケース」セクションで説明したユースケースに従って、NFDG ごとに複数。
NSDG: 1 つ。すべての NF、共有コンポーネントおよび独立したコンポーネント、インフラストラクチャ (Kubernetes クラスターまたはサポート VM) を結合します。
NSDV: 必要に応じて、NSDV のマイナーまたはメジャーバージョンの更新をトリガーする前述の「一般的なユースケース」セクションで説明したユースケースに基づいています。
CGS:
- 未婚であることを表わします。共有構成値を持つすべてのコンポーネントにグローバル。
- NFD のバージョンを含む NF ごとの NF CGS。
- パラメーターの総数に応じて、すべての CGSを 1 つの CGS にまとめることを検討してください。
CGV: CGS の数に等しい。
SNS: NSDV ごとに 1 つ。

ソフトウェアのアップグレードに関する考慮事項

NF が CNF のインプレース/インサービスアップグレードをサポートしていると仮定します。

新しいグラフとイメージが追加されると、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 の削除とアップグレードを許可するには、次の設計をお勧めします。
- 各 VM を専用の ARM テンプレートを使用してデプロイします。
- ARM テンプレートから、CGS を介して次の 2 つのパラメーターを公開する必要があります。どのインスタンスがプライマリ/セカンダリであるかを示すことができる VM 名と、VM のデプロイを許可するかどうかを制御するデプロイポリシーです。
- NFDV では、deployParameters と templateParameters をパラメーター化して、それぞれに CGV を使用して一意の値を指定できるようにする必要があります。

高可用性とディザスターリカバリーの考慮事項

Azure Operator Service Manager は、それらをサポートするリージョン内の可用性ゾーン全体にデプロイされたリージョンサービスです。 Azure Operator Service Manager を使用できるすべてのリージョンについては、「リージョン別の Azure 製品」を参照してください。可用性ゾーンを持つ Azure リージョンの一覧については、「適切な Azure リージョンを選択する」を参照してください。

次の高可用性とディザスターリカバリーの要件を考慮してください。

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

Note

リージョンが使用できなくなった場合は、別のリージョンのパブリッシャーリソースを使用して 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 に設定されます。オンボード中は、障害発生時の Helm のロールバックを防ぐために、アトミックフラグを false に設定することをお勧めします。そのための最適な方法は、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
            }

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

孤立したリソースが残らないように、次の順序でオペレーターリソースを削除します。

SNS
サイト
CGV

重要

NFDV を削除する前に、必ず SNS が削除されていることを確認してください。

孤立したリソースが残らないように、次の順序でパブリッシャーリソースを削除します。

CGS
NSDV
NSDG
NFDV
NFDG
アーティファクトマニフェスト
アーティファクトストア
発行元

NF で cert-manager が実行される場合の考慮事項

重要

このガイダンスは、特定のリリースにのみ適用されます。ご利用のバージョンを確認し、適切に動作するようにしてください。

リリース 1.0.2728-50 からリリースバージョン 2.0.2777-132 まで、AOSM では cert-manager を使用して証明書を格納およびローテーションします。この変更の一環として、AOSM は azurehybridnetwork 名前空間に cert-manager オペレーターをデプロイし、CRD を関連付けます。複数の cert-manager オペレーターが別々の名前空間にデプロイされていても、すべての名前空間を監視することになるため、クラスターで効果的に実行できる cert-manager は 1 つだけです。

ワークロードのデプロイの一環としてクラスターに cert-manager をインストールしようとすると、CRD が "存在し、現在のリリースにインポートできません" というエラーでデプロイエラーが発生します。このエラーを回避するには、cert-manager のインストールをスキップし、代わりに AOSM によって既にインストールされている cert-manager オペレーターと CRD に依存することをお勧めします。

考慮すべきその他の構成変更

以前のユーザー cert-manager に関連付けられている NfApp を無効にすることに加えて、他の変更が必要になる可能性があることがわかりました。

1 つの NfApp に cert-manager と CA インストールの両方が含まれている場合は、これらを 2 つの NfApp に分割して、パートナーが cert-manager を無効にして CA インストールを有効にできるようにする必要があります。
他の NfApp に、古いユーザーの cert-manager NfApp への DependsOn 参照がある場合は、これらを削除する必要があります。
他の NfApp が古いユーザーの cert-manager 名前空間の値を参照している場合は、新しい azurehybridnetwork 名前空間の値に変更する必要があります。

Cert-Manager バージョンの互換性と管理

cert-manager オペレーターについては、現在デプロイされているバージョンは 1.14.5 です。ユーザーは、このバージョンとの互換性をテストする必要があります。今後の cert-manager オペレーターのアップグレードは、NFO 拡張機能のアップグレードプロセスを通じてサポートされる予定です。

CRD リソースについては、現在デプロイされているバージョンは 1.14.5 です。ユーザーは、このバージョンとの互換性をテストする必要があります。共通クラスター CRD の管理は通常、クラスター管理者によって処理されるため、標準の Nexus アドオンプロセスを使用して CRD リソースのアップグレードを有効にするよう取り組んでいます。

次の方法で共有

ネットワーク機能のオンボードとデプロイに関する Azure Operator Service Manager のベストプラクティス

一般的な考慮事項

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

ネットワーク機能定義のグループとバージョンに関する考慮事項

ネットワーク機能設計バージョンのマイナーまたはメジャーバージョンの更新をトリガーする一般的なユースケース

ネットワークサービス設計のグループとバージョンに関する考慮事項

ネットワークサービス設計バージョンのマイナーまたはメジャーバージョンの更新をトリガーする一般的なユースケース

コンフィギュレーショングループスキーマに関する考慮事項

シナリオ

公開するパラメーターを選択する

コンフィギュレーショングループの値に関する考慮事項

CLI の考慮事項

サイトネットワークサービスに関する考慮事項

ユースケースごとの Azure Operator Service Manager リソースマッピング

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

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

ソフトウェアのアップグレードに関する考慮事項

高可用性とディザスターリカバリーの考慮事項

トラブルシューティングの考慮事項

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

NF で cert-manager が実行される場合の考慮事項

考慮すべきその他の構成変更

Cert-Manager バージョンの互換性と管理

フィードバック

その他のリソース

次の方法で共有

ネットワーク機能のオンボードとデプロイに関する Azure Operator Service Manager のベスト プラクティス

一般的な考慮事項

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

ネットワーク機能定義のグループとバージョンに関する考慮事項

ネットワーク機能設計バージョンのマイナーまたはメジャー バージョンの更新をトリガーする一般的なユース ケース

ネットワーク サービス設計のグループとバージョンに関する考慮事項

ネットワーク サービス設計バージョンのマイナーまたはメジャー バージョンの更新をトリガーする一般的なユース ケース

コンフィギュレーション グループ スキーマに関する考慮事項

シナリオ

公開するパラメーターを選択する

コンフィギュレーション グループの値に関する考慮事項

CLI の考慮事項

サイト ネットワーク サービスに関する考慮事項

ユース ケースごとの Azure Operator Service Manager リソース マッピング

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

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

ソフトウェアのアップグレードに関する考慮事項

高可用性とディザスター リカバリーの考慮事項

トラブルシューティングの考慮事項

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

NF で cert-manager が実行される場合の考慮事項

考慮すべきその他の構成変更

Cert-Manager バージョンの互換性と管理

フィードバック

その他のリソース

ネットワーク機能のオンボードとデプロイに関する Azure Operator Service Manager のベストプラクティス

ネットワーク機能設計バージョンのマイナーまたはメジャーバージョンの更新をトリガーする一般的なユースケース

ネットワークサービス設計のグループとバージョンに関する考慮事項

ネットワークサービス設計バージョンのマイナーまたはメジャーバージョンの更新をトリガーする一般的なユースケース

コンフィギュレーショングループスキーマに関する考慮事項

コンフィギュレーショングループの値に関する考慮事項

サイトネットワークサービスに関する考慮事項

ユースケースごとの Azure Operator Service Manager リソースマッピング

高可用性とディザスターリカバリーの考慮事項