vSAN 可讓您檢查並疑難排解因組態錯誤的 vSAN 網路而出現的不同類型的問題。

vSAN 作業取決於網路組態、可靠性和效能。許多支援請求源自不正確的網路組態,或是網路未如預期執行。

請使用 vSAN 健全狀況服務來解決網路問題。根據健全狀況檢查的結果,網路健全狀況檢查可將您引導至適當的知識庫文章。知識庫文章提供解決網路問題的指示。

網路健全狀況檢查

健全狀況服務包含用於網路健全狀況檢查的類別。

每個健全狀況檢查都會有 AskVMware 連結。如果健全狀況檢查失敗,請按一下 AskVMware,並閱讀相關聯的 VMware 知識庫文章,以取得進一步的詳細資料,以及如何解決眼前的問題的相關指引。

下列網路健全狀況檢查可提供關於 vSAN 環境的實用資訊。
  • vSAN:基本 (單點傳播) 連線檢查。此檢查可驗證 vSAN 叢集中的所有 ESXi 主機之間是否存在 IP 連線,方法是從每個其他 ESXi 主機對 vSAN 網路上的每個 ESXi 主機執行 Ping 動作。
  • vMotion:基本 (單點傳播) 連線檢查。此檢查會驗證 vSAN 叢集中已設定 vMotion 的所有 ESXi 主機之間是否存在 IP 連線。vMotion 網路上的每個 ESXi 主機都會對所有其他 ESXi 主機執行 Ping 動作。
  • 所有主機都已設定 vSAN vmknic。此檢查可確保 vSAN 叢集中的每個 ESXi 主機都已針對 vSAN 流量設定 VMkernel NIC。
  • 所有主機都有相符的多點傳送設定。此檢查可確保每台主機都有正確設定的多點傳送位址。
  • 所有主機都有相符的子網路。此檢查會測試 vSAN 叢集中的所有 ESXi 主機是否已設定,以便所有 vSAN VMkernel NIC 都位於相同的 IP 子網路上。
  • 主機與 VC 中斷連線。此檢查會確認 vCenter Server 具有與 vSAN 叢集中所有 ESXi 主機的作用中連線。
  • 有連線問題的主機。此檢查是指 vCenter Server 將主機列為已連線,但從 vCenter 對主機的 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 大小,如果已在環境中設定 Jumbo 框架,則其相當實用。在此情況下,MTU 會使用預設值 1500。

[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

傳輸單元最大值大小顯示為 9000,因此會針對 Jumbo 框架設定此 VMkernel 連接埠,其需要約 9,000 的 MTU。VMware 不會針對 Jumbo 框架的相關使用提出任何建議。但支援將 Jumbo 框架與 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 網路上是否有任何異常延遲。

如果設定了 Jumbo 框架,當 Jumbo 框架 MTU 大小不正確時,此命令將不會報告任何問題。依預設,此命令會使用 1500 的 MTU 大小。如果需要確認 Jumbo 框架是否在端對端上成功運作,請使用 vmkping 搭配較大的封包大小 (-s) 選項,如下所示:

 ~ # 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
 ~ # 

請考慮將 -d 新增至 vmkping 命令,以測試是否可以傳送封包而不會產生片段。

esxcli network ip neighbor list

此命令可協助驗證所有 vSAN 主機是否位於相同的網路區段。

在此組態中,我們有一個包含四台主機的叢集,而此命令會傳回其他三台主機的 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 內容的設定。依預設,系統會透過將探索通訊協定設定為 CDP (Cisco 探索通訊協定) 來建立 vDS。若要解決此問題,請將探索通訊協定設定為 LLDP,並將 vDS 上的作業設定為兩者

檢查多點傳送通訊

多點傳送組態可能會導致初始 vSAN 部署出現問題。

驗證多點傳送是否在 vSAN 環境中正常運作的最簡單方式之一是使用 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 

雖然此輸出似乎有點混淆,但足以說明此處顯示的輸出指出叢集中的四台主機正從主要節點取得活動訊號。此 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 (網際網路群組管理通訊協定) 成員資格相關。主機 (和網路裝置) 使用 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 叢集會在多個實體交換器之間進行設定,而在一個交換器上啟用多點傳送時,在各交換器間尚未啟用。在此情況下,系統會在一個磁碟分割中形成具有兩台 ESXi 主機的叢集,而另一個 ESXi 主機 (連線到另一個交換器) 無法加入此叢集。而是會在另一個磁碟分割中形成自己的 vSAN 叢集。先前顯示的 vsan.lldpnetmap 命令可協助您判斷網路組態,以及哪些主機連結至哪個交換器。

在 vSAN 叢集形成時,指標會顯示多點傳送可能是問題。

假設已遵循子網路、VLAN、MTU 的檢查清單,且叢集中的每台主機都可以對叢集中的所有其他主機執行 vmkping 動作。

如果在建立叢集時存在多點傳送問題,常見的症狀是每個 ESXi 主機本身會形成自己的 vSAN 叢集,且本身為主要節點。如果每台主機都有唯一的網路磁碟分割識別碼,則此症狀表示任何主機之間不存在多點傳送。

但是,如果有 ESXi 主機的部分子集形成叢集,而另一個子集形成另一個叢集,並且每個都有唯一的磁碟分割與其本身的主要節點、備份,甚或是代理程式主機,則會在交換器中啟用多點傳送,但不會在交換器間啟用。vSAN 顯示第一個實體交換器上的主機形成其自己的叢集磁碟分割,而第二個實體交換器上的主機則形成其自己的叢集磁碟分割,每個本身為自己的主要節點。如果您可以確認叢集中的主機連線到的交換器,且叢集中的主機連線到相同的交換器,則這可能就是問題。

檢查 vSAN 網路效能

請確定 ESXi 主機之間有足夠的頻寬。此工具可協助您測試 vSAN 網路的執行是否理想。

若要檢查 vSAN 網路的效能,您可以使用 iperf 工具來測量 TCP 頻寬和延遲上限。它位於 /usr/lib/vmware/vsan/bin/iperf.copy.。請使用 -–help 來執行它,以查看各種選項。使用此工具可檢查參與 vSAN 叢集之 ESXi 主機之間的網路頻寬和延遲。

VMware 知識庫 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 內的點對點網路狀態。系統會設定 vSAN 的大小,使其永遠不會用盡 RDT 關聯。vSAN 也會限制允許使用的 TCP 通訊端數目,並設定 vSAN 的大小,使其永遠不會用盡其 TCP 通訊端的配置。每台主機有 10,000 個通訊端限制。

vSAN 用戶端 代表 vSAN 叢集中物件的存取權。用戶端通常代表在主機上執行的虛擬機器。用戶端和物件可能不在相同的主機上。沒有硬性定義的限制,但會顯示此度量以協助瞭解用戶端在主機之間的平衡方式。

指定的 vSAN 物件通常只有一個 vSAN 擁有者,且通常會與存取此物件的 vSAN 用戶端成為共置狀態。vSAN 擁有者會協調對 vSAN 物件的所有存取權,並實作鏡像和分割等功能。沒有硬性定義的限制,但會再次顯示此度量以協助瞭解擁有者在主機之間的平衡方式。