Published On: 2018-03-13|Last Updated: 2020-04-26|Categories: HDD, Linux, RAID, SSD, Storage Device|

mdadm はソフトウェア RAID です。mdadm とハードウェア RAID を比較すると長短は簡単に次のようになります:

  • pros:
    • CPU、SoC、チップセットなどのストレージコントローラーを使用するため安価で環境に対する依存性が低い
    • 専用コントローラーが故障するリスクがない
    • 一部の Fake RAID よりも高速
    • SATA と USB 3.0 を組み合わせることが可能など、構成の自由度が極端に高い
    • ブート可能
    • 三面以上のミラーリングが可能
    • 十分に安定している
    • RAID アレイを構成する生のデバイスに触れるため、RAID を使用しない環境と同じノウハウが適用できる
  • cons:
    • 性能が低い
    • CPU やメモリーリソースを占有する (よほど性能をケチらなければ無視できる。市販のローエンド NAS はギリギリかも…)

同じソフトウェア RAID には Windows のダイナミックディスクがありますが、次のように実用するには難しい問題があります:

  • イベントログが不十分
  • CLI や API が存在しない
  • 厳密にはブートに対応していない
  • 高い負荷がかかると再同期が発生する (らしい)
  • メンテナンスされていない (ように見える)

このため Windows で RAID を使用する場合は安価なハードウェア RAID が採用されます (そのほとんどは fake RAID です)。一方で上にあるように mdadm は速度を求めなければハードウェア RAID よりもはるかに高機能なため、Linux で小規模な RAID アレイを構成したい場合はおそらく最適な解といえます。市販の Linux NAS の RAID 機能はこの mdadm によって実現されています。

さて、mdadm を使用するのであればハードウェアの障害に適切に対応する必要があります。メール通知機能などを適切に設定しておけば、デフォルトで実行される月初の日曜 00:57 の自動チェックで故障したデバイスがアレイから脱落し、縮退 (degraded) モードとなりますので、この時点でディスクを交換すれば十分です。故障したデバイスも状態によりますが、HDD であれば脱落した時点のデータが保たれたまま dd などでダンプできることが多いと思われます。

HDD の故障の事前兆候を把握する

HDD の場合は syslog に ata error が一つでも記録されていれば、そのディスクが故障するのは時間の問題です。SMART でエラーカウントが増加していればほぼ間違いなく故障寸前であり、信頼性を重視するのであれば即座に交換すべきです。

エラーは通常の使用時にも発生しますが、上にある自動チェックのときに発生することがほとんどです。自動チェックで ata error が発生すれば、チェックが問題なく完了しても、次回以降の自動チェックのときにアレイから脱落するでしょう。このように、自動チェックは故障の事前兆候をつかむために実行されます。

ケーブル不良

HDD を交換した直後の再同期中など、問題ない個体を使用していても ata error が多数発生することがあります。こういった場合はパニックに陥らずに SMART を確認しましょう。

SMART にエラーが記録されてなかったり、値に変化がなければケーブルの問題です。特に SATA 接続は高品質な転送能力が求められる一方で、コネクターの耐久性が低かったり、ケース内部の取り回しでケーブルがダメージを受けたりと繊細な取り扱いが求められます。SATA のケーブルは信号線、電源線ともに消耗品と割り切って使用しましょう。

ケーブルが原因の ata error は、電気的、機械的な要素が原因であるため、システムの起動などケーブルに対する負荷の低い状態でも発生します。エラーは時系列において連続して発生する、いわゆるバーストエラーとなります。

デバイスが原因の場合は 100 MB/s を超える転送が連続的に行われているときや、少なくとも 24 時間程度は安定していた状態で発生します。エラーは時系列において散発的に発生し、連続して発生した場合でも 10 を超えることはほとんどありません。

HDD を事前準備なしに交換すると、SMART の比較やシステムが低負荷で安定した状態を観察できませんので、交換用のディスクは事前に SMART の記録、ゼロフィルなどで異常がないか確認すると良いでしょう。

mdadm superblock の削除

mdadm にはスーパーブロックから自動的にアレイを構成する機能があるため、ゼロフィルを怠ったストレージを流用して RAID アレイに追加すると失敗することがあります。

一般的には mdadm –zero-superblock するとされていますが、なぜか上手く行かないことが多々あります::

$ sudo mdadm --zero-superblock /dev/sdXN

この場合は手動でゼロフィルすると解決します (例はブロックサイズが 512 bytes の環境です)::

$ sudo dd if=/dev/zero of=/dev/sdXN bs=512 count=2048
$ sudo dd if=/dev/zero of=/dev/sdXN bs=512 count=2048 seek=$((`cat /sys/class/block/sdXN/size` - 2048))

スーパーブロックの位置はバージョンによって異なるため、ゼロフィルする際は先頭だけでなく最後方も行うとより失敗しにくくなります。

関連