// you're reading...

ZFS Storage

あなたのデータが消えるとき

あなたのデータが消えるとき本記事を書こうと思ったのは Twitter で @ogawa_tter さんと会話させて頂いたことがきっかけだ。当たり前に使っているハードディスクや SSD、意外とみなさん誤解されているのではないか?そんなことを思ったので、一つ書かせて頂こうと思う。題して、「あなたのデータが消えるとき」である。

はじまりは一つの警告だった

ある日あなたはスマートフォンに警告のメールを受け取る。

「ストレージ装置に故障が起きました。 
 故障したドライブは disk-1 です。
 スペアディスクの利用を開始します。」

夜中だった。スペアディスクを使っているなら無事にデータが再構築され、部品交換の件は明日にでもメーカーに連絡すればいいだろう。 そう思っていったん眠りについた。

ふと眠りにつきかけたころ、あなたはシステムからもう 1 通メールをもらう。

「ストレージ装置に故障が起きました。 故障したドライブは disk-2 です。 
 この RAID 構成には冗長性がなくなりました。 
 壊れたと思われるファイルは以下の通りです。」

disk-2 はミラーリングをしている disk-1 と対になる面に入っているディスクだ。ミラーリングで両面に障害が出ればデータは失われる。「まずい、復旧しないと」そうつぶやきあなたは重い体を起こして会社の PC を開く。

データがどこにもない

「このシステムはある業務データの保管先だと聞いている。
ディスク装置の故障を修理したら、バックアップからリストアすればいい」

そう思ってあなたはバックアップを探すことにした。
このシステムに一番詳しいのは G さんだから彼に聞いてみよう。

あなた「夜分すみません。 ○○システムのストレージに障害があったってメールが来ました。
       どうもRAID の冗長性もなくなっているので、バックアップからリストアしたいんです。
       手順書ってどこにありますか?」
Gさん 「え?何言ってるの?それアーカイブだよ…だからそれで本番が動いているわけじゃないけど…
    まずいな…保存の必要な昔の業務データが入っているんだ。」
あなた 「アーカイブって、これしかデータがないってことですか?」
Gさん 「一応災害対策の意味でレプリケーションは取っているけど…通知来たのいつ?」
あなた 「30 分前です」
Gさん 「それじゃ、レプリケーションが走っているから災対側もデータが壊れたかもしれないね…。」
あなた 「他にバックアップは?」
Gさん 「僕が S さんに引き継いだときにバックアップを作らないとという話があったけどね。
        予算だか何だかの話しで確か止まっていた気がするよ。」

確認したところ、Gさんが恐れていたとおり、災害対策サイトのデータも壊れたファイルで上書きされてしまっていた。
Sさんに確認したところ、やはりバックアップは取られていない。
こうしてあなたのデータはなくなってしまった。

ディスクはこうして壊れる

ディスクの故障は機械である以上、HDD であれ、SSD であれ、避けることはできない。
問題はどうやってこの故障を判断し、適切に交換するかと言うことだ。

SSD は利用日数で管理

SSD はそもそもある程度寿命が予測できるので、ドライブの機種に応じて交換時期を知らせる仕掛けがシステムに備わっている場合がある。ただし、寿命予測をおこなうための基礎データを OS 側で取る仕組みがまだ標準化されておらず、SSD ドライブ毎にコードを書く必要があるとどこかで読んだように記憶している。

HDDには「半分故障」がある

HDD に関しては機種も多くもっと泥臭い。

まず、故障率だ。故障率としては、私は特別な理由がない限り 1 〜 2% 程度と思っていた。[1]
教えて頂いた論文では、1.85% (ベンダー名非公開)[2]であるので、私が過去に某所の件で集計したデータはそんなに悪いデータではなかったと言うことと思う。

壊れるパターンは、私の感覚で申し訳ないが、突然動かなくなるか、何だかエラーを出しつつも粘りながら動いていてある日突然使えなくなるかのどちらかだ。

同じ論文には壊れるまでにどれくらい正常な状態でデータが収集できたかと言うことで、同じようなデータが出ている。

論文で触れられている Group 1, Group 3 はそれぞれ論理エラー(メディアエラーなど)と write/read 時のヘッドのエラーと言うことで、ある日突然ポン、と落ちる。このエラーはシステムとしても明快なエラーなので対処しやすい。ログを見ている人間も同様である。

それに対し Group 2 は bad sector によるもので、徐々にダメになっていってある日ダメになる。
これは、read/write エラーもディスク装置的にはリカバリー可能なエラーがあるためだ。
そして、リカバリーができたときにはエラーは報告されない。 例えば、書くときに bad sector だとしても、代替 sector に書き込むことができれば、管理情報に元のセクターが利用不可である旨を記録し、代替セクターに書いて次にすすむだけだ。
このため、書き込み性能が一時的に劣化したようにみえるけれども、書き込める。
代替セクターを使い果たしたときに初めて write エラーを返すので、そこまで OS 側から通常の I/O で知る方法はない。

読みだしについても同様で、内部でリカバリをして動いている間は OS 側から通常の I/O で知る方法はない。 私が「半故障」と名付けているディスク装置は、残念ながらこういったリカバリで何となく動いてしまう。 そのため、壊れかかっていることが検出されない。そのくせ応答が悪くてそのうち 再試行可能な SCSI エラーを量産することになるので、性能劣化の片棒を担ぐことになる。また、こういうディスクが障害発生時にミラーの反対側にいたりすると悲惨である。

ZFSSA での判断

ZFSSA で「どの様に」判断しているかは申し上げられないので、「何を使って」判断しているかを簡単に説明させて頂くと、以下の通りだ。

  • SMART の情報
  • FMA (Fault Management Architecture) の Disk Transport Agent
  • ZFS からの報告

SMART の情報は、ディスクに持っている統計情報で、ZFSSA ではこの情報も使っている。predictive failure と出たときは、たいてい SMART の情報から判断して、エラーとする「しきい値」に達したという意味である。ZFSSA では FMAに Disk Transport Agent というのが設定されていて、SCSI の Test Unit Ready を定期的に送ることで死活監視をしている。 ZFS からはチェックサムエラーなども含めて報告が上がってくる。 この情報は FMA に送られている。

実際には、これらの情報を FMA の中の Diagnostic Engine が統合的に判断してディスクが fault であるべきかどうかを決めている。[3]

データロスを防ぐには?

読み書きしないとわからない故障がある

ディスクの定期的な検査をする ディスクはいろんな壊れ方をするが、実際に読み書きをしてみないとわからない。[4]
従って、各社、データを壊さない非破壊検査の仕組みを用意している。データが壊れない形で読み書きしてメディアとして大丈夫かをチェックする検査だ。各社おのおの名称が違うが、media scrub や scrub と言った用語で、呼ばれている。ZFSSA の場合は、プールの scrub ということになる。

ZFS (ZFSSA に限らず)の通常の read では使われないブロックが出てしまうので、scrub のように I/O に関係ない全検査を定期的に実施することは大切である。

半故障を見つけるようにする

半故障は、しばらくエラーが出てまた収まっての繰り返しである。FMA の Diagnostic Engine の作りは私たちもどんどん改善して言っているが、このようなパターンを見たら、一度相談して頂けると有り難い。もし半故障であるなら、早めに交換した方が良いかもしれないからだ。

RAID にもバックアップが必要と心得よ

「RAID 装置は冗長性があるからバックアップは不要」とか「レプリケーションを取っているからバックアップは不要」と思っていらっしゃるなら思い直していただきたい。理由は以下の一点につきる。

「コンピュータは、人間の目からみて誤った操作だとしても、指示されたとおりに動く」

うっかりやってしまったファイルの削除、壊れてしまったデータのレプリケーションと言ったことを防ぐことはできない。これは、誤っているということを知るのは人間だけだからだ。[5]

ご参考:
[1] 特別な理由とは洪水の後の泥で空気が汚染されていてクリーンルームでも粒子の数が多いとか、生産ロット不良があるとか言うことである。
[2] @ogawa_tter さんには以下の論文を教えていただいた。 Characterizing Disk Failures with Quantified Disk Degradation Signatures: An Early Experience by Song Huang, University of North Texas, Song Fu, University of North Texas, Quan Zhang, Wayne State University and Weisong Shi, Wayne State University
[3]これは簡略化した書き方で実際には RAID 装置や RAID の管理をおこなうソフトウェアにはプールの破壊につながる操作を禁止するような仕掛けが組み込まれている。
[4]これは最近物理学界隈でにぎやかな「観測するまで質量はない」という議論に似ているが何の関係もない。
[5]レプリケーション元のシステムで異常が出ていればレプリケーションは自動停止するべきと言うご意見もあると思う。その通りであると思う。私は同意する。

 
%d人のブロガーが「いいね」をつけました。