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: На хостах ESXi в кластере VxRail VSAN могут возникать временные проблемы с подключением, и в результате состояние 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 одновременно (наряду с другими поставленными в очередь вводами-выводом) может привести к задержке в течение достаточного времени ожидания, что приведет к тайм-ауту работоспособности vSAN.

Resolution

Временное решение проблемы — отключить повторное сканирование PTAgent и по сути оставить восстановление хранилища ESXi по умолчанию на месте. По сути, для этого используется тот же интервал повторного сканирование, что и для VMware по умолчанию с vSAN. Это изменение не представляет риска для данных или операций ввода-вывода. Это означает, что повторное сканирование выполняется не так часто, но добавление или удаление дисков не является распространенным явлением. Если диск добавляется с помощью «горячего» подключения, HBA-адаптер имеет специальную логику, информируя операционную систему (ESXi) о том, что диск был изменен. В других случаях добавление или удаление дисков при выключенном сервере и повторное сканирование является частью последовательности загрузки. В некоторых случаях может потребоваться параллельное повторное сканирование. Например, переключение репликации при отказе или добавление новых дисков из массива iSCSI, FC, FCoE). Но механизмы переключения при отказе, такие как SRM, имеют логику для обработки этого путем дополнительного повторного сканирование или используют функции этих типов дисков (например, RSCN в FC). В этом случае ни один из этих сценариев не должен быть применим, и даже когда они используются, ESXi хорошо с ними работает.

Временное решение:
ПРИМЕЧАНИЕ. Следующее поведение должным образом реализовано в PTAgent 1.9.2 и более поздних версиях. 

Проверьте примечания к выпуску VxRail на наличие версии PTAgent, включенной в текущий выпуск.
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

Отключение повторного сканирование PTAgent не приводит к проблеме с возможностями или функциональными возможностями системы хранения, поскольку ESXi уже выполняет самопроверку с регулярными интервалами.
Даже если сканирование устройств без использования дополнительного канала отключено, 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