cephとgluster次期バージョンでの新機能
Post on 22-Jul-2015
1.937 Views
Preview:
TRANSCRIPT
(Ceph|Gluster)次期バージョンでの新機能!Ceph Infernalis, Gluster 4.0
Haruka Iwao Storage Solution Architect, Red Hat K.K.
May 26, 2015
コミュニティ版最新情報 • レッドハット製品開発は”Upstream first”
– 新機能はコミュニティ版へ – 追加の品質保証を経て製品版に
• コミュニティを見れば将来のバージョンに入りそうなものが見えてくる – ただし導入を保証するものではありません
• CephおよびGlusterの最新動向をご紹介
Ceph Hammer • 2015年4月8日にリリース • v0.94
– ただしv0.94には致命的なバグがあるので、v0.94.1 以降の利用を強く推奨
– もっと言えばRHCephの利用を推奨 :) • Red Hat Ceph Enterprise 1.3のベース
Ceph Hammerの新機能 • RADOS性能向上
– 特に高速な計算機での性能が向上 – フラッシュバックエンドのスループット向上
• RGWデプロイの簡単化 – ceph-deploy rgw create HOST でokに – Apache-basedから組み込みのCivetweb
serverに変更(Apacheも手動で利用可能)
Ceph Hammerの新機能(2) • RGW Object Versioning
– S3 の Versioning API をサポート – 古いオブジェクトのバージョンを取得可能
• RGW Bucket harding – バケットインデックスをsharding – 非常に大きなバケットでの性能改善
• RBDオブジェクトマップ – イメージのどの部分がallocatedか追跡 – exportやdeleteの性能が向上
Ceph Hammerの新機能(3) • RBD mandatory locking (デフォルト無効)
– 複数のクライアントが同一イメージを同時に使えないようにロック
• RBD copy-on-read – イメージのクローンでcopy-on-read – いくつかの負荷で性能が向上
• CephFS スナップショット改善 – たくさんのバグを修正 – まだデフォルトでは無効
Ceph Hammerの新機能(4) • CephFS Recovery Tools
– ジャーナルによる復元と分析ツール – シングルMDSはGiantとHammerで安定性と性能が向上したが、まだexperimental
• CRUSHの改善 – 新しいstraw2アルゴリズムの導入 – クラスタ構成変更時のデータ移動量を削減
Ceph Hammerの新機能(5) • RADOS cache tieringの改善
– 性能とレイテンシを削減 • RDMAサポート(experimental)
– libxioを使ったRDMAの実験的なサポート • 新しい管理コマンドの追加
– ceph osd df – ceph pg ls
Ceph Infernalis • v9.0.0 がリリース
– バージョン番号については後述 • 次の長期サポート Jewel に向けての中間リリース
• 開発は引き続き継続 • 詳しくは https://wiki.ceph.com/Planning/Blueprints/Infernalis
Ceph のバージョン番号 • コードネームはABC順
– Hammer → Infernalis → Jewel → K → … • バージョン番号が変更
– Hammer: v0.94 – Infernalis: v9.y.z
• x.y.z 方式に移行 – x: n番目のリリース(Iは9番目) – y=0: 開発ver, y=1: RC, y=2: stable
osdの新機能 • New Store(詳しくは後述) • Erasure Coding の上書きサポート • 複数オブジェクト間でのトランザクションのサポート
• コールドストレージのサポート – 明示的にファイルを降格できる
• Peeringの高速化 • tail の高速化
New Store • 既存のOSDバックエンドを置き換え • メタデータをKVSへ保存 • オブジェクトのデータをファイルシステムへ保存
• 新規オブジェクトと、シーケンシャル書き込みへのダブルライトを回避
• 小さなファイルの効率が向上
RGWの新機能 • Active/active マルチサイト
– マルチサイトの複数クラスタへ書き込み可能 – 一つのクラスタがメタデータの変更を管理する「マスター」となる予定
• NFS export – RGW上のデータをNFS経由で読み書き可能に
• Hadoop over RGW – RGWでHadoopを実行
RBDの新機能 • RBD Async Mirroring
– クラスタ間非同期ミラーリング • iSCSI対応
– LIOを利用しiSCSIターゲットに対応 • xio を利用したRDMA対応 • snapshot/cloneの親からの差分をexport可能に
Gluster 3.7 新機能 • ビット化け検出 • マルチスレッドepoll
– Gluster 3.6 にもバックポート済み – 小さなファイルが多数ある場合に、特に性能が向上
• ボリュームTiering – data-classification (後述) の前準備
• ゴミ箱のサポート – 削除されたファイルを一定時間隔離
Gluster 3.7 新機能 (2) • オブジェクト数カウントの効率化
– ディレクトリ内のオブジェクト数を保存 – inode quotaのために導入
• inode quota – 容量ベースのquotaに加え、inodeを制限可能
• exports & netgroups スタイルのNFS – ボリュームやサブディレクトリ単位で、NFSのアクセス制御を可能に
• GlusterFind – ボリューム内でのイベントを監視するツール
Gluster 3.7 新機能(3) • Erasure Coding ボリュームのProactive self
healing – Replicated volumesと同様のサポート
• NFSv4, pNFS サポート – Ganesha によるサポート – NFS HAが可能に – Ganesha をGluster CLIから設定可能 – 組み込みのNFSサーバー(現状)をどうするか議論
• スナップショットスケジューリング • スナップショットクローン
Gluster 3.7 新機能(4) • Sharding [experimental]
– 詳しくは後述 • Arbiter volumes
– 3-wayレプリケーションだが、データの複製は2つで、3つ目はメタデータのみを保存
• より良いSplit brainの解決 • Geo-replicationの性能と安定性向上
Gluster 4.0 • 3.7 の次は 4.0 の予定 • RH Gluster Storageのバージョンは未定 • まだ入れる機能については議論中 • 案として上がっているものをご紹介 • 詳しくは http://www.gluster.org/community/documentation/index.php/Planning40
thousand-node-glusterd • 現在のglusterdは、お互いにn:nで監視をしている – O(N^2)
• paxos / raft ベースの合意形成に変更 • 千台を超えるスケールへ • モニターデーモンの導入 • 設定を、各サーバーにファイルを置く方式から、モニタの専用領域に移動
dht-scalability • 現在の実装では、すべてのディレクトリがすべてのノードに作成される
• 新しい実装では、ディレクトリは単一のノードのみに存在 – ファイルの場所はGFID基準で管理 – readdir()は一つのノードと通信すれば良い – 一貫性を確保するのが容易
sharding-xlator • stripingの後継 • DHTの上で動作
– stripingはDHTの下に存在していた – DHTから見ると、単にファイルが複数存在するように見える
– ノード障害や性能低下に強い
caching • クライアントサイドキャッシュ • まずは読み込みのみ • サーバーの仕事
– どのクライアントが何を持っているのかを管理
– データが変更されたらクライアントに通知 – クライアントの状態管理サーバーが死んだら、クライアントのキャッシュを無効化
data-classification • ポリシーベースのファイル配置 • DHTを複数重ね合わせるイメージ
– 現在のDHTはハッシュによるランダム配置 – その上にowner、アクセス頻度、セキュリティポリシーなどに従って配置するtranslatorを追加
• Cache tierもこの機能を使って実現予定
new-style-replication • 現在のAFRを補完(将来はもしかして置き換え?)する新しいレプリケーション
• サーバーサイド – クライアントからの通信量削減
• ジャーナルベース – 通信量削減、リカバリの高速化
• 複数の一貫性モデルを切り替え可能に • 新しい、小さなコード
compression-dedup • 重複排除
– 分散ノード上での重複排除は、計算コストと得られる結果が見合わないのでスコープ外
– 単一ブリック内での重複排除を検討 – lessfsの導入を検討中
• 圧縮 – ファイル単位での圧縮
• オフラインで、ファイルが閉じられているときに処理する
better-brick-mgmt • 現在は単一のフラットなブリック構造 • より柔軟なブリック管理
– ブリックのグループ化、階層化 – LVMのような容量の割り当て – それぞれのグループに、異なるレプリケーション/EC/分散/tieringポリシーを割り当て
top related