Event: ノードがパニックから回復しました。パニックに関する情報は、次のファイルに記録されます: var tmp panic

概要: この記事では、ユーザーおよびテクニカル サポートが「ノードがパニックから回復しました」イベントまたはメッセージを管理する方法について説明します。行動する前に、記事のすべての部分を確認してください。

この記事は次に適用されます： この記事は次には適用されません： この記事は、特定の製品に関連付けられていません。 すべての製品パージョンがこの記事に記載されているわけではありません。
他のリソースを確認する

現象

EVENT
パニックから回復したノードが1つ以上あることを示すイベント通知を受信しました。パニックに関する情報は、次の場所にあるファイルに記録されます。 /var/tmp/ 影響を受けるノード上
例： 
4.3394   03/12 18:02 W    4    53125     Node 4 has recovered from a panic. Info about panic is recorded in file: /var/tmp/panic.1615590175

原因

ノード パニックの正確な原因はさまざまですが、一般的な原因は次のとおりです。
  • ハードウェア障害
  • ソフトウェア コードの障害
  • 間違った構成
パニックの正確な原因については、PowerScaleサポートを使用してクラスター ログの分析を実行する必要があります。

解決方法

問題のトラブルシューティングを開始するには、まずノードがパニック イベントからリカバリーし、ダウンまたはオフラインになっていないことを確認します。*

トラブルシューティングを行うには、ノードへのSSH接続を開き、「root」アカウントを使用してログインします。
次のコマンドを実行して、ノードがクラスターに再参加したことを確認します。 
# isi status
「 isi status コマンドを実行すると、次のような出力が返されます。ノードが正常にクラスターに再参加した場合、[Health]列に「D」(ダウン)は表示されません。 
                   Health  Throughput (bps)  HDD Storage      SSD Storage
ID |IP Address     |DASR |  In   Out  Total| Used / Size     |Used / Size
---+---------------+-----+-----+-----+-----+-----------------+-----------------
  1|10.16.141.226  | OK  | 553M| 3.2M| 557M|61.9T/ 106T( 59%)|        L3:  1.5T
  2|10.16.141.227  | OK  | 481M| 96.0| 481M|62.2T/ 106T( 59%)|        L3:  1.5T
  3|10.16.141.228  | OK  | 372k| 332k| 704k|62.3T/ 106T( 59%)|        L3:  1.5T
  4|10.16.141.229  | OK  |10.8M| 941k|11.7M|62.6T/ 106T( 59%)|        L3:  1.5T
  5|10.16.141.230  | OK  | 9.4M| 393k| 9.8M|62.6T/ 106T( 59%)|        L3:  1.5T
  6|10.16.141.231  | OK  | 7.3M|256.0| 7.3M|63.4T/ 106T( 60%)|        L3:  1.5T
---+---------------+-----+-----+-----+-----+-----------------+-----------------
Cluster Totals:          | 1.1G| 4.9M| 1.1G| 375T/ 634T( 59%)|        L3:  8.7T

     Health Fields: D = Down, A = Attention, S = Smartfailed, R = Read-Only
次のコマンドを実行してログを収集し、パニックの分析のためにログ セットをIsilonテクニカル サポートに提供します。 
# isi_gather_info -f /var/tmp/
 
注： /var/tmp/ パニック データはデフォルトのログ収集では収集されません。必ず isi_gather_info -f /var/tmp/ 適切なパニック情報を収集します。

ログを受信すると、テクニカル サポートはパニック スタックの詳細を確認して分析します。パニック スタックが既知の問題またはナレッジベース記事に対応しているかどうかを判断します。パニック スタックの詳細が既知の問題または既存のKB記事と一致しない場合、問題はエスカレーションされてさらに評価されます。テクニカル サポートは、ハードウェアの交換、コード修正、ファームウェア アップデート、その他の軽減策など、必要なアクションを決定します

*ノードがまだダウンしている場合は、ノードをオンラインに戻すために追加のトラブルシューティングを実行する必要があります。サポートが必要な場合は、Isilonテクニカル サポートにお問い合わせください。

詳細については、記事55936を参照してください。Isilon OneFS：イベント通知：Node Offline - Event ID: 200010001、300010003、399990001、900160001、910100006、400150007

その他の情報

注：
  • この新しいイベント通知は、OneFS v8.1.2.0、v8.2.2.0、v9.1.0.5用の2021年3月のロールアップ パッチの一部として有効になっています。2021年3月のロールアップ パッチ(RUP)より前のOneFSバージョンを実行しているクラスターでは、このイベント通知は送信されません。
  • OneFS 9.2、9.3、9.4以降にはすべてこの機能が搭載されています。
  • ノード パニックが原因でOneFSが再起動を検出すると、アップデートによってイベントがトリガーされます。
  • このイベントには、問題の理解とトラブルシューティングに役立つコア ダンプ ヘッダーなどの基本情報が含まれる場合があります。
  • 結果として得られるオートコールSRには、トリアージと分析のために、読み取り可能な形式で追加情報を含めることができます。

注：この機能は、2021年3月のRUPのインストール前にクラスターに存在する可能性のある以前のパニック イベント、コア、またはミニダンプが原因で誤ったアラームを引き起こす可能性があります。OneFSは、削除されるまで古いパニック ファイルのアラートを継続する場合があります。誤ったアラームを回避するには、次の手順を実行します。
  1. ログを強制的にローテーションして、メッセージ ログをクリーンアップします。この機能では、messages.0.gz、messages.1.gzなどのgzアーカイブ内のローテーションされたログのパニック情報はチェックされません。次のコマンドを実行して、パニックが検出されるたびに/var/log/messagesをローテーションします。
isi_for_array 'grep "panic @ time" /var/log/messages && newsyslog -F /var/log/messages'.
  1. エラー コードまたはメッセージの診断を支援するため、 /var/crash コアまたはミニダンプ ファイルの各ノードのディレクトリー。承認を得た後、それらを削除またはバックアップします。
  2. 次のコマンドを実行してクリーンアップします vmcore ファイルは次の場所にあります /var/crash すべてのノード上。
isi_for_array 'find /var/crash/ -name "vmcore*" -delete'

対象製品

PowerScale OneFS

製品

Isilon
文書のプロパティ
文書番号: 000184828
文書の種類: Solution
最終更新: 09 5月 2026
バージョン:  16
質問に対する他のDellユーザーからの回答を見つける
サポート サービス
お使いのデバイスがサポート サービスの対象かどうかを確認してください。