第4回　分散環境でTokyoCabinetを動かす

kumofsの登場

前回は、TokyoCabinetを単体で動作させてみました。今回はTokyoCabinetを分散環境で動かしてみたいと思います。

TokyoCabinetのデータベースエンジン＋分散フレームワークの構成で構築されたアプリケーションがkumofsになります。こちらにkumofsのドキュメントがありますが、kumofsの特色をいくつかご紹介したいと思います。

kumofsの特色（ドキュメントから一部引用）

データは複数のサーバーにレプリケーションされます
データは複数のサーバーに分散して保存されます
一部のサーバーがダウンしても正常に動き続けます

→アベイラビリティの向上

システムを止めずにサーバーを追加できます
システムを止めずにダウンしたサーバーを復旧できます
2台から60台程度までスケールします（60台以上はまだ検証されていません）

→スケーラビリティの向上

シンプルなKVSとそれを横に拡散させる分散環境を組み合わせることによって

アベイラビリティの向上
スケーラビリティの向上

が実現されているようです。

それでは実際に環境を構築してみましょう。

kumofsのインストール

環境は前回インストールしたマシンと同様です。

OS	CentOS_5.4（32ビット）
必要なライブラリなど	Linux	2.6.18
	g++	4.1
	ruby	1.8.6
	Tokyo_Cabinet	1.4.10
	MessagePack_for_C++	0.3.1
	MessagePack_for_Ruby	0.3.1
	libcrypto_（openssl）
	zlib

基本的にkumofsのドキュメントに書かれているインストールガイドのまま進めていきます。TokyoCabinetのインストールは前回済んでいますね。まだの方は前回を参考にしてください。以下に、私の環境で必要だったものを記述しておきます。参考にしてください。

g++はCentOSの場合は、以下のようにインストールします。

# yum install gcc-c++

rubyのインストールは以下のように行います。

# yum install ruby
# yum install ruby-devel

注意

このとき、rubyのバージョンが1.8.6以上であることを確認してください。もし1.8.5の場合は以下の要領で1.8.6にupdateする必要があります。

/etc/yum.repos.d/ruby.repoを以下の内容で作成。

[ruby]
name=ruby
baseurl=http://repo.premiumhelp.eu/ruby/
gpgcheck=0
enabled=0

# yum --enablerepo=ruby install ruby ruby-rdoc ruby-devel

これで1.8.6になると思います。

gemのインストールは以下のように行います。

# wget http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz
# tar zxvf rubygems-1.3.1.tgz
# cd rubygems-1.3.1
# ruby ./setup.rb

libcrypt（openssl-devel）のインストールは以下のように行います。

# yum install openssl-devel

kumofsの構成

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

kumo-server	実際にデータを保存するノード。少なくとも1台必要です。後から追加できます。
kumo-manager	kumo-server群を管理するノード。1台または2台で動かします。
kumo-gateway	アプリケーションからのリクエストをkumo-serverに中継するプロキシ。アプリケーションを動かすホスト上で1つずつ起動しておきます。

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

サーバ	kumo-manager	kumo-server	kumo-gateway
serv1	○	○	－
serv2	○	○	－
serv3	－	○	○

kumofsの起動

kumo-managerの起動

まずkumo-managerを起動します。kumo-managerを起動するのはserv1, serv2の2台となります。

serv1でのkumo-managerの起動


$ kumo-manager -v -l serv1 -p serv2
2010-08-05 20:14:05 ./manager/init.h:43: start manager 192.168.47.101:19700
2010-08-05 20:14:07 ../rpc/client_tmpl.h:157: connecting to 192.168.47.102:19700
2010-08-05 20:14:07 ../rpc/client_tmpl.h:199: connect failed 192.168.47.102:19700: Connection refused
2010-08-05 20:14:07 ../rpc/client_tmpl.h:157: connecting to 192.168.47.102:19700
2010-08-05 20:14:07 ../rpc/client_tmpl.h:199: connect failed 192.168.47.102:19700: Connection refused
2010-08-05 20:14:07 ../rpc/client_tmpl.h:157: connecting to 192.168.47.102:19700
2010-08-05 20:14:07 ../rpc/client_tmpl.h:199: connect failed 192.168.47.102:19700: Connection refused
2010-08-05 20:14:07 ../rpc/client_tmpl.h:157: connecting to 192.168.47.102:19700
2010-08-05 20:14:07 ../rpc/client_tmpl.h:199: connect failed 192.168.47.102:19700: Connection refused
2010-08-05 20:14:07 ../rpc/client_tmpl.h:157: connecting to 192.168.47.102:19700
2010-08-05 20:14:07 ../rpc/client_tmpl.h:199: connect failed 192.168.47.102:19700: Connection refused
2010-08-05 20:14:07 manager/mod_network.cc:240: KeepAlive failed: 2
2010-08-05 20:14:09 ../rpc/client_tmpl.h:157: connecting to 192.168.47.102:19700
2010-08-05 20:14:09 ../rpc/client_tmpl.h:187: connect success 192.168.47.102:19700 fd(7)
2010-08-05 20:14:09 manager/framework.cc:69: new node 0 192.168.47.102:19700
2010-08-05 20:14:09 manager/framework.cc:78: partner connected 192.168.47.102:19700

serv2でのkumo-managerの起動

$ kumo-manager -v -l serv2 -p serv1
2010-08-05 20:14:09 ./manager/init.h:43: start manager 192.168.47.102:19700
2010-08-05 20:14:09 manager/framework.cc:69: new node 0 192.168.47.101:19700
2010-08-05 20:14:09 manager/framework.cc:78: partner connected 192.168.47.101:19700

serv2でkumo-managerが起動するまでコネクションエラーが発生していますが、serv2で起動した後はお互いがconnectedな状態になっています。ポートは19700を使用するようです。

kumo-serverの起動

続いてkumo-serverの起動をします。

serv1でのkumo-serverの起動

# kumo-server -v -l serv1 -m serv1 -p serv2 -s /var/kumodb.tch
2010-08-05 20:20:21 ./server/init.h:45: start server 192.168.47.101:19800
2010-08-05 20:20:23 ../rpc/client_tmpl.h:157: connecting to 192.168.47.101:19700
2010-08-05 20:20:23 ../rpc/client_tmpl.h:157: connecting to 192.168.47.102:19700
2010-08-05 20:20:23 ../rpc/client_tmpl.h:187: connect success 192.168.47.101:19700 fd(10)
2010-08-05 20:20:23 ../rpc/client_tmpl.h:187: connect success 192.168.47.102:19700 fd(11)
2010-08-05 20:20:23 server/framework.cc:74: new node 0 192.168.47.102:19700
2010-08-05 20:20:23 server/framework.cc:74: new node 0 192.168.47.101:19700

serv2でのkumo-serverの起動

# kumo-server -v -l serv2 -m serv1 -p serv2 -s /var/kumodb.tch
2010-08-05 20:23:48 ./server/init.h:45: start server 192.168.47.102:19800
2010-08-05 20:23:50 ../rpc/client_tmpl.h:157: connecting to 192.168.47.101:19700
2010-08-05 20:23:50 ../rpc/client_tmpl.h:157: connecting to 192.168.47.102:19700
2010-08-05 20:23:50 ../rpc/client_tmpl.h:187: connect success 192.168.47.102:19700 fd(11)
2010-08-05 20:23:50 ../rpc/client_tmpl.h:187: connect success 192.168.47.101:19700 fd(10)
2010-08-05 20:23:50 server/framework.cc:74: new node 0 192.168.47.102:19700
2010-08-05 20:23:50 server/framework.cc:74: new node 0 192.168.47.101:19700

serv3でのkumo-serverの起動

# kumo-server -v -l serv3 -m serv1 -p serv2 -s /var/kumodb.tch
2010-08-05 20:25:09 ./server/init.h:45: start server 192.168.47.103:19800
2010-08-05 20:25:11 ../rpc/client_tmpl.h:157: connecting to 192.168.47.101:19700
2010-08-05 20:25:11 ../rpc/client_tmpl.h:157: connecting to 192.168.47.102:19700
2010-08-05 20:25:11 ../rpc/client_tmpl.h:187: connect success 192.168.47.102:19700 fd(11)
2010-08-05 20:25:11 ../rpc/client_tmpl.h:187: connect success 192.168.47.101:19700 fd(10)
2010-08-05 20:25:11 server/framework.cc:74: new node 0 192.168.47.102:19700
2010-08-05 20:25:11 server/framework.cc:74: new node 0 192.168.47.101:19700

それぞれのサーバで19800ポートを使用してkumo-serverが起動しました。

kumo-serverの登録

kumo-serverは起動しましたが、kumoctlコマンドを使ってkumo-managerに登録という作業が必要になるようです。

# kumoctl serv1 status
hash space timestamp:
  Wed Dec 31 19:00:00 -0500 1969 clock 0
attached node:
not attached node:
  192.168.47.101:19800
  192.168.47.102:19800
  192.168.47.103:19800

kumo-serverの3台が見えていますが、not attached（登録されていない）状態です。これらを登録しましょう。

# kumoctl serv1 attach

確認してみます。

# kumoctl serv1 status
hash space timestamp:
  Thu Aug 05 21:01:58 -0400 2010 clock 1437
attached node:
  192.168.47.101:19800  (active)
  192.168.47.102:19800  (active)
  192.168.47.103:19800  (active)
not attached node:

すべて登録されました！

kumo-gatewayの起動

ここではserv3をアプリケーションを動かすホストとして動作させます。

serv3でkumo-gatewayの起動

$ kumo-gateway -v -m serv1 -p serv2 -t 11211
2010-08-05 21:11:21 ../rpc/client_tmpl.h:157: connecting to 192.168.47.101:19700
2010-08-05 21:11:21 ../rpc/client_tmpl.h:157: connecting to 192.168.47.102:19700
2010-08-05 21:11:21 ../rpc/client_tmpl.h:187: connect success 192.168.47.102:19700 fd(8)
2010-08-05 21:11:21 ../rpc/client_tmpl.h:187: connect success 192.168.47.101:19700 fd(7)

続けてポートが開いてるか確認してみます。

$ netstat -ant | grep 11211
tcp        0      0 0.0.0.0:11211               0.0.0.0:*                   LISTEN

大丈夫そうです。11211ポートが開放されていますね。これでアプリケーションを動かすホストとしては、ローカルにmemcachedが立ち上がっているのと同じように見えています。

kumofsを使ってみる

それではperlを使用して実際にkumofsを使用してみましょう。

kumofsはバックエンドにTokyoCabinetを使用していますが、データのやりとりのプロトコルはmemcachedと同じモノを使用しています。そのため、特別なクライアントが必要なわけではなく、memcachedクライアントがあれば使用することが可能となります。今回kumo-gatewayが動いているのはserv3になりますので、serv3で次のようなスクリプトを動かしてみます。

#!/usr/bin/perl

use strict;

use Cache::Memcached::Fast;

memcacheのモジュールをuseします。

my $key = "name";

my $c = Cache::Memcached::Fast->new({servers=>['localhost:11211']});

localhostの11211ポートを指定してインスタンスを生成します。localhostの11211ポートは先ほどkumo-gatewayでオープンされたポートですね。

$c->set($key,"wakimoto");

if( my $val = $c->get($key) )
{
        print "$key is ", $val,"\n";
}

putしてget。

ちゃんと

name is wakimoto

が表示されました。

perlから見るとローカルホストのmemcachedとしてしか見えていませんが、そのバックエンドでは実は3台のサーバに分散されているということになります。不思議な感じですね！

次回はもう少し踏み込んで、アベイラビリティ、スケーラビリティについて操作をしてみたいと思います。