さて、第3回の時に青の領域で使う技術として CAS が出てきている、と言う話を終わりのほうに書きました。それはどういう意味なのか?青の領域はIOが少ない。中でも write はもう滅茶苦茶に少ない。と言うことは、ファイルの内容が変更される可能性はほとんどない、と言うことです。
このような状態のファイルを集めてきましょう。多分、あなたのPC上のファイルだって、1年ぐらい使い続けていればそのようなファイルが結構あるはずです。普段は使うわけではないのですが、HDD上に無いとそれはそれで困るようなファイル。生半可にHDDの肥やしとなっているようなファイル。それらのファイルを CAS に入れることを考えてみましょう。
まず、そのようなファイル、実はあちらこちらのディレクトリに同じファイルが複数あったりしませんか?ここでいう「同じ」というのは、中身がまったく同じと言うこと。なぜそのようなファイルに着目するかと言うと、CAS の場合中身がまったく同じファイルは同じファイルとして扱うことになるから。つまり、ディスクスペースがそれだけで何分の一かになるわけです。一種のデータ圧縮がかけられる。
次に、青の領域にいるファイルの定義からして、当然そうなわけですが滅多にアクセスされることは無いという特徴もあるはずです。と言うことは、IO速度は気にしなくていいから、遅いHDD上にCASを作ってそこに置けば、かなり「保存ビット単価」が下げられるはずです。たとえば 15,000rpmのHDDって滅茶苦茶早いですけれど、価格.com によると、73.4Gbyte で26,979円っていう値段だったりします。
367.5円/1Gbyte。SAS。
これが 5400rpm のHDDになると12388円で 500Gbyte…24.7円/1Gbyteにまで落ちてしまうわけです。SATA。値段は 1/15 です。滅多にアクセスが無いならこれでかまわない。壊れやすさとかは念頭におく必要がありますが、それでもRAID1で5重化するという、ウルトラリッチなモデルを作っても、ビット保存単価はまだ 1/3 です。5重化を全部遠隔地に分散させても痛くもかゆくも無い。だってアクセスしないんだもの。とは言え、これで本当に性能が足りるのか?
CASではファイルが上書きされることはありません。と言うことは、ファイルシステムに対するデフラグをかけると、ものすごく効果的である、と言うこと。しょっちゅう書き換えられるファイルを管理する NAS ではフラグメンテーションによる動作効率低下が結構問題になって、それを解決するために高速なHDDを使ったりするんですが、CASの場合はちゃんとデフラグすればその効果は一生もの。と言うことは、HDDの回転速度が遅くても、ファイルを読むために必要なヘッドシーク量が少なくできるCASの場合、実は性能劣化は通常のファイルシステムにおける15000rpm対5400rpm ほどは発生しないと言うことで…ただし、CAS用に使うファイルシステムが、ちゃんとしたデフラグ機能を持っている必要がありますけどね。
CASでもファイルシステムなので、管理情報は更新されていきます。これに対してファイル本体はほとんど更新されません。と言う事は、管理情報はHDDの高速な部分(外周部)に、データ本体は内周部に置くと効果があるわけで…。
CASはファイルシステムとしてはほとんど変わることがありません。と言うことは、ここにかんしてはデータを一度バックアップしたら、新規データが保存されるまで、バックアップは必要ない、と言うことです。また、そのバックアップも極力差分バックアップでよい。と言うのは、古いファイルを上書きすることが無いので、新しい更新は常に新しいファイルの発生を意味するからです。新しいファイルの発声しか存在しないなら、古いバックアップイメージ中に無駄なビットは存在していない、と言うこと。全体のバックアップを取り直しても意味はありません…。
CAS の部分は5重化してデータを持っていても大丈夫、と言いました。また、それらは遠隔地にあっても痛くは無い、と。また、前回、Lazy にファイルのレプリカを取るシステムの話をしました。どこかから、CASにファイルを移動する際に、CAS同士のレプリケーションが3重以上になったら「大本」を消す、というルールを適用できるような移行システムがあったら…多重化に必要な時間を大きく気にする必要はなくなります。「いっせーのーでー」という感じで同期しようとするからいけないんです。Lazyに、ずるずると多重化するなら、むしろ気楽になる。
どうでしょう? 何か見えてきましたか? そう、青の領域のファイルを意識し、CASというシステムを導入すると、従来サーバ用途としては使い物にならないとされてきたHDDや、HDDの内周部分などの使い道が出てくる、と言うことです。これらをCAS用に使い、従来の高性能な部分を赤や緑の領域用にと専門に割り振ることで、全体の性能を向上させつつ、ビット保存単価を下げることができるようになる、と言うことです。赤や緑の箇所が1年経っても2年経っても、システムの50%以上を占めているとするなら…もし、企業であれば何かおかしい、と考えたほうが良いでしょう。青い部分のファイルが勝手に消えている危険性があります。
実際、赤の領域は NetApp の Filer に、緑の部分は高性能な NAS に、青の部分は CAS に割り振り、ファイルをその間で自動的に移行させながら、データを管理するのが最も効率よくなるはずです。
別の考え方として、HDDをパーティションに分割するのをやめて、単一ファイルシステムで全てを管理させてしまう、という考え方もあります。赤、緑、青の各世代にあるファイルを、どのように管理するのか、その管理方法を世代ごとに変更する。赤はHDDの最外周の高速な所に、青はCAS 型管理にしてHDDの最内周の低速なところに集めた上で、デフラグをしっかりかけ、多重化して持っているデータは(unix file system における、ハードリンクの要領で)重複を消してしまう。
他にもこういう使い方が考えられますね。
CAS はファイルの変更が起こらない。と言うことは、内容をよく精査して、Indexing などをしっかり行えば、検索が速くできる。
検索…そう、Google が行っているサービスなんかも、実は CAS に対する検索の高速化、とみなすことができます。Web上にあるページのコピーをとる。このコピーは、Google に到着した後は変更されない。この段階で一種の CAS のように管理できるようになります。で、このCAS内のファイルに対する Indexing を行う。Google の場合、同一HDD上の多重化を消して、代わりに複数のサーバが互いに持っているイメージは互いが互いのレプリカとして考える事にすれば、バックアップはすでに取られている状態になる。
日付が変更されて、同じ内容のままなページは過去に行われた Indexing の結果を引っ張ってくれば終わり。新しく変更されたものだけ Indexing を行えばよい…。
こう考えると、Google のサーチエンジンは、CAS の考え方が背後に存在する、とみなすと、その多重化、高速性能、分散性などが一気に判り易くなります。あれは CAS 相手だからこそ、多重化できるし、複数に分散しているもの同士の「同一性」が判別できる。
Winny の話を前回しました。Winny を使ったことがある人なら判るでしょうが、Winny には「分割ダウンロード」の機能があります。つまり同じファイルイメージを複数のマシンが持っている場合、各サーバからはそれぞれが持っているファイルイメージの一部分だけを送ってもらい、手元で再結合して全体を再構成する機能があります。
これは CAS のように「同一の内容」を識別しているからこそできることですが、実はこれをやると、分散ファイルサーバにとって、とても効率の良い状態が発生します。
RAM が 1Gbyte しかないマシンが10台あるとしましょう。ダウンロードしたいファイルは 3Gbyte あります。このファイルを一度に4台のクライアントが欲しい、と言い出したとします。
従来の NAS などですと、4つのサーバがそれぞれのリクエストを担当します。各サーバには 1Gbyte しかメモリがありませんから、結局 HDD が 3Gbyte 読み出す速度でしか、クライアントに答えることはできません。
しかし、この分割方式ですと、10台のサーバがそれぞれ 300Mbyte を読み出し、それをキャッシュに貯め、4台のクライアントに向かって送信すればよいことになります。1台目のクライアントは HDD の速度でしか転送できませんが、残り3台は Cache に乗った状態の速度で転送できるようになる。
10台のサーバが、同期問題を抱えているのでは、このようなことはできません。むしろ、300Mbyte づつに分割したせいで、どこかのタイミングで「書き込み」リクエストが来た場合に、変更するべき部分を持っているのは誰? という疑問に答えるための準備をしつづける、というびくびくした状態で動作し続ける必要があります。CAS であれば、そのような心配は絶対ありません。
今までの話をまとめなおすとこうなります(一部、前回以前に出てきている話も含めてあります)。
- 既存のNASサーバは、アクセス頻度を調べた上で、透過的に CAS 上に動かしたほうが良いファイルを CAS に動かすとよい。結果として高速アクセスが必要なファイルだけに、速度を稼ぐための投資を集中させることができ、システム全体のパフォーマンスが向上する。
- ファイルシステムは、ファイルのライフサイクルを意識したファイル管理を行うようにするとよい。特にCAS化したものに対するデフラグと、重複の除去、それらを HDD などのメディアの低速域に押し込む、などという事を意識したつくりになっていると、まったく新しいアイディアを盛り込むことができる。
- Winny は分散 CAS の一種である。というか、もっと分散 CAS としての性質を前面に押し出すと、その構造は「分散システム全体としての、ファイルシステムの IO 性能」向上のためのヒントが隠れている
- Google の分散サーチエンジンシステムは、背後に CAS の考え方があるからこそ、あのすさまじい分散構造を作ることができる。
というわけで、おそらく、今後、CAS と言うものに対する「注目」はもっともっと必要になると思います。また、製品を作る際に CAS の考えを取り入れるのは重要になると思います。
そして最後に、EMC の CAS 製品にとって最大のライバルは、Winny と Google である、と言うことも判ったかと思います。
と言うわけで、(今回も)長くなりましたが、CAS に関する話、今回は以上とさせていただきます。
0 件のコメント:
コメントを投稿