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 の表記の例を次に示します。
主なネットワーク アダプター機能の概要
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 印の部分)。 次の図を参照してください。
推奨されるアプローチは、アダプターのセットごとに個別のサブネットと VLAN を使用する方法です。 次の図では、右側のポートでサブネット 192.168.2.x /24 と VLAN2 が使用されています。 これにより、左側のポートのトラフィックは TOR1 に保持され、右側のポートのトラフィックは TOR2 に保持されます。
トラフィックの帯域幅の割り当て
次の表は、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 のストレッチ クラスター ネットワークは次のようになります。
ストレッチ クラスターの要件
ストレッチ クラスターには、次の要件と特性があります。
RDMA は単一サイトに限定されており、異なるサイトまたはサブネット間ではサポートされていません。
同じサイト内のサーバーは、同じラックおよびレイヤー 2 の境界内に存在する必要があります。
サイト間のホスト通信ではレイヤー 3 の境界を越える必要があります。ストレッチされたレイヤー 2 のトポロジはサポートされていません。
他のサイトでワークロードを実行するのに十分な帯域幅があること。 フェールオーバーが発生した場合は、代替サイトですべてのトラフィックを実行する必要があります。 使用可能なネットワーク容量の 50 パーセントでサイトをプロビジョニングすることをお勧めします。 ただし、フェールオーバー中のパフォーマンス低下を許容できる場合、これは要件ではありません。
サイト間のレプリケーション (北/南トラフィック) では、ローカル ストレージ (東/西トラフィック) と同じ物理 NIC を使用できます。 同じ物理アダプターを使用している場合は、それらのアダプターを SET とチーミングする必要があります。 また、アダプターには、サイト間のルーティング可能なトラフィック用にプロビジョニングされた追加の仮想 NIC が必要です。
サイト間の通信に使用されるアダプターについて
物理または仮想 (ホスト vNIC) にすることができます。 アダプターが仮想の場合は、物理 NIC ごとに、独自のサブネットと VLAN で 1 つの vNIC をプロビジョニングする必要があります。
サイト間でルーティングできる独自のサブネットと VLAN 上に配置する必要があります。
RDMA は、
Disable-NetAdapterRDMA
コマンドレットを使用して無効にする必要があります。Set-SRNetworkConstraint
コマンドレットを使用し、記憶域レプリカに特定のインターフェイスを使用するように明示的に要求することをお勧めします。記憶域レプリカの追加要件を満たしている必要があります。
ストレッチ クラスターの例
次の例は、ストレッチ クラスター構成を示しています。 特定の仮想 NIC が特定の物理アダプターにマップされるようにするには、Set-VMNetworkAdapterTeammapping コマンドレットを使用します。
次に、ストレッチ クラスター構成の例の詳細を示します。
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 | クロスサイト ルーティング可能 |
次の手順
- ネットワーク スイッチと物理ネットワークの要件について学習する。 「物理ネットワークの要件」を参照してください。
- Network ATC を使用してホスト ネットワークを単純化する方法について学習する。 「Network ATC を使用してホスト ネットワークを単純化する」を参照してください。
- フェールオーバー クラスタリング ネットワークの基礎を復習しましょう。
- デプロイについては、Windows Admin Center を使用したクラスターの作成に関する記事を参照してください。
- デプロイについては、Windows PowerShell を使用したクラスターの作成に関する記事を参照してください。