Azure Stack HCI のホスト ネットワーク要件

適用対象: Azure Stack HCI バージョン 21H2 および 20H2

このトピックでは、Azure Stack HCI のホスト ネットワークに関する考慮事項と要件について説明します。 データセンターのアーキテクチャおよびサーバー間の物理接続の詳細については、「物理ネットワークの要件」を参照してください。

Network ATC を使用してホスト ネットワークを単純化する方法の詳細については、「Network ATC を使用してホスト ネットワークを単純化する」を参照してください。

ネットワーク トラフィックの種類

Azure Stack HCI のネットワーク トラフィックは、その使用目的によって分類することができます。

  • コンピューティング トラフィック: 仮想マシン (VM) が送信元または送信先となるトラフィック。
  • ストレージ トラフィック: 記憶域スペース ダイレクトや SMB ベースのライブ移行など、サーバー メッセージ ブロック (SMB) を使用したトラフィック。
  • 管理トラフィック: リモート デスクトップ、Windows Admin Center、Active Directory などのクラスターを管理する管理者が使用するトラフィック。

ネットワーク アダプターを選択する

Azure Stack HCI では、Standard または Premium の追加資格基準 (AQ) のある、Windows Server の Software Defined Data Center (SDDC) 認定を取得しているネットワーク アダプターを選択する必要があります。 これらのアダプターでは、最も高度なプラットフォーム機能をサポートしており、ハードウェア パートナーによるテストが最も多く実施されています。 通常、このレベルの精査が行われることにより、ハードウェアとドライバーに関連する品質問題を減らすことができます。 これらのアダプターは、記憶域スペース ダイレクトに対して確立されたネットワーク要件も満たします。

Standard または Premium の AQ 付きのアダプターを特定するには、アダプターの Windows Server Catalog と該当するオペレーティング システムのバージョンを確認します。 Premium AQ の表記の例を次に示します。

Screenshot of Windows Certified options, with a Premium AQ option highlighted.

主なネットワーク アダプター機能の概要

Azure Stack HCI によって使用されるネットワーク アダプターの重要な機能には、次のものがあります。

  • 動的仮想マシン マルチキュー (動的 VMMQ または d.VMMQ)
  • リモート ダイレクト メモリ アクセス (RDMA)
  • ゲスト RDMA
  • スイッチが埋め込まれたチーミング (設定)

動的 VMMQ

Premium AQ を取得しているすべてのネットワーク アダプターでは、動的 VMMQ をサポートしています。 動的 VMMQ では、スイッチ埋め込みチーミングを使用する必要があります。

適用可能なトラフィックの種類: コンピューティング

必要な認定: Premium

動的 VMMQ は、インテリジェントな受信側テクノロジです。 動的 VMMQ は、従来の仮想マシン キュー (VMQ)、仮想 Receive Side Scaling (vRSS)、および VMMQ に基づいて構築されており、次の 3 つの主要な機能強化が行われています。

  • 少ない CPU コアを使用してホスト効率を最適化します。
  • CPU コアへのネットワーク トラフィック処理を自動チューニングすることで、VM で期待されるスループットを満たして維持できるようにします。
  • 予想されるトラフィック量を "バースト" ワークロードで受信できるようにします。

動的 VMMQ の詳細については、ブログ記事「統合アクセラレータ」を参照してください。

RDMA

RDMA は、ネットワーク アダプターに対するネットワーク スタック オフロードです。 これにより、SMB 記憶域トラフィックがオペレーティング システムをバイパスして処理できるようになります。

RDMA は、ホスト CPU リソースの使用を最小限に抑え、高スループットで待機時間の短いネットワークを実現します。 これらのホスト CPU リソースを使用して、追加の VM またはコンテナーを実行できます。

適用可能なトラフィックの種類: ホスト ストレージ

必要な認定: Standard

Standard または Premium の AQ を取得しているすべてのアダプターは、RDMA をサポートしています。 RDMA は Azure Stack HCI のストレージ ワークロード用に推奨されるデプロイの選択肢であり、必要に応じて、VM のストレージ ワークロード (SMB を使用) に対して有効にすることができます。 詳細については、この記事で後述する「ゲスト RDMA」のセクションを参照してください。

Azure Stack HCI は、インターネット ワイド エリア RDMA プロトコル (iWARP) または RDMA over Converged Ethernet (RoCE) プロトコルの実装のいずれかを使用して RDMA をサポートします。

重要

RDMA アダプターは、同じ RDMA プロトコル (iWARP または RoCE) を実装する他の RDMA アダプターでのみ機能します。

ベンダーのすべてのネットワーク アダプターが RDMA をサポートしているわけではありません。 次の表に、Premium 認定 RDMA アダプターを提供するベンダー (アルファベット順) を示します。 ただし、この一覧に含まれていないハードウェア ベンダーも RDMA をサポートしています。 RDMA のサポートを確認するには、「Windows Server Catalog」を参照してください。

Note

InfiniBand (IB) は、Azure Stack HCI. ではサポートされていません。

NIC ベンダー iWARP RoCE
Broadcom いいえ はい
Chelsio はい いいえ
Intel Yes はい (一部のモデル)
Marvell (Qlogic/Cavium) はい Yes
Nvidia (Mellanox) いいえ はい

RDMA のデプロイの詳細情報については、SDN GitHub リポジトリからドキュメントをダウンロードしてください。

iWARP

iWARP では伝送制御プロトコル (TCP) を使用します。また、必要に応じて、優先順位ベースのフロー制御 (PFC) と拡張伝送サービス (ETS) を使用して拡張することもできます。

次の場合に iWARP を使用します。

  • ネットワークの経験がほとんどまたはまったくない、またはネットワーク スイッチの管理に不安がある場合。
  • Top-of-Rack (ToR) スイッチを制御しない場合。
  • デプロイ後にソリューションを管理しない場合。
  • 既に iWARP を使用したデプロイが存在する場合。
  • どのオプションを選択したらよいかわからない場合。

RoCE

RoCE は、ユーザー データグラム プロトコル (UDP) を使用しており、信頼性を確保するために PFC と ETS を必要とします。

次の場合に RoCE を使用します。

  • データセンターに RoCE を使用したデプロイが既に存在する場合。
  • DCB のネットワーク要件を管理することに慣れている場合。

ゲスト RDMA

ゲスト RDMA を使用すると、ホスト上で RDMA を使用する場合と同じ利点を VM の SMB ワークロードで得ることができます。

適用可能なトラフィックの種類: ゲスト ベースのストレージ

必要な認定: Premium

ゲスト RDMA を使用する主な利点は次のとおりです。

  • ネットワーク トラフィック処理のための NIC への CPU オフロード。
  • 非常に短い待機時間。
  • 高スループット。

詳細情報については、SDN GitHub リポジトリからドキュメントをダウンロードしてください。

SET

SET は、Windows Server 2016 以降の Windows Server オペレーティング システムに含まれているソフトウェア ベースのチーミング テクノロジです。 SET は、使用されるネットワーク アダプターの種類に依存しません。

適用可能なトラフィックの種類: コンピューティング、ストレージ、管理

必要な認定: なし (SET はオペレーティング システムに組み込まれています)

SET は、Azure Stack HCI でサポートされている唯一のチーミング テクノロジです。 SET は、コンピューティング、ストレージ、管理の各トラフィックで効果的に機能します。

重要

負荷分散フェールオーバー (LBFO) は、Windows Server で一般的に使用される別のチーミング テクノロジですが、Azure Stack HCI ではサポートされていません。 Azure Stack HCI の LBFO の詳細情報については、ブログ記事「Azure Stack HCI でのチーミング」を参照してください。

SET は、次を可能にする唯一のチーミング テクノロジであるため、Azure Stack HCI にとって重要です。

  • RDMA アダプターのチーミング (必要な場合)。
  • ゲスト RDMA。
  • 動的 VMMQ。
  • その他の主な Azure Stack HCI 機能 (「Azure Stack HCI でのチーミング」を参照)。

SET では、対称 (同一) アダプターを使用する必要があることに注意してください。 非対称アダプターのチーミングはサポートされていません。 対称ネットワーク アダプターとは、次のものが同じであるアダプターです。

  • メーカー (ベンダー)
  • モデル (バージョン)
  • 速度 (スループット)
  • configuration

アダプターが対称であるかどうかを識別する最も簡単な方法は、速度が同じで、かつインターフェイスの説明が一致するかどうかを確認することです。 相違が許容されるのは、説明に記載されている数字のみです。 Get-NetAdapterAdvancedProperty コマンドレットを使用して、報告された構成に必ず同じプロパティ値が表示されるようにします。

次の表で、数字 (#) のみが異なっているインターフェイスの説明の例を確認してください。

名前 インターフェイスの説明 リンク速度
NIC1 ネットワーク アダプター #1 25 Gbps
NIC2 ネットワーク アダプター #2 25 Gbps
NIC3 ネットワーク アダプター #3 25 Gbps
NIC4 ネットワーク アダプター #4 25 Gbps

Note

SET では、動的または Hyper-V ポートの負荷分散アルゴリズムを使用し、スイッチに依存しない構成のみがサポートされます。 最適なパフォーマンスを得るには、Hyper-V ポートは、すべて 10 Gbps 以上で動作する NIC で使用することをお勧めします。

RDMA トラフィックに関する考慮事項

DCB を実装する場合は、ネットワーク スイッチを含むすべてのネットワーク ポート全体で、PFC と ETS の構成が正しく実装されていることを確認する必要があります。 DCB は、RoCE の場合は必須であり、iWARP の場合は省略可能です。

RDMA のデプロイ方法の詳細情報については、SDN GitHub リポジトリからドキュメントをダウンロードしてください。

RoCE ベースの Azure Stack HCI 実装では、ファブリックとすべてのホストで、既定のトラフィック クラスを含む 3 つの PFC トラフィック クラスを構成する必要があります。

クラスター トラフィック クラス

このトラフィック クラスは、クラスターのハートビート用に十分な帯域幅があることを保証します。

  • 必須: はい
  • PFC 対応: いいえ
  • 推奨されるトラフィックの優先順位:優先順位 7
  • 推奨される帯域幅予約:
    • 10 GbE 以下の RDMA ネットワーク = 2 パーセント
    • 25 GbE 以下の RDMA ネットワーク = 1 パーセント

RDMA トラフィック クラス

このトラフィック クラスは、SMB ダイレクトを使用することにより、無損失 RDMA 通信用に十分な帯域幅があることを保証します。

  • 必須: はい
  • PFC 対応: はい
  • 推奨されるトラフィックの優先順位:優先順位 3 または 4
  • 推奨される帯域幅予約: 50 パーセント

既定のトラフィック クラス

このトラフィック クラスには、VM トラフィックや管理トラフィックなど、クラスターまたは RDMA のトラフィック クラスで定義されていない他のすべてのトラフィックが記載されています。

  • 必須: 既定 (ホストでの構成は不要)
  • フロー制御 (PFC) 対応: いいえ
  • 推奨されるトラフィック クラス:既定 (優先順位 0)
  • 推奨される帯域幅予約:既定 (ホスト構成は不要)

ストレージ トラフィック モデル

SMB には、SMB マルチチャネルなど、Azure Stack HCI 用のストレージ プロトコルとして、多くの利点があります。 SMB マルチチャネルはこの記事では扱いませんが、SMB マルチチャネルが使用できるあらゆるリンクでトラフィックが多重化されていることを理解することが重要です。

Note

複数のサブネットと VLAN を使用して、Azure Stack HCI でストレージ トラフィックを分離することをお勧めします。

次の 4 つのノードを持つクラスターの例を考えてみましょう。 各サーバーには 2 つのストレージ ポート (左側と右側) があります。 各アダプターは同じサブネットと VLAN 上にあるため、SMB マルチチャネルでは、利用可能なすべてのリンクに接続が分散されます。 そのため、最初のサーバー (192.168.1.1) の左側のポートは、2 番目のサーバー (192.168.1.2) の左側のポートに接続します。 最初のサーバー (192.168.1.12) の右側のポートは、2 番目のサーバーの右側のポートに接続します。 3 番目と 4 番目のサーバーにも同様の接続が確立されます。

ただし、これにより、不要な接続が作成され、ToR スイッチに接続するインターリンク (マルチシャーシ リンク アグリゲーション グループまたは MC-LAG) で輻輳が発生します (X 印の部分)。 次の図を参照してください。

Diagram that shows a four-node cluster on the same subnet.

推奨されるアプローチは、アダプターのセットごとに個別のサブネットと VLAN を使用する方法です。 次の図では、右側のポートでサブネット 192.168.2.x /24 と VLAN2 が使用されています。 これにより、左側のポートのトラフィックは TOR1 に保持され、右側のポートのトラフィックは TOR2 に保持されます。

Diagram that shows a four-node cluster on different subnets.

トラフィックの帯域幅の割り当て

次の表は、Azure Stack HCI での一般的なアダプター速度を使用した、さまざまな種類のトラフィックの帯域幅割り当ての例を示しています。 これは集中型ソリューションの例であり、すべてのトラフィックの種類 (コンピューティング、ストレージ、管理) が同じ物理アダプター上で実行され、SET の使用によりチーミングされていることに注意してください。

このユース ケースでは、最も多くの制約が課されるため、適切なベースラインとなります。 ただし、これは、アダプターの数と速度の順列を考慮して、サポート要件ではなく、1 つの例として考える必要があります。

この例では、次のことを前提としています。

  • チームごとに 2 つのアダプターがある。

  • 記憶域バス レイヤー (SBL)、クラスター共有ボリューム (CSV)、Hyper-V (ライブ マイグレーション) トラフィックについて

    • 同じ物理アダプターを使用する。
    • SMB を使用する。
  • SMB には DCB を使用して 50% の帯域幅が割り当てられている。

    • SBL/CSV は最も優先順位の高いトラフィックであり、SMB 帯域幅の予約の 70 パーセントが割り当てられます。
    • ライブ マイグレーション (LM) は Set-SMBBandwidthLimit コマンドレットを使用して制限され、残りの帯域幅の 29 パーセントが割り当てられます。
      • ライブ マイグレーションで使用可能な帯域幅が 5 Gbps 以上で、ネットワーク アダプターが対応している場合は、RDMA を使用する。 これを行うには、次のコマンドレットを使用する。

        Set-VMHost VirtualMachineMigrationPerformanceOption SMB
        
      • ライブ マイグレーションで使用可能な帯域幅が 5 Gbps 未満の場合は、圧縮を使用してブラックアウト時間を短縮する。 これを行うには、次のコマンドレットを使用する。

        Set-VMHost -VirtualMachineMigrationPerformanceOption Compression
        
  • ライブ マイグレーション トラフィックに RDMA を使用している場合は、SMB 帯域幅の制限を使用して、ライブ マイグレーション トラフィックが RDMA トラフィック クラスに割り当てられた帯域幅全体を消費できないようにします。 このコマンドレットは 1 秒あたりのバイト数 (Bps) で入力されますが、ネットワーク アダプターは 1 秒あたりのビット数 (bps) で表示されるため注意してください。 次のコマンドレットを使用して、たとえば帯域幅の制限を 6 Gbps に設定します。

    Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB
    

    Note

    この例の 750 MBps は 6 Gbps に相当します。

以下に、帯域幅の割り当て表の例を示します。

NIC 速度 チーム化された帯域幅 SMB 帯域幅予約** SBL/CSV % SBL/CSV 帯域幅 ライブ マイグレーション % 最大ライブ マイグレーション帯域幅 ハートビート % ハートビート帯域幅
10 Gbps 20 Gbps 10 Gbps 70% 7 Gbps ** 200 Mbps
25 Gbps 50 Gbps 25 Gbps 70% 17.5 Gbps 29% 7.25 Gbps 1% 250 Mbps
40 Gbps 80 Gbps 40 Gbps 70% 28 Gbps 29% 11.6 Gbps 1% 400 Mbps
50 Gbps 100 Gbps 50 Gbps 70% 35 Gbps 29% 14.5 Gbps 1% 500 Mbps
100 Gbps 200 Gbps 100 Gbps 70% 70 Gbps 29% 29 Gbps 1% 1 Gbps
200 Gbps 400 Gbps 200 Gbps 70% 140 Gbps 29% 58 Gbps 1% 2 Gbps

* ライブ マイグレーション トラフィックに対する帯域幅の割り当てが 5 Gbps 未満のため、RDMA ではなく圧縮を使用します。

** 50 パーセントは帯域幅予約の一例です。

ストレッチ クラスター

ストレッチ クラスターを使用すると、複数のデータセンターにまたがるディザスター リカバリーを実現できます。 最も単純な形式では、Azure Stack HCI のストレッチ クラスター ネットワークは次のようになります。

Diagram that shows a stretched cluster.

ストレッチ クラスターの要件

ストレッチ クラスターには、次の要件と特性があります。

  • RDMA は単一サイトに限定されており、異なるサイトまたはサブネット間ではサポートされていません。

  • 同じサイト内のサーバーは、同じラックおよびレイヤー 2 の境界内に存在する必要があります。

  • サイト間のホスト通信ではレイヤー 3 の境界を越える必要があります。ストレッチされたレイヤー 2 のトポロジはサポートされていません。

  • 他のサイトでワークロードを実行するのに十分な帯域幅があること。 フェールオーバーが発生した場合は、代替サイトですべてのトラフィックを実行する必要があります。 使用可能なネットワーク容量の 50 パーセントでサイトをプロビジョニングすることをお勧めします。 ただし、フェールオーバー中のパフォーマンス低下を許容できる場合、これは要件ではありません。

  • サイト間のレプリケーション (北/南トラフィック) では、ローカル ストレージ (東/西トラフィック) と同じ物理 NIC を使用できます。 同じ物理アダプターを使用している場合は、それらのアダプターを SET とチーミングする必要があります。 また、アダプターには、サイト間のルーティング可能なトラフィック用にプロビジョニングされた追加の仮想 NIC が必要です。

  • サイト間の通信に使用されるアダプターについて

    • 物理または仮想 (ホスト vNIC) にすることができます。 アダプターが仮想の場合は、物理 NIC ごとに、独自のサブネットと VLAN で 1 つの vNIC をプロビジョニングする必要があります。

    • サイト間でルーティングできる独自のサブネットと VLAN 上に配置する必要があります。

    • RDMA は、Disable-NetAdapterRDMA コマンドレットを使用して無効にする必要があります。 Set-SRNetworkConstraint コマンドレットを使用し、記憶域レプリカに特定のインターフェイスを使用するように明示的に要求することをお勧めします。

    • 記憶域レプリカの追加要件を満たしている必要があります。

ストレッチ クラスターの例

次の例は、ストレッチ クラスター構成を示しています。 特定の仮想 NIC が特定の物理アダプターにマップされるようにするには、Set-VMNetworkAdapterTeammapping コマンドレットを使用します。

Diagram that shows an example of stretched cluster storage.

次に、ストレッチ クラスター構成の例の詳細を示します。

Note

NIC 名、IP アドレス、VLAN などの正確な構成は、示されているものと異なる場合があります。 これは、お使いの環境に適用できる、参照構成に過ぎません。

SiteA – ローカル レプリケーション、RDMA が有効、サイト間でルーティング不可能

ノード名 vNIC 名 物理 NIC (マップ済み) VLAN IP とサブネット トラフィック スコープ
NodeA1 vSMB01 pNIC01 711 192.168.1.1/24 ローカル サイトのみ
NodeA2 vSMB01 pNIC01 711 192.168.1.2/24 ローカル サイトのみ
NodeA1 vSMB02 pNIC02 712 192.168.2.1/24 ローカル サイトのみ
NodeA2 vSMB02 pNIC02 712 192.168.2.2/24 ローカル サイトのみ

SiteB – ローカル レプリケーション、RDMA が有効、サイト間でルーティング不可能

ノード名 vNIC 名 物理 NIC (マップ済み) VLAN IP とサブネット トラフィック スコープ
NodeB1 vSMB01 pNIC01 711 192.168.1.1/24 ローカル サイトのみ
NodeB2 vSMB01 pNIC01 711 192.168.1.2/24 ローカル サイトのみ
NodeB1 vSMB02 pNIC02 712 192.168.2.1/24 ローカル サイトのみ
NodeB2 vSMB02 pNIC02 712 192.168.2.2/24 ローカル サイトのみ

SiteA - ストレッチ レプリケーション、RDMA が無効、サイト間でルーティング可能

ノード名 vNIC 名 物理 NIC (マップ済み) IP とサブネット トラフィック スコープ
NodeA1 Stretch1 pNIC01 173.0.0.1/8 クロスサイト ルーティング可能
NodeA2 Stretch1 pNIC01 173.0.0.2/8 クロスサイト ルーティング可能
NodeA1 Stretch2 pNIC02 174.0.0.1/8 クロスサイト ルーティング可能
NodeA2 Stretch2 pNIC02 174.0.0.2/8 クロスサイト ルーティング可能

SiteB - ストレッチ レプリケーション、RDMA が無効、サイト間でルーティング可能

ノード名 vNIC 名 物理 NIC (マップ済み) IP とサブネット トラフィック スコープ
NodeB1 Stretch1 pNIC01 175.0.0.1/8 クロスサイト ルーティング可能
NodeB2 Stretch1 pNIC01 175.0.0.2/8 クロスサイト ルーティング可能
NodeB1 Stretch2 pNIC02 176.0.0.1/8 クロスサイト ルーティング可能
NodeB2 Stretch2 pNIC02 176.0.0.2/8 クロスサイト ルーティング可能

次の手順