A presentation (in Japanese) for Datastore Masakari Talks on Feb. 26th, 2015.

1. 1

2. 2
自己紹介
高橋 敬祐
! Dev at NTT PC コミュニケーションズ
! Gluster Community Advisory Board メンバー
! GlusterFS歴8年
! 携わった案件：多数
! Twitter: @keithseahus

3. 3
Recap: GlusterFSについて
昔こんなバグが！
技術関係者の証言
個人的に思うところ
まとめ

4. 4
Recap:
GlusterFSについて

5. 5
分散ファイルシステム
出典：高橋敬祐 「テクノロジー最前線 今注目の分散ファイルシステム「GlusterFS」」
『日経SYSTEMS
2014年10月号』
pp.54-­‐59

6. 6
特徴１：中央サーバを持たない構成
出典：高橋敬祐 「テクノロジー最前線 今注目の分散ファイルシステム「GlusterFS」」
『日経SYSTEMS
2014年10月号』
pp.54-­‐59

7. 7
特徴２：クライアントに豊富な機能
出典：高橋敬祐 「テクノロジー最前線 今注目の分散ファイルシステム「GlusterFS」」
『日経SYSTEMS
2014年10月号』
pp.54-­‐59

8. 8
特徴３：多様なインタフェース
出典：高橋敬祐 「テクノロジー最前線 今注目の分散ファイルシステム「GlusterFS」」
『日経SYSTEMS
2014年10月号』
pp.54-­‐59

9. 9
昔こんなバグが！

10. 10
昔こんなバグが！
self-healでtruncate忘れ(v1.3.7)
self-healでsymlink先が書き変わらない(v1.3.7)
write-behindで無駄にパフォーマンス低下(v2.0.2)
readdir中にフェイルオーバーするとクライアント側の
プロセスがダウン(v2.0.8)
WindowsからNFSマウントした場合、ファイルを削除
しても、ファイルが消えない(v3.1.x)
gfidの衝突(v3.2.x)
Geo-Replicationの取りこぼし(v3.4.x)
メモリリークいろいろ

11. 11
技術関係者の
証言

12. 12
CTDBによるNFSのフェイルバック
NFSをCTDBでフェイルオーバーさせる構成。
フェイルバックさせたいが、NFSマウントポイント配下
に対する読み込み又は書き込みの実行中にフェイルバッ
クさせると、その操作が15分程度固まる。
高橋コメント：フェイルオーバーしたら戻さないサービ
ス仕様でも、実害は無いと思われます。

13. 13
サーバのダウン時における書き込み処理の一時停止
レプリカ構成のボリュームについて、FUSEマウントし
たホストから書き込みを続けている場合に、片方の
brickのサーバをダウンさせると、書き込みが30秒程度
停止する。
高橋コメント：GlusterFS内部では、複数のレイヤでタ
イムアウト判定をしています。

14. 14
XFSに比べて遅い
fioによるベンチマークで、FUSEマウントポイント配下
に対するIOPS及びスループットが、XFSのそれに対し
て、1/4程度である。
IOzoneで計測した場合、シーケンシャルreadのスルー
プットの値は、相対的なパフォーマンスは良かった。
高橋コメント：それはそうでしょう。ちなみに、シーケ
ンシャルreadの値が良いのは、io-cacheとread-ahead
のおかげです。

15. 15
SSDの中で高速な製品を選定する意味がない
brickに用いるSSDは、製品ごとに速度にバラツキがあ
るが、GlusterFSを経由すると、IOPS及びスループッ
トは頭打ちになるため、どの製品を選んでも変わらない。
高橋コメント：これも予測可能です。レイテンシが低く、
スループットの高いインターコネクト、また、高速な
CPUとメモリを採用することで、よりSSDの性能が引
き出せると考えられます。

16. 16
CentOS 7でのKVM統合には工夫が必要
CentOS 7標準のlibvirt（バージョン1.1）を使って、
libgfapi利用のQEMU/KVMインテグレーションを行う
と、IOエラーが出るケースあり。
バージョン1.2のlibvirtに入れ替えたら、IOエラーは発
生しなくなった。
高橋コメント：OpenStack Cinderとして導入する場合
には、気をつけて下さい。

17. 17
マルチテナントは難しい
NFSでマルチテナント提供を模索。
GlusterFSのNFSに関する設定について、特定のボ
リュームに対する変更であっても、他のボリュームに対
するIOが一時的に停止する。
高橋コメント：過去に改善提案を出し、原因となる設計
の半分は対応済みで、問題の起こるオペレーションは限
定的となっています。残りの部分の対応に期待しましょ
う。

18. 18
大容量化した場合のBG処理の長時間化
リバランスが終わらない・・・
self-healが終わらない・・・
高橋コメント：収容設計は入念に行い、増設は計画的に。

19. 19
個人的に
思うところ

20. 20
個人的に思うところ
self-heal（特にノード交換からの復旧）のトラフィック
がサービスに与える影響は、必ず議論に上がる。この処
理は、GlusterFSクライアント­サーバ間とは別のネッ
トワーク・インタフェースで実行できるようにすべき。
タイムスケジューリング又はスループット制限も、でき
るようにした方が良いだろう。
リバランス（によるトラフィックと、その処理時間）は、
コンシステント・ハッシング方式の「弁慶の泣き所」。
収容設計と増設は計画的に行うべし。安価な大容量スト
レージが欲しいのであれば、4UサーバーとDASの組み
合わせでGlusterFSを組むのも手。
マルチマスタのGeo-Replicationはニーズが確実に存在
するため、早期の実装が望まれる。

21. 21
まとめ

22. 22
まとめ
GlusterFSに携わる立場から、愛のあるマサカリを投げ
てみました。
導入を検討するにあたっては、Linuxのユーザー空間で
動作するPOSIX準拠の分散ファイルシステムならではの
特性を踏まえる必要があります。
ミドルウェアとしてはほぼ問題なく動作しますが、細か
いところでサービスの要件と衝突するケースがあります。
気になる部分は実際に検証して、動作を確認しましょう。

23. 23
ご清聴ありがとうございました。
Recap: GlusterFSについて
昔こんなバグが！
技術関係者の証言
個人的に思うところ
まとめ