kumofs その５・スケールアウトしてみた

kumo-serverを２台のマシンへセットアップし、色々試してみました。

スケールアウト時のチェックポイントはserverのIPや名称等は必ず一意となるようにつける事です。
例えばmanagerを起動するサーバで
kumo-manager -v -l localhost
kumo-manager -v -l 127.0.0.1
とかやってしまうと失敗します。必ず自分のIPか一意のサーバ名としましょう。

前回接続が不安定だったのはSpymemcachedが原因でした。
memcached client for javaで接続したらエラーにならずにすみました。
んが、こちらの方が速度が遅いようです。

1台から2台にした結果、速度は遅くなりました。
まぁ２台ではボトルネックの方が大きくなってしまうのでしょうがないですね・・・

memcached client+2台状態での速度は以下のような感じでした。
Set
128,187ms

Get
112,314ms

どちらも大体同じくらいの速度で安定して動きました。
SetはHSQLDBより遅くなりましたね・・・
GetをチューニングしたらHSQLDBが最速になるかな？？と思って試してみました

Indexあり HSQLDB Get
637,811ms
622,084ms

Indexなしより４倍ぐらい早くなりましたが、kumofsと比べるとだいぶ遅いですね。
CouchDBより微妙に遅い程度なので、Grailsの中だけで使うDBという割当にCouchDBは向いていません。

続いて障害時の検証

memcached clientには複数のmemcachedをPoolして使う機能があります。
なのでkumo-gatewayを二つたてて二つをPoolして使ってみました。

マシン構成
server1 - kumo-manager , kumo-server , kumo-gateway
server2 - kumo-server , kumo-gateway

・すべてが稼働している状態からserver1or2のkumo-gatewayを落とす
正しく取得出来たり、Exceptionが出たり。
memcached clientでは接続先が落ちているかどうかまで判断はしてくれないようです。
A,Bどちらを落とした場合でも結果は同じです。

・すべてが稼働している状態からserver1or2のkumo-serverを落とす
何事もなかったかのように動作しました。

・片方のkumo-serverしか動いていない状態で、データを追加or変更し、落ちているkumo-serverを復旧させる
復旧した時点では not attached になっていますので、Aのマシンからattachします

kumoctl server1 attach

attach時にReplicationが行われ、アプリケーションからは常に変更後のデータが取得されます。
もちろんノンストップでいけます。

という事で、memcached clientのPoolは使わずに、公式のオススメどおりwebアプリとkumo-gatewayを1:1にし、kumofs側で障害対策をするのが良いようです。