BLUECORE.NET Home IT infrastructure hobbyist 分散ストレージCephの アーキテクチャ BLUECORE.NET-Administrator ：localYouser (@[email protected])

Home IT infrastructure hobbyist -BLUECORE.NET はじめに  Ceph Architectureのドキュメント (http://docs.ceph.com/docs/master/architecture/ )から、Cephのアーキテ クチャについて学んでいったことを並べていったドキュメント。  自宅Ceph障害の際、結構わからない単語が出てきたため、そもそもの仕組みに ついて一定の理解が必要と判断した。  ひとまずドキュメントを読み、順次わからないところを掘り下げるものとして当 該ドキュメントを作成する。

Home IT infrastructure hobbyist -BLUECORE.NET アーキテクチャについて書いてみる

Home IT infrastructure hobbyist -BLUECORE.NET データアクセスにおけるアーキテクチャ REST API Block File System Cephが用意している インタフェース

Home IT infrastructure hobbyist -BLUECORE.NET クライアントとクラスタの関係 REST API Block File System RADOS RADOSとして受付する プロトコルはCSCP

Home IT infrastructure hobbyist -BLUECORE.NET 主な役割：ダッシュボードからサービスを見る mds ：metadata server ：メタデータ(属性/権限等)の格納(FILEで使用) mon ：monitor ：クラスタマップの配信、認証、監視 osd ：object storage daemon ：オブジェクトの格納

Home IT infrastructure hobbyist -BLUECORE.NET オブジェクトとは オブジェクトID オブジェクトデータ メタデータ 1オブジェクトを1つのファイル としてディスクに格納する

Home IT infrastructure hobbyist -BLUECORE.NET 各役割とのやり取り クライアント/mon間の 認証キー共有 mon/mds/osd間の 認証キー共有 クライアント/mon間の認証 認証成功ならば、クライアントへ チケットを返送 チケットを使ってクライアントは リクエストを行い、認証OKならば 各IO処理デーモンは応答を返す

Home IT infrastructure hobbyist -BLUECORE.NET クライアントとOSD間のWrite処理 クライアントのWrite要求は 1つのOSDが受け付ける replica数-1の分だけ オブジェクトをコピーする Write処理の仕組みは同期型である。

Home IT infrastructure hobbyist -BLUECORE.NET クライアントとプール間のWrite処理 ■プールに対して設定する内容 ⚫ オブジェクトに対するオーナーシップ ⚫ Placement Group(PG)の数 ⚫ 使用するCRUSHルール ■Cluster Map クラスタの構成情報であり、現在の クラスタの状態も格納している。 クライアントはこれを参照してアクセスする

Home IT infrastructure hobbyist -BLUECORE.NET CRUSH Ruleとは http://www.nminoru.jp/~nminoru/unix/ceph/how-to-write-crushmap.html STEPセクション TYPEセクション 適用先プール  RADOSのプール番号を指定する  typeは基本的にreplicatedを指定  min_sizeでレプリカの最小数を指定  max_sizeでレプリカの最大数を指定  STEPセクションは上から順に処理される  takeで始まり、emitで終わる  bucketと呼ばれる、ノード定義構成の 探索順序を定義する箇所 適用先プール TYPEセクション STEPセクション

Home IT infrastructure hobbyist -BLUECORE.NET オブジェクトとPGとOSDの関係 PlacementGroupとOSD間は動的マッピ ングされている この処理もCRUSHが行っている このときの紐付けルールは、先述した CLUSTER MAPやCRUSH RULEが使用され ている。 クライアントがオブジェクトを格納す ると、CRUSHはPlacementGroupにオ ブジェクトをマップする この時、ファイルのハッシュ値を用い てPGを決定する

Home IT infrastructure hobbyist -BLUECORE.NET OSDに対するロケーションの特定 1. クライアントは、プール名とオブジェクトIDを指定する。 2. CephはオブジェクトIDを取得し、Hashする。 3. CephはPGの数を元にしてHashを計算してPG IDを取得する。 4. Cephはプール名を指定することでプールIDを取得する。 5. CephはプールIDにPG IDを付加する。 これにより、オブジェクトのロケーションが決定する。 同様の呼び出し方をクライアントからしても、一貫性の取れた位置特定が可能となる ( 4 . 58 ) Pool ID (作成時に定義したID) Placement Group ID (CRUSHによるハッシュ計算で 割り出された値) Pool : hogehoge object id : hogefuga クライアントからは こんな風に呼び出す

Home IT infrastructure hobbyist -BLUECORE.NET Peeringとは mon osd.0 良いかお前ら、 PGはこういう配 置にするぞぅ PG1 osd.1 osd.2 osd.3 PG4 PG2 PG3 monが決めたPG配置に従い、PGを受け入れた後に、 Replicaセッションを貼るためのOSD間合意形成プロセス ⇒replication先はmonがトップダウンで決めるのではなく、OSDが相互に決める Cluster map(指令書) osd.0 PG1 osd.1 osd.2 osd.3 PG4 PG2 PG3 PG1 PG2 PG4 PG3 replicas=2 PG1-primaryOSD: osd.0 PG2-primaryOSD: osd.2 PG3-primaryOSD: osd.1 PG4-primaryOSD: osd.3

Home IT infrastructure hobbyist -BLUECORE.NET Peering処理の流れ(OSD間のネゴシエーション) osd.0 osd.1 osd.2 osd.3 mon secondaryになってくれませんか？ いいですよ secondaryになってくれませんか？ いいですよ secondaryになってくれませんか？ いいですよ secondaryになってくれませんか？ いいですよ peeringできました peeringできました peeringできました peeringできました cluster map更新 cluster map更新 cluster map更新 cluster map更新

Home IT infrastructure hobbyist -BLUECORE.NET リバランス処理について ■Rebalance ノードを増設したときの再配置処理 PG配置は均される PGの移動＋Peering

Home IT infrastructure hobbyist -BLUECORE.NET Cephにおける自動階層化機能

Home IT infrastructure hobbyist -BLUECORE.NET Cache Tiering 高速なディスクで作成されたプールをキャッシュとして使用する機能 Cache Tier:高速ディスクのプールを使用し、キャッシュとして動作する Storage Tier:低速ディスクのプールを使用し、実データプールとして動作する HDD Pool SSD Pool SSD-OSD-A SSD-OSD-B SSD-OSD-C HDD-OSD-A HDD-OSD-B HDD-OSD-C Cache Tier Storage Tier キャッシュ書込 キャッシュ読出 ceph osd tier add

Home IT infrastructure hobbyist -BLUECORE.NET Cache Tiering構築の流れ SSD対応 Crushmapの作成 SSDプールの作成 Cache Tierへの組み込み Cache Tierパラメタ設定  現行Crushmapの取得  Crushmapの変換(バイナリ⇒テキスト)  Crushmapの修正(SSD/HDDの識別を可能にする)  Crushmapの変換(テキスト⇒バイナリ)  Crushmapの組み込み  SSDプールの作成  OSD配置状況の確認  Storage TierとCache Tierの紐付け  プール最大使用量の定義  キャッシュモードの設定  キャッシュ生存期間の定義  ダーティキャッシュ比率上限の定義  キャッシュデータEviction制限の定義

Home IT infrastructure hobbyist -BLUECORE.NET # begin crush map tunable choose_local_tries 0 tunable choose_local_fallback_tries 0 tunable choose_total_tries 50 tunable chooseleaf_descend_once 1 tunable chooseleaf_vary_r 1 tunable chooseleaf_stable 1 tunable straw_calc_version 1 tunable allowed_bucket_algs 54 # devices device 0 osd.0 class hdd device 1 osd.1 class hdd device 2 osd.2 class hdd device 3 osd.3 class hdd device 4 osd.4 class hdd device 5 osd.5 class hdd device 6 osd.6 class hdd device 7 osd.7 class hdd device 8 osd.8 class ssd device 9 osd.9 class ssd # types type 0 osd type 1 host type 2 chassis type 3 rack type 4 row type 5 pdu type 6 pod type 7 room type 8 datacenter type 9 region type 10 root Crushmap(devices/types)

Home IT infrastructure hobbyist -BLUECORE.NET # buckets host Ceph-01-ssd { # weight 0.793 alg straw2 hash 0 # rjenkins1 item osd.8 weight 0.500 } host Ceph-01 { id -3 # do not change unnecessarily id -4 class hdd # do not change unnecessarily # weight 0.793 alg straw2 hash 0 # rjenkins1 item osd.0 weight 0.098 item osd.6 weight 0.195 } host Ceph-02 { id -5 # do not change unnecessarily id -6 class hdd # do not change unnecessarily id -16 class ssd # do not change unnecessarily # weight 0.293 alg straw2 hash 0 # rjenkins1 item osd.1 weight 0.098 item osd.4 weight 0.195 } host Ceph-03-ssd { # weight 0.793 alg straw2 hash 0 # rjenkins1 item osd.9 weight 0.500 } host Ceph-03 { id -7 # do not change unnecessarily id -8 class hdd # do not change unnecessarily # weight 0.793 alg straw2 hash 0 # rjenkins1 item osd.2 weight 0.098 item osd.7 weight 0.195 } host Ceph-04 { id -9 # do not change unnecessarily id -10 class hdd # do not change unnecessarily id -17 class ssd # do not change unnecessarily # weight 0.293 alg straw2 hash 0 # rjenkins1 item osd.3 weight 0.098 item osd.5 weight 0.195 } Crushmap(host buckets)

Home IT infrastructure hobbyist -BLUECORE.NET root default { id -1 # do not change unnecessarily id -2 class hdd # do not change unnecessarily id -18 class ssd # do not change unnecessarily # weight 1.328 alg straw2 hash 0 # rjenkins1 item Ceph-01 weight 0.371 item Ceph-02 weight 0.293 item Ceph-03 weight 0.371 item Ceph-04 weight 0.293 } root ssd { id -11 # do not change unnecessarily id -12 class hdd # do not change unnecessarily id -15 class ssd # do not change unnecessarily # weight 1.000 alg straw hash 0 # rjenkins1 item Ceph-01-ssd weight 0.500 item Ceph-03-ssd weight 0.500 } # rules rule replicated_rule { id 0 type replicated min_size 1 max_size 10 step take default step chooseleaf firstn 0 type host step emit } rule ssd { id 2 type replicated min_size 1 max_size 10 step take ssd step chooseleaf firstn 0 type host step emit } # end crush map Crushmap(root buckets/rule)

Home IT infrastructure hobbyist -BLUECORE.NET Crushmap適用後のOSD配置状況 Poolの作成 # ceph osd tree ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF -11 1.00000 root ssd -2 0.50000 host Ceph-01-ssd 8 ssd 0.50000 osd.8 up 1.00000 1.00000 -4 0.50000 host Ceph-03-ssd 9 ssd 0.50000 osd.9 up 1.00000 1.00000 -1 1.32797 root default -3 0.37099 host Ceph-01 0 hdd 0.09799 osd.0 up 1.00000 1.00000 6 hdd 0.19499 osd.6 up 1.00000 1.00000 -5 0.29300 host Ceph-02 1 hdd 0.09799 osd.1 up 1.00000 1.00000 4 hdd 0.19499 osd.4 up 1.00000 1.00000 -7 0.37099 host Ceph-03 2 hdd 0.09799 osd.2 up 1.00000 1.00000 7 hdd 0.19499 osd.7 up 1.00000 1.00000 -9 0.29300 host Ceph-04 3 hdd 0.09799 osd.3 up 1.00000 1.00000 5 hdd 0.19499 osd.5 up 1.00000 1.00000 SSD OSD HDD OSD ceph osd pool create high-tier 100 100 replicated ssd ceph osd pool create low-tier 100 100 replicated replicated_rule ceph osd tier add low-tier high-tier ceph osd tier cache-mode high-tier writeback ceph osd tier set-overlay low-tier high-tier SSD Poolの作成 HDD Poolの作成 high-tierをlow-tierのCache-Tierとして関連付け high-tierをlow-tierのWriteback Cacheとして定義 high-tierをlow-tierのOverlayとして定義 クライアントIO要求に対し、 まずキャッシュへアクセスしに行くようになる。

Home IT infrastructure hobbyist -BLUECORE.NET  ノンチューニングだと、キャッシュ領域が枯渇する。  複数のプールでOSDを共用している場合、他のプール使用を阻害する可能性がある  本来、プールには容量制限が設けられていない(Quotaはあったような気がするが）  デフォルト設定だとこのあたりのパラメータが決まってないので、必ず設定が必要 パラメタチューニングの必要性 HDD Pool SSD Pool どっかのタイミングで、 キャッシュデータはHDDへフラッシュ しなければならない どっかのタイミングで、 キャッシュ情報を更新しなければならない SSD-OSD-A SSD-OSD-B SSD-OSD-C SSD Pool 過度にデータが溜まると、 他のプールを圧迫しかねない ⇒他のプールがStorage-Tierだったら・・・？

Home IT infrastructure hobbyist -BLUECORE.NET パラメタチューニング(ざっと分かる限り) コマンド(「ceph」以降の文字列) 概要 osd pool osd pool set target_max_bytes プールに許容された最大使用量 ※オブジェクト数制限も可能 osd pool set hit_set_count キャッシュデータがヒットしていると判断するデータアクセ ス回数 osd pool set hit_set_period キャッシュデータがヒットしていると判断するデータアクセ ス期間 osd pool set cache_min_flush_age キャッシュFlushingするダーティキャッシュの期間しきい値 osd pool set cache_min_evict_age キャッシュからEvictingするデータの最短対象機関しきい値 osd pool set min_read_recency_for_promote Promoteするに値すると判断される、Hitsetの読み取りヒッ ト回数(?) osd pool set min_write_recency_for_promote Promoteするに値すると判断される、Hitsetの書き込みヒッ ト回数(?) osd pool set cache_target_dirty_ratio 強制Flashするためのダーティキャッシュ割合 osd pool set cache_target_dirty_high_ratio 強制Flashするためのダーティキャッシュ割合 (cache_target_dirty_ratioより強い) osd pool set cache_target_full_ratio プールがフル使用されていると判断するキャッシュデータ使 用率のしきい値

Home IT infrastructure hobbyist -BLUECORE.NET CephとKubernetes(k8s)の連携

Home IT infrastructure hobbyist -BLUECORE.NET k8sで使ってるProvisioner apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rbd-provisioner roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: rbd-provisioner subjects: - kind: ServiceAccount name: rbd-provisioner namespace: kube-system apiVersion: v1 kind: ServiceAccount metadata: name: rbd-provisioner apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: rbd-provisioner rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get"] kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rbd-provisioner rules: - apiGroups: [""] resources: ["persistentvolumes"] verbs: ["get", "list", "watch", "create", "delete"] - apiGroups: [""] resources: ["persistentvolumeclaims"] verbs: ["get", "list", "watch", "update"] - apiGroups: ["storage.k8s.io"] resources: ["storageclasses"] verbs: ["get", "list", "watch"] - apiGroups: [""] resources: ["events"] verbs: ["list", "watch", "create", "update", "patch"] 権限の定義 サービスアカウント定義 認証アクセス権限定義 アカウント定義

Home IT infrastructure hobbyist -BLUECORE.NET k8sで使ってるProvisioner kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rbd-provisioner subjects: - kind: ServiceAccount name: rbd-provisioner namespace: kube-system roleRef: kind: ClusterRole name: rbd-provisioner apiGroup: rbac.authorization.k8s.io apiVersion: extensions/v1beta1 kind: Deployment metadata: name: rbd-provisioner spec: replicas: 1 strategy: type: Recreate template: metadata: labels: app: rbd-provisioner spec: containers: - name: rbd-provisioner image: "quay.io/external_storage/rbd-provisioner:latest" env: - name: PROVISIONER_NAME value: ceph.com/rbd serviceAccount: rbd-provisioner Provisioner本体 権限紐付け

Home IT infrastructure hobbyist -BLUECORE.NET k8sにおけるStorage Classの定義 apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-rbd provisioner: ceph.com/rbd parameters: monitors: 192.168.100.242:6789, 192.168.100.243:6789, 192.168.100.244:6789 adminId: admin adminSecretName: ceph-secret adminSecretNamespace: kube-system pool: kube userId: kube userSecretName: ceph-secret-kube imageFormat: "2" imageFeatures: layering PVプロビジョニング時の認証窓口である monはここに記載した中から選出される ストレージクラス名 認証に必要な情報の定義 プールの指定 imageFormatを2にしないと、RBD Layeringは使用できないので、 明示的にImage Formatを2に指定する。 ファイルシステムも選べるが、ここでは記述せず、Defaultである ext4(fourth extend)を採用 RBD Layering＝Ceph RBDにおけるスナップショット機能