私家版 ITプロフェッショナルの仕事術

LHC（(Large Hadron Collider、大型ハドロン衝突型加速器）を建設したCERNは、数多くのサーバやディスクで実験データを保存・解析している。いうまでもなくデータの整合性・完全性が非常に重要である。サーバやディスクのデータは本当に大丈夫なのだろうか。そこで、fsprobeというプログラムを作って実験してみた。

fsprobeの処理は非常に単純である。

1. 1MBの既知のビットパターンをディスクに書き込む。これをファイルが2GBになるまで繰り返す。
2. 1MBずつファイルを読んで、書き込んだはずのビットパターンと比較する。これを2GBまで続ける。

この処理を数千台のサーバで数ヶ月にわたって実行したところ、書き込んだはずのパターンが壊れているという事象がいくつも見つかった。3000ノードで5週間走らせたときは、100ノードで500個のエラーが見つかった（参考文献1）。4000ノードで走らせたときは（期間不明）、1400個の事象が230ノードで見つかった（参考文献2）（注）。実際の破損パターンを参考文献2で見ることができる。

また、ディスク上にあるファイルのチェックサムと、以前に計算してテープに保存しておいたチェックサムを比較したら、33,700ファイル（約8.7TB）のうち22ファイルで不一致が発見された。1500個に1個の割合である。

我々はディスクドライブというものを、十分信頼できる装置だと考えていて、そこにあるデータがいつのまにか壊れることなど想像もしない。エラーを検出し、訂正可能であれば修復する仕組みがいろいろな部分に組み込まれている。RAID-5のパリティもそのひとつであるし、ディスクドライブ自体もCRCチェックサムを使ってブロックの整合性を確認している。もしビットエラーが発見されたら、それは上位レベルに報告され、OSやアプリケーションが認識できるはずだ。

しかし上記の実験結果は、このような様々な仕組みをすり抜けるケースがかなりあるということを示している。何もエラーが報告されないのにいつのまにかデータが破損していることを「Silent Data Corruption」と呼ぶ。おそらくこれまではデータ容量やトラフィックが比較的少ないのでほとんど起きなかったか見過ごしていたのだろう。あるいはデータが破損している事象を経験しても、これはアプリケーションのバグか誰か他の人の操作ミスなんだろうと考えていたのかもしれない。

CERNの研究者たちはこう結論づけている。Silent Data Corruptionを撲滅することは不可能であり、こういった問題があるということを前提として対策を組み込まなければならない。そのひとつがアプリケーションレベルでのチェックサム検査である。書き込むときにチェックサムを取ってどこかに保存しておく。そして読み込み時に計算した値と比較する。

ZFSはエンド・ツー・エンドのチェックサム処理を実装していて、ディスク上のデータが破損しているかどうかを、ファイルシステムのレベルで確認する。当然、これによるCPU処理負荷が上乗せされる。従来のファイルシステムは、それによる性能劣化を嫌って実装しなかったわけだが、ZFSの開発者たちは、現在のCPUは性能が劇的に向上しているからもはや問題にならないはずと考えて、エンド・ツー・エンドのチェックサム処理を組み込んだ。

ZFSが使えないWindowsシステムで我々はどうすればよいか。バックアップは完璧ではない。破損したデータをバックアップしているかもしれないからだ。せいぜい、定期的にバックアップを取り、それを複数世代にわたって保存することくらいしか考えつかない。あとはNTFSが同様な対策を組み込むのを気長に待つしかない。

（参考文献1）
Data integrity
Bernd Panzer-Steindel, CERN/IT
Draft 1.3 8. April 2007
http://indico.cern.ch/getFile.py/access?contribId=3&sessionId=0&resId=1&materialId=paper&confId=13797

（参考文献2）
Silent Corruptions
Peter.Kelemen
CERN After C5, June 1st, 2007
http://fuji.web.cern.ch/fuji/talk/2007/kelemen-2007-C5-Silent_Corruptions.pdf

（注）
4000ノードテストは、3000ノードテストからの継続かもしれない。