March 29, 2020

Japan Rook Meetup #2

はじめに

今回はリモートでの開催だったJapan Rook Meetup #2に関するブログ枠です。基本的に、意見ほぼなしのまとめです。GlusterFSとかはなんとなく触ったことがあるのですが、RookとかCephとかはほぼ触ったことがなかったので、新鮮に勉強させていただきました。何かここが違うなど問題があれば、twitter等でご指摘いただければと思います。

アジェンダ

agenda_rook_meetup_2

ハッシュタグ

#k8sjp

Youtube

内容

Rook 基礎・バージョンアップ @rev4t


そもそもどういう時に利用する物なのか

  • Kubernetesで外部ストレージを利用したい時

解決できること

  • k8s上でStorage Operationを実現
    • storageは運用が大変だが、その自動化ができる。

Rookとは

  • OSS(Apache 2.0)
  • CNCF
  • Operator + Custom Resouceでk8s拡張可能
  • 沢山のStorageシステムに対応したフレームワーク
    • Ceph(Stable)
    • EdgeFS(Stable)
    • CockroachDB
    • Cassandra
    • NFS
    • YugabyteDB
    • minio

構成要素

  • Rook Operator
    • 実際にストレージのデプロイ・管理をしてくれるもの
  • Rook Discover
    • ストレージノードの変更等を検知して、Operatorに伝える etc…

Version Up

Rook(major version)
  1. 前提として、Cephが正常に起動していることを確認
# cephのステータス確認
ceph status
  1. RookのControl planeが正常に稼働していることを確認
  2. CRDとRBACの更新
# e.g.
# https://github.com/rook/rook/blob/v1.2.0/cluster/examples/kubernetes/ceph/upgrade-from-v1.1-apply.yaml

kubectl apply -f upgrade-from-v1.1-apply.yaml
  1. fuse or rdb-ndbを使っている場合、Cephfs plugin。rdb pluginの update strategyを onDeleteに変更
  2. Rook operatorのupdate
# e.g. v1.2.5へ
kubectl -n $ROOK_SYSTEM_NAMESPACE set image deploy/rook-ceph-oeprator rook-ceph-operator=rook/ceph:v1.2.5
  1. 更新されるまで、しばらく待つ
  2. fuse or rdb-ndbを使っている場合、CSI driverのpodをdeleteすることで更新させる
  3. 最後に、CRDを更新
# e.g.
# https://github.com/rook/rook/blob/v1.2.0/cluster/examples/kubernetes/ceph/upgrade-from-v1.1-crds.yaml

kubectl apply -f upgrade-from-v1.1-crds.yaml
Rook(minor version)
  1. imageのversionを更新するだけ。
# e.g. v1.2.5へ
kubectl -n $ROOK_SYSTEM_NAMESPACE set image deploy/rook-ceph-oeprator rook-ceph-operator=rook/ceph:v1.2.5

(注)Cephのdelete/createが伴う場合があるそう。

rook-minor-upgrade

Ceph(v14.2.4 -> v14.2.7)
  1. imageのversionを更新する。(imageを更新すれば、あとはRook Operatorがやってくれる。)
  2. 完了するまで待つ。
# cephのステータス確認して、HEALTH_OKかどうか
ceph status

cluster: id: 3casefd74-edfg-2352-b54j-51jk12tj10
health: HEALTH_OK
External Cluster

既存のCeph Clusterに対して、Rookを用いたk8sとの連携ができる。

メリット
  • CSI Driverの運用管理のみをk8sで実施する形になり、k8s側の運用コストを下げつつ、責任分界点を分けられる
  • Rook Version Upの際に、Ceph Clusterに与えるサービス影響を完全に排除できる
  • k8s networkingによる性能低下の影響をうけなくなる。
デメリット
  • Rookの他に、Cephのデプロイツールの導入をする必要が出てくる
利用例

Summary

  • 長期的な運用で、Storage Backendだけでなく、Rook Operaotr自体の運用もしなくてはならない。
  • Cephのversionがすごく楽になる。
  • k8s側の運用をシンプルにしたい場合は、ceph-ansible + Rook external clusterが良さそう。

質疑応答

Q. Ceph OSDのupdateで、nodeを変更しない以外のパターン以外で、新規のnodeにmigrationをかけることは可能か?
A. 検証していないが、多分できると思っている。

Q. Control Planのupgradeする時に、実際にデータアクセスに影響があるということでしょうか?
A. Ceph OSDのpodを再起動されることになるので、クライアントからのリクエストのlatencyが高くなるだろうと思っている。影響の少ない時間帯で実施するなどの対応が必要だろうと思っている。

Rook/Ceph upstream最新状況 @satoru_takeuchi


目次

  1. 前提知識: OSD作成方法
  2. Rook最新安定版の新機能
  3. Rook次期安定版の開発状況
  4. Rookを取り巻く状況

1. 前提知識: OSD作成方法


OSDの作成方法には大きく2つの方法があるとのこと

1.1. 従来の方法
  • OSDの設定にノード上のデバイスを直接指定する
    • これだと、Rook/Ceph cluster管理者にハードウェア構成の知識が必要
    • さらに、デバイス名直接指定しているので、自前でclusterを構築する必要がある
1.2. OSD on PVC v1.1~
  • OSDの設定にPVC templateを指定する
  • それを受けて、CSI driverがPVを作成する
    • Cluster管理者はOSD podがどこにあるかを気にしなくて良い
    • さらに、デバイスの管理もしなくて良くなる。

2. Rook最新安定版の新機能


2.1. OSD on PVCでLVサポート
  • OSD on PVCでロジカルボリューム(LV)対応した(サイボウズ作)
目的・背景
  • ローカルのNVMe SSD上にOSDを作成し、OSDを束ねて、Ceph Clusterを構築し、ブロックデバイス(RDB?)を提供したい
  • 管理コスト削減のため、PVをdynamic provisioningしたい
    • pvが欲しくなったら、dynamicなstorageが欲しい。
既存の課題
  • 以下の条件を満たすCSIドライバがない
    • ローカルボリューム
    • dynamic provisioning
    • 実用レベルのものがない
  • つまり、デバイス追加は手作業でPV作成する必要がある。
TopoLVM
  • PVCの変更を検知して、PVをdynamiv provisioningしてくれるやつ?
2.2. 従来方式でudev persistent nameをサポート
  • v1.1以前では、/dev直下は気付いたら変わりうる。
    • e.g. sda -> sdb
  • v1.2以降では、新機能devicePathFilter(サイボウズ作)
    • こうすると、/dev直下のdevice nameは変わりうるのだが、by-path名は変更されない
    • そのため、データ破壊を防げる
2.3. その他変更
  • cech-crash collector
    • daemonのクラッシュ情報をCephクラスタに保存できるので、トラブルシューティングに効果的
    • デフォルトで有効
  • FileStore OSDがobsolete
    • 既存のFileStore OSDはサポートし続ける

3. Rook次期安定版の開発状況


3.1. Failure domainをまたいだOSDの均等分散配置
  • k8sのTopologySpreadConstraints機能のサポート
    • OSD on PVCに必須
TopologySpreadConstraintsの目的
  • ラック障害耐性
  • ノード障害耐性
これまでの課題

OSD podの偏りが生まれてしまい、ラックの障害耐性がない場合が有り得る。次期安定版から、対応予定で、これでようやくOSD on PVCが使えるものとなると思っている。

3.2. OSD on LV-backed PVCのテスト追加
  • RookはPRマージ時、テスト全パスが必須。
    • (勝手な本ブログの著者の意見なのですが、、)これは、普通なんじゃないかと思ったのだが、OSSってそうでもないプロジェクトもあるんですかね?
  • しかし、3つの壁が。。。
壁1: masterでOSD on LV-backed PVCが動かない
  • このPRでリグレッションが発生
  • Issue発行
  • CI重要!!!!
    • 本来は、リグレッションさせた奴が、直せ!っていうのが筋だが、まぁ自分たちでやるかって感じになってるとのこと。笑
    • まぁ、CIとかテストをちゃんと先に書いておかないとってことでもあるんですかね。
壁2: テストがテスト環境を破壊
壁3: ローカル環境でテストがパスしない
  • 調査中
3.3. FileStoreの新規作成が不可能に
  • obsoluteではなく、不可能へ。
3.4. ストレージプロバイダ
  • 新しいストレージプロバイダなし
  • minioのコードが削除
    • メンテされていないから。
3.5. その他の課題
  • コア部分と前ストレージプロバイダが同じリポジトリ管理しているので、開発がしにくい
    • kubernetesとstorage pluginを別リポジトリを分けた話と同じ感じ。
3.6. 今後の貢献予定
  • テストの充実化
  • 暗号化デバイス上のOSD
  • バグ解決

4. Rookを取り巻く状況


4.1. プロジェクトの成熟度
4.2. Rook/Cephを使う製品

5. 参考リンク

質疑応答

Q. TopoLVMに関して、LVMのレイヤーをdeclaretiveなやり方で、VG?を作ってくれるものという認識であっていますでしょうか?
A. はい。その通りです。Storage ClassでTopoLVMのものを指定していただければ、LVを勝手に切ってくれて、それをブロックデバイス、ないし、ファイルシステムとして利用できるものです。

Q. FileStoreがobsoluteになって、BlueStoreへの移行がこれから出てくると思うのだが、マイグレーションパスの開発は進んでいるのでしょうか?
A. 現在、ドキュメント整備中です。基本的には、そのドキュメントがみてやっていただければ良いようになっていく予定です。

Rook-CephでExternal Clusterを利用する @FUTA_0203


本日お話しすること

  1. Rook-Ceph External Clusterの概要
  2. Rook-Ceph External Clusterの利用方法
  3. Rook-Ceph External Cluster利用時の注意点
1. Rook-Ceph External Clusterの概要

  • Rook-Cephを構築したクラスター外に存在する、Cephクラスターのストレージリソースを利用すること
    • local: k8s(Rook) cluster
    • external: Ceph cluster
本機能の背景
  • Rook ver 1.1から利用可能
  • 基本的には、k8s内のstorageを利用する想定だった
  • しかし、そうではない、ユースケースもあったため。
    • 既存Ceph Clusterが存在する
    • 1つのCephクラスターのリソースを複数k8sで利用したい
    • 単純にstorageを分離したい
Rook-Cephクラスター構築(通常)
# e.g. v1.2
git clone --single-branch --branch release-1.2 https://github.com/rook/rook.git
cd cluster/examples/kubernetes/ceph

1. kubectl create -f common.yaml
2. kubectl create -f operator.yaml
3. kubectl create -f cluster-test.yaml

https://rook.io/docs/rook/v1.2/ceph-quickstart.html

Rook-Cephクラスター構築(external cluster)
# e.g. v1.2
git clone --single-branch --branch release-1.2 https://github.com/rook/rook.git
cd cluster/examples/kubernetes/ceph

1. kubectl create -f common.yaml
2. kubectl create -f operator.yaml
3. kubectl create -f common-external.yaml
4. ConfigMap/Secretリソースに外部のCeph clusterの情報としていれる
  - namespace
  - FSID
  - client admin
  - monitor endpoint
5. kubectl create -f cluster-external.yaml

クラスター構築後は

  • local: OSD / MON / MGRは存在しない
  • External: Stateが、Createdではなく、Connectedの状態になる
2. Rook-Ceph External Clusterの利用方法

  • ストレージリソースを用意する際、local cluster側の操作のみで完結できるのはよき。
3. Rook-Ceph External Cluster利用時の注意点

  • 1番気をつけた方がいいのは、Cephバージョンかな?
  • configmapの修正が必要なのは、嫌だね。
    • いずれに、新しく最新versionを構築する場合は関係なさそう。
参考リンク

Rook-Cephでいろいろベンチマークとってみる @japan_rook


Rook CephでIO計測をする

モチベーション
  • IO測るの楽しい!笑
  • ストレージ直とRook-Cephを挟むとどれくらい変わるか
  • 構成変更によるIOの変化
環境
  • workerは、Rook-CephとIOをかけるが同居するため、割と強めにしている。
  • 一応、現時点で最新versionの組み合わせ。
遊び方
  • FIO 3.13
  • fioのpodから100GBをマウント
  • 時間の都合で、4K random read, 4K random writeのみ
何を測るか
  1. 素のEBS(gp2)vs Rook-Ceph 3x replica RBD
  2. CephクラスタのOSD数
  3. レプリカ数(一般的に、3xのreplicasだが。)
1. 素のEBS(gp2)vs Rook-Ceph 3x replica RBD
  • 負荷が低い時のwriteは結構違う。EBSの方が速い
  • 個人的には、それぞれOSDを3つつけていて、並列にreadができるので、1個のEBSからreadするのと、3個のEBSから読み込むよりも有利なので、Rook-Cephの方が役に立つ(read強い。)
2. CephクラスタのOSD数
3. レプリカ数
  • clush ruleにしたがって、平均になるように、replicaされている
  • なので、利用されるEBSの数は変わらない。

まとめ

質疑応答

Q. MIN_SIZE(Ceph poolの最小サイズ?)は同じにしているのかな?
A. 同じ一にしています。2xでも死んでも計測し続けられるようにしています。

Q. best practiceで、1 SSD 1 device あたり 〇〇OSDに良いみたいな指針をみた気がするのですが。そういう指針に沿うと良いとか有りますか?
A. 有効に使う 1 SSD に対して、1 OSDにしても、あまりIOがこなければもったいないので、2とか4OSDにした方が良いという話もあります。感覚としては、一旦、1 SSDに対して、1~2 OSDが良いかなと。NVMeみたいに、並列にQueueがバシバシ入るものなら、4,6OSDでも良いかなと。もう、その辺はどの程度の負荷になるか。容量にするか。によって、変えてもらえればと思います。

さいごに

オンラインイベント初だったが、発表の音声ログなど残っていれば、そんなに問題ないなと思ったりしました。

(C) Jun Kitamura 2020

Powered by Hugo & Kiss.