論理的かつ物理的に分離されたルーティング不可の 2 つの VLAN を使用すると、air-gap トポロジを作成できます。

この例では、vSphere Distributed Switch の構成手順について説明しますが、vSphere Standard Switch を使用することもできます。その場合は、10 Gb の物理 NIC を 2 つ使用し、それらを vSphere ネットワーク レイヤーで論理的に分離します。

vSAN VMkernel vmknic ごとに 2 つの分散ポート グループを作成します。ポート グループごとに個別の VLAN タグがあります。vSAN VMkernel 構成の場合、両方の VLAN で vSAN トラフィックに 2 つの IP アドレスが必要になります。

注：

通常の実装では、完全な冗長性を実現するために 4 つの物理アップリンクを使用します。

各ポート グループに、チーミングおよびフェイルオーバー ポリシーはデフォルトの設定を使用します。

  • ロード バランシングを [発信元のポート ID に基づいたルート] に設定

  • ネットワーク障害の検出を [リンク ステータスのみ] に設定

  • スイッチへの通知をデフォルト値の [はい] に設定

  • フェイルバックをデフォルト値の [はい] に設定

  • アップリンク構成で、1 つのアップリンクが [アクティブ] の位置にあり、1 つのアップリンクが [未使用] の位置にあります。

1 つのネットワークは、他のネットワークから完全に隔離されています。

vSAN ポート グループ 1

この例では、[vSAN-DPortGroup-1] という分散ポート グループを使用しています。このポート グループには [VLAN 3266] というタグが付き、次のチーミングおよびフェイルオーバー ポリシーが設定されています。

  • VLAN 3266 タグが付いたポート グループのトラフィック

  • ロード バランシングを [発信元のポート ID に基づいたルート] に設定

  • ネットワーク障害の検出を [リンク ステータスのみ] に設定

  • スイッチへの通知をデフォルト値の [はい] に設定

  • フェイルバックをデフォルト値の [はい] に設定

  • アップリンク構成で、[アップリンク 1] が [アクティブ] の位置にあり、[アップリンク 2] が [未使用] の位置にあります。

複数の vmnic、元のポートに基づくルート

vSAN ポート グループ 2

vSAN ポート グループ 1 を補完するため、[vSAN-portgroup-2] という 2 つ目の分散ポート グループを構成します。次のような違いがあります。

  • VLAN 3265 タグが付いたポート グループのトラフィック

  • アップリンク構成で、[アップリンク 2] が [アクティブ] の位置にあり、[アップリンク 1] が [未使用] の位置にあります。

vSAN VMkernel ポート構成

両方のポート グループに 2 つの vSAN VMkernel インターフェイスを作成します。この例では、ポート グループに [vmk1] と [vmk2] という名前を使用しています。

  • [vmk1] は VLAN 3266 (172.40.0.xx) に関連付けられ、結果としてポート グループ [vSAN-DPortGroup-1] に関連付けられます。

  • [vmk2] は VLAN 3265 (192.60.0.xx) に関連付けられ、結果としてポート グループ [vSAN-DPortGroup-2] に関連付けられます。

VMkernel ポートの構成

ロード バランシング

vSAN には複数の vmknic を区別するロード バランシング メカニズムがありません。そのため、選択された vSAN I/O パスを物理 NIC 間で特定できません。vSphere のパフォーマンス チャートを見ると、1 つの物理 NIC が他の物理 NIC よりも使用率が高いことが分かります。ラボでシンプルな I/O テストを実行しました。120 台の仮想マシンを使用し、4 ホスト構成のオール フラッシュ vSAN クラスタで 64K ブロックの読み取り/書き込みを 70:30 の割合で行った結果、NIC 間で負荷が分散されていないことが明らかになりました。

vSphere パフォーマンス グラフには、NIC 間で負荷が分散されていないことが表示されます。

ネットワーク アップリンクの冗長性の消失

この構成で発生するネットワーク障害について考えてみましょう。特定の vSAN ホストで vmnic1 は有効になっていません。その結果、ポート [vmk2] が影響を受けます。NIC に障害が発生すると、ネットワーク接続アラームと冗長性アラームの両方がトリガされます。

vSAN の場合、CMMDS（クラスタ監視およびメンバーシップ ディレクトリ サービス）が障害を検出してから約 [10] 秒後に、このフェイルオーバー プロセスがトリガされます。フェイルオーバーとリカバリの実行中、vSAN は、障害が発生したネットワークでアクティブな接続をすべて停止し、機能している残りのネットワーク上で接続の再確立を試みます。

2 つの個別の vSAN VMkernel ポートは隔離された VLAN で通信を行うため、vSAN 健全性チェックでエラーが発生することがあります。VLAN 3265 で [vmk2] がピアと通信できなくなるため、これは想定内の状況です。

パフォーマンス チャートには、vmnic1 に障害が発生したため、影響を受けたワークロードが vmnic0 で再起動したことが表示されます。このテストでは、vSphere NIC チーミングとトポロジの重要な違いを表しています。vSAN は、残りのネットワークで接続を再確立または再開しようとします。

ただし、障害の状況によっては、ESXi TCP 接続タイムアウトが原因で、影響を受けた接続のリカバリが完了するまでに [90 秒] ほどかかる場合があります。以降の接続も失敗する可能性がありますが、接続の試行は 5 秒でタイムアウトし、使用可能なすべての IP アドレスを順番に試していきます。この動作は、仮想マシンのゲスト I/O に影響を与えることがあるため、アプリケーションと仮想マシンの I/O の再試行が必要になる可能性があります。

たとえば、Windows Server 2012 仮想マシンで、フェイルオーバーとリカバリの処理中に、イベント ID 153（デバイス リセット）や 129（再試行イベント）が記録される場合があります。この例では、I/O がリカバリされるまで、イベント ID 129 は約 90 秒間でログに記録されていました。

深刻な影響を受ける前に、一部のゲスト OS のディスク タイムアウト設定を変更する必要がある場合があります。ディスク タイムアウト値は、VMware Tools の有無、特定のゲスト OS のタイプ、バージョンによって異なる場合があります。ゲスト OS のディスク タイムアウト値の変更については、VMware KB1009465を参照してください。

リカバリとフェイルバック

別の障害が原因で新たな障害が発生した場合を除き、ネットワークの修復後にワークロードは自動的に再分散されません。影響を受けたネットワークがリカバリされるとすぐに、新しい TCP 接続で使用できるようになります。