File Systems Unfit as Distributed Storage Backends: Lessons from 10 Years of Ceph Evolution
Authors
Abutalib Aghayev Carnegie Mellon University
Sage Weil Red Hat, Inc.
Michael Kuchnik Carnegie Mellon University
Mark Nelson Red Hat, Inc.
Gregory R. Ganger Carnegie Mellon University
George Amvrosiadis Carnegie Mellon University
SOSP '19 Proceedings of the 27th ACM Symposium on Operating Systems Principles Cephを作ってきた10年間の知見を振り返る論文
Cephは過去ストレージバックエンドを5つ作っている
分散ストレージをファイルシステム上に実装すると幾つかの点で問題がある
効率的なトランザクション
メタデータの高速な処理
新しいストレージハードウェアへの対応
Cephのアーキテクチャ
https://gyazo.com/bc18e8fce01659fb93c7276a61ed9fcb
中心となるのがReliableAutonomicDistributedObjectStorage
ObjectStorageDeviceがデバイスの単位
RADOSが面倒を見てconsistencyを維持しレプリケーションしてくれる
self-healingやマネージなどの機能を提供する
libradosはサービスがRADOSへトランザクションを発行するための機能を提供
ディレクトリ階層を持たず、ソフトウェアから利用されることを念頭に置いたストレージのこと
メタデータの管理やHTTPプロトコル対応など
avashe.iconファイルストレージと何が違うの?と思ったけど階層構造を取っ払い、メタデータを使って一意に特定できれば機械向けにもっと単純化できるということか
kimitoboku.iconファイルが無限に増える場合に階層構造だとディレクトリのサーチなども必要だけど,フラットだと見る場所が少ないし,管理も楽.完全にファイルサイズだけの課金に出来る.avashe.icon
Amazon S3が有名
RADOSBlockDeviceは仮想ブロックデバイス、CephFSはPosix対応した分散ファイルシステム
Poolが最も大きな論理的パーティション
Cephの分散システムの一塊で、冗長性を確保するシステムの単位
PlacementGroupsが多重化するオブジェクト群の単位
一個ずつ多重化するのではなく、グループにまとめてするそうです
群がまたぐOSDの数はパラメータで設定できる(replication factor)
PGを複数OSDへマッピングするのがCRUSHというpseudo-random data distribution algorithm
集権的なメタデータサービスを使わずとも、クライアント自身がオブジェクトの保存場所を判断できる
PGとCRUSHという抽象化によって、クラスタ内のワークロードの変化に応じたマイグレーションが可能
Cephバックエンドの歴史
元々はB-Treeベースのファイルシステム上に実装しており、2008年からはBtrfsを使うようになった
最初はposixのメタデータ拡張機能であるxattrsを使ってオブジェクトの情報を表現するが、LevelDBに移る