GlusterFSでサーバのIPが変わってしまった場合の対処方法

GlusterFSでreplicaモードでVolumeを動作させていた際
1つのサーバがダウンしてしまい同じIPで起動できない場合の対処方法

まずは、peerに新サーバIPを追加

$ gluster peer probe 10.153.57.98
Probe successful

次に、Volume名をlogsとして、replace-brickしちゃえば置き換えられるかと思ったのですが怒られちゃいました(´・ω・`)

$ gluster volume replace-brick logs <故サーバIP>:/brick <新サーバIP>:/brick start
brick: <故サーバIP>:/brick does not exist in volume: logs

そこで、既存Volumeを削除して同じ名前で再作成するというアプローチをとってみました

$ gluster volume stop logs
Stopping volume will make its data inaccessible. Do you want to continue? (y/n) y
Stopping volume logs has been unsuccessful

ロックが掛かっていたりするとVolumeを停止できないそうなので、glusterdを再起動してみます

$ service glusterd stop
glusterd を停止中:        [  OK  ]
$ service glusterd start
glusterd を起動中:        [  OK  ]

そして、Volume停止をリトライ

$ gluster volume stop logs
Stopping volume will make its data inaccessible. Do you want to continue? (y/n) y
Stopping volume logs has been successful

今度は成功！
続いて、既存Volumeの削除

$ gluster volume delete logs
Deleting volume will erase all information about the volume. Do you want to continue? (y/n) y
Deleting volume logs has been successful

故サーバIPをpeerから削除

$ gluster peer detach 10.153.57.194
Detach successful

あとは、Brickとして利用していたディレクトリからGFS関連の情報を削除

$ rm -rf /brick/.glusterfs

そして、Volume作成

$ gluster volume create logs replica 2 <既存サーバIP>:/brick <新サーバIP>:/brick
/brick or a prefix of it is already part of a volume

怒られちゃいました(´・ω・`)
attributeも変更しないといけないようなので変更

$ setfattr -x trusted.glusterfs.volume-id /brick
$ setfattr -x trusted.gfid /brick

Volume作成リトライ

$ gluster volume create logs replica 2 <既存サーバIP>:/brick <新サーバIP>:/brick
Creation of volume logs has been successful. Please start the volume to access data.

今度はうまくいきました！
あとは、Volumeをstart

$ gluster volume start logs
Starting volume logs has been successful

Volumeの情報を確認

gluster volume info logs
 
Volume Name: logs
Type: Replicate
Volume ID: 28fcf9b5-c4d3-4a41-9161-56fd3a1f2eac
Status: Started
Number of Bricks: 1x2=2
Transport-type: tcp
Bricks:
Brick1: <既存サーバIP>:/brick
Brick2: <新サーバIP>:/brick

オンサービスのままGlusterFSのVolume容量追加してみた

EC2上の2台のサーバから1つずつbrickを提供しレプリケーションモードで動作させているVolumeに、オンサービスのまま容量を追加するという処理を行ってみました。 最初に試したのは、サーバに既存のBrick(/gfs)よりもサイズが大きい新たなEBSを追加し、これを/gfs2にマウントして既存のBrickと置換するという方法。 小さいファイル数個のおためし環境では

gluster volume replace-brick vol1 x.x.x.x:/gfs x.x.x.x/gfs2 start

で、置換開始

gluster volume replace-brick vol1 x.x.x.x:/gfs x.x.x.x/gfs2 status

で、completeになったことを確認

gluster volume replace-brick vol1 x.x.x.x:/gfs x.x.x.x/gfs2 commit

で、コミット の手順でうまくいったので、実際の環境に試してみました 10GBのVolumeには1.5GBぐらいのデータが書き込まれている状態です

gluster volume replace-brick vol1 x.x.x.x:/gfs x.x.x.x/gfs2 start

コマンドは通ったのですが、みるみるcpu使用率が上昇しコンソール操作もままならない程になってしまいました。 このとき利用していたインスタンスタイプはc1.mediumです。
1時間程経過しても処理は終わらないので一時停止

gluster volume replace-brick vol1 x.x.x.x:/gfs x.x.x.x/gfs2 pause

これでとりあえず負荷は下がったのですが、1GB程の一時領域に書き込みつつreplaceが行えるように待機をしている状態のようでした。
このままではよろしくないと、完全にキャンセルしてみました

gluster volume replace-brick vol1 x.x.x.x:/gfs x.x.x.x/gfs2 abort

それはそれで、マシンリソースを喰いまくり、コマンドライン操作を受け付けないほどになってしまったのでデーモン停止(´・ω・`)

service gluster stop

[失敗] だそうな。。。 なので仕方なくpkillしました

pkill gluster

このあと、安定状態に戻すまでかなりの奮闘をしたのでこの方法は避けた方が良さそうです。 次は、上手くいった方法 Volumeに容量の大きなBrick(/gfs2)を追加し、既存のBrick(/gfs)を削除するという方法

gluster volume add-brick vol1 x.x.x.x:/gfs2 y.y.y.y./gfs2

すんなり追加されました つづいて、既存のBrickを削除

gluster volume remove-brick vol1 x.x.x.x:/gfs y.y.y.y./gfs start

startをつけることで、安全にBrickを削除できるように削除対象ではないところにデータを移動してくれるようです。 cpu使用率が上昇しましたが、replaceのようにコンソール操作を受け付けなくなる程ではありませんでした。

gluster volume remove-brick vol1 x.x.x.x:/gfs y.y.y.y./gfs status

で、状態を確認しながらcompleteになるまで待機 8GB程データがある状態で40分程で終了しました あとはコミットするだけ

gluster volume remove-brick vol1 x.x.x.x:/gfs y.y.y.y./gfs commit

これで無事にオンサービスのまま容量を追加することができましたよヾ(*･ω･)ｼ

GlusterFS3.3の挙動を調査してみた

前提条件として
クライアントは１台
GlusterFSクラスタは3つのトラステッドピアから成る
各ピアは１つのブリックを提供している
各ピアはレプリケーションモードでボリュームを構成

$ gluster volume create volume1 replica 3 10.x.x.x:/brick 10.x.x.y:/brick 10.x.x.z:/brick 
$ gluster volume info volume1

Volume Name: volume1
Type: Replicate
Volume ID: xxxxxx
Status: Started
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: 10.x.x.x:/brick
Brick2: 10.x.x.y:/brick
Brick3: 10.x.x.z:/brick

gfs.hoge.netのAレコードに3つのトラステッドピアのIPアドレスを登録

$ nslookup gfs.hoge.net

Non-authoritative answer:
Name:   gfs.hoge.net
Address: 10.x.x.x
Name:   gfs.hoge.net
Address: 10.x.x.y
Name:   gfs.hoge.net
Address: 10.x.x.z

クライアント側ではホスト名でマウント

$ mkdir /gfs
$ mount -t glusterfs gfs.hoge.net:/volume1 /gfs

■クライアント側で新しいファイルを作成したときの挙動
クライアントから3つのピアに対してデータが転送された

■クライアントからファイルを読み取った場合の挙動
いずれか１つのピアから転送された
連続して同じファイルを読み取る場合は転送元となるピアは同一であった
連続して同じファイルではない場合は転送元となるピアはランダムに変化した

■ピアが落ちている間にファイルが作成され、ピアが復活した場合
復活後すぐに作成されたファイルと同一名の空っぽのファイルが復活したピアのブリック上に作成される
クライアント側でlsなどのファイル操作を行うといずれかのピアからファイルが転送された

■ピアを新たに追加し、volumeにreplicaモードで追加した場合
追加した瞬間はなにも起こらない
クライアント側でファイルの追加や更新を行うとそのファイルだけ新しいピアにも転送された
クライアント側でlsを行うと既存のピアからクライアント経由で既存のファイル群が転送された

GlusterFSとnfsを比較実験してみた

AWS上でサーバ1台とクライアント3台という構成で実験してみました
各サーバのスペックは

• nfs,GlusterFSサーバ:t1.micro(ap-northeast-1a)
• クライアント1:m1.small(ap-northeast-1b)
• クライアント2:m1.small(ap-northeast-1a)
• クライアント3:c1.medium(ap-northeast-1a)

という感じでクライアント1だけ別のAvailability Zoneで立てています
サーバのローカルディスクをGlusterFSとnfsそれぞれでマウントしてパフォーマンスと整合性について実験してみます
クライアント1～3でaaaaaaaa,試行回数を同じファイルに60秒間出力するようなコマンドを実行します

start=`date "+%s"`;i=1;while true; do echo aaaaaaaa,$i >> /gfs/test.log ;now=`date "+%s"`;if [ `expr $now - $start` -gt 60 ];then break;fi;i=`expr $i + 1`;done

aaaaaaaaの部分はクライアント1ではa,2ではb,3ではcと置き換えて実行しました
出力先の/gfsはGlusterFSでマウント
/nfsはnfsでマウントした領域です
結果は
GlusterFSでマウントした方は

$ wc -l /gfs/test.log
15841 /gfs/test.log
$ tac /gfs/test.log | grep aaa -m 1
aaaaaaaa,7639
$ tac /gfs/test.log | grep bbb -m 1
bbbbbbbb,4171
$ tac /gfs/test.log | grep ccc -m 1
cccccccc,4031

となり、15841=7639+4171+4031と整合性が保たれているようです
nfsマウントした方は

$ wc -l /nfs/test.log
5461 /nfs/test.log
$ tac /nfs/test.log | grep aaa -m 1
aaaaaaaa,2504
$ tac /nfs/test.log | grep bbb -m 1
bbbbbbbb,1678
$ tac /nfs/test.log | grep ccc -m 1
cccccccc,2484

となり、5461≠2504+1678+2484=6666となりファイルに不整合がでています
パフォーマンスも1/3ぐらいしかでませんでした

CentOSにGlusterFSをセットアップ

Amazon Web Servicesなどのクラウドサービスでも利用できる分散ファイルシステムなGlusterFSをAmazon EC2上のCentOSにセットアップしてみました
まずはソースコードをダウンロードしてきて展開してconfigure

wget http://download.gluster.org/pub/gluster/glusterfs/LATEST/glusterfs-3.3.0.tar.gz
tar zxvf glusterfs-3.3.0.tar.gz
cd glusterfs-3.3.0
./configure
・
・
・
configure: error: OpenSSL crypto library is required to build glusterfs

まぁ、怒られますね。。。
openssl-develを入れてリトライ

yum -y install openssl-devel
./configure
・
・
・
configure: error: python does not have ctypes support

yum install python-ctypes
./configure
・
・
・
GlusterFS configure summary
===========================
FUSE client        : yes
Infiniband verbs   : no
epoll IO multiplex : yes
argp-standalone    : no
fusermount         : no
readline           : no
georeplication     : yes

make
make install

これでインストールは完了

gluster --version
glusterfs 3.3.0 built on Aug 24 2012 08:44:05
Repository revision: git://git.gluster.com/glusterfs.git
Copyright (c) 2006-2011 Gluster Inc. <http://www.gluster.com>
GlusterFS comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GlusterFS under the terms of the GNU General Public License.

今回は単純にサーバ側は1ノードで構成してみます

mkdir /gfs
service glusterd start
gluster volume create gv0 10.xxx.xxx.xxx:/gfs
gluster volume start gv0

※10.xxx.xxx.xxxはサーバ自身のInternal IPアドレス
情報を見てみます

gluster volume info

Volume Name: gv0
Type: Distribute
Volume ID: 2c09d301-1fda-4d91-8a50-15a8c71d0be8
Status: Started
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: 10.xxx.xxx.xxx:/gfs

これで、サーバ側は準備完了
続いてクライアント側
サーバ同様にGlusterFSをインストールして、fuseも入れます

yum -y install fuse

あとはマウントするだけ

mkdir /gfs
mount -t glusterfs 10.xxx.xxx.xxx:/gv0 /gfs

dfで状態を見てみるとちゃんとマウントできています

glusterfs#10.xxx.xxx.xxx:/gv0
                      10321152   3587840   6209024  37% /gfs