私の知恵の終わりに。サーバーがランダムにハードリセットする原因は何ですか？ （ZFSに関連しているようです）
私は何年も前に構築した、チャンピオンのように機能するサーバーを持っています。しかし、過去数か月以内に、認識できるパターンがなく、非常に不安定になり始めました。私はそれをデバッグし、部品を交換しても無駄にしています。システム内のほとんどすべてを交換しました。これが、ストレージに使用されるセーブドライブの原因である可能性があります。
システムがCentOS7.5を実行していることに注意してください。
症状は、電源装置が循環しているか、突然電力が失われたかのように、マシンが自発的にハードリセットを実行することです。数日に1回、場合によっては1日に2回発生する可能性があります。システムはアイドル状態または負荷がかかっている可能性があります。柄はありません。
必要不可欠なもの以外はすべて削除しました。私が交換したことに注意してください：
マザーボード、CPU、RAM、およびPSU。
ラムスティックのいずれかに欠陥がある場合、修正済み/修正不可能なECCエラーのログが表示されると思いますが、そうではありません。もしそれがCPUだったら、カーネルパニックの可能性からのロギングでもう少しランダムなものを期待するでしょう。電源に不具合があるのではないかと思い、交換しました。問題が解決しないので、マザーボードを交換してみました。変化なし。
システムは2つのプロセッサと16スティックの同じメモリで構成されていたので、1つのCPUと半分のRAMを取り外して、クラッシュしたかどうかを確認してから、もう1つのセットを交換しました。症状に変化はありません。
私は余分なコンポーネントを削除し始め、症状に変化がなく、最低限に到達しました。
- ログにハードウェア障害を示唆するものはありません。それらは単にリセットの時点で終了します。
- IPMIログには何もありません。
- UPSログには何もありません（UPSを削除しても解決しませんでした）。
- プロセッサは過熱していません。異常のないlmsensorsを記録しました。
- Ipmitoolログを使用して、システム温度、CPUとメモリのVcore、ファンRPM、およびPSU電圧を監視しました。
- すべてのSMARTテストは合格を報告します。
- Mdadmでミラーリングし、grubをインストールすることで、OSに使用されているプライマリディスク（/ root、boot、swap）を別のSSDにスワップしました。
- 両方のRAIDアレイ（以下の仕様を参照）はZFSであり、障害を報告しません。ビットの腐敗や破損をスキャンするときに問題はありません。
私は今、完全に完全に途方に暮れています。システムに残っているいくつかのドライブを除いて、ケース自体の保存を置き換えることを試みるために物が不足しています。
サーバーがリセットされる原因は何でしょうか。他に何をテストできますか？障害は本当にドライブの1つから来ているのでしょうか？
現在、システムは次のように指定されています。
基本コンポーネント：
- SuperMicro H8DG6-F （マザーボード）
- 1x AMD Opteronプロセッサ6328 （CPU）
- 16GB x 8 Hynix DDR3 ECC HMT42GR7BMR4C-G7 （メモリ）
ストレージ：
- 1x Samsung SSD 850 PRO 128GB XFS（/ルート、ブート、スワップ）
- 2x Samsung SSD 850 PRO 512GB ZFS RAID-1（/データ）
- 8x Western Digital RED 4TB WD40EFRX-68WT0N0 ZFS RAID-Z3（/バックアップ）
Western Digital REDドライブはケースのバックプレーンに接続され、オンボードSASコントローラーに接続されています。SSDが ToughArmor MB998SP-B バックプレーンに取り付けられている場合はすべてケース前面の5.25インチベイで、マザーボードSATAコントローラに接続されています。
冷却：
- NH-U12DO A （CPU）
- チップセットヒートシンクに追加されたファン（非常に熱くなる）
- Intelギガビットチップに小さなヒートシンクが追加されました
- すべてのヒートシンクのサーマルペーストが Noctua NT-H1 に置き換えられましたが、サーマルパッドを持つCPUの周りにある小さなヒートシンクは例外です。
ケース：
電源：
[〜＃〜] ups [〜＃〜]
更新：
安定性の問題を、ありそうもない原因であるソフトウェアまでたどることができました。これはありそうもないようで、ソフトウェアの問題（カーネルモジュールの場合でも）が最悪の場合カーネルパニックを引き起こすため、鑑別診断中に以前は楽しまなかった。
ソースはZFSアレイ（Linux上のZFS）として識別されています。 OSとZFSアレイを除くすべてのディスクを削除し、システム上の任意のZFSアレイ（同じまたは他の）で同時に読み取りが行われている間にそのアレイでスクラブを実行することで、クラッシュを再現できます。
基本的なテスト設定：
- 1 CPU
- 16GB x8メモリ
- CentOS 7.5用128 GB SSD（ブート/スワップ/ルート）
- SuperMicro H8DG6-Fマザーボード
- PWS-865-PQ 865W PSU
- オンボードMatrox G200ビデオ
すべてのディスクがマザーボードに接続されています。 PCIeスロットは装着されていません。
他の情報源の排除：
- CPU（2番目のCPUと交換）
- メモリ（メモリの2番目のセットと交換）
- マザーボード（別の同一のボードと交換、BIOSが更新）
- OSハードディスク（CrucialとSamsung 128GB SSDの間で交換）
- PSUは、このマザーボードでの使用が認定されています（これらの2つに対してテスト済み）
ZFSアクティビティ：
- 単一のアレイでスクラブ
- 同じアレイの読み取り/書き込みアクセスOR別の（排他的）
テスト1：!!クラッシュ!!
- 基本的なセットアップ（上記のとおり）
- 2x Samsung SSD 850 PRO 512GB ZFS RAID-1（/データ）
- 8x Western Digital RED 4TB WD40EFRX-68WT0N0 ZFS RAID-Z3（/バックアップ）
/ backupのZFSスクラブ。いくつかのMinecraftサーバーが/ dataで実行されます。
その後すぐにサーバーが突然再起動します。
これは、システムの通常の構成と似ていますが、テストと分析のために最小限のコンポーネントセットにまで細分化されています。
テスト2：!!安定!!
- 基本的なセットアップ（上記のとおり）
- 8x Western Digital RED 4TB WD40EFRX-68WT0N0 ZFS RAID-Z3（/バックアップ）
/ backupのZFSスクラブ。 Minecraftサーバーはアクティブではなく、ZFSディスクへのアクセスもありません。
サーバーは24時間以上安定しており、スクラブが完了します。
この時点で、/ data配列に障害があると思われます。
テスト3：!!クラッシュ!!
- 基本的なセットアップ（上記のとおり）
- 8x Western Digital RED 4TB WD40EFRX-68WT0N0 ZFS RAID-Z3（/バックアップ）
/ backupのZFSスクラブ。いくつかのMinecraftサーバーが/ backupで実行されます。
その後すぐにサーバーが突然再起動します。
この時点で、/ data配列が存在しなくなり、システムがいつもと同じようにクラッシュしたため、/ backup配列が実際の障害である可能性があります。
テスト4：!!クラッシュ!!
- 基本的なセットアップ（上記のとおり）
- 2x Samsung SSD 850 PRO 512GB ZFS RAID-1（/データ）
/ dataのZFSスクラブ。いくつかのMinecraftサーバーが/ dataで実行されます。
その後すぐにサーバーが突然再起動します。
安定性はZFSに関連しているようですか？
テスト5：!!安定!!
- 基本的なセットアップ（上記のとおり）
- 1x Samsung SSD 850 PRO 512GB XFS（/データテスト）
いくつかのMinecraftサーバーが/ data-testingで実行されます。
サーバーは数週間安定しています。
安定性の源泉はZFSアレイに関連していると今では確信しています。これまで何年も問題なくこのシステムでZFSを実行してきたので、これは非常に奇妙です。また、障害によってカーネルパニックやログが発生することなくシステム全体が再起動するのも非常に奇妙です。
誰かが提供できるかもしれない追加の洞察を歓迎します。
私は同じような状況で頭がおかしくなったので、最終的に私を助けたものを投稿したいと思いました。それはあなたの状況に正確に関連しているわけではありませんが、おそらく他の貧しい魂がこれにつまずいて慰めを見つけることができます。
会社のサーバーフリート全体でrsnapshot（ローテーションを使用したrsync）を実行するZFSバックアップサーバーがあります。 2〜3週間ごとに、サーバーは自動的にリセットされます。
@tjikkunが指摘したように、パニック情報を取得するようにしてください。私の場合、それは「パニック文字列：二重障害」エラーであり、ダンプと再帰的なZFSルーチンのスタックオーバーフローに関連するものでした。
これに関連するいくつかの情報がありますが、32ビットプロセッサにのみ適用されるようです。ただし、64ビットで実行しているため、情報が見つかりませんでした。
それでも、32ビットエラーはkern.kstack_pages特定の状況で増やす必要があるカーネル設定。私の場合、これはトリックをしたものです。追加した kern.kstack_pages=16から/boot/loader.conf、サーバーを再起動しましたが、それ以来（6か月間）クラッシュは発生していません。 ZFSがスタック制限に達したために発生したクラッシュが原因で、この設定が役に立ったことは理にかなっています。
繰り返しになりますが、必ずしもあなたの特定のケースに関連しているわけではありませんが、私はこの情報を見つけるのに非常に苦労しました。
これを絞り込むために実行できるいくつかの手順は次のとおりです。
パニックで再起動
パニック時の自動再起動がオンになっている場合は、テストのためにオフにすることをお勧めします。 sysctl kernel.panicを実行すると、現在の値を取得する必要があります。 0の場合はオフになり、その他の値は再起動までの待機秒数です。sysctl -w kernel.panic=0を使用すると、まだオフになっていない場合はオフになります。これが0に設定されていて、サーバーがまだ再起動する場合は、ハードウェアの問題だと思います。これにより自動再起動が停止した場合、再起動の原因はウォッチドッグタイマーです。
カーネルパニックを読む
これで再起動が停止し、運がよければ、画面にパニック情報が表示されます。これが事実であり、クラッシュの完全な情報が必要な場合は、シリアルロギングまたはnetconsoleを設定する必要があります。
画面に何もない
運が悪い場合は、 kdumpを構成 して、情報が得られるかどうかを確認することをお勧めします。
他に試すこと
非常に初期の0.7.xバージョンのZFSに戻って、そこで問題を再現できるかどうかを確認することをお勧めします。別のオプションは0.8.0-rc2を試すことですが、データを重視する場合はプレリリースに注意してください。データが失われることはないと思いますが、申し訳ありませんが安全です。