ディスク故障によるサーバ停止とオンサイト対応の記録
##【障害対応事例】ディスク故障によるサーバ停止とオンサイト対応の記録
今回は、監視ツールからのアラートをきっかけに発覚したディスク障害について、調査から復旧までの一連の対応をまとめます。
事象の発生
Zabbixからのアラートを確認したところ、対象サーバで再起動が発生していることが判明しました。
さらにログを確認すると、Array関連のエラーも出力されており、ハードウェア障害の可能性が浮上しました。
この時点で、ディスク障害の線を疑い、詳細調査へ進みます。
調査と原因特定
iLO（Integrated Lights-Out）からストレージの状態を確認したところ、
bay4のディスクが「Critical」状態となっていることを確認しました。
これにより、ディスク故障が原因である可能性が高いと判断。
すぐにHPEへケースを起票し、オンサイトでの部品交換対応を依頼しました。
あわせて、iLOからAHS（Active Health System）ログを取得し、メーカーとの調整を進めます。
影響範囲の確認
バックアップ状況を確認したところ、一部で失敗が発生していました。
ただし、以下の点から致命的なデータ損失は回避できていました。
- DFSR（分散ファイルシステムレプリケーション）を構築済み
- データ自体は別ノードに保持されている状態
- システム領域のバックアップは正常に完了
結果として、サービス継続に大きな影響は出ていないことを確認できました。
交換対応（オンサイト）
HPEエンジニアおよび顧客と調整を行い、ディスク交換のスケジュールを確定。
木曜の昼帯に作業を設定し、以下の条件で実施しました。
- 予定停止時間：1時間30分
実際の作業では、停止から部品交換完了まで約1時間で終了し、想定よりもスムーズに対応が完了しました。
作業後の状態
作業完了後は、以下を確認しています。
- LEDステータス正常（SE確認済み）
- 後日の状態確認も問題なし（顧客側で実施）
なお、RAIDの再構成（リビルド）には約6時間を要しましたが、システムとしては安定稼働を維持できました。
残課題と対応
ハードウェア障害自体は解消されたものの、別の課題も確認されました。
- AOMEIによるフルバックアップタスクが引き続き失敗
そのため、暫定対応として以下を実施・検討しています。
- robocopyによるバックアップ取得への切替
- 代替手段でのバックアップ運用の継続
まとめ
今回の障害はディスク故障という比較的明確な原因でしたが、
- 監視アラートからの初動対応
- メーカーとの連携
- 顧客への影響最小化
- バックアップ設計の有効性
といった運用面の重要性を改めて実感する対応となりました。
特に、DFSRによる冗長化構成が有効に機能した点は非常に大きく、
「障害は必ず起こる前提で設計すること」の重要性を再認識できた事例でした。