vSAN では、正しく設定されていない vSAN ネットワークに起因するさまざまな問題を確認し、トラブルシューティングを行うことができます。
vSAN の処理はネットワークの構成、信頼性、パフォーマンスに依存します。サポート リクエストの多くは、ネットワークの構成に問題があるか、ネットワークのパフォーマンスの低下が原因で発生しています。
vSAN 健全性サービスを使用して、ネットワークの問題を解決してください。ネットワーク健全性チェックでは、健全性チェックの結果に応じて、適切なナレッジベースの記事が表示されます。ナレッジベースの記事には、ネットワークの問題を解決する手順が記載されています。
ネットワーク健全性チェック
健全性サービスでは、カテゴリ別にネットワーク健全性チェックが実行されます。
各健全性チェックには、[AskVMware] リンクがあります。健全性チェックが失敗した場合は、[AskVMware] をクリックして、関連する VMware のナレッジベースの記事を参照します。ここで問題の詳細や問題の解決方法を確認します。
- vSAN[：基本（ユニキャスト）接続チェック]。このチェックでは、vSAN ネットワーク上の ESXi ホスト間で ping を送信することにより、vSAN クラスタ内のすべての ESXi ホストに IP 接続が存在することを確認します。
- [vMotion：基本（ユニキャスト）接続チェック]。このチェックでは、vMotion が構成されている vSAN クラスタ内のすべての ESXi ホスト間に IP 接続が存在することを確認します。vMotion ネットワーク上の各 ESXi ホストが他のすべての ESXi ホストに ping を実行します。
- [すべてのホストで vSAN vmknic が構成済み]。このチェックでは、vSAN クラスタの各 ESXi ホストで、vSAN トラフィック用の VMkernel NIC が構成されていることを確認します。
- すべてのホストでマルチキャスト設定が一致。このチェックでは、各ホストに適切なマルチキャスト アドレスが設定されていることを確認します。
- [すべてのホストでサブネットが一致]。このチェックでは、すべての vSAN VMkernel NIC が同じ IP サブネットに存在するように、vSAN クラスタ内のすべての ESXi ホストが構成されていることをテストします。
- [vCenter Server から切断されたホスト]。このチェックでは、vCenter Server から vSAN クラスタ内のすべての ESXi ホストに対してアクティブな接続が存在することを確認します。
- [接続に問題のあるホスト]。このチェックでは、vCenter Server でホストが接続済みになっていても、vCenter Server からホストへの API 呼び出しが失敗している状況を確認します。ホストと vCenter Server 間の接続の問題が強調表示されます。
- [ネットワーク遅延]。このチェックでは、vSAN ホストのネットワーク遅延チェックを実行します。しきい値が 5 ミリ秒を超えると、警告が表示されます。
- [vMotion：MTU チェック（パケット サイズの大きい ping）]。このチェックは、vMotion の基本的な ping 接続チェックを補完します。ネットワーク パフォーマンスを向上させるため、最大転送ユニットのサイズが大きくなっています。誤って構成された MTU は、ネットワーク構成の問題として表示されていなくても、パフォーマンスに関する問題が発生する可能性があります。
- [vSAN クラスタ パーティション]。この健全性チェックは、クラスタに存在するパーティションの数を確認します。vSAN クラスタに複数のパーティションが存在すると、エラーが表示されます。
- [その他のチェックに基づくマルチキャスト評価]。この健全性チェックは、すべてのネットワーク健全性チェックのデータを集計します。このチェックに失敗した場合、ネットワーク パーティションの問題の根本原因がマルチキャストに可能性があります。
ネットワークを確認するコマンド
vSAN ネットワークが構成されている場合は、次のコマンドを使用してその状態を確認します。vSAN に使用されている VMkernel アダプタ (vmknic) とその属性を確認できます。
ESXCLI コマンドと RVC コマンドを使用して、ネットワークが完全に機能していることを確認し、vSAN のネットワークに関する問題を解決します。
vSAN ネットワークに使用されている vmknic がすべてのホストで正しく構成されていることを確認し、マルチキャストが機能していることを確認して、vSAN クラスタに参加しているホスト同士が正常に通信できることを確認できます。
esxcli vsan network list
このコマンドを使用すると、vSAN ネットワークで使用されている VMkernel インターフェイスを識別できます。
次の出力は、vSAN ネットワークで vmk2 が使用されていることを示しています。vSAN がオフになっていて、ホストが vSAN に参加していない場合でも、このコマンドは引き続き機能します。
エージェント グループのマルチキャストとマスター グループのマルチキャストも確認する必要があります。
[root@esxi-dell-m:~] esxcli vsan network list Interface VmkNic Name: vmk1 IP Protocol: IP Interface UUID: 32efc758-9ca0-57b9-c7e3-246e962c24d0 Agent Group Multicast Address: 224.2.3.4 Agent Group IPv6 Multicast Address: ff19::2:3:4 Agent Group Multicast Port: 23451 Master Group Multicast Address: 224.1.2.3 Master Group IPv6 Multicast Address: ff19::1:2:3 Master Group Multicast Port: 12345 Host Unicast Channel Bound Port: 12321 Multicast TTL: 5 Traffic Type: vsan
これは、vSAN トラフィックに使用されている VMkernel インターフェイスなど、有用な情報を提供します。この場合は [vmk1] です。ただし、マルチキャスト アドレスも表示されます。クラスタがユニキャスト モードで実行されている場合でも、この情報が表示されることがあります。グループのマルチキャスト アドレスとポートも表示されています。ポート 23451 は、プライマリが毎秒送信するハートビートに使用され、クラスタ内の他のすべてのホストに表示されます。ポート 12345 は、プライマリとバックアップ間の CMMDS の更新に使用されます。
esxcli network ip interface list
このコマンドを使用すると、vSwitch または Distributed Switch などのアイテムを確認できます。
このコマンドを使用して、接続している vSwitch または Distributed Switch、MTU サイズを確認します。この情報は、環境内にジャンボ フレームが構成されている場合に役立ちます。この例では、MTU はデフォルトの 1,500 になっています。
[root@esxi-dell-m:~] esxcli network ip interface list vmk0 Name: vmk0 <<truncated>> vmk1 Name: vmk1 MAC Address: 00:50:56:69:96:f0 Enabled: true Portset: DvsPortset-0 Portgroup: N/A Netstack Instance: defaultTcpipStack VDS Name: vDS VDS UUID: 50 1e 5b ad e3 b4 af 25-18 f3 1c 4c fa 98 3d bb VDS Port: 16 VDS Connection: 1123658315 Opaque Network ID: N/A Opaque Network Type: N/A External ID: N/A MTU: 9000 TSO MSS: 65535 Port ID: 50331814
最大転送ユニット サイズは 9,000 と表示されているので、この VMkernel ポートはジャンボ フレーム用に構成され、約 9,000 の MTU が必要になります。ジャンボ フレームの使用に関しては特に推奨事項はありません。ただし、ジャンボ フレームは vSAN で使用できます。
esxcli network ip interface ipv4 get –i vmk2
このコマンドを実行すると、vSAN VMkernel インターフェイスの IP アドレスやネットマスクなどの情報が表示されます。
この情報を使用すると、管理者はコマンドラインで使用可能な他のコマンドを実行して、vSAN ネットワークが正常に動作しているかどうか確認できます。
[root@esxi-dell-m:~] esxcli network ip interface ipv4 get -i vmk1 Name IPv4 Address IPv4 Netmask IPv4 Broadcast Address Type Gateway DHCP DNS ---- ------------ ------------- -------------- ------------ ------- -------- vmk1 172.40.0.9 255.255.255.0 172.40.0.255 STATIC 0.0.0.0 false
vmkping
vmkping コマンドは、ネットワーク上の他のすべての ESXi ホストが ping 要求に応答しているかどうか確認します。
~ # vmkping -I vmk2 172.32.0.3 -s 1472 -d PING 172.32.0.3 (172.32.0.3): 56 data bytes 64 bytes from 172.32.0.3: icmp_seq=0 ttl=64 time=0.186 ms 64 bytes from 172.32.0.3: icmp_seq=1 ttl=64 time=2.690 ms 64 bytes from 172.32.0.3: icmp_seq=2 ttl=64 time=0.139 ms --- 172.32.0.3 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.139/1.005/2.690 ms
マルチキャスト機能は確認されませんが、ネットワーク問題が発生している ESXi ホストの特定に役立ちます。また、応答時間を調べることで、vSAN ネットワークで異常遅延が発生していないかどうか確認することもできます。
ジャンボ フレームが構成され、ジャンボ フレームの MTU サイズが正しくない場合、このコマンドで問題を報告することはできません。デフォルトでは、このコマンドは 1,500 の MTU サイズを使用します。ジャンボ フレームがエンドツーエンドで正常に動作しているかどうか確認する場合は、次のように、より大きいパケット サイズ (-s) オプションを使用して vmkping を実行します。
~ # vmkping -I vmk2 172.32.0.3 -s 8972 -d PING 172.32.0.3 (172.32.0.3): 8972 data bytes 9008 bytes from 172.32.0.3: icmp_seq=0 ttl=64 time=0.554 ms 9008 bytes from 172.32.0.3: icmp_seq=1 ttl=64 time=0.638 ms 9008 bytes from 172.32.0.3: icmp_seq=2 ttl=64 time=0.533 ms --- 172.32.0.3 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.533/0.575/0.638 ms ~ #
vmkping コマンドに-d を追加し、フラグメンテーションなしでパケットを送信できるかどうかテストすることも検討してください。
esxcli network ip neighbor list
このコマンドは、すべての vSAN ホストが同じネットワーク セグメント上にあるかどうかを確認するのに役立ちます。
この構成では 4 ホスト構成のクラスタを使用しています。このコマンドを実行すると、他の 3 台のホストの ARP（アドレス解決プロトコル）エントリが返されます。この中には、IP アドレスや vmknic（vSAN がこのクラスタ内のすべてのホストで vmk1 を使用するように構成した場合）も含まれます。
[root@esxi-dell-m:~] esxcli network ip neighbor list -i vmk1 Neighbor Mac Address Vmknic Expiry State Type ----------- ----------------- ------ ------- ----- ------- 172.40.0.12 00:50:56:61:ce:22 vmk1 164 sec Unknown 172.40.0.10 00:50:56:67:1d:b2 vmk1 338 sec Unknown 172.40.0.11 00:50:56:6c:fe:c5 vmk1 162 sec Unknown [root@esxi-dell-m:~]
esxcli network diag ping
このコマンドでは、ネットワーク内の重複や往復時間を確認します。
さまざまなホスト間の vSAN ネットワーク接続の詳細については、ESXCLI が提供する強力なネットワーク診断コマンドを使用します。以下に、このような出力の例を示します。ここで VMkernel インターフェイスが vmk1 上にあり、ネットワーク上の別のホストのリモート vSAN ネットワーク IP アドレスが 172.40.0.10 です。
[root@esxi-dell-m:~] esxcli network diag ping -I vmk1 -H 172.40.0.10
Trace:
Received Bytes: 64
Host: 172.40.0.10
ICMP Seq: 0
TTL: 64
Round-trip Time: 1864 us
Dup: false
Detail:
Received Bytes: 64
Host: 172.40.0.10
ICMP Seq: 1
TTL: 64
Round-trip Time: 1834 us
Dup: false
Detail:
Received Bytes: 64
Host: 172.40.0.10
ICMP Seq: 2
TTL: 64
Round-trip Time: 1824 us
Dup: false
Detail:
Summary:
Host Addr: 172.40.0.10
Transmitted: 3
Recieved: 3
Duplicated: 0
Packet Lost: 0
Round-trip Min: 1824 us
Round-trip Avg: 1840 us
Round-trip Max: 1864 us
[root@esxi-dell-m:~]
vsan.lldpnetmap
この RVC コマンドは、アップリンク ポートの情報を表示します。
環境でリンク層探索プロトコル (LLDP) が有効になっている Cisco 以外のスイッチが存在する場合、RVC コマンドを使用すると、アップリンク <-> スイッチ <-> スイッチ ポート情報を表示できます。RVC の詳細については、RVC コマンド ガイドを参照してください。
これは、vSAN クラスタが複数のスイッチにまたがる場合にどのホストがどのスイッチに接続するのかを判断する際に役立ちます。クラスタ内のホストのサブセットのみが影響を受ける場合は、特定のスイッチに対する問題を隔離するのに役立ちます。
> vsan.lldpnetmap 02013-08-15 19:34:18 -0700: This operation will take 30-60 seconds ...+---------------+---------------------------+| Host | LLDP info |+---------------+---------------------------+| 10.143.188.54 | w2r13-vsan-x650-2: vmnic7 || | w2r13-vsan-x650-1: vmnic5 |+---------------+---------------------------+
これは、LLDP をサポートするスイッチでのみ使用できます。これを構成するには、スイッチにログインし、次のように実行します。
switch# config t Switch(Config)# feature lldp
LLDP が有効になっていることを確認するには:
switch(config)#do show running-config lldp
[]デフォルトでは、LLDP は送信モードと受信モードの両方で動作します。物理スイッチ情報が見つからない場合は、vDS プロパティの設定を確認します。デフォルトでは、vDS は CDP（Cisco 検出プロトコル）に設定された検出プロトコルで作成されます。これを解決するには、検出プロトコルを LLDP に設定し、vDS で操作を [両方] に設定します。[]
マルチキャスト通信の確認
マルチキャスト構成では、vSAN の最初の展開で問題が発生する可能性があります。
vSAN 環境でマルチキャストが正常に機能しているかどうかを確認する最も簡単な方法の 1 つは、tcpdump-uw コマンドを使用することです。このコマンドは、ESXi ホストのコマンドラインから実行できます。
この tcpdump-uw コマンドを実行すると、プライマリがマルチキャスト パケット（ポートと IP 情報）を正しく送信し、クラスタ内の他のすべてのホストがそれらを受信しているかどうかを確認できます。
このコマンドを実行すると、プライマリではマルチキャスト アドレスに送信されたパケットが表示されます。その他のすべてのホストでは、同じパケットが表示されます（プライマリからマルチキャスト アドレスまで）。表示されない場合、マルチキャストは正常に動作していません。ここに示した tcpdump-uw コマンドをクラスタ内の任意のホストで実行し、プライマリからのハートビートを表示します。この場合、プライマリは IP アドレス 172.32.0.2 にあります。詳細表示の [-v] はオプションです。
[root@esxi-hp-02:~] tcpdump-uw -i vmk2 multicast -v tcpdump-uw: listening on vmk2, link-type EN10MB (Ethernet), capture size 96 bytes 11:04:21.800575 IP truncated-ip - 146 bytes missing! (tos 0x0, ttl 5, id 34917, offset 0, flags [none], proto UDP (17), length 228) 172.32.0.4.44824 > 224.1.2.3.12345: UDP, length 200 11:04:22.252369 IP truncated-ip - 234 bytes missing! (tos 0x0, ttl 5, id 15011, offset 0, flags [none], proto UDP (17), length 316) 172.32.0.2.38170 > 224.2.3.4.23451: UDP, length 288 11:04:22.262099 IP truncated-ip - 146 bytes missing! (tos 0x0, ttl 5, id 3359, offset 0, flags [none], proto UDP (17), length 228) 172.32.0.3.41220 > 224.2.3.4.23451: UDP, length 200 11:04:22.324496 IP truncated-ip - 146 bytes missing! (tos 0x0, ttl 5, id 20914, offset 0, flags [none], proto UDP (17), length 228) 172.32.0.5.60460 > 224.1.2.3.12345: UDP, length 200 11:04:22.800782 IP truncated-ip - 146 bytes missing! (tos 0x0, ttl 5, id 35010, offset 0, flags [none], proto UDP (17), length 228) 172.32.0.4.44824 > 224.1.2.3.12345: UDP, length 200 11:04:23.252390 IP truncated-ip - 234 bytes missing! (tos 0x0, ttl 5, id 15083, offset 0, flags [none], proto UDP (17), length 316) 172.32.0.2.38170 > 224.2.3.4.23451: UDP, length 288 11:04:23.262141 IP truncated-ip - 146 bytes missing! (tos 0x0, ttl 5, id 3442, offset 0, flags [none], proto UDP (17), length 228) 172.32.0.3.41220 > 224.2.3.4.23451: UDP, length 200
この出力では少し分かりづらくなっていますが、クラスタ内の 4 台のホストがプライマリからハートビートを取得しています。すべてのホストでハートビートを受信していることを確認するには、この tcpdump-uw コマンドをすべてのホストで実行する必要があります。これにより、プライマリがハートビートを送信していて、クラスタ内の他のすべてのホストがハートビートを受信していることを確認できます。これらの条件を満たしている場合、マルチキャストは機能しています。
一部の vSAN ホストがプライマリから毎秒ハートビートを取得していない場合、ネットワーク管理者はスイッチのマルチキャスト構成を確認する必要があります。
煩わしい「truncated-ip – 146 bytes missing! 」メッセージが表示されないようにするには、同じコマンドに [–s0] オプションを使用して、パケットの切り捨てを停止する必要があります。
[root@esxi-hp-02:~] tcpdump-uw -i vmk2 multicast -v -s0
tcpdump-uw: listening on vmk2, link-type EN10MB (Ethernet), capture size 65535 bytes
11:18:29.823622 IP (tos 0x0, ttl 5, id 56621, offset 0, flags [none], proto UDP (17), length 228)
172.32.0.4.44824 > 224.1.2.3.12345: UDP, length 200
11:18:30.251078 IP (tos 0x0, ttl 5, id 52095, offset 0, flags [none], proto UDP (17), length 228)
172.32.0.3.41220 > 224.2.3.4.23451: UDP, length 200
11:18:30.267177 IP (tos 0x0, ttl 5, id 8228, offset 0, flags [none], proto UDP (17), length 316)
172.32.0.2.38170 > 224.2.3.4.23451: UDP, length 288
11:18:30.336480 IP (tos 0x0, ttl 5, id 28606, offset 0, flags [none], proto UDP (17), length 228)
172.32.0.5.60460 > 224.1.2.3.12345: UDP, length 200
11:18:30.823669 IP (tos 0x0, ttl 5, id 56679, offset 0, flags [none], proto UDP (17), length 228)
172.32.0.4.44824 > 224.1.2.3.12345: UDP, length 200
tcpdump コマンドは、IGMP (Internet Group Management Protocol) のメンバーシップに関連しています。ホスト（とネットワーク デバイス）は、IGMP を使用してマルチキャスト グループ メンバーシップを確立します。
vSAN クラスタ内の各 ESXi ホストは、通常の IGMP メンバーシップ レポート (参加) を送信します。
tcpdump コマンドを実行すると、ホストからの IGMP メンバー レポートが表示されます。
[root@esxi-dell-m:~] tcpdump-uw -i vmk1 igmp tcpdump-uw: verbose output suppressed, use -v or -vv for full protocol decode listening on vmk1, link-type EN10MB (Ethernet), capture size 262144 bytes 15:49:23.134458 IP 172.40.0.9 > igmp.mcast.net: igmp v3 report, 1 group record(s) 15:50:22.994461 IP 172.40.0.9 > igmp.mcast.net: igmp v3 report, 1 group record(s)
この出力には IGMP v3 レポートの生成が表示されています。これは、ESXi ホストがそのメンバーシップを定期的に更新していることを意味します。vSAN ESXi ホストが IGMP を正しく実行しているかどうかネットワーク管理者が疑っている場合は、このコマンドをクラスタ内の各 ESXi ホストで実行して、このトレースを表示して検証できます。
マルチキャスト通信を使用している場合は、IGMP v3 を使用します。
実際には、次のコマンドを使用すると、マルチキャスト トラフィックと IGMP トラフィックを同時に確認できます。
[root@esxi-hp-02:~] tcpdump-uw -i vmk2 multicast or igmp -v -s0
よくある問題としては、vSAN クラスタが複数の物理スイッチ間で構成されているときに、1 台のスイッチでマルチキャストが有効になっていて、スイッチ間で有効になっていないことがあります。この状況では、クラスタが 1 つのパーティションにある 2 台の ESXi ホストから構成され、別の ESXi ホスト（他のスイッチに接続されているホスト）がこのクラスタに参加できません。代わりに、別のパーティションに独自の vSAN クラスタを形成します。前述の vsan.lldpnetmap コマンドを使用すると、ネットワーク構成を特定し、どのホストがどのスイッチに接続しているのかを確認できます。
vSAN クラスタが形成されている場合、マルチキャストの問題かどうか確認できる指標がいくつかあります。
たとえば、サブネット、VLAN、MTU のチェックリストを実行し、vmkping を実行してクラスタ内の各ホストがクラスタ内の他のすべてのホストと接続可能な状態であることが確認されているとします。
クラスタの作成時にマルチキャストの問題が発生した場合、それぞれの ESXi ホストが独自の vSAN クラスタを形成し、自身がプライマリとして機能していることがよくあります。各ホストに一意のネットワーク パーティション ID がある場合、この状況はホスト間にマルチキャストがないことを示しています。
ただし、ESXi ホストのサブセットがクラスタを形成し、別のサブセットが別のクラスタを形成して、それぞれが独自のプライマリ、バックアップ、エージェント ホストを持つ一意のパーティションを使用している場合、スイッチではマルチキャストが有効になっていますが、スイッチ間では有効になっていません。vSAN には、独自のクラスタ パーティションを形成している最初の物理スイッチのホストと、独自のクラスタ パーティションを形成している 2 番目の物理スイッチのホストが表示され、それぞれが独自のプライマリを使用しています。クラスタ内のホストが接続しているスイッチと、クラスタ内のホストが同じスイッチに接続していることを確認できる場合は、この問題が発生している可能性があります。
vSAN ネットワークのパフォーマンスの確認
ESXi ホスト間に十分なバンド幅があることを確認します。このツールは、vSAN ネットワークのパフォーマンスが最適かどうかをテストする際に役立ちます。
vSAN ネットワークのパフォーマンスを確認するには、iperf ツールを使用して TCP の最大バンド幅と遅延を測定します。このツールは /usr/lib/vmware/vsan/bin/iperf.copy. にあります。-–help を指定して実行すると、さまざまなオプションを確認できます。このツールを使用して、vSAN クラスタに参加している ESXi ホスト間のネットワークバンド幅と遅延を確認します。
設定とテストを行う方法については、VMware KB「2001003」を参照してください。
vSAN クラスタを使用している場合、これが最も便利なツールです。クラスタがすでに本番環境にある場合、vSAN ネットワークで [iperf] テストを実行すると、クラスタ上で実行されている仮想マシンのパフォーマンスに影響を及ぼす可能性があります。
vSAN ネットワークの制限の確認
vsan.check.limits コマンドは、違反している vSAN しきい値がないことを確認します。
> ls 0 / 1 vcsa-04.rainpole.com/ > cd 1 /vcsa-04.rainpole.com> ls 0 Datacenter (datacenter) /vcsa-04.rainpole.com> cd 0 /vcsa-04.rainpole.com/Datacenter> ls 0 storage/ 1 computers [host]/ 2 networks [network]/ 3 datastores [datastore]/ 4 vms [vm]/ /vcsa-04.rainpole.com/Datacenter> cd 1 /vcsa-04.rainpole.com/Datacenter/computers> ls 0 Cluster (cluster): cpu 155 GHz, memory 400 GB 1 esxi-dell-e.rainpole.com (standalone): cpu 38 GHz, memory 123 GB 2 esxi-dell-f.rainpole.com (standalone): cpu 38 GHz, memory 123 GB 3 esxi-dell-g.rainpole.com (standalone): cpu 38 GHz, memory 123 GB 4 esxi-dell-h.rainpole.com (standalone): cpu 38 GHz, memory 123 GB /vcsa-04.rainpole.com/Datacenter/computers> vsan.check_limits 0 2017-03-14 16:09:32 +0000: Querying limit stats from all hosts ... 2017-03-14 16:09:34 +0000: Fetching vSAN disk info from esxi-dell-m.rainpole.com (may take a moment) ... 2017-03-14 16:09:34 +0000: Fetching vSAN disk info from esxi-dell-n.rainpole.com (may take a moment) ... 2017-03-14 16:09:34 +0000: Fetching vSAN disk info from esxi-dell-o.rainpole.com (may take a moment) ... 2017-03-14 16:09:34 +0000: Fetching vSAN disk info from esxi-dell-p.rainpole.com (may take a moment) ... 2017-03-14 16:09:39 +0000: Done fetching vSAN disk infos +--------------------------+--------------------+-----------------------------------------------------------------+ | Host | RDT | Disks | +--------------------------+--------------------+-----------------------------------------------------------------+ | esxi-dell-m.rainpole.com | Assocs: 1309/45000 | Components: 485/9000 | | | Sockets: 89/10000 | naa.500a075113019b33: 0% Components: 0/0 | | | Clients: 136 | naa.500a075113019b37: 40% Components: 81/47661 | | | Owners: 138 | t10.ATA_____Micron_P420m2DMTFDGAR1T4MAX_____ 0% Components: 0/0 | | | | naa.500a075113019b41: 37% Components: 80/47661 | | | | naa.500a07511301a1eb: 38% Components: 81/47661 | | | | naa.500a075113019b39: 39% Components: 79/47661 | | | | naa.500a07511301a1ec: 41% Components: 79/47661 | <<truncated>>
ネットワークの観点から見ると、重要なものは RDT の関連付け (Assocs) とソケット数です。vSAN 6.0 以降では、ホストごとに 45,000 の関連付けがあります。RDT の関連付けは、vSAN 内でピアツーピア ネットワークの状態を追跡するために使用されます。RDT の関連付けが不足しないように、vSAN のサイズが調整されます。vSAN では、使用を許可する TCP ソケットの数も制限され、TCP ソケットの割り当てが不足しないように vSAN のサイズが調整されます。ホストあたりのソケット数の上限は 10,000 です。
vSAN [クライアント] は、vSAN クラスタでのオブジェクトのアクセスを表します。クライアントは通常、ホストで実行されている仮想マシンを表します。クライアントとオブジェクトが同じホスト上にない場合もあります。ハード定義の制限はありませんが、ホスト間でのクライアントのバランスを理解するために、このメトリックが表示されます。
特定の vSAN オブジェクトには 1 つの vSAN [所有者] があり、通常、このオブジェクトにアクセスする vSAN クライアントと一緒に存在します。vSAN 所有者は、vSAN オブジェクトへのすべてのアクセスを調整し、ミラーリングやストライピングなどの機能を実装します。ハード定義の制限はありませんが、ホスト間での所有者のバランスを理解するために、このメトリックが表示されます。
