glusterをやっと試せた。
setupは ↓ をそのままするだけ
Install and Configure GlusterFS on CentOS 7 / RHEL 7 - ITzGeek -
GlusterFS 4.0 のリポジトリ on RHEL7 はこれです。
[root@rhel7 ~]# cat /etc/yum.repos.d/Gluster.repo
[gluster40]
name=Gluster 4.0
baseurl=http://mirror.centos.org/centos/7/storage/$basearch/gluster-4.0/
gpgcheck=0
enabled=1
centosでは代わりに yum install -y centos-release-gluster をしてから、
yum install -y glusterfs-server します。
結果
見事にどのサーバでfile追加しても即座に同期されました。
障害時のテスト
- gluster1を落とす
- → gluster2/clientともに30秒間くらいr/wできなくなる
- gluster2も落とす
- → clientは何もできなくなる。readすらできない。
- gluster1を上げる
- → clientは即座に復帰してr/w可能になる
mountし直さなくても戻ってくれるのがいいね。
ただ GlusterFS(3.3)からの脱却に成功した2018.2.7 - Qiita という話もあるので、本番にはまだまだ怖い。
次はOpenShiftと組み合わせて使っていきたいかなというところ。
参考
分散ファイルシステム「GlusterFS」の高速化と自己修復機能強化 - TechTargetジャパン サーバ＆ストレージ
GlusterFS の Split-Brain 障害対応 – www.nodoka.org
当初よく起きていた問題が、冗長化された2つのデータが異なってしまう障害。それをglusterfsではSplit-Brainと位置付けている。もしかしたらデータを3つに冗長化すれば、quorumでSplit-Brainを回避してくれるのかもしれないが、自分の環境では3ノードの冗長化は想像以上に性能が劣化したので見合わせている。発生するのはいずれかのノードを停止して再構築する際。片肺状態のときにGlusterFS上のkickstartファイルやansibleのplaybookファイルに不足していた設定を加えることが多々あり、再構築後のクラスタージョイン時にSplit-Brainとなってしまった。
Managing Volumes - Gluster Docs
Configuring Transport Types for a Volume
4.5. ヒーリングとスプリットブレイン – GlusterFS Community ではじめる分散ファイルシステム
quorum
クォラムはネットワーク分断に備えて一定数（通常は過半数以上）のノードが分断時に存在していればそのノードグループが正しいものと考えてサービス継続を行う機能です。スプリットブレインとは
例えば、レプリケーション構成のボリュームにおいて次のような操作をすると、レプリカされたファイルの内容にノード間で矛盾が生じて、GlusterFSは、どちらの内容が正しいかを判断することができなくなります。※ここでは、「ボリューム構成手順」で作成したボリューム「vol02」を想定します。これは、gluster01とgluster02でレプリケーションされた構成のボリュームです。
gluster01を停止
↓
クライアントからファイルを更新（gluster02のみに書き込まれる）
↓
gluster02を停止後、gluster01を再起動
↓
クライアントからファイルを更新（gluster01のみに書き込まれる）
↓
gluster02を再起動このような状況を「スプリットブレイン」と呼びます。この時、これ以上ファイルの内容が破壊されないように、GlusterFSはクライアントから該当ファイルへのアクセスを禁止します。クライアントから該当ファイルにアクセスすると「I/Oエラー」になります。
スプリットブレイン状態のファイルを回復するには、管理者が各ノードのファイルの内容を直接確認して、不要と判断した方のファイルを手動で削除した上で再レプリケーションを行う必要があります。
RHS2.0Beta2(glusterfs-3.3.0qa38)のSelf-heal Daemon - めもめも
Split-brainについて
次のような障害シナリオを考えます。gluster02停止 -> クライアントがfile0.txtに書き込み -> gluster01停止 -> gluster02起動 -> クライアントがfile0.txtに書き込み -> gluster01起動
この場合、gluster01とgluster02が保持するfile0.txtの内容に矛盾が生じて、Self-heal Daemonはどちらからどちらに再レプリケーションしてよいかわからなくなります。このような状態をSplit-brainと呼びます。
Split-brain状態のファイルを検知したクライアントは、安全のためにそのファイルへのアクセスを停止します。（アクセスするとI/Oエラーを返す。）
また、Split-brain状態のファイルの存在は、GlusterFSサーバ上で、次のコマンドで確認できます。
[root@gluster01 ~]# gluster vol heal vol01 info split-brain
Split-brain状態のファイルに対しては、利用者自身がどちらのファイルを正とするかを決めて、再レプリケーションを行う必要があります。ただし、具体的な方法については、まだ開発中の様です。手順が確定したら、あらためて追記します。glusterfsのsplit brain の解消 | tokyox22
スプリットブレイン状態のファイルを回復するには、管理者が各ノードのファイルの内容を直接確認して、不要と判断した方のファイルを手動で削除した上で再レプリケーションを行う必要があります。
古いブリック内のファイルを削除して、正しい方のファイルで再レプリケーションします。
gluster volume stop syncdata
getfattr -d -m trusted.gfid -e hex /home/syncdata/brainfile.txt
getfattr: Removing leading ‘/’ from absolute path names
file: home/syncdata/pgdata/postgresql.conf
trusted.gfid=0xebeef9c437894a8ca910dd98ab240297
rm -rf /home/syncdata/brainfile.txt
rm -rf /home/syncdata/.glusterfs/eb/ee/ebeef9c4-3789-4a8c-a91-0dd98ab240297
gluster volume start syncdata
クライアントからbrainfile.txtに正常にアクセスするには、ファイルシステムの再マウントが必要になります。
AWS Partner SA ブログ: レッドハット社技術投稿 - Red Hat Gluster Storage編
GlusterFSのボリュームのタイプ
よく使われるボリュームタイプとして、分散ボリューム、分散レプリカボリュームがあります。ストライピングボリューム、 ストライピングレプリカボリュームは仕組み的にデータ欠損が起きる可能性が高いのでRed Hat Gluster Storageでは非サポートとしています。
しかもGlusterFSのストライピングはワークロードによっては期待通りに速くならないケースが多いので注意が必要です。キャッシュに乗らないような1個の巨大なファイルを複数のクライアントから同時にアクセスされる場合には有効ですが、ほとんどのユースケースにおいては、分散レプリカボリュームで十分要件を満たすことができます。