[HyperFlex]NFS全パス停止（APD）問題のトラブルシューティングについて

qiuxia · ‎2019-07-10

はじめに
HXデータストアはESXIにどのようにマウントされているのか？
All Paths Downとは
問題の説明
APD発生の潜在的な原因
トラブルシューティングワークフロー
各コンポーネントごとの確認
vCenter Server
全てのStCtlVM
影響を受けたESXiホスト上で動作しているStCtlVM
ESXiホストで確認
APD Logging

はじめに

このドキュメントでは、Hyperflexクラスタが統合されているvCenterで「NFS all paths down」エラーメッセージが表示された場合に原因を究明するためのトラブルシューティングの手順を簡単に説明します。

HXデータストアはESXIにどのようにマウントされているのか？

Hyperflexデータストアは、NFSマウントとしてESXIホストにマウントされます。NFSデータストアをマウントするには、NFSサーバーIPが必要です。ここではeth1:0仮想フローティングインターフェイスです。
Hyperflexクラスターは、管理(eth0:mgmtip)とストレージデータ(eth1:0)の両方の仮想フローティングIPを使用します。上記2つのIPがそれぞれ1つの特定のストレージコントローラーVM (StCtlVM=SCVM) に割り当てられます。管理IPとストレージデータIPが、それぞれ異なるStCtlVMに紐づく可能性があることにご注意ください。
重要なのは、クラスタストレージデータIP (eth1:0) がHyperflexクラスタで作成されたデータストアをマウントするために使用されるということです。それゆえ、クラスタ内の全てのノードからこのIPへ到達可能とする必要があります。
eth1:0仮想IPを所有しているStCtlVMに障害が発生した場合は、FHRP (First Hop Redundancy Protocol) のように機能する、別の使用可能なStCtlVMにマイグレートする必要があります。

All Paths Downとは

APDは、ホストがストレージにアクセスできず、ストレージアレイからPermanent Device Lost (PDL) SCSIコードが返されないことを意味します。
パスダウンが一時的なものか不明であるため、ESXIはデフォルトの140秒以上(タイムアウト)+ 3分(フェイルオーバーの遅延)まで接続を確立しようと試みますが、それ以降も接続ができない場合、ストレージデバイスに送信される仮想マシン以外のI/Oトラフィックをfailさせます。
vSphere 6.x環境でのAPDに関する詳細については、Permanent Device Loss (PDL) and All-Paths-Down (APD) in vSphere 5.x and 6.x を参照してください。
以下の画像は、各々のステージに関する説明図です。

Screenshot 2019-05-28 at 1.25.11 AM.png

vCenterでの一般的なエラーメッセージは次の通りです。

Untitled picture.png

問題の説明

ホストにAPDアラートが表示されたら、問題を理解するために以下の情報を入手してください。

1つ/複数/全てのホストが影響を受けたかどうか、または特定のホストが影響を受けたかどうか
事象発生の前に、何らかの変更が行われていたかどうか(構成変更やアップグレード等)
問題が最初に発生した時と、問題が再発した時のタイムスタンプ

APD発生の潜在的な原因

APDは、主に以下のような原因により発生します。

ネットワークの問題

ネットワーク接続の喪失
高レイテンシ

MTU の不一致

HyperflexデータパスのMTUはジャンボフレームに設定する必要があります
ジャンボフレームでデータパス上の全てのIPアドレスにpingできることを確認してください。
icmpには28バイトのオーバーヘッドがあるため、pingテスト中にパケットサイズは8972に設定されます。
以下のコマンドで-M doを実行すると、DFビットが設定されます。
Controller VM で以下を実行
ping -M do -s 8972 <destination ip address>

IPアドレスの重複

不適切なACI設定

ESXiホストの問題

ハードウェア
ソフトウェア

コントローラVMの空き容量不足 (確認コマンド: df –h)

必要なサービスがnot runningとなっている (確認コマンド: storfs, scvm client)

トラブルシューティングワークフロー

APDのトラブルシューティングを行うには、vCenter、SCVM、およびESXiホストの3つのコンポーネントで何が発生していたか、詳しく調査する必要があります。

これらのステップはAll Paths Downの原因を特定するか、絞り込むためのワークフローです。

この順番に厳格に従う必要はないので、顧客環境で発生した特定の症状に従い、適切にご実施ください。

各コンポーネントごとの確認

vCenter Server

vCenter Server(VCS)に接続し、影響を受けているホストに移動します。

Related Objects -> Virtual Machinesで、StCtlVMがpower on かつ running であることを確認します。
Related Objects -> Datastoresで、NFSデータストアが"inaccessible"になっているかどうかを確認します。もしデータストアがアクセス可能な状態であれば、[Summary]タブでAPDイベントを「Reset to Green」にして、後でアラートが表示されるかどうかを確認します。
Monitor -> Issues and Monitor -> EventsではAPDが最初に発見された時の情報を提供します。

全てのStCtlVM

全てのStCtlVMに接続し、以下の点を確認してください。クライアントPCでWindowsを使用している場合、SSHクライアントとして、MobaXtermを使用することを推奨します。

1.dateまたはntpq -pを使用して、全てのStCtlVMの時間が同じであることを確認してください。 StCtlVMでの時間ずれは、zookeeperデータベースの同期に問題を引き起こす可能性があるため、全てのStCtlVM間で同期させることが最も重要です。

ntpサーバーの前のアスタリスク * 記号は、SCVMのNTPが同期されていることを示しています。

root@SpringpathControllerPZTMTRSH7K:~# date
Tue May 28 12:47:27 PDT 2019
root@SpringpathControllerPZTMTRSH7K:~# ntpq -p -4
remote refid st t when poll reach delay offset jitter
==============================================================================
*abcdefghij .GNSS. 1 u 429 1024 377 225.813 -1.436 0.176

2. アップグレード中にAPDが発生した場合は、完全にアップグレードされていないStCtlVMを確認し、特に最後に失敗したものを特定してください。最後に失敗したものが、ストレージデータVIPであるeth1:0を保持していた可能性があります。

springpathパッケージバージョンが混在するため、完全にアップグレードされなかったStCtlVMを識別するために、dpkg -l | grep -i springpathを使用します。

root@SpringpathControllerPZTMTRSH7K:~# dpkg -l | grep -i springpath
ii storfs-appliance 4.0.1a-33028            amd64 Springpath Appliance
ii storfs-asup 4.0.1a-33028                 amd64 Springpath ASUP and SCH
ii storfs-core 4.0.1a-33028                 amd64 Springpath Distributed Filesystem
ii storfs-fw 4.0.1a-33028                   amd64 Springpath Appliance
ii storfs-mgmt 4.0.1a-33028                 amd64 Springpath Management Software
ii storfs-mgmt-cli 4.0.1a-33028             amd64 Springpath Management Software
ii storfs-mgmt-hypervcli 4.0.1a-33028       amd64 Springpath Management Software
ii storfs-mgmt-ui 4.0.1a-33028              amd64 Springpath Management UI Module
ii storfs-mgmt-vcplugin 4.0.1a-33028        amd64 Springpath Management UI and vCenter Plugin
ii storfs-misc 4.0.1a-33028                 amd64 Springpath Configuration
ii storfs-pam 4.0.1a-33028                  amd64 Springpath PAM related modules
ii storfs-replication-services 4.0.1a-33028 amd64 Springpath Replication Services
ii storfs-restapi 4.0.1a-33028              amd64 Springpath REST Api's
ii storfs-robo 4.0.1a-33028                 amd64 Springpath Appliance
ii storfs-support 4.0.1a-33028              amd64 Springpath Support
ii storfs-translations 4.0.1a-33028         amd64 Springpath Translations

3. service_status.sh を実行し、全ての関連サービスが running 状態であるかを確認してください。

主要サービスには、Springpathファイルシステム(storfs)、SCVMクライアント(scvmclient)、システム管理サービス(stMgr)、クラスタIPモニター(cip-monitor)があります。

root@SpringpathController5L0GTCR8SA:~# service_status.sh
Springpath File System                 ... Running
SCVM Client                            ... Running
System Management Service              ... Running
HyperFlex Connect Server               ... Running
HyperFlex Platform Agnostic Service    ... Running
HyperFlex HyperV Service               ... Not Running
HyperFlex Connect WebSocket Server     ... Running
Platform Service                       ... Running
Replication Services                   ... Running
Data Service                           ... Running
Cluster IP Monitor                     ... Running
Replication Cluster IP Monitor         ... Running
Single Sign On Manager                 ... Running
Stats Cache Service                    ... Running
Stats Aggregator Service               ... Running
Stats Listener Service                 ... Running
Cluster Manager Service                ... Running
Self Encrypting Drives Service         ... Not Running
Event Listener Service                 ... Running
HX Device Connector                    ... Running
Web Server                             ... Running
Reverse Proxy Server                   ... Running
Job Scheduler                          ... Running
DNS and Name Server Service            ... Running
Stats Web Server                       ... Running

4. これらのサービスまたは他の関連サービスのいずれかが起動していない場合は、start <serviceName>を使用して起動します。例：start storfs

サービス名を取得するにはservice_status.shスクリプトを参照してください。head -n25 /bin/service_status.shを実行してサービスの実名を確認します。

root@SpringpathController5L0GTCR8SA:~# head -n25 /bin/service_status.sh
#!/bin/bash
declare -a upstart_services=("Springpath File System:storfs"\
                             "SCVM Client:scvmclient"\
                             "System Management Service:stMgr"\
                             "HyperFlex Connect Server:hxmanager"\
                             "HyperFlex Platform Agnostic Service:hxSvcMgr"\
                             "HyperFlex HyperV Service:hxHyperVSvcMgr"\
                             "HyperFlex Connect WebSocket Server:zkupdates"\
                             "Platform Service:stNodeMgr"\
                             "Replication Services:replsvc"\
                             "Data Service:stDataSvcMgr"\
                             "Cluster IP Monitor:cip-monitor"\
                             "Replication Cluster IP Monitor:repl-cip-monitor"\
                             "Single Sign On Manager:stSSOMgr"\
                             "Stats Cache Service:carbon-cache"\
                             "Stats Aggregator Service:carbon-aggregator"\
                             "Stats Listener Service:statsd"\
                             "Cluster Manager Service:exhibitor"\
                             "Self Encrypting Drives Service:sedsvc"\
                             "Event Listener Service:storfsevents"\
                             "HX Device Connector:hx_device_connector");
declare -a other_services=("Web Server:tomcat8"\
                           "Reverse Proxy Server:nginx"\
                           "Job Scheduler:cron"\
                           "DNS and Name Server Service:resolvconf");

5. ifconfig -aを使用して、ストレージクラスターIP(eth1:0)が含まれているStCtlVMを特定します。

StCtlVMにそのIPが含まれていない場合は、1つ/複数のノードでstorfsがnot runningの状態である可能性があります。

root@help:~# ifconfig
eth0:mgmtip Link encap:Ethernet HWaddr 00:50:56:8b:4c:90
inet addr:10.197.252.83 Bcast:10.197.252.95 Mask:255.255.255.224
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

6. StCtlVMがCRM Masterと通信しているかどうか、また、zookeeperサービスが稼働しているかどうかを確認します。

echo srvr | nc localhost 2181でモードがleader, follower, またはstandaloneであり、Connectionsの値が > 0であるかどうかを確認してください。

root@help:~# echo srvr | nc localhost 2181
Zookeeper version: 3.4.12-d708c3f034468a4da767791110332281e04cf6af, built on 11/19/2018 21:16 GMT
Latency min/avg/max: 0/0/137
Received: 229740587
Sent: 229758548
Connections: 13
Outstanding: 0
Zxid: 0x140000526c
Mode: leader
Node count: 3577

service exhibitor status または ps -ef | grep -i exhibitor

root@help:~# service exhibitor status
exhibitor start/running, process 12519
root@help:~# ps -ef | grep -i exhibitor
root 9765 9458 0 13:19 pts/14 00:00:00 grep --color=auto -i exhibitor
root 12519 1 0 May19 ? 00:05:49 exhibitor

エラーやサービスが実行されていない場合は、以下のログを確認してzookeeperサービスを開始してみてください。

　・/var/log/springpath/exhibitor.log and /var/log/springpath/stMgr.log

　・service exhibitor start to start zookeeper service

7. vCenterが全てのStCtlVMから到達可能かどうかを確認します。

stcli cluster info | grep -i "url"でVCのFQDNまたはIPを含むURLを表示します。vCenterへ接続可能かをping <vCenter_IP>で確認します。

root@help:~# stcli cluster info | grep -i "url"
vCenterUrl: https://10.197.252.101
vCenterURL: 10.197.252.101
root@help:~# ping 10.197.252.101
PING 10.197.252.101 (10.197.252.101) 56(84) bytes of data.
64 bytes from 10.197.252.101: icmp_seq=1 ttl=64 time=0.435 ms

8. FQDNを利用するクラスタの場合、DNSが到達可能かどうかを確認します。

stcli services dns showで StCtlVMに設定されたDNSサーバーを表示します。ping <DNS_IP>とhost <FQDN> <DNS_IP>を使用してDNSサーバーへの接続と名前解決をテストします。

root@help:~# stcli services dns show
1.1.128.140
root@help:~# ping 1.1.128.140
PING 1.1.128.140 (1.1.128.140) 56(84) bytes of data.
64 bytes from 1.1.128.140: icmp_seq=1 ttl=244 time=1.82 ms

9. 全てのStCtlVMに同じ数のiptablesエントリがあるかどうかを確認します。 iptables -L | wc -l

一致しない場合、TACへケースをOpenしてください。

root@SpringpathControllerI51U7U6QZX:~# iptables -L | wc -l
48

10. 現在のクラスタのステータスと正常性を確認します。

stcli cluster info | less または stcli cluster info | grep -i "active\|state\|unavailable"でstorage unavailableとなったノードを特定できます。

root@SpringpathControllerI51U7U6QZX:~# stcli cluster info | grep -i "active\|state\|unavailable"
locale: English (United States)
state: online
upgradeState: ok
healthState: healthy
state: online
state: 1
activeNodes: 3
state: online

stcli cluster storage-summary --detailでストレージクラスタの詳細が確認できます。

root@SpringpathControllerI51U7U6QZX:~# stcli cluster storage-summary --detail
address: 10.197.252.106
name: HX-Demo
state: online
uptime: 185 days 12 hours 48 minutes 42 seconds
activeNodes: 3 of 3
compressionSavings: 85.45%
deduplicationSavings: 0.0%
freeCapacity: 4.9T
healingInfo:
inProgress: False
resiliencyDetails:
current ensemble size:3
# of caching failures before cluster shuts down:3
minimum cache copies remaining:3
minimum data copies available for some user data:3
minimum metadata copies available for cluster metadata:3
# of unavailable nodes:0
# of nodes failure tolerable for cluster to be available:1
health state reason:storage cluster is healthy.
# of node failures before cluster shuts down:3
# of node failures before cluster goes into readonly:3
# of persistent devices failures tolerable for cluster to be available:2
# of node failures before cluster goes to enospace warn trying to move the existing data:na
# of persistent devices failures before cluster shuts down:3
# of persistent devices failures before cluster goes into readonly:3
# of caching failures before cluster goes into readonly:na
# of caching devices failures tolerable for cluster to be available:2
resiliencyInfo:
messages:
Storage cluster is healthy.
state: 1
nodeFailuresTolerable: 1
cachingDeviceFailuresTolerable: 2
persistentDeviceFailuresTolerable: 2
zoneResInfoList: None
spaceStatus: normal
totalCapacity: 5.0T
totalSavings: 85.45%
usedCapacity: 85.3G
zkHealth: online
clusterAccessPolicy: lenient
dataReplicationCompliance: compliant
dataReplicationFactor: 3

11. どのデータストアがマウントされて、使用可能かどうかの状況を確認します。

root@bsv-hxaf220m5-sc-4-3:~# stcli datastore list
----------------------------------------
virtDatastore:
    status:
        EntityRef(idtype=None, confignum=None, type=6, id='235ea35f-6c85-9448-bec7-06f03b5adf16', name='bsv-hxaf220m5-hv-4-3.cisco.com'):
            accessible: True
            mounted: True
        EntityRef(idtype=None, confignum=None, type=6, id='d124203c-3d9a-ba40-a229-4dffbe96ae13', name='bsv-hxaf220m5-hv-4-2.cisco.com'):
            accessible: True
            mounted: True
        EntityRef(idtype=None, confignum=None, type=6, id='e85f1980-b3c7-a440-9f1e-20d7a1110ae6', name='bsv-hxaf220m5-hv-4-1.cisco.com'):
            accessible: True
            mounted: True

12. stcliコマンドの実行に時間がかかりすぎたり、失敗する場合は、下記のsysmtoolコマンドを試してください（stcliが機能する場合は使用しないでください）。

sysmtool --ns cluster --cmd info
sysmtool --ns cluster --cmd healthdetail
sysmtool --ns datastore --cmd list

影響を受けたESXiホスト上で動作しているStCtlVM

影響を受けたESXiホストのStCtlVMに接続します。

1. ストレージクラスタIP(eth1:0)およびストレージネットワーク上の他のサーバー (StCtlVMのeth1) への接続を確認します。

stcli cluster info | grep -i -B 1 "stctl\|hypervisor" で全てのESXi管理IP、StCtlVM eth0(Mgmt)およびStCtlVM eth1(ストレージデータ)がクラスタに参加していることを確認します。
ping –I eth1 [–M do –s 8972] <target IP address>で接続性を確認します。ESXI VMK1と SCVM eth1の間のジャンボフレームをテストします。

2. 問題が特定できない場合、下記ログを確認します。

/var/log/springpath/debug-storfs.log
grep -ai "segmentation\|critical\|panic" debug-storfs.logでパニックやsegフォルトやクリティカルなイベントがあるかどうかを確認します。
/var/log/springpath/stmgr.log
grep -i "oom\|out of mem" /var/log/kern.logでout of memoryがあるかどうかを確認します。

3. 最終手段として、問題発生中のノード上のStCtlVMを再起動し、問題が解決するかを確認してください。

ESXiホストで確認

影響を受けたESXiホストにSSH接続し、次の操作を実行します。

1. esxcli storage nfs list または esxcfg-nas -l で現在マウントされているNFSデータストアをリストし、それらがアクセス可能かどうかを確認します。

[root@bsv-hx220m5-hv-4-3:~] esxcli storage nfs list
Volume Name  Host                                     Share                 Accessible  Mounted  Read-Only   isPE  Hardware Acceleration
-----------  ---------------------------------------  --------------------  ----------  -------  ---------  -----  ---------------------
test         8352040391320713352-8294044827248719091  192.168.4.1:test            true     true      false  false  Supported
sradzevi     8352040391320713352-8294044827248719091  192.168.4.1:sradzevi        true     true      false  false  Supported
[root@bsv-hx220m5-hv-4-3:~] esxcfg-nas -l
test is 192.168.4.1:test from 8352040391320713352-8294044827248719091 mounted available
sradzevi is 192.168.4.1:sradzevi from 8352040391320713352-8294044827248719091 mounted available

cat /etc/vmware/esx.conf | grep -I nasで /etc/vmware/esx.confからNFSマウントデータストア上にあるESXi構成の整合性を確認することもできます。

2. /var/log/vmkernel.logを確認し、前の手順で確認できたタイムスタンプの前後にfailed state、mount problems またはerrorを探します。

3. IOVisor/NFS Proxy/SCVMClientのステータスを確認します。

/etc/init.d/scvmclient statusでESXI上でサービスが稼働しているかどうかを確認します。
[Optional]esxcli network ip connection list | grep -i "proto\|scvmclient"でオープン接続があるかどうかを確認できます。
esxcli software vib list | grep -i springでSCVMClient VIBがHX clusterと同じバージョンであるかどうかを確認します。

[root@bsv-hx220m5-hv-4-3:~] esxcli software vib list | grep -i spring
scvmclient                     3.5.1a-31118                         Springpath          VMwareAccepted    2018-12-13
stHypervisorSvc                3.5.1a-31118                         Springpath          VMwareAccepted    2018-12-06
vmware-esx-STFSNasPlugin       1.0.1-21                             Springpath          VMwareAccepted    2018-11-16

/var/log/scvmclient.logから”unable to obtain clustermap”のようなエラーがあるかどうかを確認します。
必要に応じてetc/init.d/scvmclient restartでSCVMClient serviceを再起動することも可能です。

4. vmk1ネットワーク上の他のESXiホストとの接続、特にストレージクラスタIP eth1:0とのネットワーク接続を確認します。

esxcfg-vmknic -lでvmk nicの詳細(IP、subnetmask、MTU等)
vmkping -I vmk1 [-v -s 8972] -d <target IP address>でコントローラデータネットワーク上のESXiホスト間の接続性(オプションでジャンボフレームあり)をテストします。

5. esxcli hardware platform getでStCtlVmの名前で使用されるサーバのシリアル番号を取得し、特定のStCtlVMがどのホストで稼働しているかをすばやく確認できます。

APD Logging

APDに関連するログは、以下を参照してください。

ESXI Logs

- /var/run/log/vmkernel.log

- /var/run/log/vobd.log (詳細内容が確認できます)

Controller logs

- /var/log/syslog

- /var/log/debug-storfs.log

- /cmds_output/service_status.sh

注意：

SCVM Clientプロセスステータスは、ローカルコントローラプロセスではなくesxiホスト上のプロセスのステータスを示します。

root@SpringpathController4DYKNI85TP:~# service_status.sh
Springpath File System ... Running
SCVM Client ... Running
System Management Service ... Running
HyperFlex Connect Server ... Running
HyperFlex Platform Agnostic Service ... Running
HyperFlex HyperV Service ... Not Running
HyperFlex Connect WebSocket Server ... Running
Platform Service ... Running
Replication Services ... Not Running
Data Service ... Not Running
Cluster IP Monitor ... Running
Replication Cluster IP Monitor ... Not Running
Single Sign On Manager ... Running
Stats Cache Service ... Running
Stats Aggregator Service ... Running
Stats Listener Service ... Running
Cluster Manager Service ... Running
Self Encrypting Drives Service ... Running
Event Listener Service ... Running
HX Device Connector ... Running
Web Server ... Running
Reverse Proxy Server ... Running
Job Scheduler ... Running
DNS and Name Server Service ... Running
Stats Web Server ... Running