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.
Some article numbers may have changed. If this isn't what you're looking for, try searching all articles. Search articles

Dell EMC VxRail: vSAN Health zgłasza czasami komunikaty "Hosty z problemami z komunikacją"

Summary: Hosty ESXi w klastrze VxRail VSAN mogą napotykać tymczasowe problemy z połączeniem, w związku z czym kondycja VSAN może zgłaszać komunikaty o błędach "Hosty z problemami z komunikacją". ...

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

Co jakiś czas hosty mogą zgłaszać problemy z połączeniem. Hosty pozostaną połączone, ale kontrola poprawności działania vSAN może okresowo wskazywać losowe hosty z problemami z komunikacją. Jeśli test VSAN zostanie ponownie przetestowany, problem zniknie, ale powróci po kilku minutach.

Wersje, których dotyczy problem:
Obecnie występuje problem vxRail w wersjach 4.5.x i 4.7.x. 

Podsumowanie analizy dziennika:

W vCenter wyświetlany jest alarm kondycji 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
W pliku vmware-vsan-health-summary-result.log można zobaczyć problemy z połączeniem hosta kondycji 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

Domyślnie ptagent jest ustawiony tak, aby wykonywać ponowną próbę urządzenia SCSI i magistrali co 3 minuty. Ten typ zapytania polega na wyszukiwaniu nowych dysków lub innych urządzeń sprzętowych, które są podłączone do serwera. Został on rozszerzony o sprawdzanie innych urządzeń blokowych, takich jak iSCSI. W istocie sprawdzamy lokalną kartę HBA, aby sprawdzić, czy ostatnio dodano nowe dyski. 
Stos pamięci masowej ESXi również domyślnie wykonuje własne urządzenie i ponownie zeskanowanie magistrali co 5 minut. Ponowne zeskanowanie urządzenia i magistrali jest kosztowną operacją z punktu widzenia pamięci masowej. Może to spowodować zablokowanie niektórych części magistrali SCSI w oczekiwaniu na zakończenie operacji. Może to mieć wpływ na większe opóźnienia oczekiwania na zakończenie operacji. Jeśli w locie jest już wiele operacji pamięci masowej, może być konieczne ich zakończenie, zanim przejdzie do ponownego zeskanowania.

Stwierdziliśmy, że czasami ptagent i ESXi ponownie zeskanują się w tym samym czasie. Może to spowodować opóźnienie w reakcji podczas wykonywania ponownego skanowania, co czasami powoduje alarm kondycji vSAN. Kondycja vSAN nie wyzwala alarmu w przypadku nieudanego testu, ale test, który jest uruchomiony, jest oznaczony jako nieudany, ponieważ upłynął limit czasu kwerendy o kondycję vSAN.
Ogólnie rzecz biorąc, problem dotyczy jednego z terminów. VSAN health has a short timeout for queries to respond, and has no retry or other verification mechanism to confirm a fault.vSAN health has a short timeout for queries to respond, and has no retry or other verification mechanism to confirm a fault. Ponowne zeskanowanie z PTAgent i ESXi uruchomione jednocześnie (wraz z innymi kolejkami we/wy) może spowodować opóźnienie na tyle długo, że wyzwala limit czasu vSAN.

Resolution

Rozwiązaniem jest wyłączenie ponownego zeskanowanie PTAgent i pozostawienie domyślnego ponownego zeskanowanie pamięci masowej ESXi. W istocie korzysta to z tego samego interwału ponownego zeskanowania, z których VMware korzysta domyślnie z vSAN. Zmiana ta nie wiąże się z ryzykiem dla danych ani operacji we/wy. Oznacza to, że ponowne zeskanowanie nie będzie wykonywane tak często, ale dodawane lub usuwane dyski nie są częstym zdarzeniem. Jeśli dysk zostanie dodany za pośrednictwem hot plug, HBA ma specjalną logikę informującą system operacyjny (ESXi), że nastąpiła zmiana dysku. Innym razem, gdy serwer jest wyłączony, należy dodać lub usunąć dyski, a ponowne zeskanowanie stanowi część sekwencji rozruchu. W niektórych przypadkach może być pożądane ponowne zeskanowanie równoległe. Takie jak przełączanie awaryjne replikacji lub nowe dyski dodane z macierzy iSCSI, FC, FCoE). Ale mechanizmy przełączania awaryjnego, takie jak SRM, mają logikę postępowania z tym poprzez dodatkowe ponowne zeskanowanie lub używają funkcji tych typów dysków (takich jak RSCN w FC). Żaden z tych scenariuszy nie powinien mieć zastosowania w tym przypadku, a nawet gdy są w grze, ESXi radzi sobie z nimi dobrze.

Obejście problemu:
UWAGA: w oprogramowaniu PTAgent 1.9.2 i nowszych jest prawidłowo wdrożone następujące zachowanie. 

Sprawdź informacje dotyczące wydania VxRail dla wersji PTAgent dołączonej do bieżącej wersji.
1) Sprawdź, czy ponowne skanowanie jest nadal wyzwalane:

[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) Przełącz hosta ESXi w tryb konserwacji.

3) Wyłącz ponowne skanowanie, stosując następujące polecenia:

       # /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) Upewnij się, że jest wyłączona
       # /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) Uruchom ponownie usługę PTAgent w węźle z następującymi opcjami:

       # /etc/init.d/DellPTAgent restart
6) Wyjdź z trybu konserwacji.

7) Powtórz te same czynności dla wszystkich węzłów w klastrze.



Additional Information

Nie ma problemów z możliwościami lub funkcjonalnością pamięci masowej, wyłączając ponowne zeskanowanie PTAgent, ponieważ ESXi robi to już samodzielnie w regularnych odstępach czasu.
Nawet jeśli skanowanie urządzeń w paśmie jest wyłączone, ptagent będzie nadal skanować przy uruchomieniu. Jeśli objaw nadal występuje nawet po wyłączeniu skanowania, należy sprawdzić przyczynę wielokrotnego ponownego uruchamiania 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