Azure Local のクラウド デプロイに関するネットワークに関する考慮事項

適用対象: Azure Local の Hyperconverged デプロイ

この記事では、クラウド デプロイ用の Azure ローカル システム ネットワークを設計および計画する方法について説明します。 続行する前に、さまざまな Azure ローカル ネットワーク パターン 使用可能な構成について理解してください。

ネットワーク設計フレームワークの理由

Azure Local インスタンスのホスト ネットワークの設計には、接続モード、アーキテクチャ、物理トポロジ、クラスター サイズ、ストレージ接続、ネットワーク アダプター ポート、ネットワーク トラフィックの意図、IP アドレス指定、VLAN、バックアップ、送信接続、ソフトウェア定義ネットワークの 10 を超えるインターロックの決定が含まれます。 構造化フレームワークは、次の場合に役立ちます。

  • 前の選択が制約され、後の選択肢が簡略化されるように、各決定を正しい順序で 1 回行います。
  • アーキテクチャ、ストレージの種類、意図のサポートされていない組み合わせなど、無効な組み合わせを早期にキャッチします。
  • アーキテクト、運用、およびフィールドデプロイ全体で共有ボキャブラリを確立します。
  • 単一ノードのエッジ クラスターから 64 ノードのマルチラック展開に反復可能なプロセスを適用します。

ネットワーク設計フレームワーク

ネットワーク 設計フレームワークは、Azure Local インスタンスに対して 11 回の決定のシーケンスです。 最初に接続モードを決定してから、設計をハイパーコンバージド (HCI) パスまたは非集約 (DA) パスにフォークするアーキテクチャを選択します。 それぞれの後の決定では、パスと終了の両方を、設計上の考慮事項の一覧と共に文書化します。

  1. 接続モードを決定する
  2. アーキテクチャを決定する
  3. クラスター トポロジを決定する
  4. クラスター サイズを決定する
  5. ストレージ接続を決定する
  6. ネットワーク アダプターのポートと構成を決定する
  7. ネットワーク トラフィックの意図を決定する
  8. 管理 IP とインフラストラクチャ ネットワークを決定する
  9. バックアップ ネットワークを決定する
  10. 送信接続を決定する
  11. ソフトウェア定義ネットワーク (SDN) を決定する

決定 1: 接続モードを決定する

接続モードによって、Azure Local インスタンスが登録、課金、ライフサイクル管理のためにAzureに到達する方法が決まります。 最初に決定するのは、ハイパーコンバージド アーキテクチャと非集約アーキテクチャの両方に適用され、 Decision 10 の送信接続設計に影響するためです。

  • 接続済み: ノードとインフラストラクチャ サービスは、インターネット経由で、直接、エンタープライズ プロキシ、または Azure Arc ゲートウェイ経由で、または ExpressRoute またはサイト間 VPN を使用するプライベート パス経由でAzureに到達します。 このモードは最も一般的であり、標準のクラウドデプロイに必要です。 送信接続の詳細については、 決定 10 で計画します。
  • 非接続（エアギャップ）: 主権環境、規制対象環境、またはエアギャップ環境では、Azure Local の非接続運用により、パブリック Azure エンドポイントの代わりにローカルの Autonomous Cloud エンドポイントが提供されます。 切断されたデプロイでは、専用の 3 ノード管理クラスターで実行されているオンプレミスのAzure Arcコントロール プレーンが使用されます。

接続モードの決定に関する考慮事項の概要を次に示します。

# 考慮事項 対象
1 接続されたデプロイでは、Arc の登録、課金、ライフサイクル管理のために、Azureへの送信アクセスが必要です。 デシジョン 10 で送信トポロジを計画します。 両方とも
2 切断環境のデプロイでは、ローカルの Autonomous Cloud エンドポイントを使用した Azure Local の切断操作を使用し、パブリック Azure エンドポイントを必要としません。 両方とも
3 切断されたデプロイには、専用の 3 ノード管理クラスターと 1 つ以上のワークロード クラスターが必要です。 両方とも
4 接続モードは、 決定 2 で選択したハイパーコンバージド アーキテクチャと非集約アーキテクチャの両方に適用されます。 両方とも

決定 2: アーキテクチャを決定する

アーキテクチャの決定は、設計を 2 つのパスのいずれかにフォークします。 この記事の残りの部分では、ストレージ アーキテクチャ、クラスター サイズ、および使用可能なネットワーク意図が決まります。

Architecture ストレージ アーキテクチャ 一般的なスケール いつ使用するか
Hyperconverged (HCI) 記憶域スペース ダイレクト (S2D) によってプールされたローカルの NVMe/SSD/HDD。 RDMA 経由のストレージ トラフィック。 1～16 ノード、単一ラックまたはラックアウェア構成 ほとんどのデプロイ。 コンピューティングとストレージは一緒にスケーリングされます。
Hyperconverged (HCI) – ハイブリッド ストレージバリアント S2D と 外部 SAN を並行運用します。 ワークロードごとにストレージの種類を選択します。 1 ~ 16 ノード、単一ラック 特定のワークロードに対して SAN ベースのボリュームも必要とするハイパーコンバージド クラスター。 SAN は初期デプロイ後に接続します。ラック認識はサポートされていません。
分離型 (DA) 外部 SAN: ファイバー チャネル (FC) または IP ベースの SAN。 S2D なし。 コンピューティングとストレージは個別にスケーリングされます。 1 ~ 8 ラック、ラックあたり最大 16 ノード、クラスターあたり 64 ノード 既に SAN ストレージを運用しているか、コンピューティングとストレージを個別にスケーリングする必要があります。

ハイパーコンバージド アーキテクチャには、S2D とサイド バイ サイドで外部 SAN を実行する オプションのハイブリッド ストレージ バリアントもあり、ワークロードごとにストレージの種類を選択できます。 これは、初期デプロイ後に追加するハイパーコンバージド専用の構成です。 決定 5 では、設計の詳細とサポートされている外部ストレージ統合について説明します。

このフレームワークの各決定では、個別のハイパーコンバージド (HCI) セクションと非集約 (DA) セクションを使用して、両方のアーキテクチャを並行して文書化します。 ここで選択したアーキテクチャの設計上の決定に従います。

アーキテクチャの決定に関する要約された考慮事項を次に示します。

# 考慮事項 対象
1 選択したアーキテクチャによって、ストレージ接続、ネットワーク アダプター ポート、および後の手順で使用できるネットワーク トラフィックの意図が決まります。 両方とも
2 Hyperconverged (HCI) は、2 つの部屋または可用性ゾーンにクラスターを拡張するラック対応のバリアントをサポートします。一方、分割 (DA) は複数のラックにまたがってスケーリングされます。 決定 3 で物理レイアウトを定義します。 両方とも
3 Hyperconverged (HCI) では、ローカル ドライブで記憶域スペース ダイレクトが使用されます。 コンピューティングとストレージは、最大 16 個のノードで一緒にスケーリングされます。 HCI
4 ハイブリッド ストレージはハイパーコンバージド専用のバリアントです。クラスターは、外部 SAN とサイド バイ サイドで S2D を実行します。 最初のデプロイ中ではなく、初期デプロイ (day-2 操作) の後に外部 SAN をアタッチします。 HCI
5 非集約 (DA) では、外部 SAN (ファイバー チャネル (FC) または IP ベースの SAN が使用され、記憶域スペース ダイレクトは使用されません。 コンピューティングとストレージは、1 ~ 8 ラック、ラックあたり最大 16 ノード、クラスターあたり 64 ノードで個別にスケーリングできます。 DA

決定 3: クラスター トポロジを決定する

クラスター トポロジの決定により、ノードとスイッチの物理的なレイアウトが定義されます。 使用可能なオプションは、 決定 2 で選択したアーキテクチャによって異なります。

どちらのアーキテクチャでも、標準的な物理構成は、ToR (トップオブラック) スイッチ 2 台を備えた単一ラックです:

  • マルチシャーシ リンク アグリゲーション (MLAG) で構成された ToR スイッチのペア。同じラック内の最大 16 ノードをサポートします。
  • ToRの上位にある帯域外管理用のベースボード管理コントローラー（BMC）スイッチ1台。
  • 既存のコア スイッチ、ルーター、またはファイアウォールへのノースアウトバウンド アップリンク。

Hyperconverged (HCI)

ハイパーコンバージド クラスターでは、単一ラックまたはラック対応レイアウトが使用されます。

  • 単一ラック: すべてのノードと ToR スイッチ ペアが 1 つのラックにあり、最大 16 個のノードをサポートします。 スイッチド パターンの場合、すべてのホスト トラフィック (管理、コンピューティング、ストレージ) が同じスイッチ ペアで実行されます。

  • ラック対応 (2 つのゾーン):ラック対応クラスターは、ハイパーコンバージドデプロイを 2 つのルームまたは可用性ゾーンに分散します。

    • 偶数台のノード（最大8ノード）が2つの部屋に分散配置され、2つのクラスター可用性ゾーンに割り当てられます。
    • S2D レプリケーションでは、ルーム間で 1 ミリ秒未満の待機時間が必要です。
    • RDMA ストレージ トラフィックは ToR レイヤーにとどまり、スパインを通過することはありません。

    ラック対応クラスターでは、次の 4 つのアップリンク オプションを使用できます。

    オプション Topology 注記
    1. 専用ストレージ リンク 1室あたり2 TOR(合計4) VLAN 711 の TOR1↔TOR3、VLAN 712 の TOR2↔TOR4。
    2. 集約されたストレージ リンク 1室あたり2 TOR(合計4) ストレージでは、部屋をまたいで LAG/vPC を使用します。オプション 1 と比べて、追加ホップが発生する可能性があり、RDMA レイテンシが増加するおそれがあります。
    3. ルームごとのノード接続 1 部屋あたり ToR 1 台 (合計 2 台) どちらのストレージ ネットワークも、部屋ごとに同じ ToR を共有します。バンドルされたルーム間リンク。
    4. クロスルーム ノード接続 1 部屋あたり ToR 1 台 (合計 2 台) 各マシンは両方の部屋のToRに配線されるため、ToR間の依存性は低減されますが、配線量は増加します。

分離型（DA）

分離型クラスターは、1～8台のラックにまたがることができます:

  • 単一ラック: 2 スイッチ HSRP ペアで最大 16 ノードで十分です。 クラスター ネットワークはスタンドアロン ネットワーク ポートで実行され、ネットワーク ATC では管理されません。
  • 複数のラック: 16 ノードを超える場合は、リーフ スパイン (Clos) ファブリックで接続された最大 8 個のラックにクラスターを分散します。各ラックには、2 つのコンピューティング リーフ スイッチがあり、2 つのスパインと 2 つのサービス リーフ スイッチがラックの上にあります。 各ラックは最大 16 個のノードを保持し、クラスターは最大 64 ノードにスケーリングします。 ファブリック ベースの SDN のみがサポートされています。Microsoft SDN はサポートされていません。

リーフスパイン ファブリック アーキテクチャ、トラフィック フロー、および分離されたパターンの選択方法の詳細については、「分離されたデプロイのネットワーク参照パターンの概要」および「分離されたデプロイのネットワーク参照パターンの選択」を参照してください。

クラスター トポロジの決定に関する考慮事項の概要を次に示します。

# 考慮事項 対象
1 ToR スイッチのペアを備えた単一のラックは、両方のアーキテクチャで最大 16 個のノードをサポートします。 両方とも
2 Hyperconverged シングルラック クラスターは、同じ MLAG 構成の ToR スイッチ ペアを介して、すべてのホスト トラフィック (管理、コンピューティング、およびストレージ) を実行します。 別のストレージ専用スイッチ ペアを使用しないでください。 HCI
3 ハイパーコンバージド ラック対応クラスターは、2 つの部屋または可用性ゾーンにまたがり、ノードの数は偶数で、ルーム間の待機時間は最大 8 ミリ秒未満です。 ラック対応クラスターは、外部 SAN (ハイブリッド) ストレージではサポートされていません。 HCI
4 ハイパーコンバージド ラック対応クラスターの場合は、4 つのアップリンク オプションのいずれかを選択します。 専用ストレージ リンク (オプション 1) は、最も短い待機時間で RDMA トラフィックを ToR レイヤーに保持します。 HCI
5 集約されていないクラスターは、リーフスパイン (Clos) ファブリックによって接続された 1 ~ 8 個のラックにまたがり、ラックあたり最大 16 ノード、クラスターあたり 64 ノードです。 DA
6 16 を超える非集約ノードの場合は、複数のラックにわたってリーフスパイン ファブリックを使用します。 ファブリック ベースの SDN のみがサポートされています。 DA

決定 4: クラスター サイズを決定する

Azure Local インスタンスのサイズを判断するには、Azure Local sizer ツールまたは Odin for Azure Localに含まれているコミュニティ ツール サイザーを使用します。ここでは、仮想マシン (VM)、VM のサイズ、Azure Virtual Desktopなどの VM のワークロードの使用など、プロファイルを定義できます。SQL Serverまたは AKS。

Azure Localコンピューターの要件に関する記事で説明されているように、単一のハイパーコンバージド (HCI) Azure Local インスタンスでサポートされるマシンの最大数は 16 です。 64 ノードへの外部 SAN スケールを使用する非集約デプロイ。 ワークロードの容量計画を完了したら、インフラストラクチャでワークロードを実行するために必要なマシン ノードの数を十分に理解している必要があります。

Hyperconverged (HCI)

ハイパーコンバージド クラスターでは、1 から 16 個のノードがサポートされます。 ノード数によって、 デシジョン 5 のストレージ接続オプションが決まります。

  • ワークロードに S2D ストレージを備えた 4 つ以上のノードが必要な場合: ストレージ ネットワーク トラフィックにスイッチレス構成を使用することはできません。 ストレージ トラフィックを処理するには、リモート ダイレクト メモリ アクセス (RDMA) をサポートする物理スイッチを含める必要があります。 Azure ローカル インスタンス のネットワーク アーキテクチャの詳細については、「 Network 参照パターンの概要を参照してください。
  • ワークロードで必要なノード数が 4 つ以下の場合: 記憶域接続用にスイッチレス構成または切り替え構成を選択できます。 スイッチレス ストレージは、1 ~ 4 ノードのクラスターでサポートされています。
  • スイッチレス構成を超えて後でスケールアウトする場合: ストレージ ネットワーク トラフィックには物理スイッチを使用する必要があります。 スイッチレス展開でスケールアウトを行う場合は、ノード間のネットワーク配線を手動で構成する必要がありますが、Microsoft はこうした構成を Azure Local のソフトウェア開発サイクルの一環として積極的には検証していません。

分離型（DA）

分割されたクラスターでは、コンピューティングとストレージが 1 ~ 8 ラックに個別にスケーリングされ、ラックあたり最大 16 ノード、クラスターあたり最大 64 ノードが使用されます。 ストレージ容量はノード数に依存しません。ストレージはローカル ドライブではなく外部 SAN によって提供されるためです。

サポートされている配置図形

ノード数とストレージ オプションの組み合わせによって、展開図形がサポートされているかどうか、およびResource Manager テンプレートが必要かどうかが決まります。

Nodes ストレージ用スイッチなし (S2D スイッチレス) ストレージ用ネットワーク スイッチ (S2D スイッチ) 外部 SAN (FC または IP ベース)
1 ノード ✅ (既定値) ✅ ✅
2 ノード ✅(Azure ポータルまたは ARM テンプレート) ✅ ✅
3 ノード ✅ (ARM テンプレートのみ) ✅ ✅
4 ノード ✅ (ARM テンプレートのみ) ✅ ✅
5 ~ 16 ノード ❌ ✅ ✅
16 を超えるノード (マルチラック) ❌ ❌ ✅

クラスター サイズの決定に関する考慮事項の概要を次に示します。

# 考慮事項 対象
1 S2D ストレージを使用するノードが 4 つを超えるハイパーコンバージド クラスターには、ストレージ ネットワーク トラフィック用の物理スイッチが必要です。 HCI
2 オーケストレーターを使用してクラスターをスケールアウトする場合は、ストレージ ネットワーク トラフィックに物理スイッチを使用する必要があります。 HCI
3 非集約クラスターは、コンピューティングとストレージを 1 ~ 8 ラックに個別にスケーリングし、ラックあたり最大 16 ノード、クラスターあたり 64 ノードにスケーリングします。 ストレージ容量は、外部 SAN によって提供されるため、ノード数に依存しません。 DA

決定 5: ストレージ接続を決定する

物理ネットワークの要件で説明されているように、ストレージ接続オプションは、決定 2 で選択したアーキテクチャによって異なります。 Resource Manager テンプレートでオーバーライドしない限り、すべての記憶域スペース ダイレクト (S2D) パターンでは、次の Network ATC ストレージの既定値が使用されます。

ストレージ ネットワーク 既定の VLAN 既定のサブネット
ストレージ ネットワーク 1 7:11 10.71.1.0/24
ストレージ ネットワーク 2 712 10.71.2.0/24
ストレージ ネットワーク 3 (存在する場合) 713 10.71.3.0/24

Hyperconverged (HCI)

Hyperconverged 展開では、次の 2 つのストレージ接続の種類のいずれかで記憶域スペース ダイレクトを使用します。

  • 切り替えストレージ: 物理ネットワーク スイッチを使用してストレージ トラフィックを処理します。 切り替えストレージは、1 から 16 個のノードをサポートし、スケールアウトをサポートします。
  • スイッチレス ストレージ: それらの間のノードを、ストレージ トラフィック用のクロス ネットワークまたはファイバー ケーブルと直接接続します。 スイッチレス ストレージは、ハード上限である 1 ~ 4 ノードのクラスターでのみサポートされており、スケールアウトはサポートされていません。

切り替えオプションとスイッチレス オプションの長所と短所については、上記のリンク先の記事を参照してください。

クラスターのサイズが 4 ノード以下の場合にのみ、切り替えストレージとスイッチレス ストレージを決定できます。 ノードが 4 つを超える S2D クラスターは、ストレージ用のネットワーク スイッチを使用して自動的にデプロイされます。

Important

スイッチド ハイパーコンバージド展開の場合は、管理トラフィックとコンピューティング トラフィックを伝送する 同じ Top-of-Rack (ToR) スイッチ ペア経由でストレージ トラフィックを実行します。 ストレージの意図に対してのみ、個別の専用のスイッチ ペアを使用することはサポートされていません。 管理ネットワークとコンピューティング ネットワークから分離されたストレージのみのスイッチ ペアは、ノードが管理パスを維持している間にストレージ (東西) パスを失う可能性があるため、クラスターのスプリットブレインの状況につながる可能性があります。 すべてのインテントは、ラックあたり 1 組の MLAG 構成された ToR スイッチ ペア内に収めてください。

クラスターに 4 つ以下のノードがある場合、ストレージ接続の決定は、 決定 7 で定義できるネットワーク意図の数と種類に影響します。 たとえば、スイッチレス構成の場合は、2 つのネットワーク トラフィックの意図を定義する必要があります。 クロス ケーブルを使用した東西通信のストレージ トラフィックには、南北接続がないため、ネットワーク インフラストラクチャの残りの部分から完全に分離されています。 つまり、管理送信接続とコンピューティング ワークロードに対して 2 つ目のネットワーク意図を定義する必要があります。

各ネットワークインテントは、1 つの物理ネットワーク アダプター ポートでのみ定義できますが、フォールト トレランスは提供されません。 そのため、ネットワーク意図ごとに少なくとも 2 つの物理ネットワーク ポートを使用することをお勧めします。 記憶域にネットワーク スイッチを使用する場合は、ストレージを含むすべてのネットワーク トラフィックを 1 つのネットワーク インテントにグループ化できます。これは、 hyperconverged または 完全に集約されたホスト ネットワーク構成とも呼ばれます 。

スイッチレス クラスターのストレージ IP 計画

スイッチレス ストレージの場合、各ノードは他のすべてのノードに直接接続する必要があるため、ストレージ サブネットの数はノードの数と共に増加します。 ストレージ サブネットの数は N × (N - 1) です。 N はノードの数です。

スイッチレス ノード ストレージ サブネット ストレージの自動IP
2 2 自動的にサポートされます
3 6 ストレージ自動 IP を無効にし、Resource Manager テンプレート内のすべてのストレージ IP を定義する
4 12 ストレージ自動 IP を無効にし、Resource Manager テンプレート内のすべてのストレージ IP を定義する

カスタム ストレージ IP の定義の詳細については、「ストレージ のカスタム IP」を参照してください。

ハイブリッド ストレージ (S2D と外部 SAN)

Azure Localでは、外部 SAN をハイパーコンバージド クラスターにアタッチして、SAN でサポートされるストレージがインボックス 記憶域スペース ダイレクト (S2D) と並行して動作するようにサポートしています。 外部 SAN は常にデプロイ後 (2 日目) の操作としてアタッチされます。最初に S2D を使用して標準のハイパーコンバージド クラスターをデプロイし、その後で SAN をアタッチします。 ハイブリッド構成は最初からデプロイできないため、クラスターの実行後に接続する場合でも、SAN ファブリックとアダプターを前もって計画してください。 これにより、VM、AKS クラスター、Azure Virtual Desktop (AVD) のワークロードごとに S2D または外部 SAN ボリュームを選択できます。 複数の SAN ボリュームが NTFS でフォーマットされたクラスター共有ボリューム (CSV) として表示され、各 CSV は VM のストレージ パスとしてマップするフォルダー パスとして表示されます。 2 つの統合が一般公開されています。

  • ファイバー チャネル (FC) SAN アレイ: 各ノードは、各ホスト上のホスト バス アダプター (HBA) を使用して、冗長性のためにデュアル ファイバー チャネル ファブリック (Fabric A および Fabric B) を介して SAN に接続します。 SAN ベースのボリュームは NTFS CSV として検出され、ノード間で共有され、コンピューティングとストレージは個別にスケーリングされます。
  • IP ベース (イーサネット) SAN: 各ノードは、標準の iSCSI イニシエーターまたはベンダーが提供するストレージ クライアントを使用してイーサネット ストレージ ネットワーク経由でアレイに接続し、冗長ファブリック間でマルチパス I/O を使用してリモート ブロック ボリュームをクラスターにマウントします。 ボリュームは NTFS CSV として表示され、ノード間で共有され、コンピューティングとストレージは個別にスケーリングされます。 これらのソリューションでは、通常、専用のストレージ サブネット、ジャンボ フレーム、NIC の結合/チーミングが使用されます。 これらのストレージ サブネットがルーティング可能かどうかは、ストレージ ネットワーク アーキテクチャによって異なります。デプロイによっては、分離されたルーティング不可能なサブネット上の専用ストレージ スイッチにホストを直接接続するデプロイもあれば、データセンター ネットワークからストレージ トラフィックをルーティングするデプロイもあります。 サポートされるノード数、スケール制限、および正確なジャンボ フレーム MTU は、ストレージ ベンダーとAzure Local検証によって異なります。

ネットワーク設計の観点から:

  • S2D ストレージ ネットワークは、元の切り替えまたは切り替えなしのデプロイから変更されません。
  • SAN 接続では、個別のファブリックとアダプター (FC HBA、または IP ベースの SAN の NIC) が使用され、ネットワーク ATC では管理されません。 SAN 接続用の専用ポートと、IP ベースのブロック ストレージ用に、ジャンボ フレームを含む専用ストレージ サブネット (ストレージ ネットワーク アーキテクチャに応じてルーティング可能またはルーティング不可能) を計画します。
  • ラック対応クラスターは、ハイパーコンバージドデプロイ用の外部 SAN ストレージではサポートされていません。

詳細については、Azure Local の外部ストレージ サポートを参照してください。

分離型（DA）

外部 SAN（ファイバー チャネルまたは IP ベースの SAN。たとえば、iSCSI や PowerFlex SDC）を使用する場合、記憶域スペース ダイレクト も、Network ATC によって管理される RDMA ストレージ インテントもありません。 両方の場合において:

  • 管理トラフィックとコンピューティング トラフィックは、スイッチ埋め込みチーミング (SET) 仮想スイッチを使用してネットワーク ATC を介して構成されます。
  • クラスター ネットワーク (クラスター共有ボリューム (CSV) と SMB マルチチャネル経由のライブ マイグレーション トラフィックは、ネットワーク ATC で管理 されていない スタンドアロン ネットワーク ポートで実行されます。 これらのネットワークの専用 VLAN とサブネットを計画します。 既定のクラスター VLAN は 1711 と 1712 です。
  • クラスター ネットワークのイーサネットサービス品質 (QoS) を構成します。 決定 6 では、推奨されるサービス クラス (CoS) の優先順位スキームと帯域幅の割り当てについて説明します。

ストレージ ファブリックは SAN の種類によって異なります。

  • ファイバー チャネル (FC):記憶域は、イーサネット ネットワークとは別に FC ファブリック上で完全に実行されます。 イーサネット 記憶域 QoS、優先順位フロー制御 (PFC)、または無損失イーサネットは必要ありません。すべてのクラスター トラフィックは、SMB マルチチャネル経由の TCP です。
  • IP ベースの SAN: ストレージは専用イーサネット アダプター経由で実行され、IP ベースの SAN にアクセスします。 記憶域スペース ダイレクトを置き換えて RDMA を削除します。また、すべてのトラフィック (IP ベースの SAN トラフィック、CSV、ライブ マイグレーション、クラスター ハートビート) が TCP 経由で実行されるため、無損失イーサネットとPFC は必要ありません。 デプロイする前に、SAN 配列モデルがサポートされていることを確認します。

iSCSI デプロイは、次の検証済みパターンに従います。このパターンは、 Decision 6 で選択します。

  • 6 ポート専用パス: 専用ポートは、クラスター ネットワークとは別に iSCSI パス A とパス B を伝送します。 このパターンでは、管理とコンピューティングの意図でバックアップ ホスト vNIC としてデプロイ後に追加する、オプションのゲスト内バックアップ ネットワークがサポートされます。 専用バックアップ アダプターは使用しません。

ファイバー チャネルと iSCSI のホスト側とアレイ側の構成など、外部 SAN の接続の詳細については、「外部ストレージ アレイをAzure Localに接続する」および「Azure Localの外部ストレージサポート」を参照してください。

iSCSI ホストの静的ルート

iSCSI デプロイの場合、管理インターフェイスにのみ既定のゲートウェイがあります。 クラスターと iSCSI インターフェイスには、既定のゲートウェイ のない IP アドレスがあります。 1 つ以上のレイヤー 3 ホップ離れた iSCSI ターゲットに到達するには、iSCSI VLAN のリーフ スイッチ ゲートウェイ (スイッチ仮想インターフェイス) に次ホップを設定し、ストレージ アダプターにバインドされたルートを使用して、すべての iSCSI ターゲット IP の各ホストに永続的な /32 静的ルートを構成します。 静的ルートは、iSCSI トラフィックをストレージ アダプターから強制的に送信し、管理ネットワークに漏洩しないようにします。 マルチパス I/O (MPIO) 構成では、各 iSCSI パスには、それぞれの VLAN 上の同じターゲットへの独自の静的ルートが必要です。 配列が同じサブネット内の多数のターゲット IP を公開している場合は、ターゲットごとに 1 つのルートを追加するのではなく、対応するパス ゲートウェイを介してターゲット サブネット全体をルーティングできます。 オペレーティング システムのインストール中に、iSCSI イニシエーター、静的ルート、および MPIO を構成します。

ノート

外部 SAN ストレージでは、記憶域スペース ダイレクトは使用されないため、RDMA に依存するストレージインテントオプションは使用できません。 管理用および計算用の設定と、上記で説明したスタンドアロン クラスター ネットワークを使用します。

ストレージ用のカスタム IP

既定では、ネットワーク ATC は次の表からストレージ用の IP と VLAN を自動的に割り当てます。

ストレージ アダプター IP アドレスとサブネット VLAN
pNIC1 10.71.1.x 7:11
pNIC2 10.71.2.x 712
pNIC3 10.71.3.x 713

ただし、デプロイ要件が既定の IP と VLAN に適合しない場合は、独自の IP、サブネット、VLAN をストレージに使用できます。 この機能は、ARM テンプレートを使用してクラスターをデプロイする場合にのみ使用でき、テンプレートで次のパラメーターを指定する必要があります。

  • enableStorageAutoIP: このパラメーターが指定されていない場合は、 trueに設定されます。 デプロイ中にカスタム ストレージ IP を有効にするには、このパラメーターを false に設定する必要があります。 ストレージ自動 IP は、2 ノードのスイッチレス クラスターでサポートされています。3 ノードおよび 4 ノードのスイッチレス クラスターの場合は、このパラメーターを false に設定し、すべてのストレージ IP を明示的に定義する必要があります。
  • storageAdapterIPInfo: このパラメーターには enableStorageAutoIP パラメーターとの依存関係があり、ストレージ自動 IP パラメーターが false に設定されている場合は常に必要です。 ARM テンプレートの storageAdapterIPInfo パラメーター内で、独自の IP とサブネット マスクを使用して、各ノードとネットワーク アダプターの ipv4Address と subnetMask パラメーターを指定する必要もあります。
  • vlanId: 上の表で説明したように、このパラメーターは、ネットワーク ATC の既定の VLAN を変更する必要がない場合に使用します。 ただし、これらの既定の VLAN がネットワークで機能しない場合は、各ストレージ ネットワークに独自の VLAN ID を指定できます。

次の ARM テンプレートには、ストレージ用のネットワーク スイッチを備えた 2 ノード Azure Local インスタンスの例が含まれています。ストレージ IP はカスタマイズされています。カスタム ストレージ IP を使用した 2 ノードのデプロイです。

ストレージ接続の決定に関する考慮事項の概要を次に示します。

# 考慮事項 対象
1 Azure ポータルを使用したスイッチレス構成は、1 つまたは 2 つのノード クラスターでサポートされています。 3 ノードと 4 ノードのストレージ スイッチレス クラスターは、Resource Manager テンプレートを使用してのみデプロイできます。 HCI
2 スケールアウト操作は、スイッチレスデプロイではサポートされていません。 デプロイ後のノード数を変更するには、手動で構成する必要があります。 HCI
3 ストレージのネットワーク スイッチは、1 から 16 までの任意の数のノードで使用でき、1 つの意図ですべてのトラフィックの種類を伝達できます。 HCI
4 ハイパーコンバージドデプロイでは、ストレージインテントは管理とコンピューティングと同じ ToR スイッチペアを共有する必要があります。 専用のストレージ専用スイッチ ペアはサポートされていないため、クラスターのスプリット ブレインの状況が発生する可能性があります。 HCI
5 非集約 (DA) では、外部 SAN (ファイバー チャネル (FC) または IP ベースの SAN (iSCSI や PowerFlex SDC など) を使用して、クラスターを外部ストレージに接続します。 記憶域スペース ダイレクトはなく、コンピューティングとストレージは最大 64 ノードまで個別にスケーリングされます。 DA
6 iSCSI デプロイでは、6 ポートの専用パス (専用 iSCSI ポート、オプションのバックアップ ネットワーク) というパターンが使用されます。 DA
7 iSCSI では、ストレージ トラフィックがストレージ アダプター上にとどまるように、ターゲットごとの /32 ホスト静的ルートと MPIO が必要です。 iSCSI は TCP 経由で実行されるため、PF と無損失イーサネットは必要ありません。 DA

決定 6: ネットワーク アダプターのポートと構成を決定する

ネットワーク アダプターは、使用されるネットワーク トラフィックの種類 (管理、コンピューティング、ストレージ) によって修飾されます。 OEM と協力して、ハードウェア上の意図 (管理、コンピューティング、ストレージ) ごとに使用可能で修飾されているアダプターを特定します。

Azure Local用のマシンを購入する前に、3 つのトラフィックの種類すべてがAzure Localで必要とされるため、少なくとも 2 つのアダプターが管理、コンピューティング、およびストレージ用に修飾されている必要があります。 クラウド展開では、ネットワーク ATC を使用して適切なトラフィックの種類のネットワーク アダプターを構成するため、サポートされているネットワーク アダプターを使用することが重要です。

オペレーティング システムをインストールし、ノードにネットワークを構成する前に、ネットワーク アダプターに OEM またはネットワーク インターフェイス ベンダーによって提供される最新のドライバーがあることを確認する必要があります。 既定の Microsoft ドライバーを使用する場合、ネットワーク アダプターの重要な機能が表示されない場合があります。

Network ATC で使用される既定値については、 クラスター ネットワーク設定に記載されています。 既定値を使用することをお勧めします。 つまり、必要に応じて、Azure ポータルまたはResource Manager テンプレートを使用して、次のオプションをオーバーライドできます。

  • ストレージ VLAN: この値をストレージに必要な VLAN に設定します。
  • ジャンボ パケット: ジャンボ パケットのサイズを定義します。 RDMA ストレージ トラフィックには、最大転送単位 (MTU) を 9216 バイトにすることをお勧めします。 物理スイッチで同じ MTU を設定します。 外部 SAN (ハイブリッドまたは非集約) ストレージ ファブリックの場合、必要なジャンボ フレーム MTU はストレージ ベンダーに依存し、S2D 値 (RDMA ストレージ ファブリックの場合は 9216 バイト、IP ベースのブロック ストレージ ネットワークの場合はベンダー指定値 (9014 バイトなど) など) とは異なる場合があります。 ストレージ ベンダーによって指定された MTU を使用し、ホストとスイッチ間で同じ値のエンド ツー エンドを構成します。
  • ネットワーク ダイレクト: ネットワーク アダプターの RDMA を無効にする場合は、この値を false に設定します。
  • ネットワーク ダイレクト テクノロジ: この値を RoCEv2 または iWarpに設定します。
  • トラフィック優先度データセンター ブリッジング (DCB): 要件に合った優先順位を設定します。 既定の DCB 値は、Microsoftおよび顧客によって検証されるため、使用することを強くお勧めします。

Hyperconverged (HCI)

ハイパーコンバージド展開では、 決定 7 で意図にトラフィックをグループ化する方法に応じて、ノードごとに 2、4、6、または 8 つのネットワーク アダプター ポートが使用されます。 各ポートの速度と RDMA 機能は、伝送するトラフィックと一致する必要があります。

  • 2 つのポート: 単一の すべてのトラフィックをグループ化 インテント。 SET は、最初の 2 つの物理アダプター (pNIC01 や pNIC02 など) を管理します。 すべてのトラフィックの種類が同じポートを共有します。 少なくとも 10 Gb が必要です。25 GbE 以上をお勧めします。
  • 4 つのポート: Port1 と Port2 (SET) の 管理とコンピューティング の意図に加えて、ポート 3 とポート 4 の専用 ストレージ インテント。 ストレージインテントは SET を使用しません。回復性と帯域幅の集計には SMB マルチチャネルが使用されます。
  • 6 つのポート: 個別の管理 (ポート 1 とポート 2、SET)、 コンピューティング (ポート 3 とポート 4、SET)、 ストレージ (ポート 5 およびポート 6、SMB マルチチャネル) の意図。
  • 8 つのポート: トラフィックを分離するために、残りのポートに 2 つ目のコンピューティングまたはバックアップインテントを追加します。

切り替えパターンの場合、ToR スイッチは 物理スイッチの要件を満たす必要があります。 スイッチレス パターンの場合、ストレージ アダプターはノード間の直接メッシュを形成するため、ストレージ スイッチは必要ありません。各ストレージ サブネットには一意の VLAN が必要であり、サブネット数は 決定 5 で説明されているように増加します。

分離型（DA）

集約されていないデプロイでは、SAN の種類に応じてイーサネット ポート レイアウトが使用されます。 物理アダプターのフォーム ファクターではなく、ネットワーク ポートの数と各ポートの役割によって設計を定義します。 いずれの場合も、2 つのネットワーク ポートには 管理とコンピューティング の意図が含まれ (ネットワーク ATC によって管理される SET チーム)、クラスター ハートビート、クラスター共有ボリューム (CSV)、Live Migration over SMB マルチチャネルなど、ネットワーク ATC が管理しないスタンドアロン ポートとして、クラスター ネットワークが別のペアで伝送されます。 これらのポートを物理アダプター間で分散する方法は OEM の選択肢です。単一のマルチポート アダプター (クワッド ポート OCP など)、2 つの別個のアダプター (オンボード OCP とアドイン アダプターなど) から、または 2 つのオンボード アダプターから取得できます。 既定のクラスター VLAN は 1711 と 1712 です。 各スタンドアロン クラスターとストレージ ポートには 1 つの VLAN が含まれているため、その VLAN を ToR ポートのアクセス (ネイティブ) VLAN として設定し、ホスト インターフェイスにタグを付けないままにすることができます。 クラスターと記憶域の QoS に関するページを参照してください。 各 SAN タイプの完全なスイッチ、ケーブル接続、およびポート レイアウトについては、 分離されたネットワーク参照パターンを参照してください。

ファイバー チャネル (FC)

FC デプロイでは、ノードごとに 4 ポートまたは 6 ポートのイーサネット レイアウトが使用されます。 各サーバーは、イーサネット ネットワーク ポートとは別に、SAN 接続にデュアル ポート FC ホスト バス アダプター (HBA) (ポート A から FC スイッチ A、ポート B から FC スイッチ B) も使用します。

  • 4 つのポート: ネットワーク ポート 1 と 2 (SET) の 管理とコンピューティング 、スタンドアロン ネットワーク ポート 3 と 4 のクラスター ネットワーク。
  • 6 ポート (ゲスト バックアップ):4 ポート レイアウトに加えて、ゲスト バックアップ トラフィック用のネットワーク ポート 5 および 6 (SET) の ゲスト バックアップ コンピューティングインテントと同じです。 詳細については、 デシジョン 9 を参照してください。

iSCSI

iSCSI デプロイでは、この検証済みパターンが使用されます。 ストレージ アダプターは、少なくとも 10 GbE (高スループットワークロードの場合は 25 GbE 以上) である必要があります。

  • 6 ポート専用パス: 管理とコンピューティング (SET) 用の 2 つのネットワーク ポート、クラスター ネットワーク用の 2 つのスタンドアロン ネットワーク ポート (VLAN 1711 と 1712)、専用 iSCSI パス A (VLAN 300) とパス B (VLAN 400) 用の 2 つのスタンドアロン ネットワーク ポート。 このパターンでは、 デシジョン 9 で説明されているように、オプションのバックアップ ネットワークがサポートされます。

クラスターと記憶域の QoS

すべての非集約ストレージとクラスター トラフィックは TCP 経由で実行されます。クラスター ネットワークの SMB マルチチャネル (CSV、ライブ マイグレーション、ハートビート)、iSCSI over TCP (ストレージ用)。 TCP は、自身の再送信と輻輳制御によって輻輳を管理し、損失から復旧するため、この設計では、ロスレス イーサネットやホスト側トラフィック シェーピングは必要ありません。 クラスターとストレージ ポートでは、次の構成を行わないようにします。

  • 優先順位フロー制御 (PFC) または無損失キュー。 PFC は RDMA/RoCE に無損失を提供します。この RDMA/RoCE は、非集約デプロイでは使用されません。 TCP ファブリックにおいて、PFC は運用リスク (ポーズ伝播、ヘッドオブライン ブロッキング、犠牲フローなど) をもたらすだけで、メリットは一切ありません。
  • ホスト側データ センター ブリッジング (DCB) または拡張伝送選択 (ETS)。 ホスト ETS と 802.1p サービス クラス (CoS) は、ホップバイホップのレイヤー 2 メカニズムです。 ホストからリーフへのリンクのみが影響を受け、帯域幅の保証はファブリック全体に及ぶことはありません。

Important

マルチラック リーフ スパインのデプロイでは、クロスラック クラスターとストレージ トラフィックは VXLAN EVPN オーバーレイ経由でレイヤー 3 でルーティングされます。 ホストが設定する 802.1p CoS は 802.1Q VLAN タグ内にのみ存在するため、リーフがフレームをルーティングしてカプセル化すると破棄されます。スパイン スイッチは、ホストの CoS ではなく、外側のパケット ヘッダーでスケジュールします。 そのため、ホスト ETS は、スパインまたはインキャストの輻輳から iSCSI またはクラスター トラフィックを保護できないため、構成すると誤った保護感が得られます。

ファブリック全体でクラスターとストレージのトラフィックを正常に保つには、次の手順を実行します。

  • 容量に合ったファブリックを設計します。 オーバーサブスクリプションを低く抑えるか発生させないリーフスパイン ファブリックを構築し、ストレージのバーストトラフィックに対応できるようスパイン アップリンクの帯域を適切に確保し、ポート構成が許す場合はストレージ トラフィックとクラスタートラフィックを専用ポートに分離します。 TCP 輻輳制御と組み合わせることで、これはクロスラック トラフィックの主な保護です。

ノート

単一ラックのディスアグリゲーテッド クラスター（1 組の ToR 上の単一 Layer 2）や、複数種類のトラフィックを伝送するコンバージド ホスト アップリンクでは、ホスト ETS はそのローカル リンク上で引き続き機能し、大量の CSV または Live Migration トラフィックによってクラスター ハートビートが圧迫されるのを防ぐことができます。 マルチラック レイアウトで推奨されているように、クラスターとストレージ ネットワークに専用ポートを使用する場合、これらのリンクを判断する必要はほとんどありません。そのため、ホスト ETS を省略すると、ごくわずかな影響があります。 すべての場所でホスト ETS を削除することは、ルーティングされた TCP ベースのファブリックの意図的な簡略化です。

クラスター ポートは SMB 経由で CSV とライブ マイグレーションを実行するため、ジャンボ フレームは価値があり、上記の QoS の決定とは無関係です。これは、より少ない、より大きなパケットのメリットを得る一括転送であるためです。 手動で構成する必要はありません。Azure Local Azure ポータルまたは ARM テンプレートで指定したジャンボ フレーム MTU をホスト アダプターに適用するため、ノードでアダプター コマンドを実行する必要はありません。 Azure Localではスイッチが構成されないため、物理スイッチ ポートで同じ MTU を構成する必要があります。一般的なペアリングは、ホスト上の MTU 9000 とスイッチの 9216 です。

ホスト QoS がないため、スタンドアロン クラスターポートとストレージ ポートは 802.1p の優先順位を維持する必要はなく、これらの各ポートは単一の VLAN のみを伝送します。 そのため、その VLAN を ToR ポートの アクセス (ネイティブ) VLAN として設定し、ホスト インターフェイスに タグを付けずにしておくことができます。ホストでは VLAN タグ付けは必要ありません。

  • クラスター ネットワーク: 2 つのクラスター ポートをクラスター VLAN に設定します (例: 1711 と 1712)。
  • iSCSI、6 ポート専用パス: 2 つの専用 iSCSI ポートをストレージ VLAN (300 や 400 など) に設定します。

管理ポートとコンピューティング ポートは別々であり、ネットワーク ATC で管理される SET チームにとどまり、複数の VLAN を伝送する場合はトランクされます。 追加の要件については、ストレージ ベンダーのガイダンスに従ってください。

物理スイッチの要件

スイッチ (ハイパーコンバージド) 展開と非集約展開の場合、物理 Top-of-Rack (ToR) スイッチは、クラスター トラフィックを確実に伝送するために次の機能をサポートする必要があります。

  • 無損失 RDMA トラフィック (IEEE 802.1Qbb) の優先順位フロー制御 (PFC)。
  • トラフィッククラス間の帯域幅割り当て向けの拡張伝送セレクション (ETS)（IEEE 802.1Qaz）。
  • MTU が 9216 バイト以上のジャンボ フレーム。
  • 明示的輻輳通知（ECN）（RoCEv2 の導入向け）
  • 冗長 ToR ペアのマルチシャーシ リンク アグリゲーション (MLAG)。

ノート

スイッチド ハイパーコンバージド (RDMA) デプロイには、PFC、ETS、ECN の機能が適用されます。 集約されていないデプロイでは、すべてのストレージとクラスターのトラフィックが TCP 経由で伝送されるため、NSG、無損失イーサネット、ホストおよびスイッチ ETS は必要ありません。 適切なファブリック容量と TCP 輻輳制御に依存します。 非集約ファブリックには、引き続きジャンボ フレーム、MLAG または仮想ポート チャネル (vPC)、および iSCSI の静的ルーティングを使用した MPIO 互換 VLAN のサポートが必要です。

ネットワーク アダプターの構成決定に関する考慮事項の概要を次に示します。

# 考慮事項 対象
1 可能な限り、既定のネットワーク ATC 構成を使用します。 両方とも
2 物理スイッチは、ネットワーク アダプターの構成に従って構成する必要があります。 Azure Local の物理的ネットワーク要件については、こちらをご参照ください。 両方とも
3 OEM と連携して、Azure Local 上の各インテントでサポートおよび認定されているネットワーク アダプターを確認してください。 サポートされているリストは、Windows Server カタログよりも制約が大きくなります。 両方とも
4 RDMA または iSCSI ストレージ トラフィックをサポートするには、少なくとも 10 Gbps のネットワーク インターフェイスが必要です。 25 GbE 以上をお勧めします。 両方とも
5 既定値を受け入れると、Network ATC はストレージ ネットワーク アダプター IP と VLAN (ストレージ自動 IP) を自動的に構成します。 場合によっては、ストレージ自動 IP がサポートされていないため、Resource Manager テンプレートを使用して各ストレージ ネットワーク アダプター IP を宣言する必要があります。 HCI
6 非集約ストレージとクラスター トラフィックは TCP 経由で実行されるため、優先順位フロー制御 (PFC) とホスト側の ETS/DCB は必要ありません。 ホスト ETS はホストとリーフ間のリンクにのみ影響し、ルーティングされたリーフ/スパイン ファブリック全体には適用されません。クロスラック トラフィックを保護できるように、ファブリック容量を設計してください。 DA
7 非集約展開ではホスト QoS が使用されないため、各スタンドアロン クラスターとストレージ ポートは 1 つの VLAN を保持し、ToR 上のアクセス (ネイティブ) VLAN (たとえば、クラスター ネットワークの場合は 1711 と 1712、専用 iSCSI の場合は 300 と 400) を使用できるため、ホスト インターフェイスには VLAN タグは必要ありません。 DA

決定 7: ネットワーク トラフィックの意図を決定する

Azure Local の場合、すべてのデプロイはホスト ネットワーク構成に Network ATC に依存します。 Azure Portal を使用して Azure Local をデプロイすると、ネットワーク意図が自動的に構成されます。 ネットワークの意図とそのトラブルシューティング方法の詳細については、 一般的なネットワーク ATC コマンドを参照してください。

このセクションでは、ネットワーク トラフィックの意図に対する設計上の決定の影響について説明します。 使用可能なオプションは、アーキテクチャ、クラスター内のノードの数、使用されるストレージ接続の種類によって異なります。

ノート

ネットワーク ATC は、管理トラフィックとコンピューティング トラフィック用の SET 仮想スイッチを作成します。 S2D デプロイのストレージ トラフィックは SMB マルチチャネルを使用し、SET スイッチの背後には配置されません。

Hyperconverged (HCI)

ハイパーコンバージド展開の場合は、ネットワーク トラフィックを 1 つ以上の意図にグループ化する 4 つのオプションから選択できます。

ネットワークの意図: すべてのトラフィックをグループ化する

Network ATC は、管理、コンピューティング、ストレージのネットワーク トラフィックを含む一意の意図を構成します。 この意図に割り当てられたネットワーク アダプターは、すべてのネットワーク トラフィックの帯域幅とスループットを共有します。

  • このオプションには、ストレージ トラフィック用の物理スイッチが必要です。 スイッチレス アーキテクチャが必要な場合は、この種類の意図を使用できません。 Azure ポータルでは、ストレージ接続用のスイッチレス構成を選択すると、このオプションが自動的に除外されます。
  • 高可用性を確保するには、少なくとも 2 つのネットワーク アダプター ポートを使用することをお勧めします。
  • ストレージの RDMA トラフィックをサポートするには、少なくとも 10 Gbps のネットワーク インターフェイスが必要です。 25 GbE 以上をお勧めします。

ネットワークの意図: グループ管理とコンピューティング トラフィック

ネットワーク ATC は、2 つの意図を構成します。 1 つ目の意図には管理とコンピューティング ネットワーク トラフィックが含まれており、2 番目の意図にはストレージ ネットワーク トラフィックのみが含まれます。 各意図には、異なるネットワーク アダプター ポートのセットが必要です。

このオプションは、次の場合に、切り替えストレージ接続とスイッチレス ストレージ接続の両方に使用できます。

  • 高可用性を確保するために、意図ごとに少なくとも 2 つのネットワーク アダプター ポートを使用できます。
  • 記憶域にネットワーク スイッチを使用する場合は、RDMA に物理スイッチが使用されます。
  • ストレージの RDMA トラフィックをサポートするには、少なくとも 10 Gbps のネットワーク インターフェイスが必要です。

ネットワークの意図: コンピューティング トラフィックとストレージ トラフィックをグループ化する

ネットワーク ATC は、2 つの意図を構成します。 最初の意図にはコンピューティングとストレージのネットワーク トラフィックが含まれており、2 番目の意図には管理ネットワーク トラフィックのみが含まれます。 各意図は、異なるネットワーク アダプター ポートのセットを使用する必要があります。

  • このオプションでは、同じポートがコンピューティング トラフィックと共有されるため、ストレージ トラフィックの物理スイッチが必要です。これには南北通信が必要です。 スイッチレス構成が必要な場合は、この種類の意図を使用できません。 Azure ポータルでは、ストレージ接続用のスイッチレス構成を選択すると、このオプションが自動的に除外されます。
  • このオプションには、RDMA の物理スイッチが必要です。
  • 高可用性を確保するには、少なくとも 2 つのネットワーク アダプター ポートを使用することをお勧めします。
  • RDMA トラフィックをサポートするコンピューティングとストレージの意図には、少なくとも 10 Gbps のネットワーク インターフェイスをお勧めします。
  • 管理インテントがコンピューティング意図なしで宣言されている場合でも、Network ATC はスイッチ埋め込みチーミング (SET) 仮想スイッチを作成して、管理ネットワークに高可用性を提供します。

ネットワーク意図: カスタム構成

少なくとも 1 つの意図に管理トラフィックが含まれている限り、独自の構成を使用して最大 3 つの意図を定義します。 2 つ目のコンピューティング意図が必要な場合は、このオプションを使用することをお勧めします。 この 2 つ目のコンピューティング意図要件のシナリオには、リモート ストレージ トラフィック、VM バックアップ トラフィック、または異なる種類のワークロードに対する個別のコンピューティング意図が含まれます。

  • ストレージの意図が他の意図と異なる場合は、切り替えストレージ接続とスイッチレス ストレージ接続の両方にこのオプションを使用します。
  • このオプションは、別のコンピューティング意図が必要な場合、または異なるネットワーク アダプター経由で異なる種類のトラフィックを完全に分離する場合に使用します。
  • 高可用性を確保するには、意図ごとに少なくとも 2 つのネットワーク アダプター ポートを使用します。
  • RDMA トラフィックをサポートするコンピューティングとストレージの意図には、少なくとも 10 Gbps のネットワーク インターフェイスをお勧めします。

分離型（DA）

非集約デプロイの場合、記憶域アレイはファイバー チャネルまたは iSCSI 経由で到達するため、RDMA ストレージの意図はありません。 以下を使用します。

  • SET 仮想スイッチを使用してネットワーク ATC を介して構成された 管理とコンピューティング の意図。
  • 決定 5 で説明されているように、ネットワーク ATC の外部のスタンドアロン ネットワーク ポートで実行されるクラスター ネットワーク (クラスター ハートビート、CSV、SMB マルチチャネル経由のライブ マイグレーション)。
  • iSCSI の場合、iSCSI パスは Network ATC が管理しないスタンドアロン ポートです。 これらは 6 ポート パターン専用です。
  • デシジョン 9 で説明されているように、6 ポート (FC) または 6 ポート専用パス (iSCSI) レイアウトを使用する場合のオプションのゲスト バックアップインテント。

サポートされている意図のグループ化

次の表は、各ストレージ接続オプションでサポートされている意図のグループをまとめたものです。

意図のグループ化 S2D スイッチレス S2D が切り替えられた 外部 SAN (FC または IP ベース)
すべてのトラフィック (管理、コンピューティング、ストレージ) をグループ化する ❌ ✅ ❌
グループの管理とコンピューティング、個別のストレージ ✅ ✅ ❌
コンピューティングとストレージのグループ化、個別の管理 ❌ ✅ ❌
カスタム構成 (最大 3 つの意図) ✅ ✅ ❌
管理とコンピューティングに加えて、ネットワーク ATC によって管理されていないクラスター ネットワーク ❌ ❌ ✅

ネットワーク トラフィックの意図の決定に関する考慮事項の概要を次に示します。

# 考慮事項 対象
1 高可用性を確保するには、意図ごとに少なくとも 2 つのネットワーク アダプター ポートを使用します。 両方とも
2 スイッチレス ハイパーコンバージド クラスターには、少なくとも 2 つの意図 (管理とコンピューティング、ストレージ) が必要です。 HCI
3 すべてのトラフィックをグループ化し、コンピューティングとストレージの意図をグループ化するには、ストレージの物理スイッチが必要であり、スイッチレス クラスターでは使用できません。 HCI
4 非集約デプロイでは、管理とコンピューティングの意図に加えて、Network ATC の外部で実行されるクラスター ネットワークが使用されます。 DA
5 iSCSI の場合、iSCSI パスはスタンドアロンで、ネットワーク ATC 外の専用ポートです DA

決定 8: 管理 IP とインフラストラクチャ ネットワークを決定する

この決定では、インフラストラクチャ サブネットのアドレス空間、これらのアドレスをクラスターに割り当てる方法、およびノードの VLAN ID 要件があるかどうかを定義します。 この決定は、ハイパーコンバージド アーキテクチャと非集約アーキテクチャの両方に適用されます。

ルーティング、ファイアウォール、またはサブネットの要件を予測できるように、デプロイを開始する前に、次のインフラストラクチャ サブネット コンポーネントを計画して定義する必要があります。

回避する予約済み IP 範囲

Azure Localをデプロイすると、プラットフォームは 2 つの内部 Kubernetes CIDR (Kubernetes サービス用に10.96.0.0/12、ポッド ネットワーク用に10.244.0.0/16) を予約します。 Azure リソース ブリッジ (ARB) コントロール プレーンは、この内部 Kubernetes プラットフォームで実行され、デプロイするすべてのAzure Kubernetes Service (AKS) クラスターで同じ範囲が使用されます。 Azure Local構成がこれらの範囲と重複している場合、デプロイが失敗したり、トラブルシューティングが困難な接続の問題が発生したりする可能性があります。

10.96.0.0/12はプラットフォームの内部 Kubernetes Service ネットワークであるため、Azure Localインフラストラクチャ IP はなく、クラスターがアクセスする必要があるコア インフラストラクチャ サービス (DNS やプロキシなど) もそれに含まれる可能性はありません。 ノードとインフラストラクチャ VM から、 10.96.0.0/12 内のアドレスに送信されるすべてのトラフィックは内部的に処理され、実際の宛先に到達することはありません。 次の項目がすべて10.96.0.0/12の外側に収まるように配置してください。

  • クラスターノードの IP アドレスとクラスター IP。
  • Azure Resource Bridge VM とその他のインフラストラクチャ VM の IP アドレス、およびそれらの割り当て元である管理 IP プール。
  • インフラストラクチャが使用する DNS サーバーとプロキシ サーバー。

10.244.0.0/16 ポッドの範囲には同じ制限があります。そこに配置するすべてのインフラストラクチャ IP、ノード IP、または論理ネットワークがポッド ネットワークと競合します。

Azure Localに AKS をデプロイする場合、同じ予約範囲に AKS ワークロードの要件がさらに 2 つ追加されます。

  • AKS 論理ネットワークは予約範囲と重複できません。 AKS クラスターをデプロイする論理ネットワーク (LNET) は、 10.96.0.0/12 (Kubernetes サービス) または 10.244.0.0/16 (ポッド) と重複してはなりません。
  • AKS は、 10.96.0.0/12内のプライベート エンドポイントに到達できません。 AKS ワークロードが依存するプライベート エンドポイント (Azure Container Registry (ACR)、Azure Key Vault、Azure Storage エンドポイントなど) は、10.96.0.0/12内に IP を持つ必要はありません。 AKS コントロール プレーン VM またはワーカー ノードから、その範囲 は 内部 Kubernetes Service ネットワークであるため、その中の任意のアドレスへのトラフィックは内部的に処理され、実際のエンドポイントに到達することはありません。 AKS がアクセスする必要があるプライベート エンドポイントまたはその他のサービスが既に環境に配置されている場合は、AKS をデプロイする前にそれらを移動します。

サービスCIDRとポッドCIDRは現在変更できないため、これらの範囲を移動することを想定するのではなく、これらの範囲を避けるためにネットワークを計画してください。 Azure Local インフラストラクチャ、そこから到達する必要があるエンドポイント、および AKS を除けば、これらのアドレス範囲によってデータセンター内のその他のアドレス空間が予約または制限されることはありません。これらのアドレス範囲と重複しないようにする必要があるのは、クラスター自体が接続するサービスだけです。 マルチラックデプロイを含む完全な AKS アドレス計画要件については、「Azure Localでの AKS の IP アドレスの計画」を参照してください。

回避すべき予約済み範囲

次の IP 範囲は、Kubernetes プラットフォーム (Arc Resource Bridge と AKS の両方で使用) によって内部的に予約されており、Azure Localインフラストラクチャ コンポーネントには使用できません。

予約範囲 これは何に使用されますか ?
10.96.0.0/12 Kubernetes 内部サービス (クラスター IP)
10.244.0.0/16 Kubernetes ポッド ネットワーク

デプロイ前に確認する内容

次の Azure ローカル インフラストラクチャ IP が上記の予約範囲内に含まれていないことを確認します。

これを確認する 問題の例
ノード管理用のあなたのIPアドレス 10.244.1.50ノードがポッド ネットワークと競合する
あなたのクラスター IP 10.96.0.5のクラスター IP にノードから到達できない
Azure リソース ブリッジ VM とインフラストラクチャ IP プール 10.100.0.1から始まるプールは10.96.0.0/12内にあります
あなたのDNSサーバーIP 10.96.1.10の DNS が競合する
プロキシ サーバーの IP 10.97.10.25のプロキシ サーバーが競合する
既定のゲートウェイ 10.96.0.1のゲートウェイが競合する
いずれかのVM用の論理ネットワーク VM サブネット 10.244.100.0/24 がポッド ネットワークと重複する

使用する安全な IP 範囲

競合しない一般的に使用されるプライベート IP 範囲の例を次に示します。

安全範囲 注記
192.168.x.x 小規模デプロイで最も一般的
172.16.x.x から 172.31.x.x まで 中規模のネットワークに適しています
10.0.x.x から 10.95.x.x まで 安全 — 予約された 10.96.0.0 境界以下に収まります
10.112.x.x以上 安全 — 予約済みの10.111.255.255境界の上

IP 計画のリファレンス

管理 IP プール

Azure Local インスタンスの初期デプロイを行うときは、既定でデプロイされるインフラストラクチャ サービスの連続する IP の IP 範囲を定義する必要があります。

範囲に現在および将来のインフラストラクチャ サービスに十分な IP を確保するには、少なくとも 6 つの連続する使用可能な IP アドレスの範囲を使用する必要があります。 これらのアドレスは、クラスター IP、Azure リソース ブリッジ VM、およびそのコンポーネントに使用されます。

インフラストラクチャ ネットワークで他のサービスを実行することが予想される場合は、インフラストラクチャ IP の追加バッファーをプールに割り当てることをお勧めします。 計画したプールのサイズが最初に使い果たされた場合は、PowerShell を使用してインフラストラクチャ ネットワークのデプロイ後に他の IP プールを追加できます。

デプロイ時に、環境チェッカーは、管理 IP プール アドレスから管理 IP プールの既定のゲートウェイへの ICMP 接続をテストします。 既定のゲートウェイで、Azure Local管理サブネットからの ICMP トラフィックが許可されていることを確認します。

管理 IP プールの概要に関する考慮事項を次に示します。

# 考慮事項 対象
1 IP 範囲は連続する IP を使用する必要があり、すべての IP がその範囲内で使用可能である必要があります。 この IP 範囲は、デプロイ後に変更することはできません。 両方とも
2 IP の範囲にはクラスター ノード管理 IP を含めてはなりませんが、ノードと同じサブネット上に存在する必要があります。 両方とも
3 管理 IP プールに定義されている既定のゲートウェイは、インターネット経由または ExpressRoute またはサイト間 VPN を使用するプライベート パス経由で、Azureへの送信接続を提供する必要があります。 両方とも
4 DNS サーバーは、プライベート パスを使用する場合を含め、Active Directoryとパブリック Azure エンドポイントで名前解決を確保する必要があります。 両方とも
5 管理 IP には、Azureへの送信接続が必要です。 決定 10 で説明されているプライベート パス トポロジを使用する場合、パブリック インターネット アクセスは必要ありません。 両方とも
6 環境チェッカーは、Azure ローカル管理 IP プール範囲から既定のゲートウェイで ICMP トラフィックが応答することを検証します。 両方とも

管理 VLAN ID

Azure ローカル インスタンスの管理サブネットでは、既定の VLAN を使用することをお勧めします。この既定の VLAN は、ほとんどの場合、VLAN ID 0 として宣言されています。 ただし、ネットワーク要件でインフラストラクチャ ネットワークに特定の管理 VLAN を使用する場合は、管理トラフィックに使用する物理ネットワーク アダプターで構成する必要があります。

管理に 2 つの物理ネットワーク アダプターを使用する場合は、両方のアダプターに VLAN を設定する必要があります。 この VLAN を使用してノードを正常に登録するには、マシンのブートストラップ構成の一部として、Azure Arc に登録する前にこれを行う必要があります。

物理ネットワーク アダプターで VLAN ID を設定するには、次の PowerShell コマンドを使用します。 この例では、物理ネットワーク アダプター NIC1で VLAN ID 44 を構成します。

Set-NetAdapter -Name "NIC1" -VlanID 44

VLAN ID が設定され、ノードの IP が物理ネットワーク アダプターで構成されると、オーケストレーターは管理に使用される物理ネットワーク アダプターからこの VLAN ID 値を読み取って格納するため、デプロイ時に必要な Azure Resource Bridge VM またはその他のインフラストラクチャ VM に使用できます。 Azure ポータルからクラウド展開を行う際に管理 VLAN ID を設定することはできません。これは、物理スイッチの VLAN が適切にルーティングされていない場合、ノードと Azure 間の接続が切断されるおそれがあるためです。

管理 VLAN ID はデプロイ後に変更できないため、慎重に計画してください。 管理 VLAN ID は、Azure Resource Bridge VM とその他のインフラストラクチャ VM にも継承されるため、それにも適用されます。 デプロイ後にインフラストラクチャ ネットワーク VLAN ID を変更することはサポートされておらず、ノード、インフラストラクチャ サービス、およびAzure間の接続が切断されます。

管理用 VLAN ID を持つ仮想スイッチ

シナリオによっては、デプロイを開始する前に仮想スイッチを作成する必要があります。

ノート

仮想スイッチを作成する前に、Hyper-V ロールを有効にしてください。 詳細については、「 必要な Windows ロールのインストール」を参照してください。

仮想スイッチの構成が必要であり、特定の VLAN ID を使用する必要がある場合は、次の手順に従います。

  1. 推奨される名前付け規則を使用して仮想スイッチを作成します。

    Azure ローカル デプロイでは、管理、コンピューティング、およびストレージの意図のために仮想スイッチと仮想ネットワーク アダプターを作成して構成するために、Network ATC に依存しています。 既定では、Network ATC は意図の仮想スイッチを作成するときに、仮想スイッチの特定の名前を使用します。

    同じ名前付け規則を使用して仮想スイッチに名前を付けることをお勧めします。 仮想スイッチの推奨名は ConvergedSwitch($IntentName)です。 $IntentName デプロイ時にポータルに入力された意図の名前と一致する必要があります。 この文字列は、次の手順で説明するように、管理に使用される仮想ネットワーク アダプターの名前とも一致する必要があります。

    次の例は、 $IntentNameで推奨される名前付け規則を使用して、PowerShell で仮想スイッチを作成する方法を示しています。 ネットワーク アダプター名の一覧は、管理およびコンピューティング ネットワーク トラフィックに使用する物理ネットワーク アダプターの一覧です。

    $IntentName = "MgmtCompute"
New-VMSwitch -Name "ConvergedSwitch($IntentName)" -NetAdapterName "NIC1","NIC2" -EnableEmbeddedTeaming $true -AllowManagementOS $true

    ノート

    Azure ローカル インスタンスがデプロイされると、管理インテント名または仮想スイッチ名の変更はサポートされません。 デプロイ後に意図を更新または再作成する必要がある場合は、同じ意図名と仮想スイッチ名を使用する必要があります。

  2. すべてのノードで必要なネットワーク ATC 名前付け規則を使用して、管理仮想ネットワーク アダプターを構成します。

    仮想スイッチと関連する管理仮想ネットワーク アダプターが作成されたら、ネットワーク アダプター名がネットワーク ATC の名前付け標準に準拠していることを確認します。

    具体的には、管理トラフィックに使用される仮想ネットワーク アダプターの名前には、次の規則を使用する必要があります。

    • ネットワーク アダプターと仮想ネットワーク アダプターの名前は、 vManagement($intentname)を使用する必要があります。
    • この名前では大文字と小文字が区別されます。
    • $Intentname には任意の文字列を指定できますが、仮想スイッチに使用される名前と同じである必要があります。 Mgmt意図名を定義するときは、Azure ポータルでこの同じ文字列を使用してください。

    管理仮想ネットワーク アダプター名を更新するには、次のコマンドを使用します。

    $IntentName = "MgmtCompute"

# Rename VMNetworkAdapter for management because during creation, Hyper-V uses the vSwitch name for the virtual network adapter.
Rename-VmNetworkAdapter -ManagementOS -Name "ConvergedSwitch(MgmtCompute)" -NewName "vManagement(MgmtCompute)"

# Rename NetAdapter because during creation, Hyper-V adds the string "vEthernet" to the beginning of the name.
Rename-NetAdapter -Name "vEthernet (ConvergedSwitch(MgmtCompute))" -NewName "vManagement(MgmtCompute)"

    ノート

    デプロイの検証中に、ノード上のすべての vSwitch に対応する vNIC が必要です。 vSwitch が存在するが、一致する vNIC がない場合、操作は次のエラーで失敗します。

    "操作を完了できませんでした。 200: ノードには vSwitch が存在しますが、vnic は存在しません。このシナリオはサポートされていません。"

    アダプターの名前が、 Get-NetAdapter の出力と Get-VMNetworkAdapter -ManagementOSの間で一致していることを確認します。 一致しない場合は、デプロイを再試行する前に NIC の名前を変更します。

  3. すべてのノードの管理仮想ネットワーク アダプターで VLAN ID を構成します。

    仮想スイッチと管理仮想ネットワーク アダプターが作成されたら、このアダプターに必要な VLAN ID を指定できます。 仮想ネットワーク アダプターに VLAN ID を割り当てるオプションは異なりますが、サポートされる唯一のオプションは、 Set-VMNetworkAdapterIsolation コマンドを使用することです。

    必要な VLAN ID を構成したら、管理仮想ネットワーク アダプターに IP アドレスとゲートウェイを割り当てて、他のノード、DNS、Active Directory、およびインターネットとの接続があることを検証できます。

    次の例では、既定ではなく VLAN ID 8 を使用するように管理仮想ネットワーク アダプターを構成する方法を示します。

    Set-VMNetworkAdapterIsolation -ManagementOS -VMNetworkAdapterName "vManagement($IntentName)" -AllowUntaggedTraffic $true -IsolationMode Vlan -DefaultIsolationID "8"

  4. 展開時に、管理インテントに使用する物理ネットワーク アダプターを指定します。

    新しく作成された仮想ネットワーク アダプターは、Azure ポータル経由でデプロイするときに使用可能と表示されますが、ネットワーク構成はネットワーク ATC に基づいていることに注意してください。 つまり、管理または管理とコンピューティングの意図を構成する場合でも、その意図に使用される物理ネットワーク アダプターを選択する必要があります。

    ノート

    ネットワーク インテントのために、仮想ネットワーク アダプターを選択しないでください。

    同じロジックが Azure Resource Manager テンプレートに適用されます。 仮想ネットワーク アダプターを使用しない、ネットワークの意図に使用する物理ネットワーク アダプターを指定する必要があります。

VLAN ID の概要に関する考慮事項を次に示します。

# 考慮事項 対象
1 マシンを Azure Arc に登録する前に、管理のために物理ネットワーク アダプターで VLAN ID を指定する必要があります。 両方とも
2 マシンを Azure Arc に登録する前に仮想スイッチが必要な場合は、特定の手順を使用します。 両方とも
3 管理 VLAN ID は、デプロイ時にホスト構成からインフラストラクチャ VM に引き継がされます。 両方とも
4 Azure portal のデプロイまたは Resource Manager テンプレートのデプロイには、VLAN ID 入力パラメーターはありません。 両方とも
5 管理に使用するすべてのアダプターには、同じ VLAN ID が構成されている必要があります。 両方とも
6 展開後に管理 (インフラストラクチャ ネットワーク) VLAN ID を変更することはできません。 Azure Resource Bridge VM とその他のインフラストラクチャ VM にも継承されるため、Azure Arcにマシンを登録する前に計画してください。 両方とも

ノードとクラスターの IP 割り当て

Azure Local インスタンスの場合、マシン ノードとクラスター IP に IP を割り当てるには、次の 2 つのオプションがあります。

  • 静的ホスト構成プロトコルと動的ホスト構成プロトコル (DHCP) プロトコルの両方がサポートされています。
  • 適切なノード IP 割り当ては、クラスターライフサイクル管理の鍵となります。 Azure Arc にノードを登録する前に、静的オプションと DHCP オプションを決定します。
  • Arc リソース ブリッジやネットワーク コントローラーなどのインフラストラクチャ VM とサービスでは、管理 IP プールの静的 IP が使用され続けます。 これは、DHCP を使用して IP をノードとクラスター IP に割り当てる場合でも、管理 IP プールが引き続き必要であることを意味します。

以降のセクションでは、各オプションの影響について説明します。

静的 IP の割り当て

ノードに静的 IP が使用されている場合、管理 IP プールを使用して使用可能な IP を取得し、デプロイ時にクラスター IP に自動的に割り当てます。

管理 IP プールに対して定義されている IP 範囲の一部ではないノードには、管理 IP を使用することが重要です。 マシン ノード IP は、定義された IP 範囲と同じサブネット上にある必要があります。

ノードのすべての物理ネットワーク アダプターに対して、既定のゲートウェイと構成済みの DNS サーバーの管理 IP を 1 つだけ割り当てることをお勧めします。 これにより、管理ネットワークの意図が作成された後に IP が変更されないようにします。 これにより、デプロイ プロセス中 (Azure Arc の登録中も含む) にノードが送信接続を維持することも保証されます。

ルーティングの問題を回避し、送信接続と Arc 登録に使用される IP を特定するために、Azure ポータルでは、複数の既定のゲートウェイが構成されているかどうかを検証します。

OS 構成中に仮想スイッチと管理仮想ネットワーク アダプターが作成された場合、ノードの管理 IP をその仮想ネットワーク アダプターに割り当てる必要があります。

DHCP IP 割り当て

ノードの IP が DHCP サーバーから取得された場合は、クラスター IP にも動的 IP が使用されます。 インフラストラクチャ VM とサービスには静的 IP が引き続き必要です。これは、管理 IP プールのアドレス範囲を、ノードとクラスター IP に使用される DHCP スコープから除外する必要があることを意味します。

たとえば、インフラストラクチャの静的 IP に対して管理 IP 範囲が 192.168.1.20 から 192.168.1.30 と定義されている場合、サブネット 192.168.1.0/24 に定義されている DHCP スコープには、インフラストラクチャ サービスとの IP 競合を回避するために、管理 IP プールと同等の除外が必要です。 また、ノード IP に DHCP 予約を使用することをお勧めします。

管理インテントを作成した後に管理 IP を定義するプロセスでは、ネットワークインテント用に選択された最初の物理ネットワーク アダプターの MAC アドレスを使用する必要があります。 この MAC アドレスは、管理目的で作成された仮想ネットワーク アダプターに割り当てられます。 つまり、最初の物理ネットワーク アダプターが DHCP サーバーから取得する IP アドレスは、仮想ネットワーク アダプターが管理 IP として使用するのと同じ IP アドレスです。 そのため、ノード IP の DHCP 予約を作成することが重要です。

クラウドのデプロイ時に使用されるネットワーク検証ロジックは、構成に既定のゲートウェイがある複数の物理ネットワーク インターフェイスを検出すると失敗します。 ホスト IP 割り当てに DHCP を使用する必要がある場合は、前述のように SET (スイッチ埋め込みチーミング) 仮想スイッチと管理仮想ネットワーク アダプターを事前に作成する必要があるため、管理仮想ネットワーク アダプターのみが DHCP サーバーから IP アドレスを取得します。

IP アドレスの概要に関する考慮事項を次に示します。

# 考慮事項 対象
1 ノード IP は、静的アドレスか動的アドレスかに関係なく、定義された管理 IP プール範囲と同じサブネット上にある必要があります。 両方とも
2 管理 IP プールにノード IP を含めてはなりません。 動的 IP 割り当てが使用されている場合は、DHCP の除外を使用します。 両方とも
3 可能な限りノードの DHCP 予約を使用します。 両方とも
4 DHCP アドレスは、ノード IP とクラスター IP でのみサポートされます。 インフラストラクチャ サービスは、管理プールの静的 IP を使用します。 両方とも
5 管理ネットワークインテントが作成されると、最初の物理ネットワーク アダプターの MAC アドレスが管理仮想ネットワーク アダプターに割り当てられます。 両方とも

DNS サーバーに関する考慮事項

Active Directory に基づく Azure ローカル デプロイには、オンプレミス ドメインとインターネット パブリック エンドポイントを解決できる DNS サーバーが必要です。 デプロイの一環として、ノードで構成されているインフラストラクチャ IP アドレス範囲に対して同じ DNS サーバーを定義する必要があります。 Azure Resource Bridge コントロール プレーン VM と AKS コントロール プレーンは、名前解決に同じ DNS サーバーを使用します。 デプロイが完了すると、DNS サーバー IP の変更はサポートされず、Azure Local プラットフォーム スタック全体でアドレスを更新することはできません。

Azure Local に使用される DNS サーバーは、デプロイ前に外部であり、運用可能である必要があります。 構成されているすべての DNS サーバーを、それらに依存する同じAzure Local インスタンス上で仮想マシンとして実行することはサポートされていません。 クラスター ノード、Azure リソース ブリッジ、および AKS では、起動中とワークロード VM が実行される前に名前解決が必要であるため、構成済みの DNS サーバーのうち少なくとも 1 つを Azure Local インスタンスの外部で実行する必要があります。 それ自体でホストされている DNS VM のみに依存するクラスターでは、完全なシャットダウン、再起動、または復旧中に、それらの VM がまだ使用できないときに名前を解決することはできません。 ローカル解決のためにクラスター上で VM として DNS を実行する場合は、構成済みの一覧に少なくとも 1 つの独立した外部 DNS サーバーを保持します。

DNS サーバー アドレスの概要に関する考慮事項を次に示します。

# 考慮事項 対象
1 クラスターのすべてのノードの DNS サーバーが同じである必要があります。 両方とも
2 インフラストラクチャ IP アドレス範囲の DNS サーバーは、ノードで使用されるものと同じである必要があります。 両方とも
3 Azure Resource Bridge VM コントロール プレーンと AKS コントロール プレーンは、インフラストラクチャの IP アドレス範囲で構成された DNS サーバーを使用します。 両方とも
4 デプロイ後に DNS サーバーを変更することはサポートされていません。 Azure ローカル デプロイを実行する前に、必ず DNS 戦略を計画してください。 両方とも
5 インフラストラクチャ ネットワークの ARM テンプレートで複数の DNS サーバーの配列を定義する場合は、次の例のように、各値が引用符 "" 内にあり、コンマで区切っていることを確認します。 両方とも
6 構成されているすべての DNS サーバーを同じAzure Local インスタンス上の仮想マシンとして実行することはサポートされていません。 少なくとも 1 つの構成済み DNS サーバーはクラスターの外部で実行する必要があります。クラスターでホストされている VM が使用できない場合、ブート、シャットダウン、再起動、復旧中に名前解決が機能するようにします。 両方とも
7 構成されているすべての DNS サーバーは、インフラストラクチャに必要なオンプレミス ドメインを解決する必要があります。 8.8.8.8 などのパブリック DNS サーバーはサポートされていません。 両方とも
八 構成されているすべての DNS サーバーは、予約済みの ARB サブネット範囲 (10.96.0.0/12 および 10.244.0.0/16) と重複してはなりません。 両方とも 
"dnsServers": [
    "10.250.16.124",
    "10.250.17.232",
    "10.250.18.107"
]

決定 9: バックアップ ネットワークを決定する

ゲスト (VM) バックアップ トラフィック用の専用バックアップ ネットワークがデプロイに必要かどうかを決定します。 この決定は、ハイパーコンバージド アーキテクチャと非集約アーキテクチャの両方に適用されます。

  • バックアップ ネットワークなし: ゲスト バックアップ トラフィックは、既存のコンピューティング意図を共有します。 これは、小規模なデプロイやバックアップ トラフィックの量が少ない場合に十分です。
  • バックアップ ネットワークを有効にする: ノードごとに 2 つの追加のネットワーク アダプター ポートを備えた専用バックアップ ネットワークを追加します。 専用バックアップ ネットワークは、運用コンピューティングおよびストレージ トラフィックからバックアップ トラフィックを分離し、バックアップ 期間中のワークロードのパフォーマンスを保護します。

Hyperconverged (HCI)

ハイパーコンバージド デプロイの場合は、決定 7 で説明されているカスタム構成意図モデルを使用して、専用のバックアップ ネットワークを 2 つ目のコンピューティング意図として追加します。 高可用性を実現するために、2 つの追加のネットワーク アダプター ポートをバックアップインテントに割り当てます。

分離型（DA）

バックアップ ネットワークのサポートは、 決定 6 で選択した SAN の種類とアダプターのレイアウトによって異なります。

  • ファイバー チャネル: 6 ポート レイアウトを使用します。このレイアウトでは、管理とコンピューティングの意図とクラスター ネットワークに加えて、ネットワーク ポート 5 と 6 (SET) に ゲスト バックアップ コンピューティングインテントが追加されます。
  • iSCSI 6 ポート (専用パス):オプションのバックアップ ネットワークをサポートします。 バックアップを有効にすると、管理ポートとコンピューティング ポート (ネットワーク ポート 1 と 2 は、管理ホスト vNIC をホストし、テナント バックアップ VLAN をトランクする NetworkATC マネージド SET スイッチにラップされます。 専用クラスターと iSCSI ポート (ネットワーク ポート 3、4、5、6) は影響を受けません。 お客様は、ネットワーク ATC マネージド仮想スイッチの上のホストにゲスト バックアップ vNIC を手動で作成します。

ファイバー チャネル バックアップとバックアップなしの参照パターンについては、「バックアップ ネットワークを使用したファイバー チャネルの分離パターン」および「バックアップ ネットワークのないファイバー チャネルの非集約パターン」を参照してください。

バックアップ ネットワークの決定に関する考慮事項の概要を次に示します。

# 考慮事項 対象
1 ハイパーコンバージドデプロイでは、カスタム構成意図モデルを使用してバックアップ ネットワークを 2 つ目のコンピューティングインテントとして追加するか、管理およびコンピューティング仮想スイッチの上に追加の vNIC を手動で作成します。 HCI
2 集約されていないデプロイでは、6 ポート (ファイバー チャネル) または 6 ポートの専用パス (iSCSI) レイアウトを使用して、ゲスト バックアップ ネットワークを追加します。 DA

決定 10: アウトバウンド接続を特定する

Azure Local ノードとインフラストラクチャ サービスが登録、課金、ライフサイクル管理のためにAzureにどのように到達するかを計画します。 この決定は、アーキテクチャと、 Decision 1 で選択した接続モードに基づくビルドの両方に適用されます。 Azure Localでは、4 つのパブリック パスバリアントと 1 つの完全プライベート パスという 5 つの送信接続トポロジがサポートされています。

# Topology エンタープライズ プロキシ Arc ゲートウェイ まとめ
1 直接発信 未構成 未構成 ノードは、インターネット経由で直接Azureに到達します。 境界ファイアウォールに 100 を超える FQDN が必要です。 ラボまたは小規模な分離環境に最適です。
2 エンタープライズ プロキシ 設定済み 未構成 すべてのホスト HTTP/HTTPS は、企業プロキシ経由でルーティングされます。 引き続き 100 を超える FQDN が許可され、Azure Local エンドポイントに対して SSL 検査が無効になっている必要があります。
3 Arc ゲートウェイ 未構成 設定済み Arc ゲートウェイ トンネルでは、Azureへの HTTPS トラフィックがサポートされ、ファイアウォール許可リスト上のエンドポイントは 30 個未満です。
4 エンタープライズ プロキシと Arc ゲートウェイ 設定済み 設定済み パブリック パスを使用する新しい運用環境のデプロイに推奨されます。 一元化されたプロキシ ポリシーと最小限の許可リスト。
5 非公開パス 構成済み (Azure Firewall 明示的プロキシ) 設定済み 規制またはセキュリティ ポリシーでパブリック インターネット経由の送信トラフィックが禁止されている場合に推奨されます。 ノードは、Azure ExpressRouteまたはサイト間 VPN 経由でAzureに接続します。 プロキシは常に明示的なプロキシAzure Firewallであり、Arc ゲートウェイが必要です。 Azure Local 2608 以降が必要です。 詳細については、「 プライベート パス」を参照してください。

エアギャップ環境では、パブリック Azure エンドポイントの代わりにローカルの Autonomous Cloud エンドポイントを提供する Azure Local の切断運用を使用します。 詳細については、 デシジョン 1 を参照してください。

Azure Arc ゲートウェイ

Azure Arc ゲートウェイにより、Azure Localのデプロイと運用に必要なパブリック エンドポイントの数が 100 を超えるから 30 未満に減ります。 Arc ゲートウェイ対応のデプロイは、次の 4 つのコンポーネントに依存します。

  • Arc エージェント: すべてのノードで実行され、Azure Arcコントロール プレーンに接続されます。
  • Arc プロキシ: Arc エージェントの一部であり、すべてのノードで実行されるローカル転送プロキシ サービス。 Azure Localで Arc ゲートウェイが有効になっている場合、Arc プロキシは、サポートされている HTTPS トラフィックを Arc ゲートウェイ トンネル経由でリダイレクトします。 ノードは、localhost:40343上でローカルに独自の Arc プロキシに到達しますが、Azure Resource Bridge VM と AKS コントロール プレーンとワーカー VM は、ポート 40343 のクラスター IP を介してそれに到達します。
  • クラスター IP: Azure Resource Bridge と AKS によって使用される 1 つのフォワーダー。 高可用性のためにノード間でフローティングされるため、リダイレクトされた Azure Resource Bridge VM と AKS VM HTTPS トラフィックは、その時点でクラスター IP を所有するノード上の Arc プロキシを常に通過します。 このトラフィックのトラブルシューティングを行うときは、他のノードではなく、現在クラスター IP を所有しているノードの Arc プロキシ ログを分析します。
  • Arc ゲートウェイ リソース: <gatewayId>.gw.arc.azure.comとしてアドレス指定された、Azure管理されたエントリ ポイント。

Arc ゲートウェイが有効になっている場合、各コンポーネントは、その送信トラフィックを特定のプロキシ経由でルーティングします。 ノード OS HTTPS トラフィックはノードのローカル Arc プロキシ (http://localhost:40343) を使用し、Azure Resource Bridge VM と AKS コントロール プレーンとワーカー VM はポート 40343 でクラスター IP を使用します。 Arc 対応Azure Local VM は、独自の専用 Arc プロキシを使用します。 どの場合も、Arc プロキシは、サポートされているMicrosoftマネージド HTTPS エンドポイントのみを Arc ゲートウェイ トンネル経由で転送します。

Arc ゲートウェイで許可されていないエンドポイントへの HTTPS トラフィック (ハードウェア ベンダーの更新サービスやノードにインストールされている他のエージェントなど、サード パーティのサービスや OEM サービスなど) は、エンタープライズ プロキシまたはファイアウォールにリダイレクトされます。 これらのエンドポイントは、要件に基づいて明示的に許可する必要があります。 HTTP トラフィックはトンネリングされることはなく、常にエンタープライズ プロキシまたはファイアウォールに送信されます。

Arc ゲートウェイのしくみとゲートウェイ リソースの作成方法の詳細については、「Azure LocalのゲートウェイAzure Arcについて」を参照してください。 ゲートウェイを介してマシンを登録するには、Arc ゲートウェイを使用して Azure Local マシンを Azure Arc に登録するを参照してください。 図を使用した各送信トラフィック フロー (ノード OS、Azure リソース ブリッジ、AKS、Azure Local VM) の詳細については、Arc ゲートウェイの送信接続の詳細を参照してください。

ノードを登録する前に、次の前提条件を満たす必要があります。

  • Azure Localをデプロイする予定のサブスクリプションに Arc ゲートウェイ リソースを作成します。
  • Arc ゲートウェイ エンドポイントに対するファイアウォールを開き、そのエンドポイントで SSL 検査を無効にします。
  • エンタープライズ プロキシを使用する場合は、Arc 登録の前に、必要なサブネット、ノード名、クラスター名、およびプライベート エンドポイント FQDN をプロキシ バイパス リストに追加します。

Arc ゲートウェイを使用しても、次のような約 23 個の FQDN が境界ファイアウォールまたはプロキシ許可リストに残ります。

  • 2 つのブートストラップ FQDN と 6 つの Arc 登録用 FQDN。
  • Arc ゲートウェイ エンドポイント (<gatewayId>.gw.arc.azure.com)。
  • Arc ゲートウェイが HTTPS のみを処理するため、証明書失効リスト (CRL) エンドポイントは HTTP 経由でのみ使用されます。
  • デプロイ用の Azure Key Vault (vault.azure.net) と監視用ストレージ アカウント (blob.core.windows.net)。

現在のエンドポイントの完全な一覧については、「 ファイアウォールの要件」を参照してください。

ノート

AKS のデプロイ時には、AKS サブネットからインフラストラクチャ サブネットに到達可能である必要があります。 ポート 40343、55000、および 65000 は AKS サブネットから Azure Local クラスター IP に送信され、ポート 22 と 6443 は AKS サブネットとインフラストラクチャ サブネットの間で双方向です。 インフラストラクチャ サブネットとは別のサブネットに AKS を配置する場合は、Arc ゲートウェイでサポートされていない FQDN エンドポイントも許可する必要があります。 完全なポートとエンドポイントの内訳については、 インフラストラクチャ サブネットとは別のサブネット上の AKS クラスターを参照してください。

Arc ゲートウェイの概要に関する考慮事項を次に示します。

# 考慮事項 対象
1 デプロイの前にプロキシ バイパス リストを計画します。 サポートされているプライベート リンク エンドポイントと、スケールアウト時に追加する予定のノード名と IP を含めます。 両方とも
2 Ssl 検査は、Arc ゲートウェイ エンドポイントではサポートされていません。 終端プロキシを使用する場合、プロキシは入れ子になった TLS トンネルをインターセプトできないため、Arc ゲートウェイ エンドポイントの TLS 検査をスキップすることはできません。 両方とも
3 プロキシを手動で構成しないでください。 Arc 登録スクリプトは、WinINET、WinHTTP、環境変数のプロキシ構成を自動化します。 両方とも
4 デプロイ後にプロキシ バイパス リストを更新して、新しいエンドポイントまたはマシンを追加することはできません。 両方とも
5 すべてのAzure Localマシンで同じプロキシ構成を使用します。 両方とも
6 サードパーティや OEM サービスなど、Arc ゲートウェイで許可されていないエンドポイントへの HTTPS トラフィックは、エンタープライズ プロキシまたはファイアウォールにリダイレクトされます。 これらのエンドポイントを明示的に許可します。 両方とも
7 リダイレクトAzureリソース ブリッジ VM と AKS VM トラフィックは、常にクラスター IP を所有するノードを通過します。 クラスター IP を現在所有しているノード上のこのトラフィックについて、Arc プロキシ ログを分析します。 両方とも

プロキシの要件

ほとんどの場合、プロキシは、オンプレミスのインフラストラクチャからインターネットに接続するために必要です。 Azure Local 2506 以降、ホスト プロキシを手動で構成しなくなりました。 代わりに、Arc 登録中にエンタープライズ プロキシ サーバーとプロキシ バイパス リストを 1 回指定すると、Arc 登録スクリプトによって、すべてのノードで 3 つのオペレーティング システム コンポーネント (WinINET、WinHTTP、環境変数) すべてにプロキシが自動的に構成されます。 プロキシの詳細は、Arc 登録スクリプトを使用するか、Configurator アプリを使用して対話形式で指定できます。 (詳細については、プロキシ設定の構成に関するページを参照してください。)

デプロイ時に同じプロキシ構成が Arc Resource Bridge VM と AKS に自動的に引き継がれ、これらのコンポーネントは追加の手動手順なしでインターネットにアクセスできます。 Arc ゲートウェイを使用すると、登録スクリプトによってホスト HTTPS プロキシがローカル Arc プロキシ (http://localhost:40343) に設定され、HTTP トラフィックがエンタープライズ プロキシにルーティングされ、必要な内部エンドポイントが各コンポーネントのバイパス リストに自動的に追加されます。

認証されていないプロキシのみがサポートされます。 .local ドメイン (http://proxy.contoso.local など) を使用するプロキシ自動構成 (PAC) ファイルとプロキシ エンドポイントはサポートされていません。

プロキシ バイパス リストを定義するときは、次の書式設定規則に従って、内部トラフィックがプロキシを正しくバイパスするようにします。

  • 少なくとも、各Azure Local マシンの IP アドレス、クラスター IP、インフラストラクチャ ネットワーク IP を含めます。 Arc Resource Bridge、AKS、および将来のインフラストラクチャ サービスでは、これらの IP が使用されます。 または、インフラストラクチャ サブネット全体をバイパスすることもできます。
  • 各マシンとクラスターの NetBIOS 名を含めます。
  • 内部ドメインの場合は、*など、先頭にアスタリスク (*.contoso.com) ワイルドカードを付けたドメイン名を使用できます。 サブネットの場合は、 192.168.1.*などのワイルドカード表記を使用します。
  • エントリはコンマで区切ります。 サブネットをバイパスする CIDR 表記はサポートされていません。

プロキシ構成に関する考慮事項の概要を次に示します。

# 考慮事項 対象
1 Azure Local 2506 以降、ホスト プロキシは手動で構成しません。 Arc 登録スクリプトは、WinINET、WinHTTP、および環境変数全体で自動的に構成します。 両方とも
2 Arc 登録中に、ノードが Azure Arc に登録される前に、エンタープライズ プロキシ サーバーとプロキシ バイパス リストを 1 回指定します。 両方とも
3 プロキシの詳細は、Arc 登録スクリプトを使用するか、Configurator アプリを介して対話形式で指定できます。 両方とも
4 Arc 登録スクリプトは、デプロイ時にプロキシ構成を Arc Resource Bridge VM と AKS に引き継ぐ。 両方とも
5 認証されていないプロキシのみがサポートされます。 .local ドメインを持つ PAC ファイルとプロキシ エンドポイントはサポートされていません。 両方とも
6 Azure Local ノード用に構成されたプロキシ サーバーは、予約済みの ARB サブネット範囲 (10.96.0.0/12 および 10.244.0.0/16) と重複してはなりません。 両方とも
7 プロキシ バイパスの一覧には、各マシンの IP、クラスター IP、インフラストラクチャ サブネット、マシンとクラスターの NetBIOS 名を含めます。 CIDR 表記はサポートされていないため、エントリをコンマで区切り、ワイルドカード表記 ( 192.168.1.* など) を使用します。 両方とも

非公開パス

プライベート パスは、前の表のトポロジ 5 です。 Azure Arc ゲートウェイとAzure Firewall明示的なプロキシを組み合わせることにより、プライベート接続上のすべてのAzure Local送信トラフィックが保持されるため、ノードはパブリック インターネットではなく、Azure ExpressRouteまたはサイト間 VPN 経由でAzureに到達します。 規制またはセキュリティ ポリシーでパブリック インターネット経由の送信トラフィックが禁止されている場合は、このトポロジを選択します。

プライベート パスを使用するには、Azure Local インスタンスでソフトウェア バージョン 2608 以降を実行する必要があります。 2608 より前のリリースでは、プライベート パス アーキテクチャはサポートされていません。

デプロイする前に、次のコンポーネントを計画します。

  • 少なくとも 1 つのワークロード サブネットと、AzureFirewallSubnetという名前の、以上のサブネットを持つ/26。
  • Standard または Premium レベルの Azure Firewall 明示的なプロキシ機能は Basic レベルでは使用できません。 ファイアウォール ポリシーで明示的なプロキシを有効にし、HTTP と HTTPS の両方のプロキシ エンドポイントとなるファイアウォールプライベート IP を書き留めます。
  • Azure Local マシンを登録するのと同じサブスクリプション内のAzure Arc ゲートウェイ リソース
  • オンプレミス環境から仮想ネットワークへのAzure ExpressRouteまたはサイト間 VPN。ルーティングは、Arc 登録が開始される前にすべてのマシンがAzure Firewallプライベート IP に到達できるように構成されています。

仮想ネットワークを計画するときは、Azure Arc Private Link スコープ制約を考慮します。 Azure Localでは、Azure Firewallが明示的なプロキシとして実行される仮想ネットワーク上のAzure Arc Private Linkスコープはサポートされていません。 ワークロードで Azure Arc for servers Private Link Scope が必要な場合は、そのために別の仮想ネットワークを計画してください。 この制約は仮想ネットワーク トポロジを形成するため、デプロイ時ではなく計画中に解決してください。

プライベート パスには、次のサポート可能性の制限もあります。

  • Azure Firewall明示的なプロキシは、転送プロキシとして使用されます。 Azure Localは、必要なエンドポイントでの TLS 検査をサポートしていません。
  • 明示的なプロキシAzure Firewallに TLS 証明書を適用することはできません。
  • Microsoftでは、ドキュメントで説明されている以外のプライベート パス アーキテクチャのバリエーションは検証またはサポートされません。

アーキテクチャ、シナリオごとのトラフィック フロー、図については、「Azure Localのプライベート パス ネットワークとは」を参照してください。デプロイ手順については、「ゲートウェイとプライベート パスにAzure Local Azure Arc登録する」を参照してください。

プライベート パスの概要に関する考慮事項を次に示します。

# 考慮事項 対象
1 プライベート パスには、Azure Local 2608 以降が必要です。 このトポロジにコミットする前に、ソフトウェアのバージョンを確認します。 両方とも
2 明示的なプロキシは Basic レベルでは使用できないため、Azure Firewallは Standard レベルまたは Premium レベルである必要があります。 両方とも
3 ExpressRoute またはサイト間 VPN 接続を終了する仮想ネットワーク内の/26以上でAzureFirewallSubnetのサイズを設定します。 両方とも
4 Arc 登録を開始する前に、すべてのマシンが Azure Firewall プライベート IP に到達する必要があります。 最初にAzure側のルーティングを完了します。 両方とも
5 Azure Firewallが明示的なプロキシとして実行される仮想ネットワークでAzure Arc Private Linkスコープを有効にしないでください。 Arc Private Link スコープを必要とするワークロードには、別の仮想ネットワークを使用します。 両方とも
6 TLS 検査は、必要なエンドポイントではサポートされていません。また、明示的なプロキシAzure Firewallに TLS 証明書を適用することはできません。 両方とも
7 このトポロジでは、Arc ゲートウェイが必須です。 プロキシは常にAzure Firewall明示的なプロキシであり、IP アドレスとポートとして指定されます。 両方とも
八 Microsoftでは、文書化されたプライベート パス アーキテクチャのみがサポートされます。 バリエーションは検証もサポートもされていません。 両方とも

プライベート エンドポイント

Azure Private Linkプライベート エンドポイントを使用して、Azure ExpressRouteまたはサイト間 VPN 経由のプライベート ネットワーク パスで、サポート Azureされているサービスとしてのプラットフォーム (PaaS) サービスへのトラフィックを保持できます。 プライベート エンドポイントは、Azure Storage (BLOB)、Azure SQL、Azure Key Vault、Azure Container Registry (ACR)、Azure Site Recoveryなどのサービスの 5 つの送信トポロジすべてでサポートされます。 サポートされているシナリオとそのシナリオごとの構成の詳細については、「Azure Localのプライベート エンドポイントAzureについて」を参照してください。

Important

Azure Arc Private Linkは、Azure Local インフラストラクチャ (ノードと Azure リソース ブリッジ)、Azure Local VM、または AKS ではサポートされていません。 Arc 登録では、パブリック Arc エンドポイントを使用する必要があります。 インフラストラクチャ DNS では、Arc FQDN ( gbl.his.arc.azure.com など) をパブリック IP に解決する必要があります。 会社の DNS がこれらの FQDN のプライベート IP を返す場合は、Azure Localに別の DNS サーバーを使用します。 ホスト上の Arc エンドポイントのプライベート IP ( 10.x、 172.16.x、 192.168.xなど) が DNS から返された場合、構成はサポートされません。

プライベート エンドポイントを計画するときは、次の規則に従います。

  • 予約範囲の重複を回避する: プライベート エンドポイント IP は、 10.244.0.0/16 (AKS ポッド) または 10.96.0.0/12 (Kubernetes サービス) 内に収まってはなりません。 重複するエンドポイントは内部クラスター トラフィックとして扱われ、仮想ネットワークから離れることはありません。 たとえば、10.244.1.4 のエンドポイントは失敗しますが、10.245.0.5 は正しくルーティングされます。
  • デプロイ時に重要なサービスをパブリックに保つ: デプロイが完了するまで、Azure Key Vaultとミラーリング監視ストレージ アカウントでパブリック アクセスを有効にし、プライベート ネットワークに制限します。
  • プライベート エンドポイントをバイパス リストに追加する: エンタープライズ プロキシを使用する場合は、Arc 登録時にプライベート エンドポイントの FQDN をプロキシ バイパス リストに追加します。 AKS ワークロードの場合は、Arc 登録後に環境変数バイパス リストに追加します。
  • ワイルドカードを使用しない: *.azurecr.io などのワイルドカード エントリは、バイパス リストではサポートされていません。 デプロイ前に正確なレジストリ FQDN を追加します。これは、イメージ プル用に Azure Resource Bridge と AKS によって使用されるためです。
  • Arc ゲートウェイの外部でプライベート エンドポイントをルーティングする: プライベート エンドポイントは Arc ゲートウェイ経由でルーティングされません。 Azure Site Recoveryなどのサービスの場合は、エンタープライズ プロキシで SSL 検査を無効にするか、できればプロキシ バイパス リストにエンドポイントを追加します。

次の表に、サービスごとのプライベート エンドポイントのガイダンスを示します。

Service FQDN Guidance
Azure Key Vault vault.azure.net デプロイに必要です（シークレットの設定）。 デプロイ時にパブリック アクセスを有効にしておく。後で制限します。
Azure Storage blob.core.windows.net 2 ノード デプロイ (クラウド監視) に必要です。 セットアップが完了するまでパブリック アクセスを有効のままにします。
Azure Container Registry azurecr.io AKS でのイメージ プルに必須です。 バイパス リストにワイルドカードがありません。展開前に特定のレジストリ FQDN を追加します。
Azure Site Recovery privatelink.siterecovery.* Arc ゲートウェイ経由では許可されません。 プロキシで SSL 検査を無効にするか、エンドポイントをプロキシ バイパス リストに追加します。

ファイアウォールの要件

現在、Azure Local とそのコンポーネントが正常に接続できるように、ファイアウォールで複数のインターネット エンドポイントを開く必要があります。 必要なエンドポイントの詳細な一覧については、 ファイアウォールの要件を参照してください。

Azure Arc にノードを登録する前に、ファイアウォールの構成を行う必要があります。スタンドアロン バージョンの環境チェッカーを使用して、ファイアウォールがこれらのエンドポイントに送信されるトラフィックをブロックしていないことを検証できます。 詳細については、「 Azure Local Environment Checker を参照して、Azure Local のデプロイの準備状況を評価します。

ファイアウォールに関する考慮事項の概要を次に示します。

# 考慮事項 対象
1 Azure Arc にノードを登録する前に、ファイアウォールの構成を行う必要があります。 両方とも
2 スタンドアロン モードの環境チェッカーを使用して、ファイアウォール構成を検証できます。 両方とも

決定 11: ソフトウェア定義ネットワーク (SDN) を決定する

ソフトウェア定義ネットワーク (SDN) は、ホスト ネットワーク (決定 1 から 10) が実施された後に適用する、オプションのワークロード ネットワーク レイヤーです。 Azure Local では、SDN はAzure Arc によって有効化され、対象は 2 つの機能に限定されています。1 つは SDN 論理ネットワーク (LNET) で、ワークロードにソフトウェア定義のネットワーク セグメントを提供し、物理ファブリック上の VLAN を基盤とします。もう 1 つは、ネットワーク セキュリティ グループ (NSG) によるマイクロセグメンテーションです。 ワークロードにプログラム可能なネットワーク セグメント化と分散セキュリティ ポリシーが必要かどうかを判断し、アーキテクチャで必要な SDN モデルがサポートされていることを確認します。

Important

Azure Local上の Arc マネージド SDN では、仮想ネットワーク (VNET)、ソフトウェア Load Balancer (SLB)、RAS/GRE ゲートウェイはサポートされません。 LNET と NSG のみがサポートされています。 ワークロードに VNET、SLB、GRE、または完全な Microsoft SDN ゲートウェイ スタックが必要な場合、Azure Localは推奨されるプラットフォームではありません。 代わりに Windows Server SDN デプロイを使用します。VNET、SLB、ゲートウェイを含む完全なネットワーク コントローラー スタックがサポートされています。

Hyperconverged (HCI)

ハイパーコンバージド デプロイでは、1 ～ 16 ノード向けの Azure Arc によって有効化された Microsoft SDN がサポートされています:

  • SDN コントロール プレーンでは、LNET と NSG のみが提供されます。 有効にすると、ワークロード仮想スイッチの Azure 仮想フィルター拡張機能が有効になります。
  • LNET はファブリック上の VLAN によってサポートされるため、各論理ネットワークの ToR スイッチで対応する VLAN を構成してトランクします。
  • ネットワーク コントローラーは、個別のインフラストラクチャ仮想マシンとしてではなく、Azure Local インスタンス上のクラスター サービスのセットとして実行されます。

SDN は、 決定 7 の次のネットワーク ATC 意図パターンでのみサポートされます。

意図パターン 説明 サポートされている SDN
すべてのトラフィックをグループ化する 管理、コンピューティング、ストレージを含む 1 つの意図。 切り替えストレージでのみサポートされます。 ✅
個別のストレージ意図を使用したグループ管理とコンピューティング 管理とコンピューティングの 1 つの意図と、ストレージ専用の 2 つ目の意図。 ✅
個別の管理意図を使用してコンピューティングとストレージをグループ化する コンピューティングとストレージは意図を共有し、管理では別の意図が使用されます。 ❌
カスタム構成 意図間でコンピューティングと管理を分離するカスタム グループ。 ❌

分離型（DA）

非集約デプロイでは、Microsoft SDN ネットワーク コントローラーは使用されません。 SDN 論理ネットワークは、 デシジョン 3 のマルチラック トポロジと一致する VXLAN EVPN オーバーレイを使用して外部リーフ スパイン ファブリックにプロビジョニングされます。

  • ファブリック VRF とオーバーレイを設計して、必要な論理ネットワークを伝送します。
  • AKS 論理ネットワークには、管理論理ネットワークへのレイヤー 3 の到達可能性が必要です。
  • 大規模な SDN を必要としない単一ラックの非集約クラスターは、よりシンプルな 2 スイッチ トポロジを維持できます。

リーフ スパイン ファブリック上の VRF および VXLAN オーバーレイ設計の詳細については、 非集約展開のネットワーク リファレンス パターンの概要を参照してください。

SDN 決定の概要に関する考慮事項を次に示します。

# 考慮事項 対象
1 SDN はオプションであり、デプロイ後にホスト ネットワークの上に階層化されます。 ワークロードに SDN 論理ネットワーク (LNET) とマイクロセグメント化 (NSG) のどちらを必要とするかを決定します。 両方とも
2 Azure Local上の Arc マネージド SDN では、LNET と NSG のみがサポートされます。 VNET、SLB、RAS/GRE ゲートウェイはサポートされていません。 HCI
3 オンプレミス のツールによって管理される SDN を使用して、Azure Localで実行されている非管理対象仮想マシンを、Azure Local仮想マシンとしてハイドレートすることはできません。 HCI
4 LNET は、ファブリック上の VLAN によってサポートされます。 各論理ネットワークの物理スイッチで対応する VLAN を設定し、トランクします。 HCI
5 ワークロードで VNET、SLB、GRE、または完全なMicrosoft SDN ゲートウェイ スタックが必要な場合は、Azure Localではなく、Windows Server SDN デプロイを使用します。 HCI
6 Disaggregated (DA) は、リーフ スパイン ファブリック上の外部ファブリック ベースの SDN (VXLAN EVPN) を使用します。 Microsoft SDN ネットワーク コントローラーは使用されません。 DA

次のステップ

  • Last updated on