PowerScale OneFS：パフォーマンスの問題のトラブルシューティング

クライアント コンピューターのパフォーマンスが遅い。特定のジョブ、特にクラスターで実行されているジョブが失敗するか、予想以上に時間がかかる。

パフォーマンスの問題は、通常、ネットワーク トラフィック、ネットワーク構成の問題、クライアントまたはクラスターの処理負荷、またはその組み合わせが原因で発生します。この記事では、パフォーマンスに関する問題をトラブルシューティングする効果的な方法について説明します。

InsightIQ

を使用したトラブルシューティングの目次:

• Isilon InsightIQの使用方法
• InsightIQを使用しないトラブルシューティング
• ネットワーク スループット
• クライアント接続の分散
• SmartConnect
• クラスター スループット
• クラスター処理
• キューに登録された操作
• CPU

Isilon InsightIQの使用方法

Isilon InsightIQを使用することは、パフォーマンスを監視し、パフォーマンスの問題をトラブルシューティングするための最良の方法です。

Isilon InsightIQ仮想アプライアンスを使用すると、InsightIQ Webベース アプリケーションの柔軟でカスタマイズ可能なチャート ビューを使用して、Isilonクラスターのアクティビティーを監視および分析できます。これらのチャートには、クラスターのハードウェア、ソフトウェア、ファイル システム、プロトコルの動作に関する詳細情報が表示されます。InsightIQは、パフォーマンスの異常値を強調する視覚的な情報にデータを変換し、ボトルネックの迅速な診断やワークフローの最適化を可能にします。

InsightIQの使用方法の詳細については、『InsightIQユーザー ガイド』を参照してください。

InsightIQを使用しないトラブルシューティング

InsightIQを使用していない場合は、さまざまなコマンドを実行してパフォーマンスの問題を調査できます。まず、ネットワークとクラスターのスループットを調べ、次にクラスターの処理を調べ、最後に個々のノードのCPUレートを調べることで、パフォーマンスの問題をトラブルシューティングします。

ネットワーク スループット

次のようなネットワーク テスト ツールを使用します。 Iperf を使用して、ネットワーク上のクラスターおよびクライアント コンピューターのスループット機能を確認します。

使用 Iperfで、クラスターとクライアントで次のコマンドを実行します。これらのコマンドは、ネットワーク リンクがレイテンシーの問題を生じた潜在的な原因であるかどうかを明らかにするのに十分なウィンドウ サイズを定義します。

• クラスター：

iperf -s -w 262144

• クライアント：

iperf -c <cluster IP> -w 262144

クライアント接続の分散

クラスターに接続されているNFSクライアントとSMBクライアントの数を確認して、1つのノードを優先していないことを確認します。

1. クラスター内の任意のノードでSSH接続を開き、「root」アカウントを使用してログインします。
2. 次のコマンドを実行して、NFSクライアントを確認します。

   isi statistics query - nodes=all --stats=node.clientstats.connected.nfs,node.clientstats.active.nfs

   出力には、ノードごとに接続されているクライアントの数と、各ノードでアクティブなクライアントの数が表示されます。
3. 次のコマンドを実行して、SMBクライアントを確認します。

   isi statistics query - nodes=all --stats=node.clientstats.connected.smb,
   node.clientstats.active.smb1,node.clientstats.active.smb2

   出力には、ノードごとに接続されているクライアントの数と、各ノードでアクティブなクライアントの数が表示されます。

SmartConnect

SmartConnectが実行されているノードにネットワーク トラフィックの負荷がないことを確認します。

1. クラスター内の任意のノードでSSH接続を開き、「root」アカウントを使用してログインします。
2. 次のコマンドを実行します。

   isi_for_array -sq 'ifconfig|grep em -A3'

   出力には、外部インターフェイスにバインドされているすべてのIPアドレスのリストが表示されます。
3. 他のノードよりも1つ多いIPアドレスを持つノードがないか確認します。
4. 次のコマンドを実行して、手順3で確認したノードのステータスを確認します。

   isi status

   出力の[throughput]列を確認して、手順3で確認したノードの負荷を判断します。

クラスター スループット

ファイルの読み取りと書き込みにかかる時間を測定する書き込みおよび読み取りテストを実施して、クラスターのスループットを評価します。次のように、少なくとも 1 つの書き込みテストと 1 つの読み取りテストを実施します。

書き込みテスト

1. クラスター内の任意のノードでSSH接続を開き、「root」アカウントを使用してログインします。
2. /ifsディレクトリーに移動します。

   cd /ifs

3. クラスター上のコマンド ライン インターフェイス(CLI)、またはUNIXまたはLinuxクライアント コンピューターから、 dd コマンドを実行して、新しいファイルをクラスターに書き込みます。次のコマンドを実行します。

   dd if=/dev/zero of=1GBfile bs=1024k count=1024

   このコマンドは、1GBのサンプル ファイルを作成し、ディスクへの書き込みにかかった時間を報告します。
4. このコマンドの出力から、シングル ストリーム ワークフローでディスクに書き込み可能な1秒あたりのMB数を推定します。
5. MACクライアントがあり、さらに分析を行う場合は、
   1. アクティビティ モニターを起動します。
   2. 次のコマンドを実行します。ここで pathToFile は、ターゲット ファイルのファイル パスです。

      cat /dev/zero > /pathToFile

      このコマンドは、Isilonクラスターでの書き込み操作のスループットを測定するのに役立ちます。（ただし、Macクライアントから dd コマンドを MAC クライアントから実行すると、結果に一貫性がなくなる可能性があります。
   3. アクティビティ モニターの [ネットワーク ]タブで、コマンドの結果を監視します。

読み取りテスト
読み取り操作のスループットを測定する場合は、書き込みテスト中に作成したファイルに対して読み取りテストを実行しないでください。このファイルはキャッシュされているため、読み取りテストの結果は不正確になる可能性があります。代わりに、キャッシュされていないファイルの読み取り処理をテストします。クラスター上で1GBを超えるファイルを見つけ、読み取りテストでそのファイルを参照します。

1. クラスター内の任意のノードでSSH接続を開き、「root」アカウントを使用してログインします。
2. クラスター上のCLIまたはUNIXまたはLinuxクライアント コンピューターから、 dd コマンドを使用して、クラスター上のファイルを読み取ります。次のコマンドを実行します。ここで pathToFile は、ターゲット ファイルのファイル パスです。

   dd if=/pathToLargeFile of=/dev/null bs=1024k

   このコマンドは、ターゲット ファイルを読み取り、その読み取りにかかった時間を報告します。
3. MACクライアントがあり、さらに分析を行う場合は、
   1. アクティビティ モニターを起動します。
   2. 次のコマンドを実行します。ここで pathToFile は、ターゲット ファイルのファイル パスです。

      time cp /pathToLargeFile > /dev/null

      このコマンドは、Isilonクラスターでの読み取り操作のスループットを測定するのに役立ちます。（ただし、Macクライアントから dd コマンドを MAC クライアントから実行すると、結果に一貫性がなくなる可能性があります。
   3. アクティビティ モニターの [ネットワーク ]タブで、コマンドの結果を監視します。

クラスター処理

再ストライピング ジョブ
クラスターの入出力(I/O)操作(IOPS)を調べる前に、次の手順を実行します。

• クラスターで実行されているジョブを確認します。自動バランス調整、収集、マルチスキャンなどの再ストライピング ジョブが実行されている場合は、それらのジョブが実行されている理由と、実行を続行する必要があるかどうかを検討します。
• 使用されているデータの種類を考慮します。クライアント コンピューターが大容量のビデオ ファイルまたは仮想マシン(VM)を操作している場合、再ストライピングされたジョブには通常よりも多くのディスクIOPSが必要です。
• 再ストライピング ジョブを一時停止することを検討してください。これにより、パフォーマンスが大幅に向上し、パフォーマンスの問題に対する実行可能な短期的なソリューションになる可能性があります。

ディスクI/O
ディスクI/Oを調べると、特定のディスクが過剰に使用されているかどうかを判断するのに役立ちます。

クラスター別

1. クラスター内の任意のノードでSSH接続を開き、「root」アカウントを使用してログインします。
2. 次のコマンドを実行して、ディスクI/Oを確認します。

   isi statistics pstat

3. このコマンドの出力から、ディスクIOPSをクラスター内のディスクの合計数で除算します。例えば、Isilon IQ 12000xノードを使用する8ノード クラスターでは、ノードあたり12台のドライブをホストし、ディスクIOPSを96で除算します。
   
   Xシリーズ ノードおよびNLシリーズ ノードの場合、100%ランダム ワークフローではディスクIOPSが70以下、100%シーケンシャル ワークフローではディスクIOPSが140以下になると予想されます。NLシリーズ ノードは、Xシリーズ ノードよりもRAMが少なく、CPU速度が遅いため、Xシリーズ ノードはより高いディスクIOPSを処理できます。

ノード別およびディスク別

1. クラスター内の任意のノードでSSH接続を開き、「root」アカウントを使用してログインします。
2. 次のコマンドを実行して、ノードごとにディスクIOPSを確認します。これは、過剰に使用されているディスクを検出するのに役立ちます。

   isi statistics query --nodes=all --stats=node.disk.xfers.rate.sum --top

3. 次のコマンドを実行して、ディスク単位で統計情報のクエリーを実行する方法を決定します。

   isi statistics describe --stats=all | grep disk
   

キューに登録された操作

ディスクが過剰に使用されているかどうかを判断するもう1つの方法として、クラスター内の各ディスクに対してキューに登録されている操作の数を確認する方法があります。単一ストリームのSMBベースのワークフローでは、キューが4つあれば問題を示すことができますが、並行性の高いNFSネームスペース操作では、キューはさらに大きくなります。

1. クラスター内の任意のノードでSSH接続を開き、「root」アカウントを使用してログインします。
2. 次のコマンドを実行して、クラスター内の各ディスクに対してキューに登録されている操作の数を確認します。

   isi_for_array -s sysctl hw.iosched | grep total_inqueue

3. キュー操作によって発生するレイテンシーを確認します。

   sysctl -aN hw.iosched|grep bios_inqueue|xargs sysctl -D

CPU

CPUの問題は、多くの場合、クライアントがクラスターで実行する操作に起因します。コマンド isi statistics コマンドを使用すると、クラスターで実行される操作を、ネットワーク プロトコルまたはクライアント コンピューターごとにカタログ化して決定できます。

1. クラスター内の任意のノードでSSH接続を開き、「root」アカウントを使用してログインします。
2. 次のコマンドを実行して、ネットワーク全体で実行されている操作を特定し、それらの操作のうち最も時間がかかっている操作を評価します。

   isi statistics protocol --orderby=TimeAvg --top

   このコマンド出力は、クラスターがクライアントに応答するのに要する時間別に整理された、すべてのネットワーク プロトコルの詳細な統計情報を提供します。このコマンドの結果では、どの操作が最も遅いかを特定できない場合がありますが、正しい方向を示すことができます。
3. 次のコマンドを実行して、最も頻繁に使用されているノードのCPUなど、CPU処理に関する詳細情報を取得します。

   isi statistics system --top

4. 次のコマンドを実行して、CPUリソースを最も消費している各ノード上の4つのプロセスを取得します。

   isi_for_array -sq 'top -d1|grep PID -A4'

• PowerScale OneFS情報ハブ
• PowerScale OneFSの現在のパッチ