Ceph: 1TiB/sへの旅

Ceph: 1TiB/sへの旅

• Cephクラスターの性能改善の歩みを描いた記事で、長いデバッグと性能最適化の過程を経て、1TiB/sのデータ処理速度を達成した物語。
• Clysoという企業が、NVMeベースの10ペタバイトCephクラスターの構築を支援する過程で発生した、さまざまな技術的問題とその解決策を共有。
• 顧客企業のネットワークは非常に高速で、イーサネット設定としては最速クラスのひとつ。

謝辞

• Clysoの顧客企業に感謝を表し、その協力のおかげでCephコミュニティと経験を共有できたことに言及。
• IBM/Red HatとSamsungが、比較テストに使用したハードウェアを提供してくれたことへの感謝も表明。
• Cephの貢献者たちにも、Cephを優れたソフトウェアにするための努力に感謝を伝える。

クラスター構成

• 顧客企業は17ラックにまたがる34台のデュアルソケット2Uノードを提案したが、Clysoはより小型のノードを使う複数の構成を提案。
• 最終的にDellアーキテクチャを選択し、コストを削減しつつ、より高速なメモリ帯域、より多いCPUリソース、より高いネットワーク帯域を提供。
• ノード障害時にクラスター復旧へ与える影響を半減。

テスト構成

• CBTを使って一時的なCephクラスターを展開し、FIOテストを実行。
• ライブラリベースのFIOテストを使ってクラスターを小さな単位に分割し、以前の結果と比較。
• 3Xレプリケーションと6+2消失訂正をテストし、メッセージバージョン2を暗号化モードとセキュアモードで検証。

PG数に関する注意

• PG数が性能に与える影響を実験的にテスト。
• PG数が多いほど性能にプラスの影響を与える可能性があるが、実運用環境では他の設定とあわせて検討する必要がある。

出だしが難しかった点

• ハードウェアに初めてログインした後、想定より低い性能のために問題解決に苦労。
• 初期の性能テストは良好だったが、複数のOSDを使ったテストで性能低下が発生。

奇妙な挙動

• さまざまなOSDテストの組み合わせを実行する中で、性能に奇妙なパターンがあることを発見。
• マルチOSDテスト後にシステム性能が低下し、数時間後に再び回復する現象を観察。

3つの解決策

• CPUのc-state切り替えによる遅延問題を解消し、性能をわずかに改善。
• IOMMUを無効化して性能を大幅に改善。
• RocksDBのコンパイルフラグ問題を解決し、4Kランダム書き込み性能を2倍に向上。

2024年最初の週

• 新年初日に別のクラスターで大規模障害が発生し、性能テストに集中できなかった。
• 金曜日に性能テストを再開し、高負荷下でもクラスターが正常に動作することを確認。

運命の微笑み

• 性能テスト結果が改善し、クラスターが線形にスケールすることを確認。
• 63ノードで構成されたクラスターで、635GiB/sのデータ処理速度を達成。

部分的に動作するデス・スター

• クライアントノードが不足していたため、OSDノードとFIOプロセスを共有する必要があった。
• この構成でも、950GiB/sに近い性能を達成。

1TiB/s到達

• OSDシャード数とメッセンジャースレッド数を調整し、1TiB/sのデータ処理速度を達成。

睡眠; 消失訂正

• 3Xレプリケーションでテストした後、顧客企業が使用する6+2消失訂正にクラスターを再構成してテスト。
• 読み取り性能は500GiB/s以上、書き込み性能はほぼ400GiB/sに到達。

GN⁺の見解:

1. この記事はCephクラスターの性能最適化プロセスを詳細に説明し、複雑な問題解決を通じて高性能を達成した事例を示すことで、技術的な洞察を提供する。
2. 顧客企業との協力、コミュニティ貢献者たちの努力、そして多様なハードウェアおよびソフトウェア最適化戦略が、現実世界でどのように大きな成果を生み出せるかを示している。
3. この文章は、大規模データストレージシステムを扱う専門家だけでなく、性能最適化に関心のある技術者にとっても有益な情報を提供する。

[GN⁺]

Hacker Newsの意見

• CERNの1TB/s到達の知らせとCephの歴史
  • あるユーザーは、CERNがEOSクラスターを通じて1TB/sの速度を達成したと述べ、このクラスターは主にHDDを使用し、より多くのノードを備えていると説明している。また、CephはDreamhostで社内的な必要性から考案され、その後Red Hatに買収されたという興味深い歴史も共有している。
• 過去の技術リーダーとしての経験とCephへの好感
  • あるユーザーは、Ciscoで技術リーダーとして働きながらKubernetesをベアメタルにセットアップし、GlusterFSやCephを試した経験を振り返り、そのような実験を楽しんでいたと述べている。また、その記事がよく書かれていると称賛している。
• ノード規模縮小の提案
  • あるユーザーは、現在のシステムではノードあたりのエネルギー消費が高いと指摘し、ノードサイズを小さくするためのエンジニアリング努力が必要だと提案している。これにより、より少ないノードでも十分になり、単一障害が10台のディスクに影響する状況を減らせると主張している。
• デジタルデータ保存量の歴史的視点
  • あるユーザーは、この60年以内のどこかで世界で初めて1TiBのデジタルデータが保存された日があったはずだと述べ、今ではその量のデータを毎秒移動させていることに驚きを示している。
• CephクラスターによるDockerキャッシュ性能向上の経験
  • あるユーザーは、Dockerレイヤーキャッシュを維持するためにCephストレージクラスターを運用しており、EBSからCephへ切り替えた後にスループットが大幅に向上したと経験を共有している。このユーザーは、Cephはほとんどメンテナンスを必要としないとも述べている。
• Kubernetes内のストレージコントローラーソフトウェアの問題
  • あるユーザーは、Kubernetes内で動的ストレージに関する最大の問題はI/Oそのものではなく、ストレージコントローラーソフトウェアが実際の問題に直面したときに発生すると述べている。特に、rook/cephやLonghornを使うと、PVCがかなり時間が経ってからでないと接続されない問題を経験したという。
• ハードウェア理論限界に対する1 TiB/s性能の分析
  • あるユーザーは、1 TiB/sという性能がハードウェアの理論的限界と比べてどうなのかを分析し、ネットワークがボトルネックになっていると指摘している。また、Cephの複雑さがCPUにかなりの負荷を与えており、OSDのスレッディングモデルが最適化されていないと結論づけ、改善に期待を寄せている。
• Cephと他のオブジェクトストレージエンジンの比較要望
  • あるユーザーは、CephとMinIO、Garageなど他のオブジェクトストレージエンジンとの比較やベンチマークを見てみたいと要望している。
• Cephのトランザクションデータベース向けストレージ適性とIOレイテンシへの質問
  • あるユーザーは、Cephがトランザクションデータベース向けストレージとして適しているのか、IOレイテンシはどうなのかと質問し、OracleのクラスタファイルシステムやVeritasのようなシステムに対抗できる、より安価なファイルシステムへ移行したいという考えを示している。