Ceph: 1 TiB/sへの旅

 (ceph.io)
4 ポイント 投稿者 GN⁺ 2024-01-21 | 1件のコメント | WhatsAppで共有
  • Clysoは、HDDベースのCephクラスタを10PBのNVMeデプロイメントへ移行する前にバーンインテストを実施し、630 OSDの単一クラスタで1.0 TiB/sの読み取りを達成した
  • 最終的なハードウェアは68台のDell PowerEdge R6615と各ノード10基のNVMe構成だったが、最高性能テストは利用可能だった63台、630 OSDで実施された
  • 初期のボトルネックは、BIOSのCPU c-state、カーネルのIOMMUマッピング競合、upstream CephのUbuntu DebパッケージにおけるRocksDBコンパイルフラグの問題を修正することで解消され、compaction時間は約3分の1に短縮、4KBランダム書き込みは2倍改善した
  • 3Xレプリケーション構成での最高値は、4MB読み取り1025GiB/s、4MB書き込み270GiB/s、4KBランダム読み取り25.5M IOPS、4KBランダム書き込み4.9M IOPSで、6+2イレイジャーコーディングでは4MB読み取り547GiB/s、書き込み387GiB/sを記録した
  • 残るリスクは、大規模書き込み時に一部のPGがactive+clean+laggy状態に入り、スループットが急落する現象であり、ノードあたり10基を超えるNVMeでさらに高いスループットを出すには200GbE以上のネットワークが必要となる

10PB NVMe Cephクラスタ設計

  • 顧客は既存のHDDベースCephクラスタを10PBのNVMeデプロイメントへ移行しようとしており、RBD、RGW、CephFSに関する特定の要件はなかった
  • 設計条件には、17ラックへの分散、ラックあたり4Uのスペース、電力、冷却、密度、ベンダー選好が含まれていた
  • 新ノードは既存クラスタへサービス停止なしで統合される必要があり、ネットワークはすでに構築済みの高速Ethernet構成だった
  • 最初の提案は17ラックに34台のデュアルソケット2Uノードを配置する方式だったが、最終的にはClysoが設計したDellベース構成が選ばれた
    • 最終見積もりは元の構成より約13%安価だった
    • OSDあたりのメモリは減ったが、それでもOSDあたり12GiB水準であり、メモリスループットはより高速だった
    • シングルソケット構成、より多い総CPU資源、より大きい総ネットワークスループット、最新のAMDプロセッサとDDR5 RAMを採用した
    • より小さいノードを使うことで、ノード障害がクラスタ復旧に与える影響を半減した

ハードウェアと基本構成

  • システム仕様は以下の通り
    • Nodes: 68 × Dell PowerEdge R6615
    • CPU: 1 × AMD EPYC 9454P 48C/96T
    • Memory: 192GiB DDR5
    • Network: 2 × 100GbE Mellanox ConnectX-6
    • NVMe: 10 × Dell 15.36TB Enterprise NVMe Read Intensive AG
    • OS: Ubuntu 20.04.6 Focal
    • Ceph: Quincy v17.2.7 upstream Deb packages
  • 顧客はラックあたりの追加消費電力を約1000〜1500Wに抑えようとしていた
    • ラックあたり4台のノードの総TDPは最低1120Wで、これにベース電力、CPUピーク、電源ユニットの非効率分が加わると見積もられた
    • 必要であればプロセッサのcTDPを下げることで、ラックあたり約100W削減できると判断した
  • 1UのDellサーバは、upstream Ceph性能ラボ用システムの最新世代に近い構成だった
    • 以前の世代のハードウェアにはなかったが、今回のハードウェアに影響した性能問題がテスト中に見つかった

テスト方法とベンチマーク選定

  • バーンインテストはCBTで一時的なCephクラスタをデプロイし、FIOテストを実行する方式で進められた
  • OSDには8GBのosd_memory_targetが設定された
    • 本番では、より高いosd_memory_targetも可能だと見込まれた
  • 顧客はblockまたはS3ワークロードのテストを必要としていなかったが、RADOS benchの代わりにFIOのlibrbdエンジンを使用した
    • 大規模なRADOS benchでは、クラスタを飽和させるために必要なインスタンス数の判断が難しく、過去には複数の同時プールが必要だった経験があった
    • 既存のupstreamラボ結果と比較するため、同じlibrbdベースのFIOテストを使用した
    • FIOが広く知られ信頼されているツールである点も考慮された
  • kernel RBDテストは省略された
    • librbdエンジンは、古いmount pointのためにシステム再起動が必要になる問題を避けられる
    • このクラスタにはIPMIアクセスがなく、テスト完了期限も厳しかった
    • 既存のテスト基準から、十分な数のクライアントがあれば総合性能は概ね同程度になると予想された
  • テスト対象には3Xレプリケーションと6+2イレイジャーコーディングが含まれた
  • msgr V2は非暗号化モードとsecureモードの両方でテストされた
    • ms_client_mode = secure
    • ms_cluster_mode = secure
    • ms_service_mode = secure
    • ms_mon_client_mode = secure
    • ms_mon_cluster_mode = secure
    • ms_mon_service_mode = secure
  • FIOはまずRBDボリュームを大きな書き込みで埋め、その後4MBと4KBのIOテストをそれぞれ300秒間実行した
    • デバッグ実行では60秒に短縮した
    • scrub、deep scrub、PG autoscaling、PG balancingのようなバックグラウンドプロセスは無効化した

PG数が性能に与えた影響

  • 以前のupstreamラボテストで、PG数が性能に大きく影響し得ることが確認されていた
  • PG数が少ない場合、ランダム分布の偏りが性能に影響する可能性があり、一部は追加のbalancingで緩和できる
  • 高速クラスタでは、OSD内部のPG lock競合も全体性能に重要な役割を果たし得る
    • この問題は、PG数を増やす以外では緩和が容易ではない
  • 60 OSDのみを使うテストでも、3XレプリケーションRBDプールのランダム読み取り性能は16384 PGまで拡大した
    • 書き込みはより早く頭打ちになったが、2048 PGまでは利点があった
  • 高いPG数を本番に盲目的に適用すべきではない
    • PG log長やPG stat updateのようなCephのデフォルト値が影響する可能性がある
    • 従来のOSDあたり100 PGという慣行が引き続き妥当か再検討する必要がある

初期の性能問題と奇妙な挙動

  • 新ハードウェアには米国のThanksgiving翌週に初めてログインでき、元の計画では1〜2週間のバーンイン検証後に既存クラスタへ統合する予定だった
  • 低レベルの性能テストは当初は良好に見えた
    • iperfのネットワークテストはノードあたり200Gb/s近く出ていた
    • 一部ノードのNVMeドライブ単体性能も妥当だった
  • 68台すべてのノードで、OSが内部のDell BOSS m.2ブートドライブではなく、誤って2本のOSDドライブにデプロイされていた
    • 計画していた3ノード30 OSDテストの代わりに、ノードあたり8基のNVMeだけを使ってテストすることになった
  • 最初のCeph結果は、減ったOSD数を考慮しても期待を大きく下回った
    • ランダム読み取りだけはまだ許容範囲に近かったが、それでも十分ではなかった
  • 単一ノード・単一OSDテストまで絞り込むと、異常なパターンが現れた
    • 単一OSDテストで正常に動いていたシステムが、8 OSDテスト後には性能低下した
    • その後、単一OSDテストでも数時間にわたり低性能が続いた後に回復した
    • マルチOSDテストを入れなければ性能は高いままだった
  • 直接ドライブにFIOを実行した場合は同じ問題を再現できなかった
  • 8 OSDテスト中、特定の1つのOSDだけが他のOSDよりはるかに多くCPUを使用していた
  • OSD wallclock profileではio_submitに多くの時間が費やされており、これは通常、ドライブキューが満杯でカーネルがblockしているときに見られるパターンだった

3つの修正

  • BIOS性能モードとc-state

    • 最初の修正は、BIOSがmaximum performanceモードではなく、CPU c-stateが有効になっていた問題だった
    • CephはCPU c-state遷移が生む遅延に非常に敏感である
    • maximum performanceモードにしてc-stateを無効化すると、性能は10〜20%改善したが、目標性能には不十分だった

  • IOMMU競合

    • 2つ目の問題はカーネル側のperf profileで明らかになった
    • 低性能時の実行では、native_queued_spin_lock_slowpathとIOMMU DMA mapping経路に多くの時間が費やされていた
    • alloc_iova
    • iommu_dma_alloc_iova
    • iommu_dma_map_sg
    • nvme_map_data
    • nvme_queue_rq
    • カーネルでIOMMUを無効化すると、8ノードテストの4MB読み取り/書き込み性能が大きく改善した
    • この修正後も4KBランダム書き込みの問題は残っていた

  • RocksDBコンパイルフラグ

    • 3つ目の問題は、4KBランダム書き込みとRocksDB compaction性能が期待より低かったことだった
    • 過去にCephで似た症状は2つの原因と関連していた
    • TCMallocサポートなしでコンパイルされている場合
    • 適切なcmakeフラグとコンパイラ最適化なしでコンパイルされている場合
    • upstream CephのUbuntuパッケージにはTCMallocが含まれていた
    • 17.2.7 Ubuntuパッケージのビルドログで、RocksDBが正しいコンパイルフラグでビルドされていないことが確認された
    • CanonicalとGentooは独自ビルドでこの問題を修正済みだった
    • upstream containerを使用するDebian/Ubuntuのcephadmユーザーは影響を受けないようだった
    • 修正済みのcustom 17.2.7パッケージをビルドすると、compaction時間は約3分の1に短縮し、4KBランダム書き込み性能は2倍になった

2024年最初の週の拡張テスト

  • 1月2日は、関連する別クラスタの大規模障害対応のため性能テストが遅延した
  • 金曜日からCBTとテスト構成を組み直し、今回はノードあたり10本のドライブをすべて使えた
  • FIOクライアント数は、平均してOSDあたりio_depth 128のFIOクライアント約1つになるよう増やした
  • 3ノードテストでは4MBランダム読み取りで63GiB/sを記録した
  • 10ノードテストでは213.5GiB/sを記録した
    • 3ノード比でほぼ線形に拡張し、98.4%の水準だった
  • 当時68ノード中63ノードだけが利用可能だった
    • 32ノード、320 OSDを片側に配置した
    • 31台のクライアントノードで、各ノード10個のFIOプロセスを実行した
  • 320 OSD規模では、読み取り635GiB/sと4KBランダム読み取り1500万IOPS超を達成した
  • 平均遅延とtail latencyは拡張テストでも一貫していた
    • PG数とFIOクライアント数をOSDとともに増やしたことが影響したと見られる
    • テストはIOが非常に多い状態で、さらにIOを追加しても性能は伸びず、遅延だけが増える領域に入っていたと考えられる

630 OSDで1 TiB/s達成

  • 全容量テスト用の追加クライアントノードがなかったため、FIOプロセスをOSDノード上にも同居させた
    • クライアントがローカルOSDと通信する可能性が63分の1あり、わずかなネットワーク上の利点がある
    • 逆に、OSDノードにFIOクライアントを同居させると性能低下が生じる可能性もある
  • 63ノードに630 OSDを立てるCBTデプロイには約15分かかった
  • 最初の試行は約950GiB/sで、1 TiB/sに非常に近かった
  • その後、OSD shardとasync messenger threadを減らし、Reef RocksDB tuningを適用した
    • 読み取り性能はやや低下し、書き込み性能は改善した
    • ランダム書き込み性能はほぼ20%改善した
    • より大きな影響はshard/thread変更によるものと見られる
  • PG数を2倍に増やし、クライアント数を再度増やす実験も行った
    • 4MBランダム読み取りはクライアント数増加とともに少し改善した
    • 小さいランダム読み取りIOPSは悪化した
    • ノードあたりFIO 8個、合計504プロセスで順次書き込み性能が大きく低下した
  • 504個のFIOプロセスが4MB書き込みを行うと、一部のPGがactive+clean+laggy状態に入った
    • スループットはクラスタが持つ性能の一部に過ぎないのに、時間とともにlaggy PGが増えていった
    • ワークロード終了までクラスタはその状態から回復しなかった
    • Cephドキュメントでは、laggy状態ではprimaryからの新しいleaseをreplicaが適時にacknowledgeできず、IOが一時停止するとされている
  • 最終的に、Cephデフォルト設定の8 shards、shardあたり2 threads、3 msgr threadsが4MB読み取りに最適だった
  • 256K PG、630 OSD、504 FIOクライアントプロセスの条件で、ceph -sは1.0 TiB/s readを表示した
    • 630 OSDはすべてup/in状態だった
    • 262145 PGはすべてactive+clean状態だった
    • 表示された読み取り処理は266.15k op/sだった

6+2イレイジャーコーディング結果

  • 顧客の実際の移行先クラスタは6+2イレイジャーコーディング構成だったため、別途テストが必要だった
  • 先行テストで良好だったPG、shard、クライアント値を選び、ECテストを実施した
  • async messenger threadが忙しく動作している様子が見られたため、デフォルトよりさらに増やす実験を行った
  • 4〜5個のasync msgr threadで次の性能を達成した
    • 読み取り: 500GiB/s超
    • 書き込み: ほぼ400GiB/s
  • 6+2 EC読み取りが3Xレプリケーションより遅い理由は、ネットワークオーバーヘッドの違いである
    • レプリケーションでは、primary OSDがローカルデータを読み、クライアントへ送るだけでよく、ネットワークオーバーヘッドは実質1Xである
    • 6+2 ECでは、primaryがobjectを構成するためにreplicaから6チャンク中5チャンクを読み、その後クライアントへ送る必要がある
    • リクエスト全体のネットワークオーバーヘッドは概ね(1 + 5/6)Xである
  • 書き込みでは逆の傾向が現れる
    • 3Xレプリケーションでは、クライアントがprimaryへ送ったobjectをprimaryが2つのsecondaryへ再送するため、総ネットワークオーバーヘッドは3Xになる
    • ECではsecondaryへ7/8チャンクを送ればよいため、大きな書き込みではより高速な性能を示す
  • 小さいIOのIOPSは別の問題である
    • 非常に小さい読み取り/書き込みでは、CephはそのobjectのPGに参加するすべてのOSDへアクセスする
    • 関心データが1つのチャンクにしかなくても、stripeに参加する全OSDからデータを取得する
    • Clysoは2023年夏にerasure codingのpartial stripe readsを実装したPRを復活させ、大きな効果を得た
    • Squidにmergeされるかどうかはまだ明確ではない

msgr暗号化の影響

  • 顧客がmsgrレベル暗号化を使用する場合の影響を見積もるため、msgr v2 encryptionのテストも実施した
  • 3Xレプリケーションと6+2イレイジャーコーディングの両方で、暗号化有効時の結果を以前の結果と比較した
  • 最も大きな影響は大きな読み取りで現れた
    • 約1 TiB/sから約750GiB/sへ低下した
  • 他の項目はより緩やかだが、一貫した性能低下を示した
  • PG scalingテストとkernel RBDテストも望まれていたが、システムを顧客へ返却して再イメージ化と統合作業を進める必要があった

最終的な最高性能まとめ

  • テストで達成した最高値は以下の通り
項目 30 OSDs (3x) 100 OSDs (3x) 320 OSDs (3x) 630 OSDs (3x) 630 OSDs (EC62)
Co-located FIO No No No Yes Yes
4MB Read 63 GiB/s 214 GiB/s 635 GiB/s 1025 GiB/s 547 GiB/s
4MB Write 15 GiB/s 46 GiB/s 133 GiB/s 270 GiB/s 387 GiB/s
4KB Rand Read 1.9M IOPS 5.8M IOPS 16.6M IOPS 25.5M IOPS 3.4M IOPS
4KB Rand Write 248K IOPS 745K IOPS 2.4M IOPS 4.9M IOPS 936K IOPS
  • テスト終了後、すべてのハードウェアは再イメージ化され、新しいOSDは顧客の既存HDDクラスタへデプロイされた
  • Danのupmap-remapped scriptでマイグレーションを制御し、既存データの約**80%**がNVMeベースOSDへ移行した
  • 初期段階では、テストで適用したすべてのチューニングをすぐに使うのではなく、まず大半をデフォルト構成でクラスタ動作を確認する方針とした
  • テストデータは、今後顧客が性能問題に直面した場合にシステムを追加チューニングするために利用できる

残る課題と拡張限界

  • 大規模書き込み負荷で発生したlaggy PG問題は解決が必要である
    • 書き込みワークロードが大きくなったときにCephが崩れる状況は許容できない
  • 今回のテストで、Cephが2×100GbE NICを飽和できることが確認された
  • ノードあたり10基を超えるNVMeドライブを使ってさらにスループットを高めるには、200GbE以上が必要となる
  • IOPSはより複雑である
    • PG数が大きく影響し得る
    • OSD threading modelも重要な役割を果たす
    • 複数のデプロイメントで、ノードあたり約400K〜600Kランダム読み取りIOPSの壁に突き当たった
  • 改善ポイントとして、async msgrとカーネルのインターフェース、shard queueに新しい作業が入ったときのOSD threadの起床方式が挙げられている
  • 高負荷でより良い結果を出すためにOSDコードを修正したこともあったが、その代償として低負荷時のレイテンシが悪化した
  • IOPS向上には、多方面からのアプローチと、一部のOSD threadingコードの書き直しが必要になる可能性がある

関連記事

1件のコメント

 
GN⁺ 2024-01-21
Hacker News のコメント

  • Ceph には興味深い歴史がある
    DreamHost の創業者たちが社内の必要から作ったもので、DreamHost は VPS、マネージド OS／データベース／アプリサーバーのように、IaaS や PaaS という言葉が業界に定着する前から、実質的にそうしたサービスを提供していた
    その後 Ceph はスピンアウトされ、Red Hat が買収した
    https://en.wikipedia.org/wiki/DreamHost

    • 今でも DreamHost の顧客だが、当時「Ceph というものを作ってみようとしている。すごいものになるかもしれない」といった感じのブログ記事かニュースレターを覚えている
      すべての文を売るために磨き上げる マーケティング文句 はなく、ただいじっていたものを共有していた時代だった
      創業者の一人の大学プロジェクトで、ほかの創業者たちが支援しながら加わったと記憶している。Docker も似たような起源だったと理解している
    • もう少し補足すると、DreamHost 創業者の Sage Weil が UC Santa Cruz で大学院課程にいた時に作ったものでもある
      UCSC は優れた ストレージ研究 が多く生まれた場所だ

  • 良い記事だ。CERN でも最近 1TB/s に到達したが、Ceph ではなく EOS（https://cern.ch/eos）で達成した
    https://www.home.cern/news/news/computing/exabyte-disk-stora...
    ただし、われわれの EOS クラスターはノード数がはるかに多く、ほとんどが HDD を使っている。CERN では Ceph も広範に使っている

    • 素晴らしい。Ceph についてはどう見ているのか気になる。長期的には EOS へ移行 する構想なのだろうか？

  • こういう実験が本当に好きだった。Cisco でテックリードとして働き、ベアメタルに Kubernetes を構成し、GlusterFS と Ceph を自分でセットアップして、どちらが良いのかを学び比較できるという贅沢を味わった
    記憶では 2017／2018 年ごろで、良い時代だった。この記事もとても良かった

    • Aerospike の応答時間を引き上げるために、AWS のインスタンスタイプだけでなく、同じタイプ内の 個別インスタンス ごとの速度まで比較するベンチマークを山ほど回す必要があった
      一部の NVMe SSD はほかよりも使用が進んでいて差が出ており、本当にばかげた作業だった
    • Heketi を使っていた人だね。自分も同じ頃に似た経験をして、本当に楽しかった。すべてがあまりにも新しく、そして壊れていた

  • 誰かがノード規模をもっと小さくしてみてくれるとよさそう。ここで説明されているシステムは、ノードあたりディスク10台で約300W/ノードなので、ディスク1台あたり30W程度になる
    オーバーヘッドがかなり大きく、少しでも冗長性を得るには相当なストレージ容量も必要になる
    多少エンジニアリングすれば、全体を10分の1に縮小できそうだ。NVMe用のPCIeレーン4本、2x10GbE（SFP+ソケット2つ）、十分に高速なARMまたはRISC-V CPUを備えた小型のシングルボードコンピューターを作り、起動用のeMMCやSDスロットを入れる、といった形だ
    こうすれば数ノード規模まで下げられ、単一障害で一度にディスク10台が失われるリスクも減る
    こうしたシステムを4Uエンクロージャーに多数収められそうだし、オプションで同じエンクロージャー内に、内部ノードを集約する完全に独立したスイッチ2台も入れられる

    • 以前、ODROID-HC2を複数台使って5ノードのCephクラスターを動かしたことがある
      armhfプロセッサだったのでインストールは本当に苦痛だったが、いったん動き始めるとうまく動作した。単一の1Gb NICのせいで遅かっただけだ
      当時は単なる学習用だった
      [0] https://www.hardkernel.com/shop/odroid-hc2-home-cloud-two/
    • NvidiaのSODIMMコンピュートモジュールインターフェースで、このコンセプトはすでに検証できる
      近いうちに7WのARM Turing RK1を2つ受け取る予定で、それぞれPCIe 3x4で4GB/sを出し、Turing Pi 2クラスター・ボードはITXフォームファクターに4つ搭載できる
      総コスト820ドルで、ワットあたり3Gbps以上を期待している
      今のところボトルネックはPCIeレーンだ。90ドルの2TB SSDでもPCIe 4x4で7GB/sと表記されているので、まだシングルボードコンピューターが最適解だとは見ていない
      Ampere Altraラインは40WでPCIe 4x128をサポートするようなので、100Gネットワークを付けた1Uブレードは面白いかもしれない
      ただしホームラボでもARM関連のバグや欠けている最適化を多く見てきたので、こうした解決策がまだデータセンター向けに準備できているとは言いにくいかもしれない
    • 低価格の100Gbpsスイッチと100Gbpsインターフェースが増えるにつれ、10Gbpsはだんだん時代遅れになっている
      今10GbpsインターフェースでCeph構成を正当化するには、本当に小さく、非常に安価である必要がある
      そのくらい小規模なら、各サーバーにローカルNVMeストレージを置くほうがよい可能性が高い
    • ざっくり変な計算をしてみると、このクラスターはおよそワットあたり0.8Gbps程度を処理している
      1TB/s × 8ビット/バイト × 1024GB/TB ÷ 34ノード ÷ 300W、という大まかな計算だ
      新しいMac miniのような非常に効率のよいARMシステムは、対話的な利用で約10Wを使い、10Gbpsネットワークを処理できるので、データ基準ではワットあたり1Gbpsほどになる
      つまり元記事のクラスターは、大まかには非常に効率のよいARMシステムと同じくらいのビット/秒/ワット水準だ
      小さなノードを使っても実際の効率が上がるとは思えず、むしろコストが高くなる可能性がある。最近の強力なサーバーのワットあたり性能はかなりよい
      いずれにせよ、これは汎用ハードウェアで動くオープンソースソフトウェアなので、数百ドルで自分でも試せる
    • この構造で非効率の主な原因はNVMeコントローラーだと思う
      OSとNVMeデバイスが離れていると、コントローラーがリクエストの意図を推測して、バッチ処理やウェアレベリングを最善の形で行わなければならないため、自然な非効率が生じる
      新しいFDP（flexible data placement）機能は、OSにより多くの制御権を与えることでこれを解決しようとする試みだ
      最もよいのは、これをホストOS側へ引き上げ、フラッシュをできるだけ「PCIeデバイスとして接続された巨大で愚直なトランジスタ配列」のように露出させることだ
      抽象化レイヤーを取り除けば、望むシステム並列性を得るために、統合100Gbps NICとそれに見合うフラッシュを備えたAtomのようなハードウェア単位で構成できそうだ

  • 世界中に保存されたデジタルデータ総量が初めて1TiBに達した時点が、歴史上どこかにあったはずだ
    その日はほぼ間違いなく過去60年以内だった可能性が高い
    ところが今では、かなり任意のある組織のサーバーで、その量のデータを毎秒移動している。国家規模や超国家的な研究プロジェクトでもないのにだ

    • 以前計算してみたところ、自分のデスクトップPCは1978年ごろの地球上のすべてのコンピューターを合計したものより強力だったはず、という結果になったのを思い出す
    • 少なくとも20年ほど前よりは昔の話だ。2003年以前にペタバイトを管理していた話をしていた古参のシステム管理者を覚えている

  • 興味深い記事だ。私たちはDockerレイヤーキャッシュを維持するためにCephストレージクラスターを運用している
    EBSからCephへ移行した後、スループットの差は凄まじかった。書き込みスループットは146MB/sと3,000 IOPSから、900MB/sと30,000 IOPSへ上がった
    いちばんよい点は、ほとんどそのまま動くことだ。たまにファイルシステムのtrimのようなものを除けば、ほとんど面倒を見る必要がない
    キャッシュシステムにとっては大きな改善だった
    [0] https://depot.dev/blog/cache-v2-faster-builds

    • ほぼ10年前に、非常によく似たことをした。同じ性能基準では、EBSのコストはノード上のディスクによるCephクラスターより10倍以上高かった
      結局、自前ラックへ移行してコストをまたほぼ10分の1に下げ、社内の運用能力を持つことで自由になった
    • EBSをベアメタルでホストしていたのか気になる。Cephは自前/レンタルのベアメタルなのか、EC2仮想マシンなのか、どのようにホストしているのだろう？
      ブログだけではすぐには明確でなかった

  • クラスター内部の動的ストレージで経験した最悪の問題は、純粋なI/O問題ではなかった
    Kubernetesのストレージコントローラーソフトウェアが、実環境の問題、たとえばPodが死んでPVCが非常に長いタイムアウトが終わるまでアタッチされず、PodはPVCのロックが解除されるまでContainerCreating状態にとどまる、といった状況をうまく処理できないことだった
    こうしたことは、rook/cephとLonghornを使う複数のクラスターで発生した

  • ホームラボで Ceph を動かしてみた人がいるのか気になる。最後に調べたときはハードウェア要件がかなり大きかった

    • 今でも要件は大きい。プロダクションとホームラボの両方でデプロイした立場から言うと、単に経験を積む、またはデモをセットアップする目的でないなら、あえてやらないほうがよい
      うまく動いているときは素晴らしいが、問題が起きるととんでもない悩みの種になる
      分散ストレージそのものに興味があるなら、ホームラボ構成にはもっとよい選択肢がある
      seaweedfs は小規模でも巨大規模でも数年間非常に安定しており、実際にプロダクションの Ceph 構成をこれに移行した
      Kubernetes の世界では Longhorn も安定していた
      GlusterFS も、何を受け入れるのか分かったうえで使うなら今でも悪くない
    • 使ってみたが、Web UI、オブジェクトストレージ、ファイルストレージはとても良かった
      ただし、まともな性能を出すのが非常に難しく、小さなクラスタでは メタデータデーモン がかなり簡単に止まってしまうことがあった
      結局、面白さが薄れると単一マシンに ZFS を載せる方向に戻った
    • 仕事とホームラボに近い環境の両方で Ceph を使った経験がある
      まず Ceph は 分散ストレージシステム だという点を念頭に置く必要があるため、複数ノードを置くのが基本前提になる
      学習用なら単一マシン上ですべて仮想化することもできるが、別々の物理マシンがあるとはるかによい
      Ceph は ZFS と同様に、ディスクへの物理的なアクセスを好む
      また、まともなネットワーク接続が必要だ。人々が Ceph の高いハードウェア要件を考えるとき、主に思い浮かべるのはこの部分だと思う
      理想的には最低でも 10GbE が望ましく、より高い性能を求めるならそれ以上が必要になる。特にバックフィルのような作業ではネットワークトラフィックが多くなり得る
      ホームラボ機材を安く手に入れられるなら 25Gbps もよく、50Gbps は技術的には行き止まりに近く、100Gbps はうまく動作する
      それでもホームラボなら、10GbE を備えた安価なミニ PC や NUC でも十分動かせ、納得できる性能と学習効果を得られる
      Ceph をベアメタルに直接インストールすることもできるし、ホームラボ Kubernetes の道に進みたいなら Rook(https://rook.io/) を使える
      参考になれば。追加の質問があれば知らせてほしい
    • Ceph 側に Raspberry Pi 4 数台へ Ceph をインストールしたブログ記事がある
      その程度なら、大きなハードウェアとはまったく言い難い
      [1] https://ceph.io/en/news/blog/2022/install-ceph-in-a-raspberr...
    • 自分のラボで Ceph を動かしている。CPU はかなり使うが、高速なネットワークを用意するつもりがあるならうまく動く
      最低 10Gb、できれば 40Gb 以上がよく、回転式ディスクを使うなら数台のノードにそれぞれ 6 台以上のディスクがあるほうがよい
      すべて SSD なら、ノードあたりのディスク数はずっと少なくても済む可能性が高い

  • 1TiB/s が実際のハードウェアの理論上の限界とどう比較されるのか見たくて計算してみた
    このクラスターは 68 台のノードで構成されており、各ノードは Dell PowerEdge R6615（https://www.delltechnologies.com/asset/en-us/products/server...）
    使用構成は U.2 ドライブベイ 10 基の R6615 で、U.2 リンクは PCIe 第 4 世代レーン 4 本でデータを転送する。PCIe レーン 1 本は 16Gbit/s で、128b-132b エンコーディングのおかげでオーバーヘッドは約 3% と無視できる程度
    したがって U.2 リンク 1 本の最大リンク帯域幅は 16×4=64Gbit/s、つまり 8Gbyte/s。ただし、使っている U.2 NVMe ドライブである Dell 15.36TB Enterprise NVMe Read Intensive AG は読み取りスループットが 7Gbyte/s のようなので（https://www.serversupply.com/SSD%20W-TRAY/NVMe/15.36TB/DELL/...）、U.2 リンクの 8Gbyte/s がボトルネックではない
    ノードあたり U.2 ドライブが 10 基あるため、各ノードはローカル読み取り I/O を最大 10×7=70Gbyte/s まで出せる
    しかし各ノードのネットワーク帯域幅は 200Gbit/s（2×100GbE Mellanox ConnectX-6）、つまり 25Gbyte/s にすぎない。これはリモート読み取りではドライブの 70Gbyte/s の能力を使い切れず、ネットワークがボトルネックだという意味
    追加のネットワークボトルネックがないと仮定すると、68 台のノードは 68×25=1700Gbyte/s のネットワーク読み取りを提供できる。著者は実際に 1TiB/s、正確には 1025GiB/s=1101Gbyte/s をベンチマークしているので、理論上の最大 1700Gbyte/s の 65% 程度
    かなり良いが、すべてのノードが 200Gbit/s のネットワークリンクを同時に完全に飽和させられるなら、理論上はもう少し伸びる可能性がある
    記事全体を読みながら、Ceph の複雑さが CPU にかなり大きな負担をかけているという印象を受けた。モジュールを -O2 でコンパイルしないこと（著者がリンクしている “Fix Three”: https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1894453）だけでも、純粋な I/O ワークロードで「一部のワークロードが最大 5 倍遅くなり得る」（https://bugs.gentoo.org/733316）というのはかなり意外
    OSD スレッドが IOMMU のスピンロックを取るために CPU を過剰に浪費しているのも妙だ。OSD スレッディングモデルが最適ではないという結論には同意する
    比較的単純な合成 100% 読み取りベンチマークでスレッド競合が露呈するべきではない。Ceph のソフトウェアアーキテクチャのその部分がうまく設計されていたなら、という話だ。修正可能な問題なので、Ceph 開発者が優先度を上げてくれることを願う

    • Ceph で IOMMU 問題を見たことがなかった点を付け加えたい
      upstream Ceph ラボには、Dell の同じ 1U シャーシの前世代と AMD Rome プロセッサを使った機材があり、同規模の約 30 OSD で同様の性能を出しながらもこの問題は起きていない
      顧客は自社データセンターで過去にもこの問題を見たことがあると言っており、AMD と一緒に原因を特定できることを期待している
      昨夏、OSD の既存スレッディングモデルを暫定的に補強する作業を少し行った。async msgr とワーカースレッド間のハンドオフの二重バッファリング、適応的なスレッド起床といったもの
      負荷がかかった状態では性能と効率を大きく向上できたが、低負荷時にレイテンシが増える代償があった。Ceph は基本的に、特定のシャードに新しい I/O が入るとスレッドを起こすことに非常に積極的
      もう一人の主要開発者と議論し、二人ともスレッディングコードの全面改修のほうが妥当だという結論に達した
    • このベンチマークはランダム I/O。ディスクの 4K ランダム読み取り IOPS は「わずか」100 万を少し超える程度で、これは約 5GiB/s に換算される
      OSD が 320 個なら約 1.6TiB/s 程度
      少なくとも私が見つけた数値はそうだった。この種のエンタープライズ NVMe ディスクのレビューが多いわけでもない
      それでも NIC とはよく合う数値に見える。この規模では、ほとんどのワークロードがストレージ層ではランダム I/O のように見える可能性が高い
    • PCIe TLP オーバーヘッドとNVMe コマンドが 7GB/s と 8GB/s の差を説明していると思う

  • 驚くのは、なぜ冷却がより難しい1U ノードと SSD 10 基／2×100Gb NIC という構成を選んだのかという点
    2U ノードに SSD 24 基と 2×200Gb または 400Gb NIC を使っていれば、ネットワークボトルネックをなくし、より大きく低速のファンとより少ない CPU パッケージのおかげで電力も減らせたはず。ソケットあたりのコア数も増やせたかもしれない
    ノード数が減ると障害の影響範囲は大きくなるが、34 ノード程度ならそこまで大きな問題ではなさそう
    ノードが少なければ、スイッチ 4 台程度でよりフラットなネットワークも構成できたように思う

    • 言っているように障害の影響範囲が主な要因で、一般的にはパッチ適用やハードウェア交換の負担も軽くなる
      ラックとスイッチはすでに存在し、ほかの用途にも多く活用されているため、Ceph のために追加される物理スペースはごくわずか :)