次どうする

WikiForme 0.2をリリースした今日この頃、次どうするか。


分散ファイルシステムの件、最近まったく進んでない。どうやら人間はシングルタスクらしいので、別のことをやっていると進まない。２つぐらいできるかなーと思ったけど、やっぱりできないらしい。うげ。


その分散ファイルシステムで、やっぱり分散ブロックデバイスの方がいい気がした。ファイルシステムレイヤーはGFSかOCFS2にお任せ。あるいはファイルシステム無しでAPIで呼ぶ。
というのも、２カ所から同時に書き込みがあったときに、レプリケーションされたデータが同じになることを保証する処理が、どうしても思いつかない。コレさえできればコードが書けるハズなんだけども…。


数珠つなぎにノードをつなげるまではいいとして、そこに２カ所から同時にデータが投げ込まれる。Google FileSystem的に、数珠のノード数を3台に限定するとか、そういう制限が２つくらい無いと厳しい。
一応うまく動くハズの解決策は、書き始めのノードと、データを回していくノードの順番を、固定する方法。それから、データを回していくときに、先に回っているデータを抜かない。この方法の問題は、書き始めのノードを誰にするのか、書き始めのノードが落ちたらどうするか、そして数珠の中のノードが書き込みを行うと無駄な通信が発生する点。書き始めのノードが落ちたら、その次のノードを自動的に書き始めのノードに昇格すればいいけども、実は落ちていなかったら困る。


無駄な通信が発生するというのは、数珠がA→B→C(→A)となっているときに、Bが書き込みを行うと、B→A→B→Cと通信が発生して、A→Bの分が無駄。それからBはB→AとB→Cを同時に行わないといけないから、スループットが落ちる。
ただこの問題は、数珠の中から書き込みを行わなければ発生しない。ストレージを持っているマシンと持っていないマシンは役割が違うはずなので、問題ないかもしれない。


書き始めのノードが落ちると、困る。でも実際そこのところは、どういう方法にしようと発生する問題ではある。