はじめてのGlusterFS 4.0

glusterをやっと試せた。

setupは ↓ をそのままするだけ

> [**Install and Configure GlusterFS on CentOS 7 / RHEL 7 - ITzGeek -**](https://www.itzgeek.com/how-tos/linux/centos-how-tos/install-and-configure-glusterfs-on-centos-7-rhel-7.html)  



**GlusterFS 4.0 のリポジトリ on RHEL7** はこれです。

```ini
[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すらできない。
 - ![image.png](https://qiita-image-store.s3.amazonaws.com/0/24737/952b7089-9a86-55cb-df8f-63c5a28f8ca4.png)
- gluster1を上げる
 -  → clientは**即座に復帰**してr/w可能になる


mountし直さなくても戻ってくれるのがいいね。


ただ  [**GlusterFS(3.3)からの脱却に成功した2018.2.7 - Qiita**](https://qiita.com/sogaoh/items/de5aed62b5093c47b517)  という話もあるので、本番にはまだまだ怖い。

次はOpenShiftと組み合わせて使っていきたいかなというところ。




##### 参考
> [**GlusterFS を使ってみた - ngyukiの日記**](http://ngyuki.hatenablog.com/entry/2015/08/26/013622)  

> [**分散ファイルシステム「GlusterFS」の高速化と自己修復機能強化 - TechTargetジャパン サーバ＆ストレージ**](http://techtarget.itmedia.co.jp/tt/news/1706/12/news01.html)  

> [**GlusterFS の Split-Brain 障害対応 – www.nodoka.org**](http://www.nodoka.org/glusterfs-の-split-brain-障害対応/)  
>> 当初よく起きていた問題が、冗長化された2つのデータが異なってしまう障害。それをglusterfsではSplit-Brainと位置付けている。もしかしたらデータを3つに冗長化すれば、quorumでSplit-Brainを回避してくれるのかもしれないが、自分の環境では3ノードの冗長化は想像以上に性能が劣化したので見合わせている。発生するのはいずれかのノードを停止して再構築する際。片肺状態のときにGlusterFS上のkickstartファイルやansibleのplaybookファイルに不足していた設定を加えることが多々あり、再構築後のクラスタージョイン時にSplit-Brainとなってしまった。

> [**Managing Volumes - Gluster Docs**](https://docs.gluster.org/en/v3/Administrator Guide/Managing Volumes/)  
>> Configuring Transport Types for a Volume

> [**4.5. ヒーリングとスプリットブレイン – GlusterFS Community ではじめる分散ファイルシステム**](https://reboot.makeall.net/docs/glusterfs/known-4-5/)  
>> quorum  
>> クォラムはネットワーク分断に備えて一定数（通常は過半数以上）のノードが分断時に存在していればそのノードグループが正しいものと考えてサービス継続を行う機能です。

> [**スプリットブレインの解消 - GlusterFS技術情報**](https://sites.google.com/site/glusterfstech/recovery/split-brain)  
>> スプリットブレインとは  
>> 例えば、レプリケーション構成のボリュームにおいて次のような操作をすると、レプリカされたファイルの内容にノード間で矛盾が生じて、GlusterFSは、どちらの内容が正しいかを判断することができなくなります。  
>>   
>> ※ここでは、「ボリューム構成手順」で作成したボリューム「vol02」を想定します。これは、gluster01とgluster02でレプリケーションされた構成のボリュームです。  
>>   
>> gluster01を停止  
>> 　↓  
>> クライアントからファイルを更新（gluster02のみに書き込まれる）  
>> 　↓  
>> gluster02を停止後、gluster01を再起動  
>> 　↓  
>> クライアントからファイルを更新（gluster01のみに書き込まれる）  
>> 　↓  
>> gluster02を再起動  
>>   
>> このような状況を「スプリットブレイン」と呼びます。この時、これ以上ファイルの内容が破壊されないように、GlusterFSはクライアントから該当ファイルへのアクセスを禁止します。クライアントから該当ファイルにアクセスすると「I/Oエラー」になります。  
>>   
>> スプリットブレイン状態のファイルを回復するには、管理者が各ノードのファイルの内容を直接確認して、不要と判断した方のファイルを手動で削除した上で再レプリケーションを行う必要があります。  
>> 

> [**RHS2.0Beta2(glusterfs-3.3.0qa38)のSelf-heal Daemon - めもめも**](http://enakai00.hatenablog.com/entry/20120508/1336444332)  
>> 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**](https://tokyox22.wordpress.com/2012/11/08/glusterfsのsplit-brain-の解消/)  
>> スプリットブレイン状態のファイルを回復するには、管理者が各ノードのファイルの内容を直接確認して、不要と判断した方のファイルを手動で削除した上で再レプリケーションを行う必要があります。  
>>   
>> 古いブリック内のファイルを削除して、正しい方のファイルで再レプリケーションします。  
>> # 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編**](http://aws.typepad.com/aws_partner_sa/2015/03/redhat-gluster-storage.html)  
>> **GlusterFSのボリュームのタイプ  
>> よく使われるボリュームタイプとして、分散ボリューム、分散レプリカボリュームがあります**。ストライピングボリューム、 ストライピングレプリカボリュームは仕組み的にデータ欠損が起きる可能性が高いのでRed Hat Gluster Storageでは非サポートとしています。  
>> しかもGlusterFSのストライピングはワークロードによっては期待通りに速くならないケースが多いので注意が必要です。キャッシュに乗らないような1個の巨大なファイルを複数のクライアントから同時にアクセスされる場合には有効ですが、ほとんどのユースケースにおいては、分散レプリカボリュームで十分要件を満たすことができます。