前回はkumofsを用いて分散環境を構築し、単純に動作させるところまで書きましたが、今回はkumofsのスケーラビリティ、アベイラビリティという視点で操作してみます。

kumofsのスケーラビリティ

前回、3台の構成でkumofsを動かしました。おさらいしておくと、以下のような構成となっています。

kumofsは3種類のデーモンで構成されます。

ここでもドキュメントのチュートリアルに従って、進めたいと思います。私の環境でも同様に3台のサーバを用いて環境を構築します。

この構成に新規にserv4を追加してみたいと思います。また、追加時にどのようなオペレーションが必要となるか、データの損失が無いかを確認してみましょう。

serv4に前回と同様に環境をセットアップします。こういうときに仮想マシンは便利ですね。コピペ感覚で新規マシンを立ち上げられるんですから。ここでも前回と同様にこちらを参考に手順を進めてみます。

今回新たにserv4を作成しました。これを用いて下記のような構成をとってみます。

その前に、前回の構築状態を確認してみたいと思います。kumofsには便利なユーティリティが付属しており、サーバの状態を把握することができます。

分散環境のどのサーバにデータが格納されているかを確認してみたいと思います。現在の構成は3台がkumo-serverです。さらにレプリケーション数も3となっていますので、1つのデータが3台のサーバに分散されることになります。

確認のコマンドはkumohashを使用します。

[waki@serv1 $ kumohash -m serv1 assign name
ca2d0d2a5599e96a name
0: 192.168.47.101:19800
1: 192.168.47.102:19800
2: 192.168.47.103:19800

nameというキーのデータはserv1, serv2, serv3に分散されていることがわかります。レプリケーション数とあっていますね。問題なさそうです。

それではサーバの追加です。serv4でkumo-serverを起動し、serv1でattachするという順序です。

# kumo-server -v -l serv4 -m serv1 -p serv2 -s /var/kumodb.tch

serv1でステータスを確認します。

$ kumoctl serv1  attach

新たにサーバが追加されました。非常に簡単ですね。

[waki@serv1$ kumoctl serv1 status
hash space timestamp:
  Fri Aug 13 19:57:04 -0400 2010 clock 43217
attached node:
  192.168.47.101:19800  (active)
  192.168.47.102:19800  (active)
  192.168.47.103:19800  (active)
  192.168.47.200:19800  (active)
not attached node:

ageというキーでデータを登録してみて、データがどのサーバに保存されたか確認してみます。

[waki@serv1 $ kumohash -m serv1 assign age
728661ab9a6bc55d  age
  0: 192.168.47.200:19800
  1: 192.168.47.102:19800
  2: 192.168.47.101:19800

新たに追加したサーバにデータが分散して登録されているようです。レプリケーション数3もそのまま有効ですね。

また既存のキーであるnameも調べてみるとデータを保持するサーバの構成が変わっていました。新規サーバ追加など構成変更が発生した場合は、データの再分散が行われるようです。これは後で出てきますが、consistent-hashingというアルゴリズムが使用されています。

kumofsのアベイラビリティ

それでは今度は障害が発生した想定で、サーバの数を減らしてみましょう。レプリケーション数が3ですので、2台までのサーバがいなくなっても正常に動作するはずです。

まずは現状の確認です。

[waki@serv1$ kumoctl serv1 status
hash space timestamp:
  Fri Aug 13 19:57:04 -0400 2010 clock 43217
attached node:
  192.168.47.101:19800  (active)
  192.168.47.102:19800  (active)
  192.168.47.103:19800  (active)
  192.168.47.200:19800  (active)
not attached node:

4台とも正常に動作しています。

それでは、以下の構成からserv2, serv4を順番に停止させて様子を見てみます。

まずserv2を停止させました。statusを確認すると、serv2がfault状態になります。

[waki@serv1 $ kumoctl serv1 status
hash space timestamp:
  Sat Aug 14 00:23:30 -0400 2010 clock 51211
attached node:
  192.168.47.101:19800  (active)
  192.168.47.102:19800  (fault)
  192.168.47.103:19800  (active)
  192.168.47.200:19800  (active)
not attached node:

新たにキー：hoge、バリュー：fugaでデータを登録、取得してみます。問題なく動作しているようです。

続けてserv4も停止させます。

[waki@serv1$ kumoctl serv1 status
hash space timestamp:
  Sat Aug 14 00:41:05 -0400 2010 clock 51746
attached node:
  192.168.47.101:19800  (active)
  192.168.47.102:19800  (fault)
  192.168.47.103:19800  (active)
  192.168.47.200:19800  (fault)
not attached node:

2台いなくなってもデータの登録、取得に問題ありません。

次に、レプリケーションでどのサーバに分散されたか確認してみます。

[waki@hadoop1 $ kumohash -m hadoop1 assign hoge
44f81bcbdb0df331  hoge
  0: 192.168.47.102:19800
  1: 192.168.47.103:19800
  2: 192.168.47.200:19800

serv2が落ちいてるはずなのに、serv2にレプリカが作成されたことになっていますね？

kumofsの分散ロジックにはconsistent hashingというロジックが使われており、サーバIPのハッシュ値とキーのハッシュ値の比較によりどのサーバにどのキーが格納されるかが決定されるようになっています。ここでの表示はconsistent hashingの計算結果が表示されているということだと思われます（実際にはserv2にデータのレプリカは存在しないので⁠）⁠。

それでは元の4台構成に戻してみましょう。serv2, serv4のデータベースファイルを削除し、kumo-serverを起動、attachし直します。

[waki@serv1$ kumoctl serv1 status
hash space timestamp:
  Sat Aug 14 01:54:43 -0400 2010 clock 53970
attached node:
  192.168.47.101:19800  (active)
  192.168.47.102:19800  (active)
  192.168.47.103:19800  (active)
  192.168.47.200:19800  (active)
not attached node:

無事復活しました。データの登録、取得も問題ありません。

このような感じで使ってみましたが、スケーラビリティ、アベイラビリティともに必要最小限のオペレーションで実現できている感じがします。いわゆるRDBMSではこのように簡単にサーバを追加したり、レプリケーションの復旧はできません。

これがシンプルなNoSQLと分散環境のなしえる妙ということでしょう。