Ceph + OpenStackの実例紹介

日本OpenStackユーザ会 第49回 勉強会

Transcript

1. © 2024 KDDI 0 日本OpenStackユーザ会 日本OpenStackユーザ会 2024/08/02 ネットワーク開発本部 Ceph + OpenStackの実例紹介 日本OpenStackユーザ会 第49回勉強会
2. © 2024 KDDI 1 日本OpenStackユーザ会 辻 広志 齋藤 裕子 後半 前半 ネットワーク開発本部 キャリアクラウド開発部 ネットワーク開発本部
3. © 2024 KDDI 2 日本OpenStackユーザ会 前々回の発表内容 通信キャリアにおける最近のOpenStackの活用事例
4. © 2024 KDDI 3 日本OpenStackユーザ会 OpenStackの全体構成 バックボーン ネットワーク グローバルリージョン 認証機能 ダッシュボード DNSaaS 東日本リージョン2 認証機能 仮想サーバ 仮想ネットワーク 仮想ボリューム その他‥ 東日本リージョン1 認証機能 仮想サーバ 仮想ネットワーク 仮想ボリューム その他‥ 西日本リージョン1 西日本リージョン2  各リージョンごとにOpenStackクラスタをデプロイ  全体を連携して利用できるようにグローバルリージョンを設定し 認証機能やDNSaaSなどといった機能やダッシュボードを提供
5. © 2024 KDDI 4 日本OpenStackユーザ会 KDDIで利用しているOpenStackのコンポーネント 通常リージョン Storage Cinder backend/ Swift 互換Object グローバルリージョン デプロイ用 デプロイ用 LBaaS VNFM DNSaaS 主にOpenStackのメジャーなサービスのみをデプロイ CinderのバックエンドやSwift互換のオブジェクトストレージはCephで提供 2021年ごろからCephの商用運用を開始してます
6. © 2024 KDDI 5 日本OpenStackユーザ会 Cephの強み① （広いユースケース） Nova / Cinder / Glance / Swift互換 / S3互換 / etc… OpenStackの様々なバックエンドを単一のCephだけでサポートできるのが強み オブジェクトストレージ Swift互換/S3互換 Bootディスク ディスクイメージ 外部 ブロックストレージ オブジェクト ストレージ KDDIでは利用していませんが、Manila(File system service)のバックエンドにCephFS/Ceph + NFS Ganeshaも利用可能 RBD RGW
7. © 2024 KDDI 6 日本OpenStackユーザ会 Cephの強み② （柔軟性の高い運用） CephはCRUSHルールと呼ばれる運用上の冗長化ポリシーを定義し、 柔軟なリソースの配置、および再配置が可能となる。 作業のためにデータを逃がしたり容量の調整のために組み替えたりが容易 # orange arrows rule example1a { ruleset 0 type replicated min_size 2 max_size 10 # orange (1) step take rack1 # orange (2) step choose firstn 0 host # orange (3) step choose firstn 1 osd step emit } # blue arrows rule example2 { ruleset 0 type replicated min_size 2 max_size 10 # blue (1) step take room1 # blue (2) step chooseleaf firstn 0 rack step emit } ラック１配下で冗長化した二つ ホストからOSD(Disk)を選択する例 ルーム１の中から冗長化した二つのラック からOSDを選択する例 • さらにOSDごとに重みがつけられており変化させられる（通常はOSDごとのDisk容量が重みになっている） • 障害が発生した場合や作業時には重みが０になるリバランシングが可能となる • 処理は非常に高度に自律化・分散化されている 重み OSD ラック ホスト ルーム ルーム1 ラック1 ホスト1 osd.1 osd.2 ホスト2 osd.3 osd.4 ラック2 ホスト3 osd.5 osd.6 ホスト4 osd.7 osd.8 1 2 3 1 2 1.92 1.92 1.92 1.92 1.92 1.92 1.92 1.92 例示についてはSUSE様のドキュメントを引用：https://documentation.suse.com/ja-jp/ses/7.1/html/ses-all/cha-storage-datamgm.html#datamgm-rules-step-iterate (osd.1, osd.4) (osd.3, osd.7)
8. © 2024 KDDI 7 日本OpenStackユーザ会 RADOS クライアント(=ハイパーバイザ等） Cephの特徴：RADOS Cephの本質はオブジェクトストレージでありRADOSという仕組みを持つ （ただしHTTP(s) で操作するS3のようなオブジェクトストレージではない） RADOS(Reliable Autonomic Distributed Object Storage) RADOS librados • CephのクラスタとしてRADOSのインタフェースを提供 • MONとOSDという二つのファンクションの集合で提供(=分散ストレージ） • 言葉が正しいかはわかりませんが・・・RADOSはあくまでもアルゴリズム/プロトコル MON MON MON OSD OSD OSD
9. © 2024 KDDI 8 日本OpenStackユーザ会 Cephの特徴：CRUSH RADOS クライアント(=ハイパーバイザ等） オブジェクト（＝任意のビット列）をRADOSによりハッシングされてOSDに格納する ブロックデバイスもファイルも最終的にはオブジェクトとして扱われる CRUSH (Controlled Replication Under Scalable Hashing) RADOS librados • 管理者により障害ドメインを意識したCRUSH「ルール」が作られる • CRUSHルールに従いCRUSH「マップ」が管理系ノードであるMONにより自動で生成される • CRUSHマップはデータを格納するOSDや、RADOSのクライアントに共有される • CRUSHマップをもとにデータの読み書きがRADOSクライアントからOSDsに対して行われる MON MON MON OSD OSD OSD Control plane Data plane CRUS rule map map map map データのやり取りに管理系のMONは関与しない 全員が同じCRUSH mapを持つことを前提に インテリジェンスをクライアントに持たせる
10. © 2024 KDDI 9 日本OpenStackユーザ会 Cephの特徴：プール Cephクラスタの内部で「プール(pool)」と呼ばれる単位を構成し、 プールごとに冗長化方式やCRUSHルールを指定し用途を割り当てる プール 名称: az-a-cinder-std 方式: レプリカ(2 copy) 用途: RBD-Cinderバックエンド プール 名称: az-a-cinder-ha 方式: レプリカ(3 copy) 用途: RBD-Cinderバックエンド プール 名称: az-a-nova-boot 方式: レプリカ(2 copy) 用途: RBD-Novaバックエンド プール 名称: objectstorage 方式: レプリカ(3 copy) 用途: RGW/Swift互換用
11. © 2024 KDDI 10 日本OpenStackユーザ会 Cephの特徴：コンポーネント MONとOSDがメインのコンポーネント 利用する機能ごとに追加のコンポーネントを追加する MON (Monitor) • クラスタのヘルス状態、すべてのノードのマップ、 データ分散ルールを保管(CRUSHマップ) • MON障害時に情報の正しさを多数決で決めるため、 奇数個(3個以上)のMONが存在するのが推奨 OSD (Object Storage Device) • 物理ストレージユニットまたは論理ストレージユ ニットの単位(=SSD単位 or パーティション単位) で存在させる • 1台のサーバに複数SSDがある場合はSSDごとにデー モンが存在する • MONと通信してデータのレプリケーションや、 ノードが追加/削除された場合のリバランスもする Swift/S3互換オブジェクトストレージ用 RGW (RADOS Gateway) • HTTP(S)リクエストをRADOSの操作に変 換するためのコンポーネント • オブジェクトストレージをオブジェクトス トレージに変換（なのでGateway） NFS/Manila用 MDS(Metadata Service) • ファイルシステムの階層構造等のメタデー タを管理するためのコンポーネント そのほかにもMGR(Manager)などの 監視コンポーネントなどもあります
12. © 2024 KDDI 11 日本OpenStackユーザ会 Hypervisor qemu Cephの特徴：通信のパターン（1/5） 管理系通信：MONとの通信 • RADOSを扱うすべてのCephのクライアント・デーモンはMONと通信を行う • MONから取得した CRUSH Mapを全体で共有する OSDサーバ OSD OSD SSD SSD map map MONサーバ MONサーバ MONサーバ MON map RGWサーバ RGW map librados librbd map Virtual Machine Guest OS Applications KVM librados OSDサーバ OSD OSD SSD SSD map map virtio
13. © 2024 KDDI 12 日本OpenStackユーザ会 Hypervisor qemu Cephの特徴：通信のパターン（2/5） OSDサーバ OSD OSD SSD SSD map map MONサーバ MONサーバ MONサーバ MON map RGWサーバ RGW map librados librbd map Virtual Machine Guest OS Applications KVM librados OSDサーバ OSD OSD SSD SSD map map 管理系通信：OSD同士の通信とMONとのやり取り • OSD同士は定期的に死活監視を投げ合い、OSDの健全性を相互に確認する • OSDが障害等により疎通がうまくいかないとOSDが落ちたことをMONに伝える • MONは状態が変わったことを認識し、CRUSH Mapを更新する virtio
14. © 2024 KDDI 13 日本OpenStackユーザ会 Hypervisor qemu Cephの特徴：通信のパターン（3/5） OSDサーバ OSD OSD SSD SSD map map MONサーバ MONサーバ MONサーバ MON map RGWサーバ RGW map librados librbd map Virtual Machine Guest OS Applications KVM librados OSDサーバ OSD OSD SSD SSD map map データ系通信：RADOS Block Device(RBD)の書き込み • VMで発行されたWrite IOはlibrbd/libradosを通じ、 CRUSH Mapに基づいてOSDにNW越しに書込む • 書込まれたデータはOSD側でもCURSH Mapをもとに、レプリカ先に書込みが行われ データの冗長性が担保される レプリケーション virtio write()
15. © 2024 KDDI 14 日本OpenStackユーザ会 Hypervisor qemu Cephの特徴：通信のパターン（4/5） OSDサーバ OSD OSD SSD SSD map map MONサーバ MONサーバ MONサーバ MON map RGWサーバ RGW map librados librbd map Virtual Machine Guest OS Applications KVM librados OSDサーバ OSD OSD SSD SSD map map データ系通信：RADOS Block Device(RBD)の読み込み • VMで発行されたRead IOはlibrbd/libradosを通じ、 CRUSH Mapに基づいてOSDにNW越しに読 み込みを行う • 読み込み処理では冗長系は関係ないため、PrimaryとなっているOSDからのみ取得する virtio read()
16. © 2024 KDDI 15 日本OpenStackユーザ会 Hypervisor qemu Cephの特徴：通信のパターン（5/5） OSDサーバ OSD OSD SSD SSD map map MONサーバ MONサーバ MONサーバ MON map RGWサーバ RGW librados librbd map Virtual Machine Guest OS Applications KVM librados OSDサーバ OSD OSD SSD SSD map map データ系通信：Swift/S3互換オブジェクトストレージの読み書き • VMで発行されたHTTPリクエストはRGWにて処理される • RGW上で、CRUSH Mapに基づいてOSDにNW越しに読み書きを行いレスポスを返す virtio HTTP POST map
17. © 2024 KDDI 16 日本OpenStackユーザ会 Cephの特徴：サーバとデーモンの配置例とネットワーク デーモンとサーバーの配置例、どのデーモンを分離する同居するは設計次第 クライアントからアクセスされるネットワーク(Public Network)と クラスタを形成するネットワーク(Cluster Network)を分離することが推奨 Cephクライアント Network Configuration Reference — Ceph Documentation サーバ#1 MON MGR サーバ#2 MON MGR サーバ#3 MON MGR サーバ#4 RGW OSD OSD SSD SSD サーバ#5 RGW OSD OSD SSD SSD Cluster Network Public Network OpenStack Services(Controllers) VM’s OpenStack Compute Servers ≧10Gbps ≧10Gbps 死活監視 データの複製 読み書き
18. © 2024 KDDI 17 日本OpenStackユーザ会 実際の環境での利用例 バックボーン ネットワーク グローバルリージョン 認証機能 ダッシュボード DNSaaS 東日本リージョン2 認証機能 仮想サーバ 仮想ネットワーク 仮想ボリューム その他‥ 東日本リージョン1 認証機能 仮想サーバ 仮想ネットワーク 仮想ボリューム その他‥ 西日本リージョン1 西日本リージョン2 • 原則OpenStackクラスタと対になるかたちでCephクラスタも構築
19. © 2024 KDDI 18 日本OpenStackユーザ会 設計上の工夫：構成の紹介 100GbpsのNICを有効活しつつ、設計をシンプル化するためにBGP/L3で冗長化 一つのCephクラスタ内で複数OSDサーバをゾーンごとに分割し利用 Availability zone Server Server Ceph Ceph Server Server Ceph Ceph Leaf switch Leaf switch Leaf switch Leaf switch Group1 Server Server Ceph Ceph Server Server Ceph Ceph Leaf switch Leaf switch Leaf switch Leaf switch Group2 Server Server Ceph Ceph Server Server Ceph Ceph Leaf switch Leaf switch Leaf switch Leaf switch Group3 Spine switch Spine switch Spine switch プール 名称: az-a1 方式: レプリカ(2 copy) 用途: RBD-Cinderバックエンド プール 名称: az-a2 方式: レプリカ(2 copy) 用途: RBD-Cinderバックエンド プール 名称: az-a3 方式: レプリカ(2 copy) 用途: RBD-Cinderバックエンド
20. © 2024 KDDI 19 日本OpenStackユーザ会 設計上の工夫： 100 Gbps NICとFRRによるBGP 100GbE 100GbE 100GbE 100GbE 100GbE 100GbE 100GbE 100GbE lo [2001:db8:100::1/128] Public Network Cluster Network lo [2001:db8:101::1/128] Cluster Network通信向け通信で 利用するloの経路をフィルタ Public Network向け通信で 利用するloの経路をフィルタ Public Network/Cluster NetworkでNICを 分離するプラクティスはBGP化でも踏襲 ルーティングデーモンであるFRRを導入しL3で冗長化 対向Leaf SwitchとBGPで経路を交換 NICを分割して利用するために経路フィルタ等で入/出のトラフィックを制御 Leaf Leaf OSDサーバ
21. © 2024 KDDI 20 日本OpenStackユーザ会 設計上の工夫： IP anycastによるRGWの冗長化 RGWのもつSwift/S3互換のObject storageのAPIエンドポイントは IP Anycastにより冗長化およびロードバランシングを実施 ロードバランサを入れた場合にはロードバランサがボトルネックとなってしまう RGW RGW RGW DCNW ECMP RGW RGW RGW HAPorxy HAPorxy Act/Sby ボトルネック ↓ D C N W D C N W
22. © 2024 KDDI 21 日本OpenStackユーザ会 設計上の工夫： IP AnycastによるRGWのトラフィック偏り対策 • a → VIP:A向け通信は全てサーバ#1に • b → VIP:A向け通信は全てサーバ#1に • c → VIP:A向け通信は全てサーバ#3に • d → VIP:A向け通信は全てサーバ#6に Spine Spine Spine Leaf Leaf Leaf Leaf Leaf Leaf サーバ#2 サーバ#1 サーバ#4 サーバ#5 サーバ#3 サーバ#7 サーバ#8 サーバ#6 外部NW A A A b c d a Leafスイッチ数削減のために外部NWとサーバを同 一Leafに収容 • DNSラウンドロビンでVIP:B/VIP:Cを確率的に選択 • 外部NWの収容Leafにはオブジェクトストレージサー ビスを置かない Spine Spine Spine Leaf Leaf Leaf Leaf Leaf Leaf サーバ#2 サーバ#1 サーバ#4 サーバ#5 サーバ#3 サーバ#7 サーバ#8 サーバ#6 外部NW B C a B C IP Anycast/ECMP特有の難しさも存在し、トラフィックの生成元に近いサーバが 選択されるためトラフィックの偏りが出る場合がある
23. © 2024 KDDI 22 日本OpenStackユーザ会 設計上の工夫： OSDサーバのゾーン分割 Availability zone Server Server Server Server Leaf switch Leaf switch Leaf switch Leaf switch Group1 Server Server Server Server Leaf switch Leaf switch Leaf switch Leaf switch Group2 Server Server Server Server Leaf switch Leaf switch Leaf switch Leaf switch Group3 Spine switch Spine switch Spine switch Ceph/OSD Ceph/OSD Ceph/OSD Ceph/OSD Ceph/OSD Ceph/OSD Ceph/OSD Ceph/OSD Ceph/OSD Ceph/OSD Ceph/OSD Ceph/OSD フェイラードメインを意識し、OSDをプールごとに分けて定義 各サーバには同一フェイラードメインのバックエンドを割り当てる Cinder/Nova用プール Cinder/Nova用プール Cinder/Nova用プール Swift用プール
24. © 2024 KDDI 23 日本OpenStackユーザ会 設計上の工夫： OSDサーバのゾーン分割（NGの例） フェイラードメインが異なるプール間でOSDサーバを一部でも共有すると 障害時のリバランスなどによるIO劣化の影響を相互に受けることになる Availability zone Server Server Server Server Leaf switch Leaf switch Leaf switch Leaf switch Group1 Server Server Server Server Leaf switch Leaf switch Leaf switch Leaf switch Group2 Server Server Server Server Leaf switch Leaf switch Leaf switch Leaf switch Group3 Spine switch Spine switch Spine switch Ceph/OSD Ceph/OSD Ceph/OSD Ceph/OSD Ceph/OSD Ceph/OSD Ceph/OSD Ceph/OSD Ceph/OSD Ceph/OSD Ceph/OSD Ceph/OSD Cinder/Nova用プール Cinder/Nova用プール Cinder/Nova用プール Swift用プール
25. © 2024 KDDI 24 日本OpenStackユーザ会 運用上の工夫 Cephを商用環境で数年運用していく中で生じた課題などへの対応 リバランス時に負荷が上昇してClient IO性能が劣化するためその対策が主 障害時・故障時の安定性向上動作 スケールアウト時の対応 • バタつきによるIOブロッキングが 複数回起こる問題への対処 • リバランシングに対するパラメータチューニ ング • 故障交換対応時の事前迂回・戻しの オペレーション • 容量拡張方式と自動でのデプロイ • PGオートスケールの無効化 • 増設時や故障交換時のInitial weight 0による 予期しない組み込みの防止
26. © 2024 KDDI 25 日本OpenStackユーザ会 OSD(Daemon) SSD OSD(Daemon) SSD OSD(Daemon) SSD systemd systemd systemd OSDの異常終了検知 リスタート OSD(Daemon) SSD systemd 他のOSD 他のOSD 他のOSD 他のOSD 故障OSDのDownを検知・切り離し 故障OSDのDownを検知・切り離し OSDのUpを検知し再組み込み でも実は死んでる IOの発行を契機にエラーを検知し終了 運用上の工夫：障害時のバタつき防止 OSDはSSDの故障等でプロセスが異常終了する 安定動作のために異常終了時にプロセス再起動をトライする処理を無効化 osd_max_markdown_count 0
27. © 2024 KDDI 26 日本OpenStackユーザ会 運用上の工夫：リバランシング（データ再配置） 「データの冗長度の復旧時間（リバランス時間）」と「client IO劣化」は トレードオフの関係 データの冗長化のプロセスの多重度を上げるパラメータは「osd_maxbackfills」 パラメータ上げると復旧時間は早くなるがclient I/Oは劣化 osd_maxbackfills=5 osd_maxbackfills=1(default) リバランス時間：約3時間半 リバランス時間：約２時間 ※リバランス時間はOSD数やデータ量など様々な要素により変動する。上記は計測環境における参考時間 ① ③ 正常時の 6,7割程度 osd_maxbackfills=2 ② 正常時の 3,4割程度 リバランス時間：約２時間半 通常運用時は②を 採用 測定した数値は client側のキャッ シュを使用しない設 定での値なので、 キャッシュを有効に した場合、より性能 は改善する OSD down時のClient IO 正常時の 1割程度
28. © 2024 KDDI 27 日本OpenStackユーザ会 運用上の工夫：リバランシング（データ再配置） ※リバランス時間はOSD数やデータ量など様々な要素により変動する。上記は計測環境における参考時間 リバランス時間：約５時間 リバランス時間：約１６時間 手動迂回時のClient IO 手動迂回時は、故障時と比べてパラメータによるclient I/Oの劣化が緩やか また、パラメータ変更によるリバランス時間の差が顕著なので、オペレーション時 にパラメータを変更してからリバランス実行する運用としている osd_maxbackfills=1(default) osd_maxbackfills=5 正常時の 8,9割程度 正常時の 5,6割程度 リバランス途中でパ ラメータを変更した り、リバランスを停 止することも可能
29. © 2024 KDDI 28 日本OpenStackユーザ会 運用上の工夫：スケールアウト時の対応 既存ホストにSSDを追加した場合、物理作業後の設定作業不要で OSDを自動デプロイ ＝ ゼロタッチオペレーション service_type: osd placement: hosts: - ceph-osd-001 - ceph-osd-002 - ceph-osd-003 data_devices: all: true SSD ceph-osd-001 SSD SSD SSD ↑増設 /dev/sda /dev/sdb /dev/sdc /dev/sdd OS上で認識 Orchestratorが新しいdeviceを自動検知し、 OSDデーモンを自動デプロイ host ceph-osd-001 ID CLASS WEIGHT NAME STATUS REWEIGHT 0 ssd 13.97 osd.0 up 1.00000 1 ssd 13.97 osd.1 up 1.00000 2 ssd 13.97 osd.2 up 1.00000 3 ssd 0 osd.3 up 1.00000 設定 ↑対象ホスト上のすべての デバイスをOSDとして利用 する定義設定
30. © 2024 KDDI 29 日本OpenStackユーザ会 運用上の工夫：スケールアウト時の対応 増設時のサービス影響をコントールするため、「initial weight 0」を設定 サービス影響を出さずに複数台のOSDの一括増設(デプロイ)作業が可能 サービス影響が発生する組み込み(weight値設定)作業のみを別作業として 影響を考慮しながら実施することで作業を効率化できる host ceph-osd-001 ID CLASS WEIGHT NAME STATUS REWEIGHT 0 ssd 13.97 osd.0 up 1.00000 1 ssd 13.97 osd.1 up 1.00000 host ceph-osd-002 2 ssd 0 osd.2 up 1.00000 3 ssd 0 osd.3 up 1.00000 host ceph-osd-003 4 ssd 0 osd.4 up 1.00000 5 ssd 0 osd.5 up 1.00000 host ceph-osd-001 ID CLASS WEIGHT NAME STATUS REWEIGHT 0 ssd 13.97 osd.0 up 1.00000 1 ssd 13.97 osd.1 up 1.00000 host ceph-osd-002 2 ssd 13.97 osd.2 up 1.00000 3 ssd 13.97 osd.3 up 1.00000 host ceph-osd-003 4 ssd 0 osd.4 up 1.00000 5 ssd 0 osd.5 up 1.00000 増設時 サービス組み込み
31. © 2024 KDDI 30 日本OpenStackユーザ会 運用上の工夫：スケールアウト時の対応 プールごとに想定利用量を算出し、OSDごとのデータ量の偏りが少なるなるよ うプールごとのPG数を静的に設定 OSDの増設・データ量の増加などによりPG数の見直し・修正が必要 「pg autoscale」という機能があるが、想定外のリバランス(=サービス影響) を抑止するため、当環境では無効化している Pool PGs USED ----------------------- Cinder-std 256 20TiB Cinder-ha 256 20TiB backups 125 8TiB object 32 10GiB OSD PGs ------------ osd.1 110 osd.2 115 osd.3 105 ... OSDごとのPG数は 100～200推奨
32. © 2024 KDDI 31 日本OpenStackユーザ会 まとめ
33. © 2024 KDDI 32 日本OpenStackユーザ会  KDDIではCephの運用をかれこれ3-4年ほどやってます  CephとOpenStackは非常に相性がよく、 様々なストレージのバックエンドとして利用できます  性能や可用性を考えて様々な設計観点があり、 オペレータの要求に合わせた柔軟な構成や設定行えます  現在オンデマンド配信が始まっているCODT2024でも Cephの取り組みをご紹介しております 内製化していろいろやってます！ 興味ある人がいればお声がけください！ もう少し詳しい構成を 聞いてみたい どんな仕事か 聞いてみたい OpenStackってどうですか‥？ 内製化ってどうですか？