koie blog : いってきた: Linux女子部09 「新定番!10年効く分散ストレージ技術 Ceph勉強会」

2014-08-07 19:00〜21:15
恵比寿ネオナート5F レッドハット(株)セミナールーム
#ljstudy
募集ページ: http://ljstudy.connpass.com/event/7291/
「Cephアーキテクチャ解説」/岩尾はるか: https://schoo.jp/class/1012
まとめ: http://togetter.com/li/703541

7/5深夜に募集開始して朝になっても登録数が伸びてないので余裕かましてたら、昼にみたときには定員越えててあわてて申しこんだが補欠16番目。当日の夕方になってやっと繰り上がり。

余裕をもって会社を出たのに、場所の確認がいいかげんだったので恵比寿駅から歩く歩道を歩いてガーデンプレイスに着いたところで屋外に出てgoogle mapをみると現在位置はかな〜り会場から離れていていて、実は会場は駅に近かったことを知った。事前に調べて覚えていたビルの外観を頼りに早足で歩いて汗だく5分前入場。最後列(机なし)に陣どる。

席はけっこう埋まっていて、さすがに女子部というだけあってIT系のイベントとしては女子率が高い。

第一部「Cephアーキテクチャ解説」/岩尾はるか氏 @Yuryu

19:03〜19:58
https://schoo.jp/class/1012
(2014-7-1版) http://www.slideshare.net/Yuryu/ceph-36503772
筑波大学の研究室でcephの論文にふれる。
2003年: UCSCで開発
2006年: オープンソース化
2007年: cephの論文が公開
ハードディスクの容量はどんどん増加している
- ※スライドでは線形と書いてあるが、容量は指数増加。
- ただし1980年ごろのHDDはとても高価なことに注意。
扱う情報が増えてきたので溜めるための技術が必要になった。RAID→SAN→分散ストレージ
RADOS レイドス
- reliable, autonomic, distributed, objectstore の略
- RADOSが信頼できるのでceph fsが信頼できるというロジック。
- osdとmonからなる。
- osdはバックエンドストアにxfs/btrfsをつかう。
- 追記(write-ahead)なので途中でクラッシュしてもリカバリできる。
- osdは数万台でも設計上はだいじょうぶ。
- monはクラスタの管理をする。少数でよい。奇数台。
- CRUSHというアルゴリズムをつかう。
- 計算のみでオブジェクトの名前からハッシュ関数で決定的にosdを決める。MDSが介在しないのでSPoFがない。
- osdをそのまま扱うとめんどくさい?のでplacement group(PG)を導入する。
- PG = Hash(名前) % PG数, OSD = CRUSH(PG, クラスタマップ, ルール)
- クラスタマップはラック→ホスト→ディスクのように階層化して記述できる。分散したつもりが同じラックに入っていて電源障害で同時停止しないように。
- CRUSHで計算される先頭のosdが複製するときのプライマリになる。
- 同期的にリプリケーションされるのでwriteがおわったら冗長化は済んでいる。
- osdが止まるとdown状態になって5分たつとout状態になってクラスタマップから外される。いきなりoutにならないのは、サーバメンテでリブートしたいときに。
radosgw
- S3/swift互換のRADOSのゲートウェイ
RBD
- RADOSをOSのブロックデバイスにみせる。
- オブジェクト単位だとあつかいにくいので4Kとかのブロック単位にみせる。
- mkfsしてマウントできる。複数のOSからマウントすると整合性がとれなくてファイルシステムが壊れる(ロックはかからない)。
Ceph FS
- POSIX互換
- mdsがファイルシステムツリーを管理する。
  - mdsはジャーナルを書く。
  - active-standbyは動くが、active-activeはうまく動かない。
  - mtimeなどもmdsの管理。
- dynamic subtree partitioning
  - ディレクトリサブツリーを別のmdsに分担させられる。親とつながっているところが1点になるメリット。
  - 負荷をみて動的に構成。
  - これは計画中(まだ動いてない?)
- Ceph FSはなかなか安定せず、いまだに実験的レベル。
- Ceph FSはロードマップから消えた。しばらくはメンテされるだろうが、いずれ止めてしまう可能性大。アイデアはよかったが実装が難しい?
- ローリングアップグレードでサービスを動かしたままバージョンアップできる。
- erasure coding: リードソロモン符号(誤り訂正)をつかって容量オーバヘッドを減らして冗長化を達成する。その代り計算コストがかかるのでアクセス頻度が低いデータに有効。
- osdのバックエンドにxfs/btrfsではなく、もっと軽いLevelDB(key-value store)をつかえるようになった。
- バックエンドネットワークとクライアントからのネットワークを分離できる。
Q: osd自体はHAになっていない?
A: osdが死んでも複製のosdにアクセスできればよいので。
デモ:
- RHじゃなくてubuntu。
- ceph-deployコマンド(python)をばしばしたたくとできる。
- 名前がdeployなのに何度もサブコマンドを実行しないと終わらないのはヘンだけど。
- ceph-deployはあんまりまじめに作ってないらしい。
Q: LVMはつかえる?
A: つかえる。
Q: RBDは共有ドライブとしてつかえる?
A: マウントできるのは一人だけ。

10分休憩

第二部「Cephにまつわる経験談」/小原泰弘氏

20:10〜20:38〜20:53
UCSC: cephの研究室にいっていた。日本に帰ってきたらcephが流行ってた。
UCSCのあるSanta Cruzは日本の軽井沢みたいなところでいいところ。
UCSCのマスコットはbanana slug(ナメクジ)でゆるキャラ。
ナメクジにならってceph?
luster,GPFSのあとに出てきた。後発なのでデザインがよく、トップカンファレンスに論文が何本もとおっている。
HPC分野では数TBのファイルを区切って計算を分担することがよくある。
cephはいろいろなアクセスのためのインタフェースがそろっている。
ラックの一列は電源系統が同じことが多く、同時に障害がおこる可能性が高いので、ポリシーを書いて異なるラック列からosdを選択できたり。
lusterとちがいリバランスに対応している。
レプリカ数は自由に変えられる。
IPv6に対応している!
拡張属性(xattr)に対応している。
ベンチマーク(fio)
- スループット・IOPSともに生ディスクと比べると性能が落る。
- ただしシーケンシャルreadはキャッシュが効いてしまうのか、とんでもない性能が出ている。
Q: SSDをジャーナルにつかうとどのくらい速くなる?
A: よくかわってないが、HDD 5台に対してSSD 1台くらいがおすすめらしい。
Q: osdを追加してゆくときにオーバヘッドは発生するか?
A: 特にない。データの移行も徐々に進行して、いきなり負荷が上がるようなことはない。
- 注意点: PacementGroupの数は変えられないため、あらかじめ大きめの値にしておく必要あり。大きすぎて困ることはない。
- 注意点: PGの数を変える機能はexperimentalで入っているが、使ってはいけない。
sageはがんばり屋だが、それでもceph fsは安定せず。実験的機能を入れすぎなのかも。RBDは安定している。
Q: 派手に壊れたことはあるか?
A: CRUSHマップを手でいじって復旧不可能になったことはある。