1 Rookie
•
18 メッセージ
0
32
iDRAC/OMSA/その他サーバコンポーネントによる物理ディスクの自動無効化→オフライン→自動有効化→リビルド開始について
あるサーバのアラートログを監視していて初めて目にするログが記録されていました。
以下に時系列に発生した現象を記載致します。
1. パトロールリードが開始される
2. 整合性チェックが開始される
3. HDD(#0:1:6)をシステムが自動的に無効化？
---
Physical device removed: Physical Disk 0:1:6 Controller 0, Connector 0
---
4. HDD(#0:1:6)に対してコマンドタイムアウトが数回発生
---
Command timeout on physical disk: Physical Disk 0:1:6 Controller 0, Connector 0
---
5. 整合性チェックが完了
6. HDD(#0:1:6)の故障が検知される
---
Device failed: Physical Disk 0:1:6 Controller 0, Connector 0
---
7. HDD(#0:1:6)がオフライン化される
---
Physical disk offline: Physical Disk 0:1:6 Controller 0, Connector 0
---
8. HDD(#0:1:6)に対して以下のメッセージ
---
Device returned to normal: Physical Disk 0:1:6 Controller 0, Connector 0
---
9. HDD(#0:1:6)がINSERT(挿入)された？システムが自動的に無効化したのとは反対に、自動的に有効化したのでしょうか？
---
Physical device inserted: Physical Disk 0:1:6 Controller 0, Connector 0
---
10. リビルドが開始され今に至る
---
Physical disk Rebuild started: Physical Disk 0:1:6 Controller 0, Connector 0
---
上記に記載させて頂いた一連のログは、深夜4時前後に発生したものと記録されています。
確実なことは言えませんが、そのような時間帯に人の手を介してディスク交換が行われたとは考えづらいです。
つまり、タイトルに記載させて頂いたように、何らかのサーバコンポーネント(RAIDコントローラなど)が、整合性チェックを開始した時点で問題のあるディスクを検出(#0:1:6)を検証し、上記ログに記載されているような一連の処理を自動的に行ってくれることはあり得るのでしょうか？
私の知識でただログの内容だけを確認したら、普通に考えて誰かがディスク交換を行ったとしか思えないのですが、時間帯が明らかにおかしいのと、やはりサーバ所有者も交換を行ってはいないとおっしゃられています。
ではこれは何の機能がそうさせたのか。博識な方の知恵をお借りしたく質問させて頂きました。
何卒宜しくお願い致します。
Uehara Y.
Community Manager
Community Manager
•
5K メッセージ
1
2024年6月11日 07:55
同様のログシーケンスについて説明するものが見つかればよかったのですが、見つけられず。。
とはいえあり得る動きだと考えています。
（私はPowerEdgeのスペシャリストではなく、ストレージエンジニア（旧EMC製品）を得意分野としているのですが、その経験からの考察/回答です）
記載して頂いたアラートログを見ると、7.まではHDD（#0.1.6）のドライブが不安定であることを判断したPowerEdge（PERC）が当該ドライブを切り離すまでの動作であり特に気持ち悪さはないと思うのですが、8.で突然そのドライブが「returned to normal」というように戻ってくることが「何だこれ？」と感じられる部分だと考えています。
想定される動作としては以下2つあると考えていて、1つ目は旧EMC製品のストレージが行う動作と同じという想定。2つ目はPowerEdgeはこう動作することもあるのかなという想定（旧EMC製品ではなかった動作）です。
（1つ目：ホットスペアドライブが存在していることが前提）
7.で#0.1.6が切り離された後、RAIDグループがデグレード状態になってしまっているためにホットスペアドライブが#0.1.6の代わりに利用開始さることとなる。当該ホットスペアドライブは、その他のRAIDグループのメンバーに「これまでと同じ状態を構築するために」自分が（切り離された）#0.1.6であるように振る舞う（そのためにログでは#0.1.6ドライブが復活してきたように記録される）。そしてそのホットスペアドライブに対してリビルドが行われ、リビルドが完了した時点でRAIDグループの状態が正常に戻る。
また、PERC6以降を利用している場合には、故障した/切り離されたドライブ#0.1.6を物理的に交換した後、（元）ホットスペアドライブから新たに交換されたドライブに対してデータのコピーバックが走る。
（2つ目）
7.で#0.1.6が切り離された後、RAIDグループがデグレード状態になってしまったが、何らかの理由で#0.1.6がまた復活して利用できる状態となった（※）。しかしながら、そのドライブの信頼性が担保できないので、もう一度残りのRAIDグループの情報を用いてリビルドを行い、当該ドライブのすべてのデータを上書きした。
（※）今回の例では深夜なので当てはまらなそうですが、Device returned to normalの説明では、一度高温になってエラー状態となったドライブが温度が下がり元のように利用できるようになった例が書かれていました。
Mangoro
1 Rookie
1 Rookie
•
18 メッセージ
0
2024年6月15日 04:56
@Uehara Y. 様
ご経験に基づいた鋭いご推察をありがとうございました。自身の所有するサーバで発生した現象でないことから、詳細情報をお伝えすることができていないにも関わらず、真摯に問題を考察頂き誠に感謝致します。