ごもっともな質問でございます。それに答えるには、やはり SAS や NAS との比較が一番でしょう。
SAS の場合、セクター番号を指定するとセクターの中身を教えてくれます。セクター番号を指定して、データ列を指定すると、そのセクターが保持しているデータを書き換えることができます。
と言う事は、SAS にセクター番号を指定すると、何が返ってくるのかは判らない、ということです。まぁ、当たり前ですよね? SAS は「自分が格納したいデータを保存する場所」であり、その内容は日々更新できるからこそ意味がある。一度書いたら二度と変更できない HDD なんて…5年もしたら、使えるセクターがほとんど残らないじゃないですか。
NAS の場合も似ています。ファイル名を指定するとファイルの中身を教えてくれます。ファイル名を指定して、データ列を指定すると、そのファイルが保持しているデータを書き換えることができます。
このように、検索キーに対して出てくるデータの内容を変更できる事を更新可能性といいます。この更新可能性は、ごくごく当たり前の機能なんですが、システムの複製と保全 という観点からは実は非常に厄介な問題とペアになっています。この問題の名前を 同期問題 といいます。
コンピューターシステムに限らず、多くの高信頼システムは多重化というデザインによって高信頼性を確保しています。Storage ですと Raid なんかがそうですね。Raid 1 から 5 までのデザインは、すべて
データを複数の HDD で重複して持たせよう。
そうすればひとつひとつの HDD は簡単に壊れても、
Raid 全体が提供できる機能は HDD 単体よりもずっと長持ちする。
安物のHDDをたくさん使う事でコストを下げれば
トータルで見たコストも下がるに違いない
そうすればひとつひとつの HDD は簡単に壊れても、
Raid 全体が提供できる機能は HDD 単体よりもずっと長持ちする。
安物のHDDをたくさん使う事でコストを下げれば
トータルで見たコストも下がるに違いない
というコンセプトで成り立っています。どう重複させるか、そのやりようが違うだけです。
このコンセプト、確かに正しいんですが、一つ弱点があります。たとえば Raid 1 のミラーを考えてください。あるセクター番号 xxxx にデータを書き込むとします。
HDD単体にデータを書き込む場合は、文字通りその HDD のセクター番号 xxxx に対応するセクターにデータを書き込めば終わりです。
しかしミラーリングをしている場合、Raid が仮想的に見せているセクター番号 xxxx に対応するセクターは複数(HDD の数だけ)あるはずです。並列に書き込めるとはいえ、ミラーリングにおいては全部のセクターに書き込みが終わらない限り、セクターへの書き込みが終わったといってはならないはずです。
たとえば、ある HDD ではデータ更新が完了しており、別の HDD ではデータ更新が完了していない状態で、「データ更新が完了した側の HDD が壊れたら」 Raid 全体としてはデータ書き込みがまだ終わっていない状態のセクターしか残っていないことになってしまいます。ここで、さらに電源断のような障害が発生したら、そのデータは完全にロストしてしまうでしょう。OS などに「書き込み終わったよ」と報告しておきながら、データがなくなってしまうのは許される状態ではありません。そのような Storage は信頼できないからです。
すべての HDD が所定のセクターへの書き込みが終わるまで待つ、というこのような動作を同期といいます。同期を必要とするシステムは全て、一番遅い奴に足を引っ張られるという特徴があります。結果として、平均IO速度は通常の HDD よりもどうしても遅くなってしまいます。
この問題は、SAS やNAS 一般に議論を拡張しても同じでして、データを保護する、となると2つ以上の Storage にデータを書くことになります。それぞれの Storage が『書き込み完了』と報告してくるはずですが、その報告が全てそろってからでないと、SAS として、あるいは NAS として、書き込みが完了したことにしてはいけないわけです。
天災などを回避するために、多重化した Storage のいくつかが、遠隔地に存在する場合、遠隔地との通信による遅延も発生します。一般に10m以内の計算機同士で通信するより、100km離れた場所にある計算機との通信のほうが遅くて、時間がかかるものです。
遠隔地での書き込みを待たずに処理を行う方法もあります。この場合、遠隔地にある Storage には最新のデータはおいてありません。何らかの理由で遠隔地の Storage を使う必要が出た場合、最新の更新データは一部失われることになります。どれぐらい失われるのか、というのは通信回線やシステムデザインとのご相談になりますし、それを許容できるかどうかはアプリケーションならびに計算機全体が提供するサービスの要求仕様に依存します。一般に距離の3乗に比例してコストは跳ね上がっていく、といわれます。
この同期問題を考えないで、SAS や NAS の複製を作りますと、検索するたびにあっちのマシンやこっちのマシンから別々なデータイメージが飛んできます。あるものは ver 2.0, べつのものは ver 6.2…ちゃんとバージョン管理されていてその情報も飛んでくるならいいほうです。いつのバージョンだか判らないものが飛んできた日には…もうどれを信頼すればいいのか、client からはさっぱり。
かといって、これらを信頼できるようにすると…今度はめちゃくちゃ遅いシステムになってしまう…そういうジレンマがあります。
さて、これに対して。CAS の場合はどうでしょう?
CAS の場合、ファイルの内容でファイルの本体を検索します。特にファイル内容の完全一致に対応するのが絶対条件。となりますと、面白い性質が出てきます。
CAS にはファイルを作る・消すという操作はありえても、更新可能性は無いんですよ。ファイルの内容を変更すると、それは別のファイルにせざるを得ない。なぜなら「変更前」のファイルを検索するために使える検索キーと、「変更後」のファイルを検索するために使える検索キーは違うから。検索キーが違っちゃうって事は、前の検索キーで更新後のファイルは探せないって事で…。
これを、CAS は WORM (Write Once Read Many) の性質がある、と表現します。
別の言い方をしましょう。 CAS に乗っているファイルは、全て ver 1.0 しか存在しない んです。
この性質は多重化された Storage の同期問題に画期的な解決策をもたらします。
話を簡単にするために、一番最初は手元の CAS Storage にしかコピーをおかないことを考えましょう。で、CAS システムは自動的に、かつダラダラと暇なときに、こいつのコピーをレプリカサーバーにコピーしていくとします。
あるとき、このファイルに対する検索をかけたとします。まぁ、もちろん手元の Storage が答えてくれてもいいんですが、たまたまこいつが手一杯だったとします。で、遠隔地のサーバーが答えた。「あるよ」って。
NAS や SAS の場合、
「それは本当に最新のもんですかぃ?」
と疑わなくちゃいけないんですが、CAS の場合この心配をしなくていい。
- ファイルの内容が変更できないから -
あるといわれたら、ある。ないといわれたら、ない。
したがって、CASの場合
- 取り合えず一番手近な Storage に書き込んでおく(この段階ではまだ信頼性は低い。データを失う可能性がある)。
- で、徐々にコピーを別の CAS にも分散させていく(時間が経つに従って信頼性があがっていく)
もし、ファイル共有ソフト…えー Bit Torrelant でも Winny でもいいんですが、使ったことが一度でもある人なら判るでしょう。この挙動、ファイル共有ソフトのそれと同じだ、という事がわかると思います。
これらのソフトにおいて、ファイルの「ファイル名」ってのはあまり意味を持ちません。同じファイル名の、ファイルサイズだの ID だのが違う代物がいっぱい出回っています。
でも、同じ ID のものは1種類しかない。最初誰かがこのファイルを ファイル共有のネットワークに登録したときに、割り振った ID があって、多分それはファイルのバイト列からhash値を作ってそれをベースに作っている。
ファイル共有ソフトはこのファイルのレプリカを周囲の PC に作っていく。自動的に、だらだらと。
で、どこかのPCがそのコピーが欲しい、と言ったら誰が持っているのか教えてくれるけれど、IDが中身から作られているから、IDが一致していれば中身は絶対一致していると考えていい。だから、いちいち中央サーバーなんか作らなくても P2P でファイルをダウンロードするので間に合う。
最初のうちは、コピーは1箇所ぐらいにしかないからそのPCが止まっている間は欲しいデータは入手できない。でも徐々にコピーが広まるに従って Servicability が向上して、いつでも手に入るようになる。また手近なマシンから手に入るようになるので、徐々にダウンロード速度もあがっていく。
CAS ってのは、このようなファイル共有ソフトのP2P通信の部分を取り除いたようなものだ、と表現することができます。
で、その CAS がファイルの一生とどう関わるのか? それは、刮目して待て、次号!!
#誰が少年探偵団だ。
0 件のコメント:
コメントを投稿