kumofs の attach, detach - tmtms のメモ

最近 kumofs の attach, detach 時の動きについて調べてます。

kumo-manager のログ

kumo-manager の「lost node」のログにバイナリコードが含まれてます。

2011-05-14 23:00:00 manager/framework.cc:97: lost node XX 127.0.0.1:19803

この「XX」の部分が 0x01 になっています。この値が何を意味するのかはわかってませんが、たぶんバグだと思います。こんな感じで直りました。
https://github.com/tmtm/kumofs/commit/5d9dc75f9e386620bde72a16a4fedcfde7132770

kumo-server のログ

attach, detach 時に以下のようなログが大量に出力されます。

2011-05-14 22:39:55 server/mod_replace.cc:291: current_owners.empty() || current_owners.front() != self

おそらく、自ノードにあるデータのうち、自ノードがプライマリノードでないものがあるとこれを出力しています。
でもノードが保持しているデータの 2/3 は複製データ(プライマリノードでないデータ)なので、これをログに出力する意味はありません。たぶん。
こんな感じで直りました。というか元に戻しただけですが。
https://github.com/tmtm/kumofs/commit/0095ae93b83af1768a5b8b529b8e2faac8322b92

kumoctl status と kumostat の違い

kumo-server の状態を調べるには、kumoctl status コマンドと kumostat コマンドがあります。
当初なんで2つ用意されているのかわからなかったのですが、わかったような気がします。
kumoctl status は kumo-manager が認識しているサーバーの状態を表示するのに対し、kumostat は各サーバーが自分の状態を表示します。

なので、kumoctl status で、あるサーバーが fault になっていても、kumostat では ready になっていることがあり得ます。

監視する時には両方のコマンドを確認した方が良いでしょう。

attach 時の動き

サーバー(ノード)を attach した時の動きを調べてみました。

自ノードが保持しているデータのうち、自ノードがプライマリノードであるデータで、かつ、新しく attach されたノードも複製を持つべきデータについて、すべてを一時ファイルに作成します。一時ファイルは送るべきノード単位に作られます。(Copying)
一時ファイルを作成し終えると、新ノードに送信します。
新ノードは送られたファイルからデータを登録します。
全ノードが Copying 処理を完了し、新ノードがデータを登録し終えるまで待ちます (WAIT)
自ノードが保持しているデータのうち、不要になったデータを削除します (Deleting)
通常の状態になります (ready)

括弧の中は kumotop の status 欄または kumostat replstat で表示されるものです。

detach 時もほぼ同じ動きです。データをコピーする相手が新しいノードではなく、すべての既ノードになるだけです。

少数のサーバーで大量のデータを保持している場合は、一時ファイルがかなり大きくなってしまいます。一時ファイルはデフォルトでは /tmp に作成されますが、/tmp に余裕がない場合は kumo-server の --offer-tmp オプションで別のディレクトリを指定しておくのが良いでしょう。

また、コピーするデータを全部作成してから送るのではなく、少しずつ送る方法もあります。kumo-server の --replace-memory-limit オプションを指定すると、コピーするデータが指定サイズ(MB単位)に達するとその時点で新サーバーに送られるようになります。ただし、このオプションはドキュメントには載っていないようです。

attach 中のデータ参照＆登録

kumofs はノードとデータの分散用のハッシュスペースとして、参照用のハッシュスペース(rhs)と、登録用のハッシュスペース(whs)の2つを使用します。

ノードを attach, detach すると、データの再配置が完了するまでの間は、rhs は古いまま、whs は新しいものになります。

既存のデータの参照については rhs を見れば良いので問題ありません。新しいデータは登録時は whs が示すノードに書かれて、参照時は rhs が示すノードを見ます。異なるノードを見ることになって問題はないのでしょうか。

おそらく通常は問題ないと思います。なぜなら、whs のプライマリノードに登録されたデータは、プライマリノードの次のノードにもコピーされますが、このノードは rhs では該当データに関するプライマリノードだったはずだからです。

問題となり得るのは 3台以上のノードを一度に attach する場合です。この場合は whs のプライマリノードとコピーされるノードがすべて新しいノードになってしまう可能性があるためです。もしかしたら kumofs はそういう場合のこともちゃんと考慮して作られているかもしれませんが、わかりませんでした。

さいごに

kumofs の attach, detach の動きについて調べてみました。
自分は C++ を満足に読めないので、kumofs のソースをちゃんと読めている自信はないです。なので、上に書いてあることは間違ってるかもしれません。
もし間違いを見つけたら教えていただければ嬉しいです。