vSAN을 사용하면 잘못 구성된 vSAN 네트워크에서 발생하는 다양한 유형의 문제를 검토하고 해결할 수 있습니다.
vSAN 작업은 네트워크 구성, 안정성 및 성능에 따라 달라집니다. 많은 지원 요청이 잘못된 네트워크 구성이 있거나 네트워크가 예상되는 성능을 나타내지 않을 때 발생합니다.
vSAN 상태 서비스를 사용하여 네트워크 문제를 해결하십시오. 네트워크 상태 점검은 상태 점검 결과에 따라 적절한 기술 자료 문서로 안내할 수 있습니다. 기술 자료 문서에서는 네트워크 문제를 해결하기 위한 지침을 제공합니다.
네트워크 상태 점검
상태 서비스에는 네트워킹 상태 점검을 위한 범주가 포함되어 있습니다.
각 상태 점검에는 AskVMware 링크가 있습니다. 상태 점검이 실패하면 AskVMware를 클릭하고 관련 VMware 기술 자료 문서에서 자세한 정보와 문제를 쉽게 해결하는 방법에 대한 지침을 참조하십시오.
- vSAN: 기본(유니캐스트) 연결 확인. 이 검사는 vSAN 네트워크에 있는 각 ESXi 호스트를 다른 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 호스트가 구성되었는지 테스트합니다.
- 호스트가 VC에서 연결이 끊김. 이 검사는 vCenter Server에서 vSAN 클러스터의 모든 ESXi 호스트에 대한 활성 연결이 있는지 확인합니다.
- 연결 문제가 있는 호스트. 이 검사는 vCenter Server가 호스트를 연결된 것으로 표시되지만 vCenter에서 호스트로의 API 호출이 실패하는 상황을 나타냅니다. 호스트와 vCenter Server 간의 연결 문제를 중점적으로 나타낼 수 있습니다.
- 네트워크 지연 시간. 이 검사는 vSAN 호스트의 네트워크 지연 시간 검사를 수행합니다. 임계값이 100ms를 초과하면 경고가 표시됩니다. 지연 시간 임계값이 200ms를 초과하면 오류가 발생합니다.
- 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은 기본에서 1초마다 전송되는 하트비트에 사용되며 클러스터의 다른 모든 호스트에 표시됩니다. 포트 12345는 기본과 백업 간의 CMMDS 업데이트에 사용됩니다.
esxcli network ip interface list
이 명령을 사용하면 vSwitch 또는 분산 스위치와 같은 항목을 확인할 수 있습니다.
이 명령을 사용하여 연결된 vSwitch 또는 분산 스위치와 환경에서 점보 프레임이 구성된 경우 유용할 수 있는 MTU 크기를 확인합니다. 이 경우 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으로 표시되므로 이 VMkernel 포트는 약 9,000의 MTU가 필요한 점보 프레임용으로 구성된 것입니다. VMware는 점보 프레임 사용에 대한 권장 사항을 제공하지 않습니다. 그러나 점보 프레임은 vSAN에서 사용하도록 지원됩니다.
esxcli network ip interface ipv4 get –i vmk2
이 명령은 vSAN VMkernal 인터페이스의 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
멀티캐스트 기능을 확인하지는 않지만 네트워크 문제가 있는 rogue ESXi 호스트를 식별하는 데 도움이 될 수 있습니다. 또한 응답 시간을 검토하여 vSAN 네트워크에 비정상적인 지연 시간이 발생하는지 확인할 수 있습니다.
점보 프레임이 구성된 경우 점보 프레임 MTU 크기가 잘못되어도 이 명령은 문제를 보고하지 않습니다. 기본적으로 이 명령은 MTU 크기 1500을 사용합니다. 점보 프레임이 전체적으로 작업을 성공적으로 수행하는지 확인해야 하는 경우 다음과 같이 더 큰 패킷 크기(-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개 호스트 클러스터가 있으며, 이 명령은 IP 주소와 해당 vmknic(vSAN이 이 클러스터의 모든 호스트에서 vmk1을 사용하도록 구성됨)를 포함하는 다른 3개 호스트에 대한 ARP(Address Resolution Protocol) 항목을 반환합니다.
[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에서는 강력한 네트워크 진단 명령을 제공합니다. 다음은 이러한 출력의 예입니다. 여기서 vmk1에 VMkernel 인터페이스가 있고 네트워크에 있는 다른 호스트의 원격 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(Link Layer Discovery Protocol)가 사용하도록 설정된 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 Discovery Protocol)로 설정된 검색 프로토콜을 사용하여 생성됩니다. 이 문제를 해결하려면 검색 프로토콜을 LLDP로 설정하고 vDS에서 작업을 both로 설정합니다.
멀티캐스트 통신 확인
멀티캐스트 구성은 초기 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
이 출력은 약간 혼동을 가져올 수 있지만, 여기에 표시된 출력은 클러스터의 4개 호스트가 기본에서 하트비트를 가져오는 것을 의미합니다. 이 tcpdump-uw 명령은 하트비트를 수신하는지 확인하기 위해 모든 호스트에서 실행해야 합니다. 이 명령은 기본이 하트비트를 전송하고 있고 클러스터의 다른 모든 호스트가 이를 수신 중인지 확인합니다. 그럴 경우 멀티캐스트가 작동 중인 것입니다.
일부 vSAN 호스트가 기본에서 1초 하트비트를 선택할 수 없는 경우 네트워크 관리자는 해당 스위치의 멀티캐스트 구성을 확인해야 합니다.
truncated-ip – 146바이트 누락을 방지하기 위해서입니다! 메시지가 표시되지 않도록 하려면 동일한 명령에 –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)
ESXi 호스트가 정기적으로 멤버 자격을 업데이트하고 있음을 나타내는 IGMP v3 보고서가 출력에 표시됩니다. 네트워크 관리자는 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 클러스터를 구성하게 되는 것이 일반적인 증상입니다. 이러한 증상이 있더라도 각 호스트에 고유한 네트워크 파티션 ID가 있는 경우 호스트 간에 멀티캐스트가 없는 것을 암시합니다.
그러나 ESXi 호스트의 하위 집합이 클러스터를 형성하고 다른 하위 집합은 다른 클러스터를 형성하며, 각각에 고유한 기본, 백업 및 에이전트 호스트까지 있는 고유한 파티션을 포함할 경우 여러 스위치가 아닌 해당 스위치에서 멀티캐스트가 사용하도록 설정됩니다. vSAN은 자체 클러스터 파티션을 형성하는 첫 번째 물리적 스위치의 호스트와 각각이 고유한 기본을 보유하는 고유한 클러스터 파티션을 형성하는 두 번째 물리적 스위치의 호스트를 보여 줍니다. 클러스터의 호스트가 연결하는 스위치를 확인할 수 있고 클러스터의 호스트가 동일한 스위치에 연결된 경우 이것에 문제가 될 수 있습니다.
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 내에서 피어 투 피어 네트워크 상태를 추적하는 데 사용됩니다. vSAN은 RDT 연결이 부족하지 않도록 크기가 조정됩니다. 또한 vSAN은 사용할 수 있는 TCP 소켓 수를 제한하며, TCP 소켓 할당이 부족하지 않도록 크기가 조정됩니다. 호스트당 10,000개 소켓으로 제한됩니다.
vSAN client는 vSAN 클러스터의 개체 액세스를 나타냅니다. 클라이언트는 일반적으로 호스트에서 실행되는 가상 시스템을 나타냅니다. 클라이언트와 개체가 동일한 호스트에 있지 않을 수 있습니다. 명확하게 정의된 제한은 없지만 이 메트릭은 클라이언트가 여러 호스트에서 밸런스를 유지하는 방법을 이해하는 데 도움을 줍니다.
주어진 vSAN 개체에는 하나의 vSAN 소유자만 있으며, 이 소유자는 일반적으로 이 개체에 액세스하는 vSAN 클라이언트와 함께 배치됩니다. vSAN 소유자는 vSAN 개체에 대한 모든 액세스를 조정하고 미러링 및 스트라이핑과 같은 기능을 구현합니다. 명확하게 정의된 제한은 없지만 이 메트릭은 소유자가 여러 호스트에서 밸런스를 유지하는 방법을 이해하는 데 도움을 주기 위해 한번 더 표시됩니다.
