Hyperflexクラスタのパフォーマンス問題のトラブルシューティング
内容
概要
このドキュメントでは、ゲスト仮想マシン(VM)、ESXiホスト、および(SCVM)の観点から、hyperflex環境におけるパフォーマンスの影響について説明します
特定
Hyperflex環境でパフォーマンスのトラブルシューティングを行うには、クラスタのタイプ、パフォーマンスが低下するオペレーション、パフォーマンス低下の頻度、パフォーマンス低下を引き起こすパフォーマンスへの影響のレベルを特定することが重要です。
Hyperflexクラスタには、ゲストVM、ESXIホストレベル、およびストレージコントローラVMレベルで複数のレベルの影響があります。
クラスタタイプ
●ハイブリッドノード：ソリッドステートドライブ(SSD)をキャッシングに使用し、HDDを容量レイヤに使用します。
● オールフラッシュノード：キャッシングにはSSDドライブまたは不揮発性メモリExpress(NVMe)ストレージを使用し、キャパシティレイヤにはSSDドライブを使用します。
●全NVMeノード：NVMeストレージをキャッシングとキャパシティレイヤの両方に使用します。全NVMeノードは、最も要求の厳しいワークロードに対してキャッシングにより最高のパフォーマンスを提供します。
パフォーマンスグラフの説明
Hyperflexシステムにはパフォーマンスを監視する機能があり、グラフにはストレージ・クラスタの読み取り/書き込みパフォーマンスが表示されます。
IOPS
Input/Output Operations per second(IOPS)は、HDDを含むコンピュータストレージデバイスの測定に使用される一般的なパフォーマンスメトリックです。このメトリックは、ランダムI/Oワークロードのパフォーマンスを評価するために使用されます。
IOPSパフォーマンスグラフ。
スループット
この図は、ストレージクラスタ内のデータ転送速度をMbps単位で示しています。
スループットパフォーマンスのグラフ
遅延
遅延は、1つのI/O要求が完了するまでにかかる時間の尺度です。要求を発行してから応答を受信するまでの時間をミリ秒単位で測定します。
遅延パフォーマンスグラフ。
周波数
環境に与える可能性のある影響を確認するには、パフォーマンスへの影響の頻度と期間を定義することが重要です。
パフォーマンスが常に影響を受ける場合は、パフォーマンスの低下が始まった場所を確認し、クラスタ間の設定変更や問題を確認する必要があります。
パフォーマンスが断続的に影響を与えている場合は、その時点で動作またはサービスが実行されているかどうかを確認する必要があります。
外部要因
クラスタのパフォーマンスは、スナップショットやバックアップ操作などの外部要因の影響を受ける可能性があります。
外部要因の詳細については、次のリンクを参照してください。
VMware vSphereスナップショット：パフォーマンスとベストプラクティス。
Cisco HyperFlex SystemsおよびVeeam Backup and Replicationホワイトペーパー
ゲストVMレベルでのパフォーマンスの問題の特定
これは、hyperflex環境で最も顕著な影響レベルであり、VMが提供しているサービスに直接影響を与え、直接影響を受けるユーザではより明確です。
一般的なオペレーティングシステムのパフォーマンスを確認するための一般的なテストを次に示します。
Windows
WindowsゲストVMのパフォーマンスの問題を特定するために使用可能なツールを確認します。
ESXi
パフォーマンスへの影響を特定し、パフォーマンス低下の考えられる原因を検討した後、パフォーマンスを改善するためのパフォーマンスチェックをいくつか行います。
- オーバープロビジョニングをチェックします（すべてのVMに割り当てられるvCPUの総数は、ESXiホストマシンで使用可能な物理コアの総数を超えることはできません）。
- ゲストOSがvCPUの一部を使用しない場合でも、これらのvCPUを使用してVMを設定すると、ESXiに若干のリソース要件が課され、それがホストの実際のCPU消費に変換されます。
- また、メモリを過剰に割り当てると、VMのメモリオーバーヘッドが不必要に増加し、特に予約が使用されている場合にメモリ競合の原因となる可能性があります。
- バルーンドライバがメモリを保持していないことを確認します。詳細については、このリンクを参照してください。
「ESX/ESXi仮想マシンのパフォーマンス問題のトラブルシューティング」を参照してください。
PVSCSIチェック
Paravirtual SCSI (PVSCSI)アダプタは、ディスクI/O要件の高い仮想マシンに対してスループットの向上とCPU使用率の低下を実現できる高性能のストレージアダプタです。PVSCSIアダプタの使用を推奨します。PVSCSIコントローラは、仮想化対応の高性能SCSIアダプタであり、CPUオーバーヘッドを最小限に抑えながら、遅延を最小限に抑え、スループットを最大限に高めることができます。
PVSCSIアダプタ。
ネットワークアダプタの確認
VMXNET 3は、パフォーマンスを重視して設計された疑似仮想化NICで、ジャンボフレーム、マルチキューサポート（Windowsでは受信側スケーリングとも呼ばれる）、IPv6オフロード、およびMSI/MSI-X割り込み配信とハードウェアオフロードなど、最近のネットワークで一般的に使用される高パフォーマンス機能を提供します。
アダプタタイプがVMXNET3であることを確認します。
ネットワークアダプタ。
RSSチェック
注：このチェックは、Windowsオペレーティングシステムを実行しているゲスト仮想マシンにのみ適用されます。
受信側スケーリング(RSS)は、マルチプロセッサシステムの複数のCPUにネットワーク受信処理を効率的に分散できるようにするネットワークドライバテクノロジーです。
Windowsサーバには、カーネルモードのネットワーク処理の負荷を複数のCPUに分散できるようにするドライバ設定があります。
これが有効になっているかどうかを確認するには、Windows PowerShellで次のコマンドを実行します。
netsh interface tcp set global rss=enabledRSSを有効にするには、このリンクを確認してください
CPUホットプラグチェック
CPUホットプラグは、VM管理者が電源を切らずにVMにCPUを追加できるようにする機能です。これにより、サービスを中断することなく、稼働中にCPUリソースを追加できます。CPUホットプラグがVMで有効な場合、vNUMA機能は無効になります。
CPUホットプラグは無効です。
一般的なオペレーティングシステムとアプリケーションのベストプラクティスを確認します。
Windows.
Windows Server 2022のパフォーマンスチューニングガイドライン。
Red Hat.
Linuxプロセスのパフォーマンス向上のための3つのヒント（優先度と親和性）。
SQL Server.
VMwareでのMicrosoft SQL Serverの設計
RedHat
ホストレベルでのパフォーマンスの問題の特定
パフォーマンスへの影響をホスト・レベルで特定するには、ESXIホストに組み込まれているESXIハイパーバイザのパフォーマンス・グラフを確認し、影響を受けるホストの数を確認します。
vCenterのパフォーマンスグラフは、[モニタ]タブで[パフォーマンス]タブをクリックして表示できます。
vCenterパフォーマンスグラフ。
これらのグラフでは、CPU、メモリ、およびディスクに関連するパフォーマンスグラフを表示できます。チャートについては、このリンクを参照してください。
注：特にストレージネットワークでのCRCエラーとMTUの不一致により、遅延の問題が発生します。 ストレージトラフィックはジャンボフレームを使用する必要があります。
ストレージI/Oコントロールとキューの深さのチェック
ストレージI/O制御(SIOC)は、仮想マシンのI/O使用率を制御し、事前定義されたI/O共有レベルを徐々に適用するために使用されます。この機能をHyperflexクラスタで無効にする必要があります。
キューの深さは、ストレージリソースが一度に処理できる保留中の入出力(I/O)要求の数です。
次の手順を使用して、SIOCが無効になっていることと、キュー項目数の設定を確認できます。
SIOCがESXiで実行されていることとキューの深さの設定を確認します。
ステップ 1：HX ESXiホストにSSHで接続し、データストアを一覧表示するコマンドを発行します。
[root@] vsish -e ls /vmkModules/nfsclient/mnt
encrypted_app/
Prod/ <----- Datastore name
Dev/
App/ステップ 2：データストア名を使用して、コマンドを発行します。
vsish -e get /vmkModules/nfsclient/mnt/
/properties [root@] vsish -e get /vmkModules/nfsclient/mnt/Prod/properties mount point information { volume name:Prod server name:7938514614702552636-8713662604223381594 server IP:127.0.0.1 server volume:172.16.3.2:Prod UUID:63dee313-dfecdf62 client src port:641 busy:0 socketSendSize:1048576 socketReceiveSize:1048576 maxReadTransferSize:65536 maxWriteTransferSize:65536 reads:0 readsFailed:0 writes:285 writesFailed:0 readBytes:0 writeBytes:10705 readTime:0 writeTime:4778777 readSplitsIssued:0 writeSplitsIssued:285 readIssueTime:0 writeIssueTime:4766494 cancels:0 totalReqsQueued:0 metadataReqsQueued(non IO):0 reqsInFlight:0 readOnly:0 hidden:0 isPE:0 isMounted:1 isAccessible:1 unstableWrites:0 unstableNoCommit:0 maxQDepth:1024 <-------- Max Qdepth configuration iormState:0 <-------- I/O control disabled latencyThreshold:30 shares:52000 podID:0 iormInfo:0 NFS operational state: 0 -> Up enableDnlc:1 closeToOpenCache:0 highToAvgLatRatio:10 latMovingAvgSmoothingLevel:2 activeWorlds:55 inPreUnmount:0 }
ステップ 3：出力で、次の行を探します。
iormState:0 0= disabled 2= enabledmaxQDepthの行は1024でなければなりません
ステップ 4：残りのデータストアについても同じ手順を繰り返す必要があります
SIOCの無効化
SIOCを無効にするには、次の手順を実行します。
ステップ 1：HTMLクライアントを使用してvsphereにログインします。
ステップ2：ドロップダウンメニューからStorageを選択し、左側のペインで該当するHX Datastoreを選択します。
データストアを選択します。
ステップ 3： データストアの右側のペインの上部セクションで、configureタブを選択します。
[設定]タブ：
ステップ 4： 右側のペインの中央のセクションで、[More]の下の[General]を選択し、右側で[DataStore Capabilities]までスクロールダウンして[Edit]をクリックします
データストア機能の編集
Disable Storage I/O Control and Statistics collectionオプションボタンがオフになっている場合は、これをチェックします。
ストレージのI/O制御を無効にします。
[Disable Storage I/O Control and statistics collection]ラジオ・ボタンをオンにした場合は、[Enable Storage I/O Control and statistics collection]と[Disable Storage I/O Control and statistics collection]を切り替えます。
ストレージI/Oコントロールが無効になっています。
ステップ 5：必要に応じて、他のすべてのデータストアに対して手順1 ～ 4を繰り返します。
MaxQDepthの変更
maxQDepthを変更するには、データストアごとにnextコマンドを発行します。
vsish -e set /vmkModules/nfsclient/mnt/
/properties maxQDepth 1024
Rx_no_Buffのチェック
ネットワークトラフィックが多いHyperFlexサーバや、マイクロバーストを伴うネットワークトラフィックは、rx_no_bufsの形式でパケット損失を引き起こす可能性があります。
この問題を特定するには、ESXiホストで次のコマンドを実行してrx_no_bufカウンタを確認します。
/usr/lib/vmware/vm-support/bin/nicinfo.sh | egrep "^NIC:|rx_no_buf"
NIC: vmnic0
rx_no_bufs: 1
NIC: vmnic1
rx_no_bufs: 2
NIC: vmnic2
rx_no_bufs: 2
NIC: vmnic3
rx_no_bufs: 71128211 <---------Very high rx_no_bufs counter
NIC: vmnic4
rx_no_bufs: 1730
NIC: vmnic5
rx_no_bufs: 897
NIC: vmnic6
rx_no_bufs: 24952
NIC: vmnic7
rx_no_bufs: 2
数分待ってからコマンドを再度実行し、rx_no_bufsカウンタが増加していないかどうかを確認します。
- これらのカウンタの値が低い（1,000未満）場合は、デフォルトのキュー設定によるパケット損失がほとんどなく、チューニングは必要ない可能性があります。
- これらのカウンタの値が高い(> 10,000)場合は、このキューの設定による影響があり、調整が少し役立つ可能性があります。
- これらのカウンタの値が非常に高い(> 1,000,000)場合は、さらに大きな影響があるため、キューを増やすことを強くお勧めします。
- rx_no_bufsがアクティブに増加している場合、これはパケットがネットワーク全体に到達し、仮想層に到達した後、パケットがドロップされることを意味します。
これらの値にカウンタが表示される場合は、パフォーマンス向上のためにvNIC設定を調整するためにCisco TACにお問い合わせください。
ESXIレベルでベストプラクティスとその他のチェックを確認します。
VMware vSphere 7.0のパフォーマンスのベストプラクティス
パフォーマンスの問題の特定ストレージコントローラ仮想マシン(SCVM)レベル
クラスタの状態
クラスタが正常かどうかを確認します。
hxshell:~$ sysmtool --ns cluster --cmd healthdetail
Cluster Health Detail:
---------------------:
State: ONLINE <---------- State of the cluster
HealthState: HEALTHY <---------- Health of the cluster
Policy Compliance: COMPLIANT
Creation Time: Tue May 30 04:48:45 2023
Uptime: 7 weeks, 19 hours, 45 mins, 51 secs
Cluster Resiliency Detail:
-------------------------:
Health State Reason: Storage cluster is healthy.
# of nodes failure tolerable for cluster to be fully available: 1
# of node failures before cluster goes into readonly: NA
# of node failures before cluster goes to be crticial and partially available: 3
# of node failures before cluster goes to enospace warn trying to move the existing data: NA
# of persistent devices failures tolerable for cluster to be fully available: 2
# of persistent devices failures before cluster goes into readonly: NA
# of persistent devices failures before cluster goes to be critical and partially available: 3
# of caching devices failures tolerable for cluster to be fully available: 2
# of caching failures before cluster goes into readonly: NA
# of caching failures before cluster goes to be critical and partially available: 3
Current ensemble size: 3
Minimum data copies available for some user data: 3
Minimum cache copies remaining: 3
Minimum metadata copies available for cluster metadata: 3
Current healing status:
Time remaining before current healing operation finishes:
# of unavailable nodes: 0
hxshell:~$
この出力は、ノードが使用できないためにクラスタが正常に動作していないことを示しています。
hxshell:~$ sysmtool --ns cluster --cmd healthdetail
Cluster Health Detail:
---------------------:
State: ONLINE <-------State of the cluster
HealthState: UNHEALTHY <-------Health of the cluster
Policy Compliance: NON-COMPLIANT
Creation Time: Tue May 30 04:48:45 2023
Uptime: 7 weeks, 19 hours, 55 mins, 9 secs
Cluster Resiliency Detail:
-------------------------:
Health State Reason: Storage cluster is unhealthy.Storage node 172.16.3.9 is unavailable. <----------- Health state reason
# of nodes failure tolerable for cluster to be fully available: 0
# of node failures before cluster goes into readonly: NA
# of node failures before cluster goes to be crticial and partially available: 2
# of node failures before cluster goes to enospace warn trying to move the existing data: NA
# of persistent devices failures tolerable for cluster to be fully available: 1
# of persistent devices failures before cluster goes into readonly: NA
# of persistent devices failures before cluster goes to be critical and partially available: 2
# of caching devices failures tolerable for cluster to be fully available: 1
# of caching failures before cluster goes into readonly: NA
# of caching failures before cluster goes to be critical and partially available: 2
Current ensemble size: 3
Minimum data copies available for some user data: 2
Minimum cache copies remaining: 2
Minimum metadata copies available for cluster metadata: 2
Current healing status: Rebuilding/Healing is needed, but not in progress yet. Warning: Insufficient node or space resources may prevent healing. Storage Node 172.16.3.9 is either down or initializing disks.
Time remaining before current healing operation finishes:
# of unavailable nodes: 1
hxshell:~$
この出力は、再構築が原因の異常なクラスタを示しています。
Cluster Health Detail:
---------------------:
State: ONLINE
HealthState: UNHEALTHY
Policy Compliance: NON-COMPLIANT
Creation Time: Tue May 30 04:48:45 2023
Uptime: 7 weeks, 20 hours, 2 mins, 4 secs
Cluster Resiliency Detail:
-------------------------:
Health State Reason: Storage cluster is unhealthy.
# of nodes failure tolerable for cluster to be fully available: 1
# of node failures before cluster goes into readonly: NA
# of node failures before cluster goes to be crticial and partially available: 2
# of node failures before cluster goes to enospace warn trying to move the existing data: NA
# of persistent devices failures tolerable for cluster to be fully available: 1
# of persistent devices failures before cluster goes into readonly: NA
# of persistent devices failures before cluster goes to be critical and partially available: 2
# of caching devices failures tolerable for cluster to be fully available: 1
# of caching failures before cluster goes into readonly: NA
# of caching failures before cluster goes to be critical and partially available: 2
Current ensemble size: 3
Minimum data copies available for some user data: 3
Minimum cache copies remaining: 2
Minimum metadata copies available for cluster metadata: 2
Current healing status: Rebuilding is in progress, 58% completed.
Time remaining before current healing operation finishes: 18 hr(s), 10 min(s), and 53 sec(s)
# of unavailable nodes: 0これらのコマンドは、クラスタの全体的な健全性の概要を表示し、クラスタの動作に影響を与えているものがあるかどうか（たとえば、ブラックリストに登録されているディスクがあるかどうか、オフラインノードがあるかどうか、クラスタが修復されているかどうかなど）を通知します。
I/Oに参加しているノード
入出力操作に参加していないノードによってパフォーマンスが影響を受ける可能性があります。I/Oに参加しているノードを確認するには、次のコマンドを発行します。
ステップ 1：ストレージコントローラVMの診断シェルに入ります。
hxshell:~$ su diag
Password:
_ _ _ _ _ _____ _ ___
| \ | (_)_ __ ___ | || | | ___(_)_ _____ / _ \ _ __ ___
| \| | | '_ \ / _ \ _____ | || |_ _____ | |_ | \ \ / / _ \ _____ | | | | '_ \ / _ \
| |\ | | | | | __/ |_____| |__ _| |_____| | _| | |\ V / __/ |_____| | |_| | | | | __/
|_| \_|_|_| |_|\___| |_| |_| |_| \_/ \___| \___/|_| |_|\___|
Enter the output of above expression: -1
Valid captcha
ステップ2：このコマンドを発行して、I/O処理に参加しているノードを確認します。IPの数は、クラスタ上のコンバージドノードの数と等しくなければなりません。
diag# nfstool -- -m | cut -f2 | sort | uniq
172.16.3.7
172.16.3.8
172.16.3.9内部サービスチェック
クリーナ
クリーナーの主な目的の1つは、システム内の死んだストレージブロックと生きているストレージブロックを識別し、死んだものを取り除き、それらによって占有されたストレージスペースを解放することです。これはバックグラウンドジョブであり、その攻撃性はポリシーに基づいて設定されます。
次のコマンドを発行して、クリーナサービスを確認できます。
bash-4.2# stcli cleaner info
{ 'name': '172.16.3.7', 'id': '1f82077d-6702-214d-8814-e776ffc0f53c', 'type': 'node' }: OFFLINE <----------- Cleaner shows as offline
{ 'name': '172.16.3.8', 'id': 'c4a24480-e935-6942-93ee-987dc8e9b5d9', 'type': 'node' }: OFFLINE
{ 'name': '172.16.3.9', 'id': '50a5dc5d-c419-9c48-8914-d91a98d43fe7', 'type': 'node' }: OFFLINE
クリーナプロセスを開始するには、次のコマンドを発行します。
bash-4.2# stcli cleaner start
WARNING: This command should be executed ONLY by Cisco TAC support as it may have very severe consequences. Do you want to proceed ? (y/n): y
bash-4.2# stcli cleaner info
{ 'type': 'node', 'id': '1f82077d-6702-214d-8814-e776ffc0f53c', 'name': '172.16.3.7' }: ONLINE
{ 'type': 'node', 'id': 'c4a24480-e935-6942-93ee-987dc8e9b5d9', 'name': '172.16.3.8' }: ONLINE
{ 'type': 'node', 'id': '50a5dc5d-c419-9c48-8914-d91a98d43fe7', 'name': '172.16.3.9' }: ONLINE <---------All nodes need to be online
bash-4.2# 
注意：このコマンドはCisco TACの承認を得て実行する必要があります。
再調整
ストレージクラスタは定期的なスケジュールでリバランスされます。これは、使用可能なストレージ内の変更に対する保存データの分散を再調整し、ストレージクラスタの状態を復元するために使用されます。
リバランスは、さまざまな理由でクラスタ内で実行されます。
- 物理リソース（ノード/ディスク）がダウンし、HXがそれらのVnodeをクラスタ内の別の物理リソースに再配置しています。
- クラスタ内の個々のドライブはすべて比較可能に使用されているわけではないため、HXクラスタ内のデータ可用性（データのコロケーション）に関してホットスポットが作成されています。
- リバランスは、クラスタが正常であってもゾーンのコンプライアンスが存在しない場合にも実行できます。
- 既存のクラスタに新しいノードが追加されると、追加されたノードは既存のクラスタに参加するとすぐに新しい書き込みを行います。
クラスタでリバランスが有効になっていることを確認します。
hxshell:~$ stcli rebalance status
rebalanceStatus:
percentComplete: 0
rebalanceState: cluster_rebalance_not_running
rebalanceEnabled: True <---------Rebalance should be enabled
hxshell:~$
注意：リバランスに関連するすべての操作は、Cisco TACの承認を得て行う必要があります。
ディスク障害
正しく動作するためには、クラスタにブラックリストに登録されたディスクやオフラインリソースが存在してはなりません。
HX Connectインターフェイスのクラスタにブラックリストに登録されたディスクがあるかどうかを確認する必要があります。
ブラックリストに登録されたディスク
CLIで、各コンバージェンスノードのオフラインリソースを確認します。
sysmtool --ns cluster --cmd offlineresources
UUID Type State InUse Last modified
---- ---- ----- ----- -------------
000cca0b019b4a80:0000000000000000 DISK DELETED YES <------- Offline disk
5002538c405e0bd1:0000000000000000 DISK BLOCKLISTED NO <------- Blacklisted disk
5002538c405e299e:0000000000000000 DISK DELETED NO
Total offline resources: 3, Nodes: 0, Disks: 3ブラックリストに登録されているリソースがあるかどうかを確認します。
hxshell:~$ sysmtool --ns disk --cmd list | grep -i blacklist
Blacklist Count: 0
Blacklist Count: 0
Blacklist Count: 0
Blacklist Count: 0
State: BLACKLISTED
Blacklist Count: 5
Blacklist Count: 0
Blacklist Count: 0
次のコマンドを使用して、各コンバージェンスノードに障害ディスクがあるかどうかを確認する必要があります。
admin:~$ cat /var/log/springpath/diskslotmap-v2.txt
0.0.1:5002538e000d59a3:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M302248:HXT76F3Q:SATA:SSD:3662830:Inactive:/dev/sdj <---------Inactive disk
1.0.2:5002538c40be79ac:Samsung:SAMSUNG_MZ7LM240HMHQ-00003:S4EGNX0KC04551:GXT51F3Q:SATA:SSD:228936:Active:/dev/sdb
1.0.3:5002538e000d599e:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M302243:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sdc
1.0.4:5002538e000d59a0:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M302245:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sdd
1.0.5:5002538e000eb00b:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M302480:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sdi
1.0.6:5002538e000d599b:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M302240:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sdf
1.0.7:5002538e000d57f6:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M301819:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sdh
1.0.8:5002538e000d59ab:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M302256:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sde
1.0.9:5002538e000d59a1:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M302246:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sdg
1.0.10:5002538e0008c68f:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M200500:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sdj
0.1.192:000cca0b01c83180:HGST:UCSC-NVMEHW-H1600:SDM000026904:KNCCD111:NVMe:SSD:1526185:Active:/dev/nvme0n1
admin:~$ディスク障害のないノードの例。
hxshell:~$ sysmtool --ns cluster --cmd offlineresources
No offline resources found <-------- No offline resources
hxshell:~$ sysmtool --ns disk --cmd list | grep -i blacklist
hxshell:~$ <-------- No blacklisted disks
hxshell:~$ cat /var/log/springpath/diskslotmap-v2.txt
1.14.1:55cd2e404c234bf9:Intel:INTEL_SSDSC2BX016T4K:BTHC618505B51P6PGN:G201CS01:SATA:SSD:1526185:Active:/dev/sdc
1.14.2:5000c5008547c543:SEAGATE:ST1200MM0088:Z4009D7Y0000R637KMU7:N0A4:SAS:10500:1144641:Active:/dev/sdd
1.14.3:5000c5008547be1b:SEAGATE:ST1200MM0088:Z4009G0B0000R635L4D3:N0A4:SAS:10500:1144641:Active:/dev/sde
1.14.4:5000c5008547ca6b:SEAGATE:ST1200MM0088:Z4009F9N0000R637JZRF:N0A4:SAS:10500:1144641:Active:/dev/sdf
1.14.5:5000c5008547b373:SEAGATE:ST1200MM0088:Z4009GPM0000R634ZJHB:N0A4:SAS:10500:1144641:Active:/dev/sdg
1.14.6:5000c500854310fb:SEAGATE:ST1200MM0088:Z4008XFJ0000R6374ZE8:N0A4:SAS:10500:1144641:Active:/dev/sdh
1.14.7:5000c50085424b53:SEAGATE:ST1200MM0088:Z4008D2S0000R635M4VF:N0A4:SAS:10500:1144641:Active:/dev/sdi
1.14.8:5000c5008547bcfb:SEAGATE:ST1200MM0088:Z4009G3W0000R637K1R8:N0A4:SAS:10500:1144641:Active:/dev/sdj
1.14.9:5000c50085479abf:SEAGATE:ST1200MM0088:Z4009J510000R637KL1V:N0A4:SAS:10500:1144641:Active:/dev/sdk
1.14.11:5000c5008547c2c7:SEAGATE:ST1200MM0088:Z4009FR00000R637JPEQ:N0A4:SAS:10500:1144641:Active:/dev/sdl
1.14.13:5000c5008547ba93:SEAGATE:ST1200MM0088:Z4009G8V0000R634ZKLX:N0A4:SAS:10500:1144641:Active:/dev/sdm
1.14.14:5000c5008547b69f:SEAGATE:ST1200MM0088:Z4009GG80000R637KM30:N0A4:SAS:10500:1144641:Active:/dev/sdn
1.14.15:5000c5008547b753:SEAGATE:ST1200MM0088:Z4009GH90000R635L5F6:N0A4:SAS:10500:1144641:Active:/dev/sdo
1.14.16:5000c5008547ab7b:SEAGATE:ST1200MM0088:Z4009H3P0000R634ZK8T:N0A4:SAS:10500:1144641:Active:/dev/sdp <------All disks are active
hxshell:~$
Free Memory
次のコマンドで空きメモリを確認します。空きメモリは2048 MB(空き+キャッシュ)を超える必要があります。
hxshell:~$ free –m
total used free shared buff/cache available
Mem: 74225624 32194300 38893712 1672 3137612 41304336
Swap: 0 0 0
hxshell:~$ フリー+キャッシュメモリが2048未満の場合は、メモリ不足状態を発生させているプロセスを特定するために必要です。
注:topコマンドを使用すると、大量のメモリを消費しているプロセスを識別できます。ただし、変更はTACの承認を得て行う必要があります。OOM状態をトラブルシューティングするには、Cisco TACにお問い合わせください。
End Of Space条件
ストレージクラスタのスペース使用率のベストプラクティスは、HX Connectのキャパシティビューで76 %を超えないようにすることです。76 %を超えると、HX Connectのキャパシティビューで使用するとパフォーマンスが低下します。
ストレージクラスタでENOSPC状態が発生している場合、クリーナは自動的に高い優先度で実行され、クラスタのパフォーマンスの問題を引き起こす可能性があります。優先度はクラスタ領域の使用状況によって決まります。
ストレージクラスタがENOSPC WARN状態になると、クリーナはENOSPCが設定された状態でガベージを収集するI/Oの数を増やして強度を高め、最も高い優先順位で動作します。
次のコマンドを使用して、クラスタのENOSPCINFOステータスを確認できます。
hxshell:~$ sysmtool --ns cluster --cmd enospcinfo
Cluster Space Details:
---------------------:
Cluster state: ONLINE
Health state: HEALTHY
Raw capacity: 42.57T
Usable capacity: 13.06T
Used capacity: 163.08G
Free capacity: 12.90T
Enospc state: ENOSPACE_CLEAR <--------End of space status
Space reclaimable: 0.00
Minimum free capacity
required to resume operation: 687.12G
Space required to clear
ENOSPC warning: 2.80T <--------Free space until the end of space warning appears
Rebalance In Progress: NO
Flusher in progress: NO
Cleaner in progress: YES
Disk Enospace: NO
hxshell:~$
『Cisco HyperFlexにおける容量管理』ホワイトペーパーを参照して、Hyperflexクラスタの容量を管理するためのベストプラクティスを特定してください。
パフォーマンスグラフのトラブルシューティング
hyperflexパフォーマンスグラフに情報が表示されない場合があります。
Hyperflexパフォーマンスチャート
この動作が発生した場合は、クラスタ内で統計サービスが実行されているかどうかを確認する必要があります。
hxshell:~$ priv service carbon-cache status
carbon-cache stop/waiting
hxshell:~$ priv service carbon-aggregator status
carbon-aggregator stop/waiting
hxshell:~$ priv service statsd status
statsd stop/waiting
プロセスが実行されていない場合は、サービスを手動で開始します。
hxshell:~$ priv service carbon-cache start
carbon-cache start/running, process 15750
hxshell:~$ priv service carbon-aggregator start
carbon-aggregator start/running, process 15799
hxshell:~$ priv service statsd start
statsd start/running, process 15855関連情報
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
27-Jul-2023 |
初版 |
フィードバック