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が「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正常性クエリーがタイムアウトすると失敗とマークされます。
全体的に、問題はタイミングの1つです。vSANの稼働状態では、クエリーが応答するためのタイムアウトが短く、障害を確認するための再試行やその他の検証メカニズムはありません。PTAgentとESXiからの再スキャンが同時に実行されると(他のキューに登録されたI/Oと一緒に)、vSANの正常性タイムアウトをトリガーするのに十分な時間がかかる場合があります。

Resolution

回避策は、PTAgentの再スキャンを無効にし、基本的にデフォルトのESXiストレージの再スキャンをそのままにすることです。これは基本的に、vSANでVMwareがデフォルトで使用するのと同じ再スキャンインターバルを使用します。この変更により、データまたは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