前回はkumofsを用いて分散環境を構築し、単純に動作させるところまで書きましたが、
今回はkumofsのスケーラビリティ、アベイラビリティという視点で操作してみます。
■kumofsのスケーラビリティ
前回、3台の構成でkumofsを動かしました。
おさらいしておくと以下のような構成となっています。
--
kumofsは3種類のデーモンで構成されます。
kumo-server 実際にデータを保存するノード。少なくとも1台必要です。後から追加できます。
kumo-manager kumo-server群を管理するノード。1台または2台で動かします。
kumo-gateway アプリケーションからのリクエストをkumo-serverに中継するプロキシ。アプリケーションを動かすホスト上で、１つずつ起動しておきます。
ここでもドキュメントのチュートリアルに従って、進めたいと思います。
私の環境でも同様に3台のサーバを用いて環境を構築します。
serv1, serv2: kumo-manager
serv1, serv2, serv3: kumo-server
serv3: kumo-gateway
--
この構成に新規にserv4を追加してみたいと思います。
また、追加時にどのようなオペレーションが必要となるか、データの損失が無いかを確認してみましょう。
serv4に前回と同様に環境をセットアップします。
こういうときに仮想マシンは便利ですね。コピペ感覚で新規マシンを立ち上げられるんですから。
今回新たにserv4を作成しました。
これを用いて下記のような構成をとってみます。
--
serv1, serv2: kumo-manager
serv1, serv2, serv3, serv4: kumo-server
serv3: kumo-gateway
--
その前に前回の構築状態を確認してみたいと思います。
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を順番に停止させて様子を見てみます。
--
serv1, serv2→停止: kumo-manager
serv1, serv2→停止, serv3, serv4→停止: kumo-server
serv3: kumo-gateway
--
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と分散環境のなしえる妙ということでしょう。