オンラインにする前に Ceph オブジェクト ストレージについて理解する必要があります

Ceph は、オープンソースの分散ストレージ ソフトウェアとして、ストレージのローカル ストレージ リソースを使用でき、ストレージの高信頼性、高性能、高拡張性に対する企業のニーズを満たし、企業での支持が高まっています。数多くの制作実践を経て、Ceph の設計コンセプトは先進的で、機能が包括的で、使用が柔軟で柔軟性があることが証明されました。ただし、Ceph のこれらの利点は、企業にとっては諸刃の剣でもあり、適切に管理されていれば、十分なスキルがなく、Ceph の性質を理解していないと、場合によっては大きな問題を引き起こす可能性があります。以下にそのようなケースを共有したいと思います。

A 社は、Ceph オブジェクト ストレージ クラスターを展開することで外部クラウド ストレージ サービスを提供し、顧客が写真、ビデオ、APK インストール パッケージなどの非構造化データのクラウド管理を迅速に実現できるようにする SDK を提供しています。正式に事業を開始する前に、Ceph 上で十分な機能テスト、例外テスト、パフォーマンス テストが実施されました。

クラスターのサイズはそれほど大きくなく、コミュニティ バージョン 0.80 を使用しており、各サーバーには 32GB のメモリ、10 台の 4T SATA ディスク、および 1 台の 160G Intel S3700 SSD が構成されています。オブジェクト データを保存するために 300 個の SATA ディスクがデータ リソース プール (デフォルト構成は .rgw.buckets という名前のプール) を形成し、30 個の SSD ディスクがメタデータ リソース プールを形成します (デフォルト構成は .rgw.buckets.index プールという名前のプール)。 、オブジェクトのメタデータを保存します。 Ceph オブジェクト ストレージの運用と保守の展開の経験がある友人は、Ceph オブジェクト ストレージがマルチテナントをサポートしているため、この構成が国際的な慣行でもあることを知っています。複数のユーザーがオブジェクトを同じバケット (ユーザーの論理空間) に配置すると、メタデータが同じバケット インデックス オブジェクトが共有されるため、アクセス時にこのインデックス オブジェクトをロックする必要があり、バケット インデックス オブジェクトは高性能ディスク SSD で構成されるリソース プールに保存されます。各インデックス オブジェクトのアクセス時間が短縮され、IO パフォーマンスが向上し、オブジェクト ストレージの全体的な同時実行性が向上します。

システムがオンラインになった後、顧客データは Ceph オブジェクト ストレージ クラスターに継続的に保存され始め、最初の 3 か月間はすべてが正常に動作しました。この期間中に SATA ディスク障害も発生しましたが、Ceph 独自の障害検出および修復メカニズムを利用することで簡単に解決できたので、運用保守担当者は非常にリラックスしていました。 5 月に入ると、運用保守担当者は、SSD ディスクに対応する OSD が時々非常に遅くなり、ビジネスに遅れが生じると苦情を言うことがありました。この状況に遭遇したときの簡単かつ効果的な方法は、OSD を再起動して通常に戻すことでした。おそらくこの現象は散発的に数回発生しており、運用保守のお兄さんから「うちのSSDの使い方がおかしいのでは？」と聞かれました。分析の結果、ディスク スケジュール アルゴリズムをデッドラインに変更することを除いて、SSD ディスクのアプリケーションに関して特別なことは何もないと考えられます。これはすでに変更されているため、この点にはあまり注意を払いません。

5月28日の夕方21時30分、運用保守担当者らは携帯電話で少数のファイルの書き込みに失敗したというシステムアラームを受信し、すぐにシステムにログインして確認した。のサーバー上の SSD ディスクに対応する OSD の読み取りと書き込みが遅いことが原因でした。以前の経験によれば、このような場合、OSD プロセスを再起動すると、ためらわずに OSD プロセスを再起動し、システムが通常に戻るまで待つことができます。しかし今回は、SSD の OSD プロセスの起動が非常に遅く、同じサーバー上の SATA ディスクの OSD プロセスがフリーズし、一定期間後に他のサーバーで SSD ディスクの OSD プロセスがゆっくりとフリーズし始めたことが判明しました。サーバー。他のサーバー上の SSD ディスクに対応する OSD プロセスを再起動し続けると、SSD ディスク OSD プロセスを繰り返し再起動すると、同様の状況が発生し、開始できない SSD ディスク OSD プロセスが増えます。運営・保守兄弟たちは直ちに技術研究開発部門に状況を報告し、即時支援を要請した。

オフィスに到着した後、運用保守兄弟からのフィードバックに基づいて、サーバーに乗り込み、複数の SSD ディスクに対応する OSD プロセスを開始してみ、比較プロセスの起動プロセスを繰り返し観察しました:

1 OSD プロセスを検出するには、top コマンドを使用します。 起動後、システム メモリが使い果たされているため、場合によっては最大 20 GB、場合によっては 30 GB までメモリを割り当て始めます。プロセスが正常にプルアップされても、OSD は依然として最大 10 GB のメモリを使用します。

2. OSD ログを確認し、FileJournal::_open ステージに入った後にログ出力が停止していることを確認します。長い時間 (30 分以上) が経過すると、出力はload_pg ステージに入ります。load_pg ステージに入った後、さらに長い待機時間がかかりますが、load_pg は完了してもプロセスは自殺して終了します。

3. 上記の長い起動プロセス中に、pstack を使用してプロセス呼び出しスタック情報を表示します。FileJournal::_open ステージで確認される呼び出しスタックは、トランザクション処理中に実行されます。 load_pg ステージでは、取得されたコール スタック情報は、levelDB ログを使用して levelDB ファイルを修復します。

4. SSD ディスク OSD プロセスが正常に開始される場合がありますが、一定時間実行すると、他の SSD ディスク OSD プロセスが異常終了します。

これらの現象から判断すると、これらはすべてlevelDBに関連しています。大量のメモリ割り当てはこれに関連していますか？ levelDB に関連するコードをさらに確認したところ、トランザクションで levelDB イテレータが使用されると、イテレータによるレコードへのアクセス中にメモリが継続的に割り当てられ、イテレータが使い果たされるまですべてのメモリが解放されないことがわかりました。この観点から見ると、反復子によってアクセスされるレコードの数が非常に多い場合、反復処理中に大量のメモリが割り当てられることになります。これに基づいて、バケット内のオブジェクトの数を調べたところ、いくつかのバケット内のオブジェクトの数が 2,000 万、3,000 万、5,000 万に達しており、これらの大きなバケット インデックス オブジェクトの保存場所が偶然だったことがわかりました。問題が発生した場所の SSD ディスク OSD。大量のメモリ消費の原因が判明したはずです。これは大きな進歩です。ここ 2 日の 21:00 には、ユーザー全員が「」と感じています。大きな問題だ」。彼らは48時間近く戦い続けており、兄弟たちの目は赤く腫れている。立ち止まって休まなければ、夜明け前に倒れてしまう兄弟もいるだろう。

31日8時半、兄弟は再び戦闘に入った。

別の問題があります。それは、一部の OSD は長い起動プロセスを経て、load_pg が完了した後に最終的に自殺によって終了します。 cephのコードを読むと、長時間スケジュールされていないことによるタイムアウトにより一部のスレッドが自殺していることが確認されました（おそらくlevelDBスレッドが長時間CPUを占有するため）。 ceph 構成には filestore_op_thread_suicide_timeout パラメータがあります。テストと検証を通じて、このパラメータを大きな値に設定すると、この種の自殺を回避できます。再び少し明るくなり、時計は12時半を指していました。

一部のプロセスは開始後も最大 10GB のメモリを占有します。この問題が解決されない場合、SSD ディスク OSD がプルアップされても、同じサーバー上の他の SATA ディスク OSD の動作が影響を受けます。メモリが不足しています。兄弟たち、頑張ってください、これは夜明け前の暗闇です、あなたはそれを乗り越えなければなりません。情報をチェックする人もいれば、コードを調べる人もいて、最終的に 14 時 30 分に ceph 情報ドキュメントからメモリを強制的に解放するコマンドを見つけました: ceph Tell osd.* heap release このコマンドは、プロセスが終了した後に実行できます。 OSD プロセスによって占有されている過剰なメモリの解放を開始しました。誰もが非常に興奮し、すぐにテストして、実際に効果があることを確認しました。

SSD ディスク OSD が起動して実行されると、他の SSD ディスク OSD プロセスが終了します。これは主に、データが移行された OSD がその後に関連するレコード情報を削除するためです。データが移行され、levelDB がオブジェクトのメタデータ レコードを削除するようになります。大きすぎるバケット インデックス オブジェクトが見つかると、levelDB は反復子を使用してオブジェクトのメタデータ レコードを走査します。これにより、過剰なメモリ消費が発生し、サーバー上で OSD プロセスが発生します。異常であること。

上記の分析に基づいて、約 2 時間にわたる議論とデモンストレーションを繰り返した結果、次の緊急措置を策定しました:

1. クラスターに noout フラグを設定し、PG の移行を許可しません。 PG が移行される可能性があります。PG が移動された後、OSD は PG 内のオブジェクト データを削除し、PG 内に大きすぎるバケット インデックス オブジェクトがある場合、オブジェクト メタデータ レコードを削除します。イテレータがメタデータ レコードを走査するために消費されます。

2. SSD に対応する OSD を保存し、できるだけ早くシステムを復元するために、SSD に対応する OSD プロセスを開始するときに、起動パラメーター filestore_op_thread_suicide_timeout を追加し、大きな値を設定します。障害のある OSD がプルアップされると、一連の LevelDB プロセスが CPU を占有し、スレッドのスケジュールがブロックされます。Ceph には、このパラメータで設定された時間が経過してもスレッドがスケジュールされていない場合があります。スレッドのデッドロックであると判断されます。スレッドのデッドロックによるプロセスの自殺を回避するには、このパラメータを設定する必要があります。

3. メモリが限られている現在の状況では、OSD プロセスの起動を高速化するために、スワップ パーティションを SSD ディスクに調整します。

4. スケジュールされたタスクを開始し、コマンド ceph Tell osd.* heap release を定期的に実行して、OSD によって占有されているメモリを強制的に解放します。

5. SSD に対応する OSD に問題がある場合は、以下の手順に従ってください:

a) まず、サーバー上のすべての OSD プロセスを停止して、すべてのメモリを解放します。

b) 次に、OSD プロセスを開始し、filestore_op_thread_suicide_timeout パラメーターを実行し、72000 などの大きな値を指定します。

c) OSD の起動プロセスを観察します。load_pgs が実行されたら、すぐに ceph Tell osd.N heap release コマンドを手動で実行して、占有されているメモリを強制的に解放できます。

d) クラスターのステータスを観察し、すべての PG のステータスが正常に戻ったら、他の SATA ディスクに対応する OSD プロセスを開始します。

上記の手順に従って、17:30 から OSD プロセスを 1 つずつ再開しました。この間、非常に大きなバケット インデックス オブジェクトのバックフィルに時間がかかりました。がブロックされ、アプリケーションのビジネス リクエストがタイムアウトになります。これは、単一のバケットに多数のオブジェクトを保存することによる悪影響でもあります。

5 月 31 日 23:00 に、すべての OSD プロセスが最終的に復旧しました。障害からシステムの復旧に成功するまで、私たちは 72 時間にわたって懸命に働きました。全員が顔を見合わせ、興奮しすぎました。この問題に対する完全な解決策を検討し策定するために熱心に取り組んでください。 解決策:

1. サーバーのメモリを 64 GB に拡張します。

2. 新しいバケットの場合、ストレージ オブジェクトの最大数を制限します。

3. 十分なテストの後、過度に大きい単一バケットインデックスオブジェクトの問題を解決するために、Ceph バージョン 0.94 がバージョン 0.94 にアップグレードされました。

4. 大規模なトランザクションでは、セグメント化された反復を通じて、反復子は一定数のレコードの走査を完了した後にその現在の反復位置を記録し、それを解放し、走査を続ける新しい反復子を再作成します。最後の反復の位置から、反復子のメモリ使用量を制御します。

決して過去を忘れず、未来から学び、経験と教訓から学びましょう。以下の点をまとめます:

1. システムはオンラインにする前に完全にテストする必要があります

A 社のシステムをオンラインにする前に、ceph はすでにテストを行っています。完全な機能、パフォーマンス、および例外のテストは行われていますが、大量のデータを使用したスト​​レス テストはありません。これまでに数千万のオブジェクトが 1 つのバケットでテストされていた場合、この隠れた危険性が事前に発見される可能性があります。

2. 運用保守プロセスのあらゆる異常には、時間内に注意を払う必要があります

この場合、残念なことに、問題が発生する少し前に、運用保守部門はすでに SSD の異常の問題を報告していました。もしその時点でそれが行われていなかったら、詳細な分析を通じて問題の根本原因を見つけ出し、事前に回避策を立てることができるかもしれません。

3. ceph の性質を確認する

どのソフトウェア製品にも対応する仕様制限があり、ceph も例外ではありません。 ceph アーキテクチャとその実装原理を事前に深く理解し、単一のバケットに多数のオブジェクトを過剰に保存することによる悪影響を理解し、事前に計画を立てることができれば、この場合に遭遇する問題は解決されます。起こらない。 RGW は、ユーザー レベルおよびバケット レベルのクォータを含むクォータを非常に包括的にサポートしており、単一のバケットに保存できるオブジェクトの最大数を設定できます。

4. コミュニティの最新の進捗状況を常に追跡します

Ceph バージョン 0.94 では、バケット インデックス オブジェクトのシャード機能がサポートされており、バケット インデックス オブジェクトを複数のシャード オブジェクトに分割して保存することができます。単一バケット インデックス オブジェクトが大きすぎる問題。