Posted inリナックス

smartmontoolsによるLinuxハードドライブのヘルス監視：smartctlとメールアラート通知

Linux tutorial - IT technology blog
Linux tutorial - IT technology blog

背景と重要性：サイレントなディスク劣化という問題

予期せぬストレージ障害ほど、運用上の緊急事態において混乱を招くものはありません。サーバーは突如として読み取り専用（read-only）ファイルシステムに移行し、アプリケーションのスレッドは割り込み不能な待機状態（恐るべきDステート）に陥って滞留します。さらに悪いことに、ディスクへの書き込み途中でデータベースのトランザクションが破損し、テーブルが破壊されてチーム全体が対応に追われる事態にもなりかねません。

現代のストレージドライブが、事前の兆候なしに突然故障することは滅多にありません。モーターの焼き付きやNANDコントローラの完全なフリーズが発生する遥か前から、ストレージデバイスには警告サインが蓄積されていきます。不良ブロック、代替セクタ、あるいはSATAケーブルの緩みや劣化に起因するCRC伝送エラーなどがその兆候です。

55°Cを超える温度上昇も大きなダメージを与えます。残念ながら、ドライブがバックグラウンドで不良セクタの再割り当てを行っている間、標準的なLinuxカーネルは何の警告も発しません。OSは内部の摩耗処理をドライブコントローラ任せにしており、読み書きのI/O処理が完全にブロックされるまで異常に気付かないのです。

このギャップを埋めるのがアクティブなハードウェアテレメトリです。S.M.A.R.T.（Self-Monitoring, Analysis and Reporting Technology）は、ほぼすべての最新ドライブコントローラに内蔵されています。Linuxでは、smartmontoolsを使用することで、以下の2つの主要ユーティリティを通じてこのハードウェアデータに直接アクセスできます。

  • smartctl: 手動でのスポットチェック、オンデマンドのハードウェアセルフテスト、ベンダー固有のアトリビュート情報のダンプを行うコマンドラインユーティリティ。
  • smartd: ドライブの健全性を定期的にポーリングし、スケジュールされたセルフテストを実行し、重大なしきい値を下回った際にメール警告をトリガーする軽量なバックグラウンドデーモン（通常、メモリ消費量は15MB未満）。

2台のSATA SSDを搭載した高負荷なUbuntuデータベースホストにおいて、/dev/sdbで発生した24個の代替セクタを早期に発見できたことで、深夜3時の突発的な障害対応に追われることなく、計画された15分間のメンテナンス枠内でドライブを安全に交換できた経験があります。

インストール：smartmontoolsとメール送信環境のセットアップ

デーモンから障害通知アラートを外部へ送信できるように、コアとなる診断ツールと最小限のメール転送ユーティリティを用意する必要があります。

1. Debian/UbuntuおよびRHEL系システムでのパッケージインストール

DebianおよびUbuntuでは、smartmontoolsとともにmailutils（またはbsd-mailx）をインストールします。

sudo apt update
sudo apt install smartmontools mailutils -y

RHEL、Rocky Linux、AlmaLinuxの場合は、dnfを使用してパッケージをインストールします。

sudo dnf install smartmontools mailx -y

2. 接続されているストレージデバイスの検出と確認

設定ファイルを変更する前に、物理ディスクをスキャンします。

sudo smartctl --scan

検出されたドライブ一覧が、バスインターフェース（SATA、NVMe、SCSI）とともに表示されます。

/dev/sda -d scsi # /dev/sda, SCSIデバイス
/dev/nvme0 -d nvme # /dev/nvme0, NVM Expressデバイス

次に、対象のデバイスでS.M.A.R.T.監視が有効になっているかを確認します。

sudo smartctl -i /dev/sda

出力結果の末尾数行を確認してください。S.M.A.R.T.サポートが利用可能（Available）でありながら無効（Disabled）になっている場合は、有効化します。

sudo smartctl -s on /dev/sda

設定：ポーリング、セルフテスト、メール通知の設定

単発のトラブルシューティングであれば手動チェックでも十分ですが、人間の記憶に頼るのは危険です。真のサーバー耐障害性を実現するには、smartdによる継続的なヘルス監視が不可欠です。

1. smartctlによるアドホックなドライブ診断

まずはドライブ全体の健全性をクイックチェックします。

sudo smartctl -H /dev/sda

PASSEDという結果は安心材料にはなりますが、これだけですべてを判断することはできません。保留中の不良ブロックが数百個存在していても、ベンダーの規定するエラースきい値を超えていなければ合格判定が出てしまうためです。実際の状態を把握するために、生のアトリビュート値を確認しましょう。

sudo smartctl -A /dev/sda

SATA HDDおよびSSDでは、以下の重要カウンターに注目してください。

  • ID 5 (Reallocated_Sector_Ct): 生の値（Raw Value）が0を超えている場合、損傷したセクタがすでに予備領域に再配置されていることを示します。数日のうちに0から50などに跳ね上がった場合は、メディア表面の劣化・故障が進行しています。
  • ID 187 (Reported_Uncorrect): ハードウェアECCでも修復できなかった読み取りエラーです。この値が0より大きい場合は、直ちにデータのバックアップを取得してください。
  • ID 197 (Current_Pending_Sector): 再配置待ちの不安定なセクタ数です。ここへの書き込みが失敗すると、直後にデータ消失へとつながります。
  • ID 199 (UDMA_CRC_Error_Count): 通常、ドライブ自体の故障というよりも、SATAデータケーブルの折り曲げ、酸化、または緩みが原因です。まずはケーブルの差し直しや交換を試みてください。

NVMeドライブはテレメトリのフォーマットが異なります。以下のコマンドで確認してください。

sudo smartctl -a /dev/nvme0n1

書き込み寿命が尽きる前にハードウェアを計画的に交換できるよう、Available Spare（予備領域：10%を下回ったらドライブ交換を推奨）とPercentage Used（使用率の割合）を常に注視してください。

2. smartdデーモンの設定

メインのデーモン設定ファイルを開きます。

sudo nano /etc/smartd.conf

大半のLinuxディストリビューションでは、デフォルトで未設定の包括ルールが有効になっています。本番環境のディスクに対して明示的な監視ルールを定義できるよう、DEVICESCANの行をコメントアウトします。

# デフォルトの包括設定行をコメントアウト:
# DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner

ファイルの末尾に、環境に合わせた監視ディレクティブを追加します。

# /dev/sda (SATA SSD/HDD) を監視
/dev/sda -a -o on -S on \
  -s (S/../.././02|L/../../6/03) \
  -W 4,45,55 \
  -m [email protected] -M test

各フラグはsmartdに対して以下のような動作を指示しています。

  • -a: 標準のすべてのS.M.A.R.T.ヘルスアトリビュートを監視します。
  • -o on: サポートされているハードウェアにおいて、4時間ごとの自動オフラインバックグラウンドデータ収集を有効にします。
  • -S on: 電源再投入後もアトリビュートの状態を自動的に保存・引き継ぎます。
  • -s (S/../.././02|L/../../6/03): 毎日午前2:00にショートセルフテスト（S）を実行し、毎週土曜日の午前3:00にロングセルフテスト（L）を実行します。
  • -W 4,45,55: 動作温度を追跡します。4°Cの変化を記録し、45°Cで警告を発し、55°Cに達した場合は重大アラートをトリガーします。
  • -m [email protected]: アラートの送信先メールアドレスです。
  • -M test: smartdの再起動時に毎回テストメールを送信し、メールサーバーがアラートを正常にルーティングできるか検証します。

3. デーモンサービスの有効化

Debianや古いUbuntuリリースでは、/etc/default/smartmontools内でデーモンの起動フラグが有効になっていることを確認してください。

sudo sed -i 's/^#start_smartd=yes/start_smartd=yes/' /etc/default/smartmontools

systemdサービスを有効化し、起動します。

sudo systemctl enable --now smartd

検証と監視：テスト実行とメール配信の確認

動作検証が行われていない監視設定は、誤った安心感を生むだけです。通知メールが確実に届くこと、およびスケジュールされたハードウェアセルフテストが正常に完了することを必ず確認してください。

1. テストメールの確認

/etc/smartd.confの-M testパラメータにより、サービスが立ち上がった瞬間にデーモンからメールが送信されます。システムジャーナルを確認して送信状況をチェックしましょう。

sudo journalctl -u smartd -e

ローカルのMTAまたはリレーへの配信成功を示すログを確認します。

smartd[2412]: Executing test of <mail> to [email protected]...
smartd[2412]: Test of <mail> to [email protected]: successful

受信トレイ（および迷惑メールフォルダ）を確認するか、mailqコマンドでローカルのメールキューを調査してください。メッセージが正常に届くことを確認できたら、/etc/smartd.confから-M testフラグを削除してデーモンをリロードします。

# /etc/smartd.conf から "-M test" を削除後、リロードを実行:
sudo systemctl reload smartd

2. 手動セルフテストの実行と確認

週末の定期実行スケジュールを待つのではなく、直ちにハードウェアをテストしてみましょう。/dev/sdaに対して手動でショートセルフテストを実行します。

sudo smartctl -t short /dev/sda

ショートテストは通常60〜120秒程度で完了します。なお、大容量12TBのメカニカルドライブなどに対するロングテスト（拡張テスト）は、完了までに18〜24時間以上かかる場合があります。2分ほど待ってから、ドライブのセルフテストログを確認します。

sudo smartctl -l selftest /dev/sda

テーブルの最上部にある最新のエントリを確認してください。

Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%      14280        -

Completed without errorは、コントローラがメディア表面の欠陥や機械的な問題を検出しなかったことを意味します。もしステータスに修復不可能な読み取りエラー（uncorrectable read failure）が報告されている場合は、LBA_of_first_errorのアドレスを記録し、ディスクが読み取り専用状態に陥る前に速やかにドライブ交換の計画を進めてください。

3. 日常運用のためのメンテナンスコマンド

日々の運用に役立つシステム管理コマンドとして、以下をツールキットに加えておきましょう。

  • systemctl status smartd: バックグラウンドデーモンが正常に稼働しているか確認します。
  • smartctl -l error /dev/sda: 内部ATAエラーログを表示し、ハードウェアのハンドシェイクのリセット、コマンドタイムアウト、バスの不具合などを追跡します。
  • smartctl -X /dev/sda: アプリケーションが急遽ディスクI/Oの最大スループットを必要とした場合などに、実行中のセルフテストを直ちに中止します。

smartmontoolsを用いたハードウェアチェックの自動化により、予期せぬドライブ障害を日常的で計画的なメンテナンス業務へと変えることができます。

Share:
Tags: