shimxmemo

メモをのこすよ!

kumofsを利用する上での注意点

ぼくのかんがえたさいきょうの高ディスクI/Oマシン

http://shimx.hateblo.jp/entry/2013/09/11/194409 

 という記事の続き。

 

上記記事でセットアップした仮想マシンで何やってたかというと、今回障害が発生したプロダクトではkumofsというKVSを利用しておりまして

The Kumofs Project

http://kumofs.sourceforge.net/ 

 HAHAHA、見事に更新が止まってますね。

 

事象としては

kumo-serverが3台以上ダウンした

https://github.com/etolabo/kumofs/blob/master/doc/doc.ja.md

 に当たります。

 

この際、full-replaceサブコマンドを発行しろと書いてあるのですが、いかんせんサーバスペック的に時間がかかりすぎる、と。

 

なので、kumomergedbというコマンドを使って、複数サーバに分散させているデータベースファイルを1つにマージさせる手法を取りました。

 

full-replaceは分散されているデータの再配置を行っており(という理解をしている)、データを全部マージして1つのデータベースファイルにして、各サーバに配置すれば同様の結果になりますので(ファイルサイズはともかく)。

 

そもそも「バックアップとるだろJK」という声も聞こえますが、データベースファイルが肥大化しすぎて、バックアップするとサービス止まるという悲惨な状況に。

サーバを追加しようとしても、attachコマンド発行すると追加したサーバにデータを配置しようとしてトラフィックがえらいことになりパフォーマンスが低下、結果サービスが止まるという。

初期設計のミスでした。ほんとごめんなさいごめんなさいごめんなさい。

ここでkumomergedbコマンドを使う上での注意点があります。

 

kumofsを利用した事のある人には常識ですが、kumofsが利用しているTokyoCabinetには64GBの壁というものが存在します。 

TokyoCabinet 64GBの壁

http://ameblo.jp/cyberx-engineer/entry-10688375059.html

64bit環境で容量64GB以上のTokyoCabinetのデータファイルを扱うには、

HDBTLARGEオプションを指定する必要があるようです。 

この壁、実はkumomergedbする際に出力するファイルが64GB超えた場合にも存在します。

 公式ドキュメントには

$ kumomergedb backup.tch-20090101 \
              server1.tch-20090101 server2.tch-20090101 server3.tch-20090101

と書いてありますが、この

backup.tch-20090101

が64GBを超えると、データが書き込めなくなり、その先処理がいつまでたっても進まなくなります。

 

この場合、

$ tchmgr create -tl backup.tch-20090101 400000000
$ kumomergedb backup.tch-20090101 \
              server1.tch-20090101 server2.tch-20090101 server3.tch-20090101

と、事前にHDBTLARGEオプションをつけて空の出力ファイルを作っておくか、

 

$ cp -ap server1.tch-20090101 backup_tenuki.tch-20090101
# server1.tch-20090101があらかじめHDBTLARGEオプションを指定して作られたデータファイルならここでoptimizeの必要多分なし
$ tchmgr optimize -nl -tl backup_tenuki.tch-20090101 400000000
$ kumomergedb backup_tenuki.tch-20090101 \
              server2.tch-20090101 server3.tch-20090101
# deleteフラグ立ってるけど消えてないデータとか?余計なデータが混ざるようなのでもう一度optimizeすると前者と同じファイルになるよ
$ tchmgr optimize -nl -tl backup_tenuki.tch-20090101 400000000

とmergeする前にoptimizeかけて、そのファイルを出力先にするという、横着するのもありですね。

 

両方試して、できたファイルに対しsha512sumでハッシュを計算、チェックサムを比較したところ同じでした)

$ sha512sum backup.tch-20090101
d6328ab93e1638f74d5c8c61c3f16894e83c6fbe8b31f226e0aa7765a72f886c2c2764c7572a44543119320d3917a48b6671cf5733b29ca1d05e234e800af3a8
$ sha512sum backup_tenuki.tch-20090101
d6328ab93e1638f74d5c8c61c3f16894e83c6fbe8b31f226e0aa7765a72f886c2c2764c7572a44543119320d3917a48b6671cf5733b29ca1d05e234e800af3a8

 

 

他注意点。

 

kumofsはCentOS 6には普通にやってはインストールできません。

kumofs on CentOS6

http://blog.developerlabs.net/2013/02/kumofs-on-centos6.html

0.5.0 から msgpack の executeメソッドが使えず

/usr/local/bin/kumoctl:61:in `receive_message': undefined method `execute' for # (NoMethodError)

が出てくるので 0.4.7が必須です

どはまりした際、本当に助かりました…

 

こんな感じでインストールしました。

yum -y install libtool.x86_64 openssl.x86_64 openssl-devel.x86_64 zlib.x86_64 zlib-devel.x86_64 bzip2-devel.x86_64

cd /usr/local/src
tar zxvf ncurses-5.6.tar.gz
cd ncurses-5.6
./configure --with-shared --without-normal --without-debug
make
make install
ldconfig

cd /usr/local/src
tar zxfv ruby-1.9.3-p125.tar.gz
cd ruby-1.9.3-p125
./configure --prefix=/usr/local/ruby
make
make install

echo /usr/local/ruby/lib > /etc/ld.so.conf.d/ruby.conf
ldconfig

cd /usr/local/src
tar zxfv rubygems-1.8.24.tgz
/usr/local/src/rubygems-1.8.24
/usr/local/ruby/bin/ruby setup.rb

cd /usr/local/src
tar zxfv msgpack-0.5.0.tar.gz
cd /usr/local/src/msgpack-0.5.0
./configure --prefix=/usr/local/msgpack
make
make install
echo /usr/local/msgpack/lib > /etc/ld.so.conf.d/msgpack.conf
ldconfig

/usr/local/ruby/bin/gem install msgpack -v=0.4.7

cd /usr/local/src
tar zxfv tokyocabinet-1.4.45.tar.gz
cd /usr/local/src/tokyocabinet-1.4.45
./configure --prefix=/usr/local/tokyocabinet
make
make install
echo /usr/local/tokyocabinet/lib > /etc/ld.so.conf.d/tokyocabinet.conf
ldconfig

cd /usr/local/src
tar zxfv ragel-6.6.tar.gz
cd /usr/local/src/ragel-6.6
./configure --prefix=/usr/local/ragel
make
make install
ln -s /usr/local/ragel/bin/ragel /usr/bin/ragel

mkdir /usr/local/kumofs
cd /usr/local/src
tar zxvf kumofs-0.4.13.tar.gz
cd kumofs-0.4.13
./configure --prefix=/usr/local/kumofs/kumofs0413 --with-msgpack=/usr/local/msgpack --with-tokyocabinet=/usr/local/tokyocabinet
make
make install
ln -s /usr/local/kumofs/kumofs0413 /usr/local/kumofs/default

 

他に、サーバは生きているけどネットワークに障害が起こったケースも注意が必要です。

下記のようなkumo-managerが関わる障害が発生したと仮定

---------------
ネットワーク1
KMGR-1  KSV-1
        KSV-2
        KSV-3
        KSV-4
---------------
ネットワーク2
KMGR-2  KSV-5
        KSV-6
---------------

というようにネットワークが分かれていて、スイッチ等が故障してネットワーク1からネットワーク2に接続できなくなった場合

---------------
ネットワーク1
KMGR-1  KSV-1
        KSV-2
        KSV-3
        KSV-4
KMGR-1「あれ、KSV-5、KSV-6の2台死んだぞ?だがまだいける!」
---------------
ネットワーク2(死亡)
KMGR-2  KSV-5
        KSV-6
KMGR-2「あれ、KSV-1からKSV-4まで4台死んだぞ?full-replace必要だわー!」
---------------

という状態になります。

で、このまま復旧、ネットワーク1からネットワーク2につながるようになり、replaceサブコマンドを発行すると、

---------------
ネットワーク1
KMGR-1  KSV-1
        KSV-2
        KSV-3
        KSV-4
KMGR-1「あれ、KSV-1からKSV-4まで4台死んだぞ?full-replace必要だわー!」(<- KMGR-2から同期)
---------------
ネットワーク2
KMGR-2  KSV-5
        KSV-6
KMGR-2「あれ、KSV-1からKSV-4まで4台死んだぞ?full-replace必要だわー!」
---------------

という事も起きえます。

 

ドキュメントには「まずダウンしたkumo-managerを再起動してください」と書いてありますが、ネットワーク障害が復旧してからkumo-managerを再起動させるか、プロセスを殺しておいて復旧してから起動、replaceサブコマンドを発行しょう。

 

なかなかこんな事ないとは思いますが。

 

以下、要参照。

kumofs - がしまっくす

http://www.gashimax.com/wiki/index.php?kumofs

 kumofsを使うならここを熟読すべし。

@tmtms のメモ

http://tmtms.hatenablog.com/category/kumofs

 attach、detachの動作の解説など

 

多分もうkumofs使うことないだろうなあ。