Rook の人気の高まりに関連して、Rook の落とし穴と、途中で待ち受ける問題についてお話したいと思います。
私について: ハンマー バージョンからの ceph 管理の経験、コミュニティ創設者 電報で。
根拠のないことを避けるために、ceph の問題に関して Habr によって受け入れられた (評価から判断して) 投稿を参照します。 これらの投稿でほとんどの問題に私も遭遇しました。 使用した素材へのリンクは記事の最後にあります。
Rook に関する投稿で ceph について触れているのには理由があります。Rook は本質的に ceph を kubernetes でラップしたものであり、これはすべての問題を引き継いでいることを意味します。 ceph の問題から始めましょう。
クラスター管理を簡素化する
Rook の利点の XNUMX つは、kuberentes を通じて ceph を管理しやすいことです。
ただし、ceph には設定用の 1000 を超えるパラメータが含まれていますが、同時に rook を通じて編集できるのはそのうちのほんの一部だけです。
ルミナスの例
> ceph デーモン mon.a 設定の表示 | トイレ -l
1401
Rook は、ceph をインストールおよび更新するための便利な方法として位置付けられています
Rook なしで ceph をインストールすることに問題はありません。ansible プレイブックは 30 分で作成されますが、更新には多くの問題があります。
クロック氏の投稿からの引用
例: hummer から Jewel に更新した後、クラッシュ調整パラメータが正しく機能しません
> ceph osd crash show-tunables
{
...
"straw_calc_version": 1、
"allowed_bucket_algs": 22、
"プロフィール": "不明",
「optimal_tunables」: 0、
...
}
しかし、マイナーバージョンであっても問題はあります。
例: アップデート 12.2.6 により、クラスターが正常性エラー状態になり、条件付きで PG が壊れます
更新せずに待ってテストしますか? しかし、私たちは更新などの利便性のために Rook を使用しているようです。
Rook のディザスタ リカバリ クラスタの複雑さ
例: OSD が停止し、足元でエラーが多発します。 構成内のパラメータの XNUMX つに問題があるのではないかと考え、特定のデーモンの構成を変更したいと考えていますが、kubernetes と DaemonSet があるため変更できません。
代替手段はありません。 ceph Tell osd.Num injectargs が機能しません - OSD が嘘をついています。
難易度デバッグ
一部のセットアップとパフォーマンス テストでは、デーモンの OSD ソケットに直接接続する必要があります。 Rook の場合、まず目的のコンテナを見つけてからそのコンテナに入り、デバッグ用のツールが不足していることに気づき、非常に動揺する必要があります。
OSDを順番に上げるのが難しい
例: OSD が OOM に陥り、リバランスが開始され、その後次のものが陥ります。
解決策: OSD を一度に XNUMX つずつ上げ、クラスタに完全に含まれるまで待ってから、次の OSD を上げます。 (詳細については、Ceph レポートを参照してください。災害の分析)。
ベアメタル インストールの場合、これは単純に手動で行われます。Rook およびノードごとに 1 つの OSD の場合、特に問題はありません。ノードごとの OSD > XNUMX の場合、代替リフティングの問題が発生します。
もちろん、それらは解決できますが、Rook を使用して物事を単純化しますが、より複雑になります。
ceph デーモンの制限を選択するのが難しい
ceph のベアメタル インストールの場合、クラスターに必要なリソースを計算するのは非常に簡単です。公式があり、調査が利用可能です。 弱い CPU を使用している場合は、Numa が何であるかを知るためにパフォーマンス テストを実行する必要がありますが、それでも Rook よりは簡単です。
Rook の場合、計算できるメモリ制限に加えて、CPU 制限を設定するという問題もあります。
そしてここでは、パフォーマンステストに一生懸命取り組む必要があります。 制限を下げるとクラスターが遅くなり、unlim を設定すると、リバランス中にアクティブな CPU 使用率が発生し、kubernetes のアプリケーションに悪影響を及ぼします。
ネットワークの問題 v1
ceph の場合は、2x10GB ネットワークを使用することをお勧めします。 XNUMX つはクライアント トラフィック用で、もう XNUMX つは ceph サービスのニーズ (リバランス) 用です。 ベアメタル上で ceph を使用している場合、この分割は簡単に構成できますが、Rook を使用している場合は、すべてのクラスター構成で XNUMX つの異なるネットワークをポッドにフィードできるわけではないため、ネットワークによる分割によって問題が発生します。 。
ネットワークの問題 v2
ネットワークを分離することを拒否すると、リバランス時に ceph トラフィックがチャネル全体を詰まり、kubernetes のアプリケーションが速度低下またはクラッシュします。 ceph のリバランスの速度を下げることはできますが、リバランスに時間がかかるため、ディスクまたは OOM を介して XNUMX 番目のノードがクラスターから外れてしまうリスクが増加し、クラスターの読み取り専用がすでに保証されています。
長いリバランス - アプリケーションの遅延が長い
Ceph の投稿からの引用。 災害の解剖学。
クラスターのパフォーマンスをテストします。
サイズ 4 KB の書き込み操作には 1 ミリ秒かかり、パフォーマンスは 1000 スレッドで 1 操作/秒です。
4 MB (オブジェクト サイズ) の操作には 22 ミリ秒かかり、パフォーマンスは 45 操作/秒です。
その結果、XNUMX つのドメインのうち XNUMX つのドメインに障害が発生すると、クラスターはしばらくの間機能低下状態になり、ホット オブジェクトの半分が異なるバージョンに分散され、書き込み操作の半分が強制リカバリで開始されます。
強制回復時間は、劣化したオブジェクトへの書き込み操作にかかるおおよその時間を計算します。
まず 4 ミリ秒で 22 MB を読み取り、22 ミリ秒で書き込み、次に 1 ミリ秒で 4 KB の実データを書き込みます。 標準パフォーマンスが 45 ミリ秒だった場合、SSD 上の劣化したオブジェクトへの書き込み操作ごとに合計 1 ミリ秒かかり、パフォーマンスは 45 分の XNUMX に低下します。
劣化したオブジェクトの割合が高くなるほど、すべてが悪化します。
クラスターが正しく動作するには、リバランスの速度が重要であることがわかりました。
Ceph の特定のサーバー設定
ceph では、特定のホストの調整が必要になる場合があります。
例: sysctl 設定と同じ JumboFrame、これらの設定の一部はペイロードに悪影響を与える可能性があります。
Rook の本当の必要性には疑問が残る
クラウドを使用している場合は、クラウド プロバイダーからストレージを利用できるため、はるかに便利です。
独自のサーバーを使用している場合は、kubernetes を使用しないで ceph を管理する方が便利です。
低コストのホスティング会社からサーバーをレンタルしていますか? そうすれば、明らかに ceph に悪影響を与えるネットワーク、その遅延、帯域幅を大いに楽しむことができるでしょう。
合計： kuberentes の実装とストレージの実装は、異なる入力と異なるソリューション オプションを持つ異なるタスクです。これらを混合することは、どちらか一方のために危険なトレードオフを行うことを意味します。 これらのソリューションを組み合わせるのは設計段階でも非常に難しく、まだ運用期間がある。
参考文献：
でもセフって言うけど...彼は本当に優秀なの?
セフ。 災害の構造
出所： habr.com