1　

2　

自己紹介

 高橋 敬祐 ! Dev at NTT PC コミュニケーションズ ! Gluster Community Advisory Board メンバー

! GlusterFS歴8年 ! 携わった案件：多数

! Twitter: @keithseahus

3　

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

4　

Recap: GlusterFSについて

5　

分散ファイルシステム

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

6　

特徴１：中央サーバを持たない構成

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

7　

特徴２：クライアントに豊富な機能

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

8　

特徴３：多様なインタフェース

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

9　

昔こんなバグが！

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　

技術関係者の 証言

12　

CTDBによるNFSのフェイルバック

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

13　

サーバのダウン時における書き込み処理の一時停止

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

14　

XFSに比べて遅い

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

15　

SSDの中で高速な製品を選定する意味がない

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

16　

CentOS 7でのKVM統合には工夫が必要

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

17　

マルチテナントは難しい

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

18　

大容量化した場合のBG処理の長時間化

 リバランスが終わらない・・・   self-healが終わらない・・・  高橋コメント：収容設計は入念に行い、増設は計画的に。

19　

個人的に 思うところ

20　

個人的に思うところ

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

21　

まとめ

22　

まとめ

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

23　

ご清聴ありがとうございました。

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