4.7. RADOS

バックフィル中の進行が遅く、CPU 使用率が高い問題が解決されました

以前は、OSD シャードで最小のインデックスを持つワーカースレッドは、アイテムが mClock キューからスケジュールされるまで、または通知されるまで待機する代わりに、メインのワーカーループに戻りました。これにより、ビジーループと高い CPU 使用率が発生しました。

STS から返された一時認証情報を使用する場合にラージオブジェクトの名前変更が失敗しなくなりました。

以前のリリースでは、ラージオブジェクトの名前変更中の iam ポリシーの権限評価が間違っていたため、STS から返された一時的な認証情報が使用されると、ラージオブジェクトの名前変更が失敗していました。

小さな書き込みが遅延されるようになりました

以前は、Ceph はユニットの割り当て中に書き込みを遅延していました。アロケーションユニットが 64 K のように大きい場合は、小さな書き込みは遅延の対象にはなりませんでした。

モニターの数を減らしても Ceph Monitor がクラッシュしなくなりました。

以前のリリースでは、ユーザーが ceph orch apply mon NUMBER コマンドを使用してクォーラム内のモニターの数を減らすと、cephadm はシャットダウンする前にモニターを削除していました。Ceph は、モニターの削除前にシャットダウン中であると想定することが原因でアサーションがトリガーされていました。

初期サービスマップを処理する Ceph Manager チェックが緩和されました

以前は、クラスターをアップグレードするときに、Ceph Manager は以前にアクティブだった Ceph Manager から複数の service_map バージョンを受信していました。これにより、新たにアクティブになったマネージャーが、以前にアクティブであったマネージャーが送信したバージョンよりも新しいバージョンでマップを受信してしまうと、コード内の不正なチェックが原因でマネージャーのデーモンがクラッシュしました。

ceph --help コマンドでは、yaml フォーマッターが ceph orch コマンドに対してのみ有効であることを表示するようになりました。

以前のリリースでは、ceph config dump コマンドなど、ceph コマンドで有効な yaml 形式のオプションである ceph --help コマンドの仕様が欠けていることがわかりました。

PG ログの破損した重複エントリーは、オフラインおよびオンラインのトリミングで削除できる

以前は、PG ログ重複エントリーのトリミングは、人間のオペレーターよりもはるかに高い頻度で PG オートスケーラーによって使用される低レベルの PG 分割操作中に阻止されていました。重複を取り除くと、PG ログのメモリー増大が大幅に増大し、OSD がメモリーが不足するとクラッシュしていました。OSD を再起動しても、PG ログはディスクに保存され、起動時に RAM に再ロードされるため、問題が解決されませんでした。

starts メッセージが追加され、スクラブまたはディープスクラブプロセスが開始されたことを通知します。

以前は、starts メッセージがクラスターログにないため、配置グループ (PG) のスクラビングプロセスがいつ開始されたかをユーザーが判断できませんでした。これにより、PG のスクラブまたはディープスクラブにかかる時間を計算することが困難になりました。

PG 自動スケーリングが無効になっている場合、autoscale-status コマンドで NEW PG_NUM 値が表示されなくなりました。

以前のリリースでは、PG 自動スケーリングが有効になっていない場合でも、autoscale-status コマンドは NEW PG_NUM 値を表示していました。これは、PG オートスケーラーが NEW PG_NUM 値をプールに適用したかのようにエンドユーザーに表示されていましたが、実際はそうではありません。

ユーザーは、クラスターのアップグレード後に複製されたオブジェクトを削除できる。

以前は、クラスターを Red Hat Ceph Storage 4 から Red Hat Ceph Storage 5 にアップグレードした後、以前のバージョンで作成されたオブジェクトのスナップショットを削除すると、クローンが残り削除できませんでした。これは、SnapMapper キーが誤って変換されたためです。

ceph daemon heap stats コマンドは、デーモンに必要な使用状況の詳細を返すようになりました。

以前のリリースは、ceph daemon osd.x heap stats コマンドは、Ceph デーモンの現在のヒープ使用量ではなく、空の出力を返していました。その結果、ユーザーは必要なヒープ使用量を取得するために ceph Tell heap stats コマンドを使用する必要がありました。

Prometheus メトリクスは、要求されるたびにすべての Ceph Monitor の正しい Ceph バージョンを反映するようになりました。

以前のバージョンでは、Prometheus メトリクスは、モニターのアップグレード時に Ceph Monitor の一致しない Ceph バージョンを報告していました。その結果、この不整合を解決するには、アクティブな Ceph Manager デーモンを再起動する必要がありました。さらに、Ceph マネージャーは、handle_mon_map パラメーターを通じてモニターのメタデータを更新していました。これは、モニターがクラスターから削除または追加されたとき、アクティブな mgr が再起動されたとき、または mgr のフェイルオーバー時にトリガーされました。

再マッピング された配置グループに、正しいレプリカのセットが使用されるようになりました

以前は、再マッピング された配置グループの場合、誤ったレプリカのセットにスクラブ情報が照会され、存在しないはずの不一致が特定されて、スクラブプロセスが失敗していました。

対象の rank_removed が live_pinging および dead_pinging 状態でスタックしなくなりました

以前のリリースでは、場合によっては、モニターのランクが変更される前にモニターマップの paxos_size が更新されていました。たとえば、paxos_size は 5 から 4 に減りますが、モニターの最高ランクは 4 のままであるため、古いコードは、dead_pinging 状態からのランクの削除をスキップします。これが原因で、ターゲットのランクが dead_pinging のままになり、election strategy: 3 の peer_tracker スコアが異常な値になっていました。

サイトのフェイルオーバー中に Ceph モニターが停止しなくなりました。

以前のリリースは、removed_ranks 変数では、モニターマップが更新されるたびにその内容が破棄されませんでした。そのため、2 サイトのストレッチクラスターにあるモニターが置き換えられ、サイトの片方がフェイルオーバーすることで、スコアに関連するランクなど、接続スコアが一致しなくなりました。

ユーザーはレプリカの size を 1 に設定できるようになりました。

以前のリリースでは、ユーザーはプールの size を 1 に設定できませんでした。check_pg_num() 関数は、プールの予測配置グループ番号を誤って計算し、アンダーフローが発生しました。結果が誤っているため、pg_num が最大制限を超えているように見えていました。

require-osd-release フラグがクラスターのアップグレード後に適切なリリースに設定されていない場合、Ceph クラスターはヘルス警告を発行します。

以前のバージョンでは、アップグレード後に require-osd-release フラグの不一致を検出するコードのロジックが、コードのリファクタリング作業中に誤って削除されていました。アップグレード後の ceph -s 出力で警告が発生しないため、適切なリリースにフラグを設定せずにクラスターに加えられた変更により、配置グループ (PG) が特定の状態でスタックし、Ceph のメモリー消費が過剰に行われ、他の多くの問題を含む要求が遅くなっていました。