2015-09-23

正規表現再入門

PHP

最近ピザとかも出るようになった社内勉強会（仮）で発表した資料がでてきたので置いておきます。

正規表現再入門

先日、とあるサイトで再帰的パターンというものを知りまして、改めて PHP の PCRE のページを見てみると、知らない構文とか、知ってはいたけど全く使っていないなー、という構文が結構あったので、改めて一通り見てみました。

その中から、わりと知られていなさそうなものをピックアップしてみました。

ここからの内容は reveal.js でスライド表示されている Markdown ファイルをそのまま張り付けています。

スライドとして見る場合は↑の方にリンクを置いているのでそこから見てください。

正規表現再入門

PHP の PCRE のページ、よく見たら知らないものがいろいろあったので、改めて一通り見てみました

http://php.net/manual/ja/reference.pcre.pattern.syntax.php

デリミタ

正規表現でデリミタといえば、

/ ～ /

とか

# ～ #

のように同じ文字を最初と最後に使いますが

実は対応したカッコも使えます () とか {} とか [] とか <> とか

preg_match("(\d+)", 'abc123xyz', $m);
var_dump($m); // "123"

preg_match("{\d+}", 'abc123xyz', $m);
var_dump($m); // "123"

preg_match("[\d+]", 'abc123xyz', $m);
var_dump($m); // "123"

preg_match("<\d+>", 'abc123xyz', $m);
var_dump($m); // "123"

あんまり使いみちはなさそう

空白要素とコメント

x 修飾子を付けると空白要素やコメントを無視できます

$p = <<<'EOS'
# 英字
[a-zA-Z]+

# ドット
\.

# 数字
\d+
EOS;

preg_match("/$p/x", '123abc.789xyz', $m);
var_dump($m); // "abc.789"

次のように書いているのと同じです

preg_match("/[a-zA-Z]+\.\d+/", '123abc.789xyz', $m);
var_dump($m); // "abc.789"

超長い正規表現を書くときに便利そう

(?# から次の ) まではコメントになります（ネスト不可）

preg_match('/(?#これはコメントです)\d+/', 'abc123xyz', $m);
var_dump($m); // "123"

次のように書いているのと同じです

preg_match('/\d+/', 'abc123xyz', $m);
var_dump($m); // "123"

x 修飾子の方がいいと思う

言明

マッチ結果には含めずに直前や直後の文字をテストします

// 先読みの言明 ... 数字３つの後が "abc" である文字列にマッチ
preg_match_all('/\d{3}(?=abc)/', '123abc 789xyz', $m);
var_dump($m[0]); // "123"

// 先読みの否定言明 ... 数字３つの後が "abc" ではない文字列にマッチ
preg_match_all('/\d{3}(?!abc)/', '123abc 789xyz', $m);
var_dump($m[0]); // "789"

// 戻り読みの言明 ... 数字３つの前が "abc" である文字列にマッチ
preg_match_all('/(?<=abc)\d{3}/', 'abc123 xyz789', $m);
var_dump($m[0]); // "123"

// 戻り読みの否定言明 ... 数字３つの前が "abc" ではない文字列にマッチ
preg_match_all('/(?<!abc)\d{3}/', 'abc123 xyz789', $m);
var_dump($m[0]); // "789"

そこそこ使う

単語境界の言明

\b で単語の境界の言明

preg_match_all('/\b\d\w*/', '123abc abc456 abc/789 ', $m);
var_dump($m[0]); // "123abc" "789"

"123abc" は "1" が文字列の先頭で単語の始まりなのでマッチする
"abc456" は "4" が単語の始まりじゃないのでマッチしない
"abc/789" は "/" があるので "7" が単語の始まりになりマッチする

要するに (?<!\w)(?=\w) だと思う

preg_match_all('/(?<!\w)(?=\w)\d\w*/', '123abc abc456 abc/789 ', $m);
var_dump($m[0]); // "123abc" "789"

直前が \w ではなく、かつ、\w にマッチ

知ってたけど使ったこと無い

マッチ結果の位置のリセット

マッチ結果の開始位置を \K の位置にリセットするつまり \K より前の文字がマッチ結果に含まれなくなる

preg_match('/abc\Kxyz/', 'abcxyz', $m);
var_dump($m); // "xyz"

正規表現は "abcxyz" にマッチしているけど結果は "xyz" だけ

ただしサブパターンによるキャプチャには影響しない

preg_match('/(abc\Kxyz)/', 'abcxyz', $m);
var_dump($m); // "xyz", "abcxyz"

あんまり使いみちはなさそう

名前付きサブパターン

サブパターンに名前を付けてキャプチャ結果を連想配列にする

preg_match('/(?P<sub>\d+)/', 'abc123xyz', $m);
var_dump($m['sub']); // "123"

preg_match('/(?<sub>\d+)/', 'abc123xyz', $m);
var_dump($m['sub']); // "123"

preg_match("/(?'sub'\d+)/", 'abc123xyz', $m);
var_dump($m['sub']); // "123"

なにかの WAF で Routing に使われてたかも？

重複した後方参照番号

次の例だと (abc) と (yz) は異なる数字添字

preg_match_all('/123(?:(abc)|x(yz))/', '123abc 123xyz', $m);
var_dump($m[1]); // "abc" ""
var_dump($m[2]); // "" "yz"

?| を使うと (abc) と (yz) は同じ数字添字

preg_match_all('/123(?|(abc)|x(yz))/', '123abc 123xyz', $m);
var_dump($m[1]); // "abc" "yz"

知っていれば使うこともあるかも

独占的量指定子

量指定子の後に + を付けるとバックトラックしなくなる

// 貪欲的
preg_match('/\w*a/', '123abc123abc#123', $m);
var_dump($m); // "123abc123a"

// 非貪欲的
preg_match('/\w*?a/', '123abc123abc#123', $m);
var_dump($m); // "123a"

// 独占的
preg_match('/\w*+a/', '123abc123abc#123', $m);
var_dump($m); // no match

言葉で説明するのは難しい・・・

/\w*+a/ は \w* を最も長くマッチした後に a にマッチしなければテストは失敗します

日本語的に説明すると

貪欲的
- なるべく長くマッチしてダメだったら少し短くして再試行
非貪欲的
- なるべく短くマッチしてダメだったら少し長くして再試行
独占的
- ひたすら長くマッチしてダメだったら後は知らん

次のように独占的でもそうじゃなくても同じなら（マッチしないときの）性能の向上が見込める

// 貪欲的
preg_match('/\d*a/', '123123abc', $m);
var_dump($m); // "123123a"

// 非貪欲的
preg_match('/\d*?a/', '123123abc', $m);
var_dump($m); // "123123a"

// 独占的
preg_match('/\d*+a/', '123123abc', $m);
var_dump($m); // "123123a"

次のような使い方もできます

// .jpg で終わる連続する非空白要素にマッチ
preg_match_all('/\S++(?<=\.jpg)/', 'a.jp b.jpg c.jpghoge', $m);
var_dump($m); // "b.jpg"

次のようにしても結果は同じですけど

// .jpg で終わる連続する非空白要素にマッチ
preg_match_all('/\S+\.jpg(?!\S)/', 'a.jp b.jpg c.jpghoge', $m);
var_dump($m); // "b.jpg"

覚えておいて損はないかも

後方参照の相対指定

\g{-1} のように負数を指定すると相対で後方参照できる

preg_match('/(\d+)(\w+)\g{-1}\g{-2}/', '123abcabc123', $m);
var_dump($m); // "123abcabc123" "123" "abc"

\g{-1} は１つ前の (\w+) でマッチした文字列
\g{-2} は２つ前の (\d+) でマッチした文字列

これは次の例と同じです

preg_match('/(\d+)(\w+)\2\1/', '123abcabc123', $m);
var_dump($m); // "123abcabc123" "123" "abc"

\2 は２つ目のサブパターンの (\w+) でマッチした文字列
\1 は１つ目のサブパターンの (\d+) でマッチした文字列

あまり使わなさそう

再試行無しのサブパターン

(?> で始まるサブパターンは再試行されません

preg_match('/(?>\w*)a/', '123abc123abc#123', $m);
var_dump($m); // no match

preg_match('/(?>\d*)a/', '123123abc', $m);
var_dump($m); // "123123a"

独占的量指定子とあまり変わらないような気がします

preg_match('/\w*+a/', '123abc123abc#123', $m);
var_dump($m); // no match

preg_match('/\d*+a/', '123123abc', $m);
var_dump($m); // "123123a"

条件付きサブパターン

条件に応じてパターンを使い分けることができます

(?(条件)真パターン)
(?(条件)真パターン|偽パターン)

パターンには次のものが使えます。

数字
- その番号のサブパターンにマッチしていれば真
言明
- その言明にマッチすれば真
"R"
- 再帰パターンに再帰していると真
- 再帰していないトップレベルだと偽

良い例が思いつかないのでパス

再帰的パターン

こういうの

$str = "dummy(1+1), dummy(2+(3*4)), dummy(5-dummy(6*7)), dummy(2+((6/3)*(4-1)))";
$pattern = 'dummy (\( (?: [-+*\/0-9]++ | (?1) )* \))';
preg_match_all("/$pattern/x",$str,$match);

print_r($match[0]);
/*
Array
(
    [0] => dummy(1+1)
    [1] => dummy(2+(3*4))
    [2] => dummy(6*7)
    [3] => dummy(2+((6/3)*(4-1)))
)
*/

開き括弧と閉じ括弧の対応にマッチします

わかりにくいのでバラしてみます

dummy
( ※１番目のサブパターンの開始
- \( ※開き括弧
- (?:
  - [-+*\/0-9]++ ※式っぽい文字の繰り返し
  - |
  - (?1) ※１番目のサブパターンに再帰
- )
- *
- \) ※閉じ括弧
) ※１番目のサブパターンの終了

(?R) でパターン全体に再帰
(?1) とか (?2) とかはサブパターンに再帰
(?P>name) とか (?&name) とかで名前付きサブパターンに再帰

回分にマッチする正規表現もできました

$pattern = '/(.)(?:(?R)|.)?\1/u';

$str = "キツツキがトマトを食べたらしんぶんしがたけやぶやけた";
preg_match_all($pattern, $str, $m);
var_dump($m[0]); // "キツツキ" "トマト" "しんぶんし" "たけやぶやけた"

$str = "ああ、みたいな２文字でも回文になってしまうので不完全";
preg_match_all($pattern, $str, $m);
var_dump($m[0]);

Wikipedia の回分のページにあった7文字以上の回分

$doc = new DOMDocument();
$doc->loadHTMLFile('https://ja.wikipedia.org/wiki/%E5%9B%9E%E6%96%87');
$xpath = new DOMXpath($doc);
$str = $xpath->query("id('mw-content-text')")[0]->textContent;

$pattern = '/(.)(?:(?R)|.)?\1/u';
preg_match_all($pattern, $str, $m);
$a = array_unique(array_filter($m[0], function ($s) { return mb_strlen($s) >= 7; }));

print_r($a);
// akasaka
// わかみかものとかなかとのもかみかわ
// もくよとんとことんとよくも
// しみしかししかしみし
// みなくさのなははくとしれくすりなりすくれしとくははなのさくなみ
// たのむそのいかにもにかいのそむのた
// さかのなはやとりたりとやはなのかさ
// の世しばしよしばし世の
// かなのよしはしよしはしよのなか
// まさかさかさま
// アニマルマニア
// スキトキメキトキス

"たいもくよとんとことんとよくもいた" のように上手くマッチしないものもあって不完全

正規表現・・・奥が深い

おわり

2015-08-26

GlusterFS を使ってみた

GlusterFS

先日、もう社内勉強会でいいや的な何か（仮）で、GlusterFS について話したりデモしたりしたときの資料が出てきたので置いておきます。

2¹² 番煎じぐらいで真新しいものではありません。

GlusterFS とは

いわゆる分散ファイルシステム
- 分散並列フォールトトレラントファイルシステム
- POSIX互換（ファイルシステムとしてマウントできる）
当初は Gluster, Inc. で開発されていたが Red Hat に買収された
- RHEL では Red Hat Gluster Storage という名前になっている
ネームノードとかメタデータノードとか分散ロックマネージャーとかのようなノードが無い
- クライアントががんばる
- レプリケーションもクライアントががんばって全部に書き込んでいる
NFS のように普通のファイルシステムの上に分散ファイルシステムが構築される
- 必要なメタ情報はファイルシステムの拡張属性に保存される
- ので、下位ファイルシステムはある程度限定される（xfs/ext4/etc..）
- ので、下位ファイルシステム上には分散ファイルシステム上のファイルがそのまま見える
レプリケーションやストライピングも可能
- レプリケーションで HA にすることもできる
- 復帰時の再レプリケーションも簡単
- ストライピングは１つのファイルを分散配置できる
- ファイル単位の分散配置もできる
ファイルシステムなのにユーザー空間で動く
- マウントには fuse を使用
ライブラリ（libglusterfs）を用いて直接アクセスも可能
- オーバーヘッドが少ない
NFS でもマウントできる
- NFSv3 のみ
REST API でもアクセス可能
- OpenStack Swift 互換らしい
小さいファイルが大量にあるのは苦手
- 大きなファイルが少量が得意
- ストライプドじゃなくても大きいファイルは得意なのか？

用語とか

ブリック
- GlusterFS が使う下位ファイルシステム上のディレクトリ
- ファイルシステムは XFS を奨励
ボリューム
- 複数のノードのブリックで構成された GlusterFS 上の仮想的なボリューム
ディストリビューテッドボリューム
- 複数のブリックにファイルを分散して配置する
- ファイル単位で配置が分散される（ストライピングではない）
レプリケーテッドボリューム
- 複数のブリックに同じファイルを複製して配置する
- 可用性を求めるなら必須
ストライプドボリューム
- 複数のブリックに一つのファイルを分散して配置する
- いわゆるストライピング
- あまり奨励されていない？（実験的？）
- 消し飛んでも構わないファイル用？
ヒーリングデーモン
- レプリケーテッドで整合性が失われた時に自動的に復旧するためのデーモン
リバランス
- ボリュームにブリックを追加/削除したときにファイルを再配置すること
- 手動で実行する必要がある（自動でリバランスはされない）

インストール

CentOS のリポジトリに GlusterFS 関連のパッケージが幾つかあるのですが・・なぜか glusterfs-server が無いので使えません。

yum list | grep ^glusterfs

glusterfs.x86_64                        3.6.0.29-2.el7                 base     
glusterfs-api.x86_64                    3.6.0.29-2.el7                 base     
glusterfs-api-devel.x86_64              3.6.0.29-2.el7                 base     
glusterfs-cli.x86_64                    3.6.0.29-2.el7                 base     
glusterfs-devel.x86_64                  3.6.0.29-2.el7                 base     
glusterfs-fuse.x86_64                   3.6.0.29-2.el7                 base     
glusterfs-libs.x86_64                   3.6.0.29-2.el7                 base     
glusterfs-rdma.x86_64                   3.6.0.29-2.el7                 base

なので、GlusterFS の yum リポジトリの設定をダウンロードします

cd /etc/yum.repos.d/
wget http://download.gluster.org/pub/gluster/glusterfs/LATEST/CentOS/glusterfs-epel.repo

サーバには glusterfs-server をインストールします

yum -y install glusterfs-server

クライアント（マウントする側）は glusterfs-fuse だけで十分です。

yum -y install glusterfs-fuse

下記のバージョンがインストールされました。

glusterfs.x86_64                  3.7.3-1.el7                         @glusterfs-epel
glusterfs-api.x86_64              3.7.3-1.el7                         @glusterfs-epel
glusterfs-cli.x86_64              3.7.3-1.el7                         @glusterfs-epel
glusterfs-client-xlators.x86_64   3.7.3-1.el7                         @glusterfs-epel
glusterfs-fuse.x86_64             3.7.3-1.el7                         @glusterfs-epel
glusterfs-libs.x86_64             3.7.3-1.el7                         @glusterfs-epel
glusterfs-server.x86_64           3.7.3-1.el7                         @glusterfs-epel

Vagrant box

ここまでの作業が適用された Vagrant box を作成します。

Vagrant.configure(2) do |config|
  config.vm.box = "ngyuki/centos-7"

  config.vm.provision "shell", inline: <<-SHELL
    cd /etc/yum.repos.d/
    wget http://download.gluster.org/pub/gluster/glusterfs/LATEST/CentOS/glusterfs-epel.repo
    yum -y install glusterfs-server glusterfs-fuse
    yum clean all
  SHELL

  config.vm.provider :virtualbox do |vb|
    file_to_disk = "#{ENV["HOME"]}/glusterfs.vdi"
    unless File.exist?(file_to_disk)
      vb.customize ['createhd', '--filename', file_to_disk, '--size', 20 * 1024]
      vb.customize ['storageattach', :id,
        '--storagectl', 'SATA Controller',
        '--port', 1,
        '--device', 0,
        '--type', 'hdd',
        '--medium', file_to_disk]
    end
  end
end

provision で glusterfs-server と glusterfs-fuse をインストールし、さらに GlusterFS のためのディスクを作成してアタッチしています。

glusterfs という名前で Box を作成＆追加します。

vagrant up
vagrant package --output ~/glusterfs.box
vagrant box add glusterfs ~/glusterfs.box --force
rm -f ~/glusterfs.box
vagrant destroy -f

Vagrant up

次の Vagrantfile で４台の GlusterFS のノードと、GlusterFS をマウントする１台のクライアントを作成します。

Vagrant.configure(2) do |config|

  config.vm.box = "glusterfs"

  config.vm.define :g1 do |cfg|
    cfg.vm.hostname = "g1"
    cfg.vm.network "private_network", ip: "192.168.33.11", virtualbox__intnet: "glusterfs"
  end

  config.vm.define :g2 do |cfg|
    cfg.vm.hostname = "g2"
    cfg.vm.network "private_network", ip: "192.168.33.12", virtualbox__intnet: "glusterfs"
  end

  config.vm.define :g3 do |cfg|
    cfg.vm.hostname = "g3"
    cfg.vm.network "private_network", ip: "192.168.33.13", virtualbox__intnet: "glusterfs"
  end

  config.vm.define :g4 do |cfg|
    cfg.vm.hostname = "g4"
    cfg.vm.network "private_network", ip: "192.168.33.14", virtualbox__intnet: "glusterfs"
  end

  config.vm.define :cl do |cfg|
    cfg.vm.hostname = "cl"
    cfg.vm.network "private_network", ip: "192.168.33.21", virtualbox__intnet: "glusterfs"
  end

end

起動します。

vagrant up

すべてのゲストに ssh で接続します。

vagrant ssh g1
vagrant ssh g2
vagrant ssh g3
vagrant ssh g4
vagrant ssh cl

起動

ゲストの hosts にノードの一覧を追記しておきます。

cat <<EOS> /etc/hosts
127.0.0.1       localhost localhost.localdomain localhost4 localhost4.localdomain4
192.168.33.11   g1
192.168.33.12   g2
192.168.33.13   g3
192.168.33.14   g4
192.168.33.21   cl
EOS

~~glusterfs-server のインストール時に /var/lib/glusterd/glusterd.info というファイルの中にノードの UUID が作成されています。~~

cat /var/lib/glusterd/glusterd.info

UUID=7096ff3d-e640-494f-8409-b0fa52e74b8c
operating-version=30702

この値はクラスタのノードで重複しないようにする必要があります。もし、共通の AMI などからインスタンスを作ったのであれば、UUID が重複しないように GlusterFS の起動前にこのファイルを削除しておく必要があります。

~~今回は Vagrant box から起動したため重複しています。なので次のように削除しておきます。~~

rm -f /var/lib/glusterd/glusterd.info

と、思ったんだけど作成されていなかった。。。 3.7.2 で検証してたときはインストール時に作成されていた気がするのだけど・・？ 3.7.3 から変わったのか、あるいは勘違いしていたのか・・・

GlusterFS のデーモンを起動します。

systemctl enable glusterd.service
systemctl start  glusterd.service
systemctl status glusterd.service

~~起動時に UUID は自動生成されます。~~ 初回の起動時にも /var/lib/glusterd/glusterd.info は作成されなくて、gluster pool list したら作成されました。

gluster pool list
cat /var/lib/glusterd/glusterd.info

Brick の作成

適当なディレクトリにファイルの置き場所となる Brick（ブリック）を作ります。

追加ディスクにパーティションを切ります。動作要件に i-node サイズが 512B とあるらしいのでファイルシステムの作成時に指定します。

parted -s -a optimal /dev/sdb mklabel msdos -- mkpart primary xfs 1 -1
mkfs.xfs -i size=512 /dev/sdb1
mkdir -p /glfs/vols

cat <<EOS>>/etc/fstab
/dev/sdb1 /glfs/vols xfs defaults 0 0
EOS

mount /glfs/vols

ブリックのディレクトリを作成します。

mkdir -p /glfs/vols/data

GlusterFS クラスタ

GlusterFS のノードでクラスタを組んでストレージプールを作ります。

gluster peer status でクラスタのピア数を表示してみます。

gluster peer status

まだ 0 個です、つまり自分以外は居ません。

Number of Peers: 0

gluster pool list でノードの一覧を表示してみます。

gluster pool list

自分しか表示されません。

UUID                                    Hostname        State
89a1b9b4-f7e0-4091-aeff-80279d8c0024    localhost       Connected

gluster peer probe <remote> でピアを追加できます。下記を g1 で実行してみます。

gluster peer probe g2
gluster peer probe g3
gluster peer probe g4

成功したっぽいメッセージが表示されます。

peer probe: success.

もう一度 gluster peer status とか gluster pool list とかを実行してみると、それっぽく表示されます。

gluster peer status

Number of Peers: 3

Hostname: g2
Uuid: 9256e049-e3f9-43a7-9fda-3ce631d4e5c1
State: Peer in Cluster (Connected)

Hostname: g3
Uuid: 9a5eaa0d-3db9-40af-a58e-e5caa804cb78
State: Peer in Cluster (Connected)

Hostname: g4
Uuid: 8fde5fcc-2e33-489b-976f-76171fcd162f
State: Peer in Cluster (Connected)

gluster pool list

UUID                                    Hostname        State
9256e049-e3f9-43a7-9fda-3ce631d4e5c1    g2              Connected 
9a5eaa0d-3db9-40af-a58e-e5caa804cb78    g3              Connected 
8fde5fcc-2e33-489b-976f-76171fcd162f    g4              Connected 
89a1b9b4-f7e0-4091-aeff-80279d8c0024    localhost       Connected

Volume を作成

ボリュームを作成します。

この例だと、ボリュームの名前は data で、g1=g2 と g3=g4 がそれぞれレプリカで、それぞれの組にファイルが分散されます。

gluster volume create data replica 2 \
  g1:/glfs/vols/data \
  g2:/glfs/vols/data \
  g3:/glfs/vols/data \
  g4:/glfs/vols/data

正常に作成されれば次のようなメッセージが表示されます。

volume create: data: success: please start the volume to access data

ボリュームを開始します。

gluster volume start data

正常に開始されれば次のようなメッセージが表示されます。

volume start: data: success

ボリュームの情報を見てみます。

gluster volume info data

それっぽい内容が表示されます。

Volume Name: data
Type: Distributed-Replicate
Volume ID: 48bf6f46-c6d8-4743-b65e-4ecba2e27969
Status: Started
Number of Bricks: 2 x 2 = 4
Transport-type: tcp
Bricks:
Brick1: g1:/glfs/vols/data
Brick2: g2:/glfs/vols/data
Brick3: g3:/glfs/vols/data
Brick4: g4:/glfs/vols/data
Options Reconfigured:
performance.readdir-ahead: on

ボリュームのステータスを見てみます。

gluster volume status data

それっぽい内容が表示されます。

Status of volume: data
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick g1:/glfs/vols/data                    49152     0          Y       2800 
Brick g2:/glfs/vols/data                    49152     0          Y       2752 
Brick g3:/glfs/vols/data                    49152     0          Y       2754 
Brick g4:/glfs/vols/data                    49152     0          Y       2753 
NFS Server on localhost                     N/A       N/A        N       N/A  
Self-heal Daemon on localhost               N/A       N/A        Y       2828 
NFS Server on g4                            N/A       N/A        N       N/A  
Self-heal Daemon on g4                      N/A       N/A        Y       2781 
NFS Server on g2                            N/A       N/A        N       N/A  
Self-heal Daemon on g2                      N/A       N/A        Y       2780 
NFS Server on g3                            N/A       N/A        N       N/A  
Self-heal Daemon on g3                      N/A       N/A        Y       2782 
 
Task Status of Volume data
------------------------------------------------------------------------------
There are no active volume tasks

クライアントからマウント

クライアントのノードからマウントしてみます。まずマウントポイントを作ります。

mkdir -p /glfs/data

適当なノードを指定してマウントする必要があります。そのため、次の例では g1 が停止しているとマウントに失敗します。

mount -t glusterfs g1:/data /glfs/data

次のようにマウントオプションを指定すると、g1 が停止しているときは g2 にフォールバックされるようにできます。

mount -t glusterfs g1:/data /glfs/data -o backupvolfile-server=g2

一旦マウントしてしまえばどのノードをマウントで指定したかは関係なくなるので、前者の方法でも g1 が SPOF になるというわけではありませんが・・どうせなら後者の方が良いと思います。

replica運用してるglusterfsボリュームでmount時のフォールバックオプションを付ける - Qiita

動作確認

クライアントから適当に書き込んでみます。

echo 1 > /glfs/data/1.txt
echo 2 > /glfs/data/2.txt
echo 3 > /glfs/data/3.txt
echo 4 > /glfs/data/4.txt

g1 や g2 のブリックを確認してみると、

ssh g1 ls -l /glfs/vols/data
ssh g2 ls -l /glfs/vols/data

-rw-r--r-- 2 root root 2  7月  3 16:48 4.txt

両方に 4.txt だけが保存されています。

g3 や g4 のブリックを確認してみると、

ssh g3 ls -l /glfs/vols/data
ssh g4 ls -l /glfs/vols/data

両方に残りのファイルが保存されています。

-rw-r--r-- 2 root root 2  7月  3 16:48 1.txt
-rw-r--r-- 2 root root 2  7月  3 16:48 2.txt
-rw-r--r-- 2 root root 2  7月  3 16:48 3.txt

レプリケーション＆分散配置されています。

ノード障害時の動作

Vagrant のホストから、おもむろに g1 を強制終了します。

vagrant halt -f g1

適当なノード（例えば g2）から、ストレージプールの状態などを確認してみます。

gluster peer status すると g1 が Disconnected になっています。

gluster peer status

Number of Peers: 3

Hostname: g1
Uuid: 89a1b9b4-f7e0-4091-aeff-80279d8c0024
State: Peer in Cluster (Disconnected)

Hostname: g3
Uuid: 9a5eaa0d-3db9-40af-a58e-e5caa804cb78
State: Peer in Cluster (Connected)

Hostname: g4
Uuid: 8fde5fcc-2e33-489b-976f-76171fcd162f
State: Peer in Cluster (Connected)

gluster pool list でも同上です。

gluster pool list

UUID                                    Hostname        State
89a1b9b4-f7e0-4091-aeff-80279d8c0024    g1              Disconnected 
9a5eaa0d-3db9-40af-a58e-e5caa804cb78    g3              Connected 
8fde5fcc-2e33-489b-976f-76171fcd162f    g4              Connected 
9256e049-e3f9-43a7-9fda-3ce631d4e5c1    localhost       Connected

gluster volume status data だと g1 がいません。

gluster volume status data

Status of volume: data
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick g2:/glfs/vols/data                    49152     0          Y       2752 
Brick g3:/glfs/vols/data                    49152     0          Y       2754 
Brick g4:/glfs/vols/data                    49152     0          Y       2753 
NFS Server on localhost                     N/A       N/A        N       N/A  
Self-heal Daemon on localhost               N/A       N/A        Y       2780 
NFS Server on g4                            N/A       N/A        N       N/A  
Self-heal Daemon on g4                      N/A       N/A        Y       2781 
NFS Server on g3                            N/A       N/A        N       N/A  
Self-heal Daemon on g3                      N/A       N/A        Y       2782 
 
Task Status of Volume data
------------------------------------------------------------------------------
There are no active volume tasks

いかにも g1 が死んでいる風になっていますが、g1 と g2 でレプリカになっているはずなのでクライアントから読み書きできるか試してみます。

クライアントからファイルを読んでみると・・なにごともなく読むことができます。

cat /glfs/data/1.txt
cat /glfs/data/2.txt
cat /glfs/data/3.txt
cat /glfs/data/4.txt

次はファイルを書き込んでみると・・なにごともなく書き込むことができます。

echo 5 > /glfs/data/5.txt
echo 6 > /glfs/data/6.txt
echo 7 > /glfs/data/7.txt
echo 8 > /glfs/data/8.txt

生きているノードのブリックを確認してみます。

まずは g2。

ssh g2 ls -l /glfs/vols/data

-rw-r--r-- 2 root root 2  7月  3 16:48 4.txt
-rw-r--r-- 2 root root 2  7月  3 16:58 8.txt

次は g3。

ssh g3 ls -l /glfs/vols/data

-rw-r--r-- 2 root root 2  7月  3 16:48 1.txt
-rw-r--r-- 2 root root 2  7月  3 16:48 2.txt
-rw-r--r-- 2 root root 2  7月  3 16:48 3.txt
-rw-r--r-- 2 root root 2  7月  3 16:58 5.txt
-rw-r--r-- 2 root root 2  7月  3 16:58 6.txt
-rw-r--r-- 2 root root 2  7月  3 16:58 7.txt

さらに g4。

ssh g4 ls -l /glfs/vols/data

-rw-r--r-- 2 root root 2  7月  3 16:48 1.txt
-rw-r--r-- 2 root root 2  7月  3 16:48 2.txt
-rw-r--r-- 2 root root 2  7月  3 16:48 3.txt
-rw-r--r-- 2 root root 2  7月  3 16:58 5.txt
-rw-r--r-- 2 root root 2  7月  3 16:58 6.txt
-rw-r--r-- 2 root root 2  7月  3 16:58 7.txt

g2 に保存されたファイルは g2 にしか存在しない状態です。

ノード復帰時の動作

Vagrant ホストから g1 を復帰させます。

vagrant up g1
vagrant ssh g1

適当なノード（例えば g2）からいろいろ確認してみます。

gluster peer status で見ると g1 が Connected になっています。

gluster peer status

Number of Peers: 3

Hostname: 192.168.33.11
Uuid: 89a1b9b4-f7e0-4091-aeff-80279d8c0024
State: Peer in Cluster (Connected)

Hostname: g3
Uuid: 9a5eaa0d-3db9-40af-a58e-e5caa804cb78
State: Peer in Cluster (Connected)

Hostname: g4
Uuid: 8fde5fcc-2e33-489b-976f-76171fcd162f
State: Peer in Cluster (Connected)

gluster pool list も同上です。

gluster pool list

UUID                                    Hostname        State
89a1b9b4-f7e0-4091-aeff-80279d8c0024    g1              Connected 
9a5eaa0d-3db9-40af-a58e-e5caa804cb78    g3              Connected 
8fde5fcc-2e33-489b-976f-76171fcd162f    g4              Connected 
9256e049-e3f9-43a7-9fda-3ce631d4e5c1    localhost       Connected

gluster volume status data にも g1 が追加されています。

gluster volume status data

Status of volume: data
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick g1:/glfs/vols/data                    49152     0          Y       1055 
Brick g2:/glfs/vols/data                    49152     0          Y       2752 
Brick g3:/glfs/vols/data                    49152     0          Y       2754 
Brick g4:/glfs/vols/data                    49152     0          Y       2753 
NFS Server on localhost                     N/A       N/A        N       N/A  
Self-heal Daemon on localhost               N/A       N/A        Y       2780 
NFS Server on g4                            N/A       N/A        N       N/A  
Self-heal Daemon on g4                      N/A       N/A        Y       2781 
NFS Server on 192.168.33.11                 N/A       N/A        N       N/A  
Self-heal Daemon on 192.168.33.11           N/A       N/A        Y       2212 
NFS Server on g3                            N/A       N/A        N       N/A  
Self-heal Daemon on g3                      N/A       N/A        Y       2782 
 
Task Status of Volume data
------------------------------------------------------------------------------
There are no active volume tasks

ただし、まだ g1 と g2 は同期されていません。g1 が停止していた間のファイルは g1 にはありません。

ssh g1 ls -l /glfs/vols/data

-rw-r--r-- 2 root root 2  7月  3 16:48 4.txt

ssh g2 ls -l /glfs/vols/data

-rw-r--r-- 2 root root 2  7月  3 16:48 4.txt
-rw-r--r-- 2 root root 2  7月  3 16:58 8.txt

クライアントからそのファイルを読み込むと g1 のブリックにファイルが複製されました。

他にも次のようなタイミングで同期されます。

Self-heal daemon によって自動的に
gluster volume heal <volume> で手動で開始

ノードの交換

Vagrant のホストから、おもむろに g1 をぶっ壊して作り直します。

vagrant destroy g1
vagrant up g1
vagrant ssh g1

g1 を再セットアップします。まず、hosts を更新します。

cat <<EOS> /etc/hosts
127.0.0.1       localhost localhost.localdomain localhost4 localhost4.localdomain4
192.168.33.11   g1
192.168.33.12   g2
192.168.33.13   g3
192.168.33.14   g4
192.168.33.21   cl
EOS

適当な他のノードから、以前の g1 の UUID を調べます。

ssh g2 gluster pool list

新規の g1 の UUID を↑で調べた値に変更します。

vim /var/lib/glusterd/glusterd.info

UUID=89a1b9b4-f7e0-4091-aeff-80279d8c0024
operating-version=30703

ブリックを作ります。

parted -s -a optimal /dev/sdb mklabel msdos -- mkpart primary xfs 1 -1
mkfs.xfs -i size=512 /dev/sdb1
mkdir -p /glfs/vols

cat <<EOS>>/etc/fstab
/dev/sdb1 /glfs/vols xfs defaults 0 0
EOS

mount /glfs/vols
mkdir -p /glfs/vols/data

glusterd を起動します。

systemctl enable glusterd.service
systemctl start  glusterd.service
systemctl status glusterd.service

g1 から g1 以外のすべてに gluster peer probe します。

gluster peer probe g2
gluster peer probe g3
gluster peer probe g4

gluster pool list で確認するとクラスタが復帰していることがわかります。

gluster pool list

これだけだとボリュームの情報が g1 に無いことがあるようです。

gluster volume list

そんなときは glusterd を再起動すると良いようです（gluster volume sync g2 all でもいいのかもしれない？）。

systemctl stop  glusterd.service
systemctl start glusterd.service

ボリュームの情報が得られることを確認します。

gluster volume info data

なぜか gluster volume status data で見るとボリュームが Online になっていないことがあります。

gluster volume status data

Status of volume: data
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick g1:/glfs/vols/data                    N/A       N/A        N       N/A  
Brick g2:/glfs/vols/data                    49152     0          Y       2794 
Brick g3:/glfs/vols/data                    49152     0          Y       2754 
Brick g4:/glfs/vols/data                    49152     0          Y       2753
...snip...

そんなときは glusterd を再起動すると良い？らしい？？です？？？（さっきもしたけど・・）

systemctl stop  glusterd.service
systemctl start glusterd.service

3.4.0 以降だとこれでもダメなようです。

https://bugzilla.redhat.com/show_bug.cgi?id=991084

このとき、ブリックのログに次のように記録されています。

[2015-07-14 05:59:08.521960] E [posix.c:6012:init] 0-data-posix: Extended attribute trusted.glusterfs.volume-id is absent
[2015-07-14 05:59:08.521972] E [xlator.c:426:xlator_init] 0-data-posix: Initialization of volume 'data-posix' failed, review your volfile again
[2015-07-14 05:59:08.521978] E [graph.c:322:glusterfs_graph_init] 0-data-posix: initializing translator failed
[2015-07-14 05:59:08.521983] E [graph.c:661:glusterfs_graph_activate] 0-graph: init failed
[2015-07-14 05:59:08.522710] W [glusterfsd.c:1219:cleanup_and_exit] (--> 0-: received signum (0), shutting down

ブリックのディレクトリに trusted.glusterfs.volume-id 拡張属性が無いためらしいのですが、次のコマンドで再生成できます。

gluster volume start data force

今度こそボリュームがオンラインになっていることを確認します。

gluster volume status data

Status of volume: data
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick g1:/glfs/vols/data                    49153     0          Y       3281 
Brick g2:/glfs/vols/data                    49152     0          Y       2794 
Brick g3:/glfs/vols/data                    49152     0          Y       2754 
Brick g4:/glfs/vols/data                    49152     0          Y       2753
...snip...

オンラインになっても自動的に同期はされません。

ll /glfs/vols/data/

total 0

gluster volume heal <volume> full で再同期します。

gluster volume heal data full

Launching heal operation to perform full self heal on volume data has been successful 
Use heal info commands to check status

ご覧の通りです。

ll /glfs/vols/data/

total 4
-rw-r--r-- 2 root root  0 Jul  7 20:15 4.txt
-rw-r--r-- 2 root root 29 Jul  7 20:15 8.txt

の、はずなんですが、3.7.3 にバージョンアップしたらなぜか上手く行きませんでした、ディレクトリが空のままです。マウントしているクライアントからファイルのアクセスするとレプリケートされましたけど・・・？？

さらにブリックの拡張属性を見てみると trusted.glusterfs.dht がなかったりするし・・・いっそのこと rsync で --xattr を付けて拡張属性ごとブリックをコピーしてしまえばいいのだろうか？？

古いメモ

これはだいぶ前に検証したときのメモです。

分散ハッシュテーブル

ファイル名を元にハッシュ値が計算される。ハッシュ値を元にどのブリックに保存するかが決定される。

ハッシュテーブルはディレクトリごとに異なる。

ハッシュレンジはディレクトリの拡張属性に保存される。

getfattr -d -m . /glfs/vols/data/

getfattr: Removing leading '/' from absolute path names
# file: glfs/vols/data/
trusted.afr.data-client-0=0sAAAAAAAAAAAAAAAA
trusted.afr.data-client-1=0sAAAAAAAAAAAAAAAA
trusted.afr.dirty=0sAAAAAAAAAAAAAAAA
trusted.gfid=0sAAAAAAAAAAAAAAAAAAAAAQ==
trusted.glusterfs.dht=0sAAAAAQAAAAAAAAAA/////w==
trusted.glusterfs.volume-id=0sE6WciNVBR7ekZgK1wu3xgw==

ファイルをリネームしてハッシュ値が変わり、別のブリックに保存される事になった場合、新しい保存先のブリックには sticky ビットのついた空のファイルが作成されて、拡張属性で元のブリックへのリンクが記録される。

ll 9.txt

---------T 2 root root 0 12月 13 17:12 9.txt

getfattr -n trusted.glusterfs.dht.linkto 9.txt

# file: 9.txt
trusted.glusterfs.dht.linkto="data-replicate-1"

リバランスによってこのようなファイルを本来の位置に再配置できる。

既存ボリュームにブリックを追加すると

追加直後は、既存のディレクトリは新しいブリックを使用しない
- ハッシュテーブルに当該ブリックのエントリがないため
新規作成したディレクトリには新しいブリックを含むハッシュテーブルが作成される
リバランスすれば既存ディレクトリに新しいブリックを含むハッシュテーブルが作成される

既存ボリュームからブリックを削除すると

事前に削除対象ブリックを除いた新しいハッシュテーブルを作成して再配置する
再配置によって削除対象ブリックからファイルが無くなった後に当該ブリックを削除する

性能

大きなファイルをストライプ構成することで性能向上が見込めるが、小さい大量のファイルを扱う場合は性能が遅くなる（NFS より遅くなる可能性もある）。

v3.4.0 からのバグ

http://e-garakuta.net/techinfo/doku.php/linux/gluster

直接拡張属性を書いても大丈夫。

grep volume-id /var/lib/glusterd/vols/data/info | cut -d= -f2 | sed 's/-//g'

setfattr -n trusted.glusterfs.volume-id \
  -v 0x$(grep volume-id /var/lib/glusterd/vols/data/info | cut -d= -f2 | sed 's/-//g') \
    /glfs/vols/data

getfattr -n trusted.glusterfs.volume-id -e hex /glfs/vols/data

service glusterd restart

所感

分散ファイルシステムにしては構築が異様に簡単
ノード交換時の作業が GlusterFS のバージョンがちょっと代わるたびに上手く行かなくなる気がする
- 検証するたびに試行錯誤している
CentOS 7 の公式リポジトリだと server が無いので GlusterFS の公式のリポジトリを使うしか無い
- バージョンアップに追従していくのは大変そう
- ストレージなのでなるべく安定していた方がいい
RHEL で Red Hat Gluster Storage とかのほうが良いかもしれない
- ストレージにはお金かけても良いと思う
- サーバの要件が異様に厳しそうだけど・・（RHCS は異様に厳しかった気がするし）

参考

GlusterFS技術情報
- https://sites.google.com/site/glusterfstech/
10年効く分散ファイルシステム技術 GlusterFS & Red Hat Storage
- http://www.slideshare.net/enakai/10-glusterfs-red-hat-storage
分散ファイルシステム GlusterFS を使う上で知っておきたい 5つのこと « インフラ本舗
- http://infra.makeall.net/archives/2093
IT検証ラボ - 分散ファイルシステムのGlusterFS：こんなとき、どうなる：ITpro
- http://itpro.nikkeibp.co.jp/article/COLUMN/20130104/447701/

2015-07-18

Consul を使ってみた

Consul

先日、社内勉強会以外の伺か（仮）で、Consul について話したときの資料がでてきたので置いておきます。

2¹³ 番煎じぐらいで真新しいものではありません。

Consul is なに？

Packer や Vagrant の HashiCorp 社が作っているオーケストレーションツール。

Docker コンテナ

Consul を試す環境として Docker で以下の環境を作ります。

server
- 10.88.0.10
- 8080 => 8080
node1
- 10.88.0.11
node2
- 10.88.0.12

次の Dockerfile を使います。最近の CentOS 7 のコンテナは systemd のサービスが普通に動くので、軽量な仮想環境として使うのに便利です。

FROM centos:7

RUN yum install -y epel-release &&\
    yum install -y wget unzip bind-utils dnsmasq nginx rsync &&\
    yum clean all

RUN wget -q https://dl.bintray.com/mitchellh/consul/0.5.2_linux_amd64.zip &&\
    unzip 0.5.2_linux_amd64.zip &&\
    mv consul /usr/local/bin/consul &&\
    rm -vf 0.5.2_linux_amd64.zip

RUN wget https://dl.bintray.com/mitchellh/consul/0.5.2_web_ui.zip &&\
    unzip 0.5.2_web_ui.zip &&\
    mkdir -p /opt/consul/dist/ &&\
    rsync dist/ /opt/consul/dist/ -av &&\
    rm -rvf 0.5.2_web_ui.zip dist/

ENTRYPOINT /sbin/init

yum は説明不要だと思います。他の２つの RUN は、consul のコマンドとか UI とかをダウンロードしているのですが、後ほど説明します。

最後の ENTRYPOINT /sbin/init は、コンテナの中で systemd のサービスを動かすためです。

ビルドします。

docker build -t example/consul .

コンテナを起動します。--privileged は pipework を使うために必要です。

docker run --privileged -d --name server -h server -p 8080:8080 example/consul
docker run --privileged -d --name node1 -h node1 example/consul
docker run --privileged -d --name node2 -h node2 example/consul

pipework でコンテナに固定IPを付与します。

sudo pipework br1 server 10.88.0.10/24
sudo pipework br1 node1 10.88.0.11/24
sudo pipework br1 node2 10.88.0.12/24

インストール

Go 言語なのでバイナリいっこ落とすだけ。（Dockerfile でやってるので不要です）

wget https://dl.bintray.com/mitchellh/consul/0.5.2_linux_amd64.zip
unzip 0.5.2_linux_amd64.zip
sudo mv consul /usr/local/bin/consul

Consul Server

server にログインします。

docker exec -it server /bin/bash

次のように consul を実行します。

consul agent -server -bootstrap-expect=1 -data-dir=/tmp/consul -node=server \
  -bind=10.88.0.10 -ui-dir=/opt/consul/dist

別のターミナルでログインします。

docker exec -it server /bin/bash

メンバーの一覧を表示してみます。

consul members

まだ自分しかいません。

Node    Address          Status  Type    Build  Protocol  DC
server  10.88.0.10:8301  alive   server  0.5.2  2         dc1

consul の DNS インタフェースを dig で呼んでみます。

dig server.node.consul @127.0.0.1 -p 8600

次のように結果が返ります。

;; ANSWER SECTION:
server.node.consul.     0       IN      A       10.88.0.10

port 番号とかを指定するのが面倒なので dnsmasq を使います。

.consul をローカルの 8600 ポートにフォワードするように設定します。

cat <<EOS> /etc/dnsmasq.d/consul.conf
server=/consul/127.0.0.1#8600
strict-order
EOS

デフォルトのネームサーバをローカルにするために nameserver 127.0.0.1 を /etc/resolv.conf の先頭に挿入します。

sed -i '1i nameserver 127.0.0.1' /etc/resolv.conf

設定を反映します。

systemctl restart dnsmasq.service

名前解決してみます。

dig server.node.consul

先ほどと同じように結果が帰ります。

;; ANSWER SECTION:
server.node.consul.     0       IN      A       10.88.0.10

Consul Client

node1 と node2 に nginx を入れて consul を使って DNS ラウンドロビンするようにしてみます。

node1 と node2 にそれぞれログインします。

docker exec -it node1 /bin/bash
docker exec -it node2 /bin/bash

nginx を起動します。

systemctl start nginx.service
systemctl status nginx.service

ドキュメントルートに、どちらのホストを見ているのか判るようにホスト名が書かれたファイルを置きます。

uname -n > /usr/share/nginx/html/consul.html
curl http://127.0.0.1/consul.html

consul のサービスの設定ファイルを作成します。この例だと web というサービス名で、curl でサービスの監視をしています。

mkdir -p /etc/consul.d/

cat <<EOS> /etc/consul.d/web.json
{
  "service": {
    "name": "web",
    "tags": [ "nginx" ],
    "port": 80,
    "check": {
      "script": "curl http://127.0.0.1:80/consul.html >/dev/null 2>&1",
      "interval": "10s",
      "timeout": "5s"
    }
  }
}
EOS

node1 と node2 でそれぞれ consul を起動します。

consul agent -data-dir=/tmp/consul -node=$(uname -n) \
  -bind=10.88.0.11 -config-dir=/etc/consul.d/ -join=10.88.0.10

consul agent -data-dir=/tmp/consul -node=$(uname -n) \
  -bind=10.88.0.12 -config-dir=/etc/consul.d/ -join=10.88.0.10

server のターミナルでメンバーの一覧を表示してみます。

consul members

node1 と node2 が追加されています。

Node    Address          Status  Type    Build  Protocol  DC
server  10.88.0.10:8301  alive   server  0.5.2  2         dc1
node1   10.88.0.11:8301  alive   client  0.5.2  2         dc1
node2   10.88.0.12:8301  alive   client  0.5.2  2         dc1

名前解決もできます。

dig node2.node.consul a

次のようにサービス名を指定すると、node1 と node2 の両方のアドレスが返ってきます。

dig web.service.consul a

サービス名の URL を複数回表示すると、DNS ラウンドロビンされているのがわかります。（と思ったんだけどなぜかラウンドロビンされない・・Vagrant で環境作った時にはできたんだけど・・？）

curl http://web.service.consul/consul.html

node1 の nginx を止めてみます。

docker exec node1 systemctl stop nginx.service

メンバーの一覧は特に変わりません。

consul members

サービス名で名前解決してみると、node2 のアドレスしか返らなくなっています。

dig web.service.consul a

もちろん、サービス名の URL も node2 にのみアクセスします。

curl http://web.service.consul/consul.html

node1 の nginx を再開します。

docker exec node1 systemctl start nginx.service

サービス名で node1 と node2 の両方が返るように戻ります。

dig web.service.consul a

サービス名の URL も両方に振り分けられるように戻ります。（と思ったんだけどやっぱりラウンドロビンされない？）

curl http://web.service.consul/consul.html

クエリ

serf でやったようなクエリの機能はデフォで有効です。

次のようにすると、すべてのホストでの uname -a の結果が得られます。

consul exec uname -a

特定のノードを指定することもできます。

consul exec -node=node2 uname -a

特定のサービスを指定することもできます。

consul exec -service=web uname -a

次のように、web サーバだけを対象に nginx を再起動させたりできます。

consul exec -service=web systemctl restart nginx.service

UI

consul には Web の UI があります。

UI のファイルをダウンロードして、適当なディレクトリ（consul agent の --ui-dir に指定したディレクトリ）に展開します。（Dockerfile でやっているので不要です）

wget https://dl.bintray.com/mitchellh/consul/0.5.2_web_ui.zip
unzip 0.5.2_web_ui.zip
mkdir -p /opt/consul/dist/
rsync dist/ /opt/consul/dist/ -av

nginx をそれっぽく設定します。

cat <<EOS> /etc/nginx/conf.d/consul.conf;
server {
    listen 8080 default_server;
    server_name server.node.consul;

    location / {
        proxy_pass http://127.0.0.1:8500;
    }
}
EOS

nginx を開始します。

systemctl start nginx.service
systemctl status nginx.service

以下の URL を開くと Web 画面が見えます。

open http://localhost:8080/ui/

さいごに

このデモでは、サーバが１台と、クライアントが２台で試しましたが、高可用にするためにはサーバは３台か５台にするべきらしいです（マルチデータセンターならデータセンターごとに３台か５台）。

また、Consul サーバはそれなりに重たいので、Consul サーバ専用のホストとして構築するべきらしいです。

逆にクライアントはとても軽量なので、他のサービスと一緒に動作させて問題ありません（というかそうしなければ意味が無い）。

つまり、Consul を使ったクラスタでは、Consul サーバのためだけに最低３台の専用のホストが必要となります。

・・・ちょっとした小規模クラスタに使う感じではありませんね。

2015-06-29

Serf 使ってみた

Serf

先日、社内勉強会以外の何か（仮）で、serf について話したときの資料がでてきたので置いておきます。

https://gist.github.com/ngyuki/23b9fa494fd49e358734

まあ、4096番煎じぐらいで真新しいものではありません。

Serf is なに？

Packer や Vagrant の HashiCorp 社が作っているオーケストレーションツール

オーケストレーション is なに？

サーバプロビジョニングを構成する要素の一部だと言われていますが・・・

Bootstrapping
- Kickstart とか
Configuration
- Ansible とか
Orchestration
- Serf とか

オーケストレーション (コンピュータ) - Wikipedia

オーケストレーション（英: Orchestration）は、複雑なコンピュータシステム/ミドルウェア/サービスの配備/設定/管理の自動化を指す用語。何らかの知的制御や自律制御として議論されることが多いが、技術的解説と言うよりも大部分は単なるアナロジーである。実際には、オーケストレーションは制御理論の要素としてオートメーションやシステムの考え方を持ち込んだものと言える。このようなコンピュータシステムの「オーケストレーション」という用語は、仮想化やプロビジョニングの文脈で語られることが多く、バズワード的要素が強い。

Bootstrapping でも Configuration でもないその他いろいろ、程度のニュアンスだと思います。

Docker コンテナ

試す環境として Docker を使います。

docker run -dit --name node1 -h node1 centos:7 bash
docker run -dit --name node2 -h node2 centos:7 bash
docker run -dit --name node3 -h node3 centos:7 bash

それぞれ別のターミナルでログインします。

docker exec -it node1 bash

docker exec -it node2 bash

docker exec -it node3 bash

この Docker コンテナは最小構成の CentOS 7 なので、あとで必要になるパッケージをインストールしておきます。

yum install -y wget unzip

serf インストール

serf は golang 製なのでバイナリいっこ配置するだけでインストールできます。

wget https://dl.bintray.com/mitchellh/serf/0.6.4_linux_amd64.zip
unzip 0.6.4_linux_amd64.zip
mv serf /usr/local/bin

serf をとりあえず試す

すべてのノードでエージェントを起動します。

serf agent -iface=eth0

クラスタメンバの確認します。上で開いたターミナルは serf agent がフォアグラウンドにいるので、別のターミナルから docker exec でコンテナの中でコマンドを実行します（インデント部分はコマンドの出力）。

docker exec node1 serf members
    node1  172.17.0.10:7946  alive

docker exec node2 serf members
    node2  172.17.0.11:7946  alive

docker exec node3 serf members
    node3  172.17.0.12:7946  alive

まだお互いを認識していないので、メンバには自分自身だけ表示されます。

node02 で node01 のクラスタにジョインします。

docker exec node2 serf join 172.17.0.10

もう一回クラスタメンバを確認してみます（インデント部分はコマンドの出力）。

docker exec node1 serf members
    node1  172.17.0.10:7946  alive  
    node2  172.17.0.11:7946  alive

docker exec node2 serf members
    node2  172.17.0.11:7946  alive  
    node1  172.17.0.10:7946  alive

docker exec node3 serf members
    node3  172.17.0.12:7946  alive

node01 と node02 はお互いを認識しました。

node03 も node01 のクラスタにジョインします。

docker exec node3 serf join 172.17.0.10

すべてのノードがお互いを認識するようになりました（インデント部分はコマンドの出力）。

docker exec node1 serf members
    node3  172.17.0.12:7946  alive  
    node1  172.17.0.10:7946  alive  
    node2  172.17.0.11:7946  alive

docker exec node2 serf members
    node2  172.17.0.11:7946  alive  
    node1  172.17.0.10:7946  alive  
    node3  172.17.0.12:7946  alive

docker exec node3 serf members
    node3  172.17.0.12:7946  alive  
    node2  172.17.0.11:7946  alive  
    node1  172.17.0.10:7946  alive

ディスカバリ

前述の方法だと、最初にいずれかのノードを指定してクラスタにジョインする必要がありましたが、マルチキャストが使える環境であれば自動的にクラスタにジョインさせることもできます。

いったんすべてのノードでエージェントを停止します。

次のように -discover に適当な名前を付けて起動します。

serf agent -iface=eth0 -discover=oreore

起動後にクラスタメンバを確認してみると、自動的にクラスタにジョインされています（インデント部分はコマンドの出力）。

docker exec node1 serf members
    node1  172.17.0.10:7946  alive  
    node2  172.17.0.11:7946  alive  
    node3  172.17.0.12:7946  alive

docker exec node2 serf members
    node2  172.17.0.11:7946  alive  
    node1  172.17.0.10:7946  alive  
    node3  172.17.0.12:7946  alive

docker exec node3 serf members
    node3  172.17.0.12:7946  alive  
    node1  172.17.0.10:7946  alive  
    node2  172.17.0.11:7946  alive

なお、-discover に指定した名前がクラスタの名前になるので、同じセグメントに複数のクラスタがある場合はクラスタごとに異なる名前にする必要があります。

イベントハンドラ

serf はクラスタ内で発生するさまざまなイベントに対してスクリプトを実行することができます。

一旦 node1 のエージェントを停止してイベントハンドラのスクリプトを node1 に作成します。

cat <<'EOS'> handler.sh
#!/bin/bash
echo 
printf "\e[0;32m%s=%s\e[m\n" "SERF_EVENT" "${SERF_EVENT}"
printf "\e[0;32m%s=%s\e[m\n" "SERF_SELF_NAME" "${SERF_SELF_NAME}"
printf "\e[0;32m%s=%s\e[m\n" "SERF_USER_EVENT" "${SERF_USER_EVENT}"
printf "\e[0;32m%s=%s\e[m\n" "SERF_USER_LTIME" "${SERF_USER_LTIME}"
while read line; do
    printf "  \e[0;32m%s\e[m\n" ${line}
done
EOS
chmod +x handler.sh

イベントハンドラを指定してエージェントを起動します。

serf agent -iface=eth0 -discover=oreore -log-level=debug -event-handler=$PWD/handler.sh

さっそくノードがジョインしたイベントが発生しました。

SERF_EVENT=member-join
SERF_SELF_NAME=node1
SERF_USER_EVENT=
SERF_USER_LTIME=
  node1
  172.17.0.10
  node2
  172.17.0.11
  node3
  172.17.0.12

node2 のエージェントを停止すると member-leave イベントが発生します。

SERF_EVENT=member-leave
SERF_SELF_NAME=node1
SERF_USER_EVENT=
SERF_USER_LTIME=
  node2
  172.17.0.11

もう一度 node2 のエージェントを起動すると member-join が発生します。

SERF_EVENT=member-join
SERF_SELF_NAME=node1
SERF_USER_EVENT=
SERF_USER_LTIME=
  node2
  172.17.0.11

node3 のエージェントをサスペンドさせると member-failed が発生します (Ctrl+Z)。

SERF_EVENT=member-failed
SERF_SELF_NAME=node1
SERF_USER_EVENT=
SERF_USER_LTIME=
  node3
  172.17.0.12

再開させると (fg) member-join が発生します。

SERF_EVENT=member-join
SERF_SELF_NAME=node1
SERF_USER_EVENT=
SERF_USER_LTIME=
  node3
  172.17.0.12

カスタムイベント

次のように任意のカスタムイベントを発生させることができます

docker exec node1 serf event hoge 1234567890

hoge はイベント名で 1234567890 はペイロードです、ペイロードは標準入力から得られます

SERF_EVENT=user
SERF_SELF_NAME=node1
SERF_USER_EVENT=hoge
SERF_USER_LTIME=1
  1234567890

クエリ

カスタムイベントはイベントを通知するだけですが、クエリだと各ノードからコマンドやスクリプトの実行結果を得ることができます

一旦すべてのノードのエージェントを停止して、次のようにイベントハンドラを指定してエージェントを起動します

serf agent -iface=eth0 -discover=oreore -event-handler=query:shell=/bin/bash

クエリを実行します

docker exec node1 serf query shell uptime

すべてのノードで uptime を実行した結果が得られます。

Query 'shell' dispatched
Ack from 'node1'
Response from 'node1':  12:55:05 up 1 day, 12:09,  0 users,  load average: 0.00, 0.00, 0.00
Ack from 'node2'
Ack from 'node3'
Response from 'node3':  12:55:06 up 1 day, 12:09,  0 users,  load average: 0.00, 0.00, 0.00
Response from 'node2':  12:55:06 up 1 day, 12:09,  0 users,  load average: 0.00, 0.00, 0.00
Total Acks: 3
Total Responses: 3

Docker コンテナを管理

もう少し実用的な用途として、Docker のコンテナ起動時に serf を自動でホストを含むクラスタに参加させるようにしてみます。

まず、ホスト側にも serf をインストールします。

wget https://dl.bintray.com/mitchellh/serf/0.6.4_linux_amd64.zip
unzip 0.6.4_linux_amd64.zip
sudo mv serf /usr/local/bin

コンテナ起動時に serf を実行するための Dockerfile を作成します。

FROM centos:7

RUN yum install -y wget unzip ;\
    yum clean all

RUN wget -q https://dl.bintray.com/mitchellh/serf/0.6.4_linux_amd64.zip && \
    unzip 0.6.4_linux_amd64.zip && \
    mv -v serf /usr/local/bin ;\
    rm -vf unzip 0.6.4_linux_amd64.zip

ENTRYPOINT ["serf"]
CMD ["agent", "-iface=eth0", "-discover=oreore", "-event-handler=query:shell=/bin/bash"]

イメージをビルドします。

docker build -t example:serf .

コンテナを起動します。

docker run -d --name node1 -h node1 example:serf
docker run -d --name node2 -h node2 example:serf
docker run -d --name node3 -h node3 example:serf

さらにホスト側でも起動

serf agent -iface=docker0 -discover=oreore -node=host >/dev/null &

メンバを一覧すると・・・

serf members

コンテナの一覧が得られます。

host   172.17.42.1:7946  alive  
node1  172.17.0.10:7946  alive  
node2  172.17.0.11:7946  alive  
node3  172.17.0.12:7946  alive

クエリを使えば・・・

serf query shell uptime

すべてのコンテナでコマンドを実行することができます。

Query 'shell' dispatched
Ack from 'host'
Ack from '361998e3d055'
Response from '361998e3d055':  13:10:24 up 1 day, 12:24,  0 users,  load average: 0.00, 0.05, 0.02
Ack from 'd0e5b5fb6c63'
Response from 'd0e5b5fb6c63':  13:10:24 up 1 day, 12:24,  0 users,  load average: 0.00, 0.05, 0.02
Ack from '3fc7c50f677e'
Response from '3fc7c50f677e':  13:10:25 up 1 day, 12:24,  0 users,  load average: 0.00, 0.05, 0.02
Total Acks: 4
Total Responses: 3