Content-addressable storage -2- 続・ファイルの一生

さて、私が考えたのは次のようなものだ。ファイルの一生を大きく2つに分ける。1つは書き込みが結構存在する時代、そしてもう一つは書き込みがほとんど無い時代だ。


赤の領域は書き込み頻度が極めて高い。ここで要求されるのは「書き込み速度の速さ」だ。しかし、これは言うほど簡単ではない。特に NAS のように複数のクライアントから同時に書き込みや読み込み要求が飛んでくる場合は、きわめて難しい。

HDDが、書き込み要求に高速に対応するには、連続した領域に、書けといわれたデータを到着した順に書くのが最も効率が良くなる。というのは、HDDはいったんヘッドの位置を決めてしまえば、そのトラックに対する読み書きの速度は完全に一定になるからだ。つまり、ヘッドがまったく動かない状態が最も高速な書き込み速度で、ヘッドシーク時間が無駄時間になる。書き込み要求を高速にこなす、とはつまり書き込みに際してヘッドシーク時間の割合を減らす、ということに他ならない。と言う事は「あるトラックにヘッドを移動したら最後、トラック一周が完了するまでヘッドを動かさなくて良い」場合が最高速度になる。HDDの「ヘッドシークなしの」書き込み速度は4Gbit/sec 近い速度を誇れるので、本当にそれだけの書き込み要求が1つのファイルについて、シーケンシャルに、存在できるならば最高だ。

しかし実際は、NASであれ、通常のアプリケーションであれ、このような大量のデータを、シーケンシャルに、書き込むよう要求することは、まれだ。実際には複数のクライアントやアプリケーションが、それぞれはちまちまとした分量の書き込みを要求することになる。必然的にファイルシステムに到着するデータは異なるファイルの異なる部位が到着することになる。これを「連続した書き込み」にするには、到着した順にHDDに書いて、なおかつそれを意味のあるものとできる必要がある。


このような性質を持つファイルシステムは存在する。Log Structured File System と言われるものがそうだ。ただし、これは定期的な Garbage Collection を必要とする。この弱点を補ったのが NetApp が彼らの Filer といわれる製品シリーズに利用している WAFL で、バッテリーバックアップの RAM Disk を中間バッファーとして利用し、これが抑えられる範疇でデフラグを施した上で、RAID に一気に書き込む、という事をやっている。


赤の領域の間は、あまり読み込み速度のことは気にしなくて良い。なぜなら、ここで何か読み込み速度のための改善を行っても、次の瞬間にはまた書き込みが発生して、せっかくの改善が水泡に帰すからだ。




緑の領域は書き込みがほとんど無い。つまり、書き込み性能はIO性能にほとんど影響を与えない。この場合、ファイルはデフラグされ、連続した領域に1つのファイル情報が集まっていることが望ましい。というのは、昨今のOSは十分なメモリ容量を背景に、大量の先行読み込みを行うからだ。

HDDのヘッドシークオーバーヘッドという観点からすれば、10kbyteを読むためにあるトラックにヘッドシークを行うのも、1Mbyteを読むためにあるトラックにヘッドシークを行うのもコストは変わらない。であれば、ファイルをなるべくヘッドシーク量が最小ですべて読める領域に配置し、OSの先行読み込み機構に期待すれば、無駄なヘッドシーク量は最小で済み、その分IO性能が上がって見える計算になる。



実はこのような状態には WAFL は非常に不利だ。WAFLは「RAM Disk 1block分」の範囲内ではデフラグを行う能力があるのだが、block 間デフラグをデフォルトでする能力は無い。非常に多くのクライアントがバラバラに、それぞれ複数のファイルの書き込み要求をしてしまうと、1つのファイルの情報が複数の block 間にまたがってしまう。赤の領域では無敵を誇る RAM Disk + バースト書き込み機構は、緑の領域では逆に不利になるわけだ。

で、IBMにいる間に私が提案したのは、

HDD自身にある程度のファイルシステムとしての機能を持たせる

というものだ。具体的には uFS などでいう、inode 管理はHDDが行う。

HDDは、赤の領域に属するファイルに関するものの場合、まるで Log Structured File System のようにプラッターに書き込む。つまり、書き込み順序は到着順序どおりとし、同じファイルのデータがなるべく集中するように、などということは考えない。

逆に緑の領域に属するファイルの場合は、なるべく同じファイルのデータが1箇所に集まるようにレイアウトを決める。

さらに、赤から緑に属性が変化するタイミングで、ディスクの異なる場所へと内容をコピーする。この際にデフラグを行う。また、IOが少なく、暇なタイミングを狙って、赤の領域、緑の領域とも、再デフラグを行う。特に赤の領域は、本当に使っている部分と使っていない部分がまだら模様になるはずなので、これを集約して使える連続領域を確保するのだ。計算機システムにおいてIOが少ないタイミングは2種類ある。1つはメイン計算機が「計算」に謀殺されているとき。もう一つは本当に暇なとき。従来は「本当に暇なとき」にしかデフラグできなかったが、HDDがファイルシステムとしての役割を果たし、ディスク上のレイアウトを決定できるように書き換えれば、通電しておきさえすれば勝手にデフラグし続けることができる。

おそらく、このような HDD 自身に対する大改造を行わない限り、NetApp Filer 以上の性能を出すシステムを開発するのはきわめて困難だろう、というのが私の結論だった。



さて、この結論から5年後。私はEMCに入って、自分が馬鹿だったことに気がつかされる。

EMCが提唱する ILM(Information Lifecycle Management) によるならば、ファイルの一生は次のように分類する。そして、私が考える限り、私が考えた赤緑の2フェーズよりも、この3フェーズモデルのほうが正しい。
というわけで、次回は、この3フェーズモデルについて説明しよう。

…おかしいな、CASに行く前の「前フリ」がこんなに長くなるとは思わなかったぞ?