kumofsを利用する上での注意点
ぼくのかんがえたさいきょうの高ディスクI/Oマシン
という記事の続き。
上記記事でセットアップした仮想マシンで何やってたかというと、今回障害が発生したプロダクトではkumofsというKVSを利用しておりまして
The Kumofs Project
HAHAHA、見事に更新が止まってますね。
事象としては
kumo-serverが3台以上ダウンした
に当たります。
この際、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 - がしまっくす
kumofsを使うならここを熟読すべし。
@tmtms のメモ
attach、detachの動作の解説など
多分もうkumofs使うことないだろうなあ。