論理的かつ物理的に分離されたルーティング不可の 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、元のポートに基づくルート](images/GUID-331C7D20-100A-4883-AB7E-D0C0B390F6D7-low.png)
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 ポートの構成](images/GUID-FEA0DDA9-04BE-4FEF-94C0-0A4682DCB43A-low.png)
ロード バランシング
vSAN には複数の vmknic を区別するロード バランシング メカニズムがありません。そのため、選択された vSAN I/O パスを物理 NIC 間で特定できません。vSphere のパフォーマンス チャートを見ると、1 つの物理 NIC が他の物理 NIC よりも使用率が高いことが分かります。ラボでシンプルな I/O テストを実行しました。120 台の仮想マシンを使用し、4 ホスト構成のオール フラッシュ vSAN クラスタで 64K ブロックの読み取り/書き込みを 70:30 の割合で行った結果、NIC 間で負荷が分散されていないことが明らかになりました。
vSphere パフォーマンス グラフには、NIC 間で負荷が分散されていないことが表示されます。
ネットワーク アップリンクの冗長性の消失
この構成で発生するネットワーク障害について考えてみましょう。vmnic1 が特定の vSAN ホストで無効になります。その結果、ポート [vmk2] が影響を受けます。NIC に障害が発生すると、ネットワーク接続アラームと冗長性アラームの両方がトリガされます。
vSAN の場合、CMMDS(クラスタ監視およびメンバーシップ ディレクトリ サービス)が障害を検出してから約 [10] 秒後に、このフェイルオーバー プロセスがトリガされます。フェイルオーバーとリカバリの実行中、vSAN は、障害が発生したネットワークでアクティブな接続をすべて停止し、機能している残りのネットワーク上で接続の再確立を試みます。
2 つの個別の vSAN VMkernel ポートは隔離された VLAN で通信を行うため、vSAN 健全性チェックでエラーが発生することがあります。VLAN 3265 で [vmk2] がピアと通信できなくなるため、これは想定内の状況です。
パフォーマンス チャートには、vmnic1 に障害が発生したため、影響を受けたワークロードが vmnic0 で再起動したことが表示されます(このテストのため vmnic1 を無効にしています)。このテストでは、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 接続で使用できるようになります。