Skip to main content
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Enjoy members-only rewards and discounts
  • Create and access a list of your products
  • Manage your Dell EMC sites, products, and product-level contacts using Company Administration.

Dell EMC VxRail: vSAN Health에서 "Hosts with communication issues" 메시지가 가끔 보고됨

Summary: VxRail VSAN 클러스터 내의 ESXi 호스트에 일시적인 연결 문제가 발생할 수 있으며, 그 결과 VSAN 상태가 "Hosts with communication issues" 오류 메시지를 보고할 수 있습니다.

This article may have been automatically translated. If you have any feedback regarding its quality, please let us know using the form at the bottom of this page.

Article Content


Symptoms

호스트는 때때로 연결 문제를 보고할 수 있습니다. 호스트는 연결된 상태로 유지되지만 vSAN 상태 점검에서 통신 문제가 있는 임의의 호스트를 주기적으로 표시할 수 있습니다. VSAN 상태를 재검사하면 문제가 사라지지만 몇 분 후에 반환됩니다.

영향을 받는 버전:
지금까지 VxRail 버전 4.5.x 및 4.7.x가 영향을 받고 있습니다. 

로그 분석 요약:

vCenter에 vSAN 상태 알람이 표시되는 것을 볼 수 있습니다.

2019-08-14T12:56:01.422Z INFO vsan-mgmt[EventMonitor] [VsanEventUtil::_generateVcEvent opID=noOpId] Generate VC event for managed object NC1V01 with testName=Hosts with connectivity issues, testId=com.vmware.vsan.health.test.hostconnectivity, preStatus=green, curStatus=red
vmware-vsan-health-summary-result.log에서 vSAN 상태 호스트 연결 문제를 확인할 수 있습니다.
2019-08-14T12:56:01.355Z INFO vsan-mgmt[EventMonitor] [VsanHealthSummaryLogUtil::PrintHealthResult opID=noOpId] Cluster NB1X01  Overall Health : red
   Group network health : red
      Test hostdisconnected health : green
      Test hostconnectivity health : red
         HostsWithCommunicationIssues: Host
                                       (Host-234),
      Test clusterpartition health : green
      Test vsanvmknic health : green
      Test smallping health : green
      Test largeping health : green
      Test vmotionpingsmall health : green
      Test vmotionpinglarge health : green
      Test hostlatencycheck health : green
         NetworkLatencyCheckResults: FromHost  ToHost  NetworkLatency(Ms)  NetworkLatencyCheckResult
                                     (Host-227, Host-236, 0.18, Green), (Host-227, Host-234, 0.23, Green), (Host-227, Host-238, 0.16, Green), (Host-227, Host-232, 0.12, Green), (Host-234, Host-232, 0.27, Green),
                                     (Host-234, Host-238, 0.31, Green), (Host-234, Host-236, 0.29, Green), (Host-234, Host-227, 0.26, Green), (Host-236, Host-227, 0.1, Green), (Host-236, Host-234, 0.12, Green),
                                     (Host-236, Host-238, 0.1, Green), (Host-236, Host-232, 0.1, Green), (Host-232, Host-236, 0.1, Green), (Host-232, Host-238, 0.1, Green), (Host-232, Host-234, 0.12, Green),
                                     (Host-232, Host-227, 0.11, Green), (Host-238, Host-232, 0.15, Green), (Host-238, Host-236, 0.11, Green), (Host-238, Host-234, 0.23, Green), (Host-238, Host-227, 0.12, Green),
   Group cloudhealth health : yellow
      Test vsancloudhealthceipexception health : yellow
   Group vum health : yellow
      Test vumconfig health : yellow


 
vmware-vsan-health-service.log:

2019-08-14T12:55:54.403Z ERROR vsan-mgmt[Thread-590807] [VsanPyVmomiProfiler::InvokeMethod opID=noOpId] Timed out for host nc1v02ps12.corp.ukrail.net in invoke-method:vsanSystem:Query
HostStatus
2019-08-14T12:55:54.403Z INFO vsan-mgmt[Thread-590807] [VsanPyVmomiProfiler::logProfile opID=noOpId]   invoke-method:vsanSystem:QueryHostStatus: 8.44s:nc1v02ps12.corp.ukrail.net
2019-08-14T12:55:54.403Z ERROR vsan-mgmt[Thread-590807] [VsanClusterHealthSystemImpl::PerHostQueryNetworkHealth opID=noOpId] Exception in host nc1v02ps12.corp.ukrail.net:
Traceback (most recent call last):
  File "C:\Program Files\VMware\vCenter Server\vsan-health\pyMoVsan\VsanClusterHealthSystemImpl.py", line 1004, in PerHostQueryNetworkHealth
    SetHostClusterUuid(host, hostInfos[host], fetchHostStatus=True)
  File "C:\Program Files\VMware\vCenter Server\vsan-health\pyMoVsan\VsanClusterHealthSystemImpl.py", line 784, in SetHostClusterUuid
    status = vs.QueryHostStatus()
..
..
..
    return self._sslobj.read(len, buffer)
  File "C:\Program Files\VMware\vCenter Server\python\lib\ssl.py", line 583, in read
    v = self._sslobj.read(len, buffer)
socket.timeout: The read operation timed out
 

Cause

기본적으로 PTAgent는 SCSI 디바이스를 수행하고 버스는 3분마다 재검사하도록 설정되어 있습니다. 이 유형의 쿼리는 서버에 연결된 새 디스크 또는 기타 하드웨어 디바이스를 찾는 것입니다. iSCSI와 같은 다른 블록 디바이스도 검사하도록 확장되었습니다. 기본적으로 로컬 HBA에서 새 디스크가 최근에 추가되었는지 확인합니다. 
또한 ESXi 스토리지 스택은 자체 디바이스를 수행하고 버스는 기본적으로 5분마다 재검사합니다. 디바이스 및 버스 재검사는 스토리지 관점에서 비용이 많이 드는 작업입니다. 이로 인해 SCSI 버스의 특정 부분이 차단되어 작업이 완료될 때까지 대기할 수 있습니다. 이로 인해 작업이 완료될 때까지 대기 시간이 늘어나면 영향을 줄 수 있습니다. 이미 많은 스토리지 작업이 전송 중인 경우 재검사로 이동하기 전에 완료해야 할 수 있습니다.

PTAgent와 ESXi가 기본적으로 동시에 재검사되는 경우가 있다는 것을 확인했습니다. 이로 인해 재검사를 완료하는 동안 응답이 지연되어 vSAN 상태 경보가 발생하는 경우가 있습니다. vSAN 상태가 실패한 테스트에 대한 알람을 트리거하지는 않지만 실행 중인 테스트는 vSAN 상태 쿼리 시간 초과로 실패한 것으로 표시됩니다.
전반적으로 이 문제는 시기 중 하나입니다. vSAN 상태에는 쿼리 응답 시간 초과가 짧으며 오류를 확인하기 위한 재시도 또는 기타 검증 메커니즘이 없습니다. PTAgent 및 ESXi에서 동시에 실행 중인 재검사(다른 대기열 I/O와 함께)로 인해 vSAN 상태 시간 초과가 트리거될 정도로 지연될 수 있습니다.

Resolution

해결 방법은 PTAgent 재검 검사를 비활성화하고 기본적으로 기본 ESXi 스토리지 재검사 기능을 그대로 두는 것입니다. 기본적으로 VMware가 vSAN에서 사용하는 것과 동일한 재검사 간격을 사용합니다. 이러한 변경으로 데이터 또는 I/O 작업에는 위험이 없습니다. 즉, 재검사 빈도는 발생하지 않지만 추가되거나 제거되는 디스크는 일반적인 문제가 아닙니다. 핫 플러그를 통해 디스크를 추가하는 경우 HBA에는 운영 체제(ESXi)에 디스크 변경이 있었다는 것을 알리는 특수 로직이 있습니다. 서버가 꺼져 있을 때 디스크를 추가하거나 제거하는 다른 시간도 있고 재검사도 부팅 순서의 일부입니다. 병렬 재검사가 바람직할 수 있는 경우가 있습니다. 복제 페일오버 또는 iSCSI, FC, FCoE 어레이에서 추가된 새 디스크 등). 하지만 SRM과 같은 페일오버 메커니즘에는 추가 재검색을 통해 이를 처리하는 로직이 있거나 FC의 RSCN과 같은 디스크 유형의 기능을 사용하고 있습니다. 이 경우 이러한 시나리오는 적용되지 않아야 하며, ESXi가 이러한 시나리오를 잘 처리하고 있는 경우에도 마찬가지입니다.

해결 방법:
참고: 다음 동작은 PTAgent 1.9.2 이상에서 올바르게 구현됩니다. 

현재 릴리스에 포함된 PTAgent 버전에 대한 VxRail 릴리스 노트를 확인하십시오.
1) 재검사에서 여전히 트리거되는지 확인합니다.

[root@vs218:~] grep -w "Dispatch rescan" /var/run/log/hostd.log |tail -10
2019-10-17T12:16:06.080Z info hostd[2106293] [Originator@6876 sub=Solo.VmwareCLI opID=esxcli-0a-ae0b user=root] Dispatch rescan
2019-10-17T12:16:07.231Z info hostd[2106293] [Originator@6876 sub=Solo.VmwareCLI opID=esxcli-0a-ae0b user=root] Dispatch rescan done

2) ESXi 호스트를 유지 보수 모드로 전환합니다.

3) 다음 명령을 적용하여 재검출을 비활성화합니다.

       # /opt/dell/DellPTAgent/tools/pta_cfg set in_band_device_scan_enabled=false
       # /opt/dell/DellPTAgent/tools/pta_cfg set in_band_device_poll_interval_minutes=0
4) 비활성화되어 있는지 확인합니다.
       # /opt/dell/DellPTAgent/tools/pta_cfg list |grep "in_band_device"
           in_band_device_poll_interval_minutes => 0
           in_band_device_scan_enabled          => False
       # grep -A4 in_band_device_scan_enabled /scratch/dell/config/PTAgent.config
           "in_band_device_scan_enabled": {
               "value": false,
               "defaultValue": true,
               "description": "On ESXi platforms, controls if PT-agent should force adapter scans periodically (controlled by in_band_device_poll_interval_minutes) before probing storage devices."
           },
5) 다음을 통해 노드에서 PTAgent 서비스를 재시작합니다.

       # /etc/init.d/DellPTAgent restart
6) 유지 보수 모드를 종료합니다.

7) 클러스터의 모든 노드에 대해 동일한 단계를 반복합니다.



Additional Information

ESXi가 이미 정기적으로 진행되므로 PTAgent 재검사 기능을 끄면 스토리지 기능이나 기능 문제가 없습니다.
인밴드 디바이스 검사가 비활성화되어 있더라도 PTAgent는 시작 시에도 계속 스캔합니다. 검사를 비활성화한 후에도 증상이 계속 발생하는 경우 PTAgent가 반복적으로 재시작되는 이유를 확인해야 합니다.

Article Properties


Affected Product

VxRail Appliance Family

Product

VxRail Appliance Family, VxRail Appliance Series, VxRail E Series Nodes, VxRail E460, VxRail E560, VxRail E560F, VxRail P470, VxRail P570, VxRail P570F, VxRail S570, VxRail Software

Last Published Date

17 Jun 2023

Version

6

Article Type

Solution