第4章 バグ修正

PID 制限が削除され、コンテナー内のワークロードがクラッシュしなくなります。

以前の Red Hat Enterprise Linux 9 デプロイメントでは、コンテナー内で実行できるプロセスの数を制限する pid 制限が適用されていました。このため、Ceph Object Gateway 同期などの特定の操作がクラッシュします。

Cephadm は設定ファイルとキーリングファイルを無作為に一時削除しなくなりました。

以前のリリースでは、クライアント設定とキーリングを計算するタイミングが正しくなかったため、cephadm はどのホストにも設定とキーリングが配置されるべきではないと計算して、その後はそれらをすべて削除していました。

Ceph Object Gateway デーモンがループバックアドレスに正しくバインドされるようになりました

以前は、Ceph Object Gateway デーモンをバインドするためにホスト上で有効な IP アドレスを探すときに、cephadm がループバックインターフェイスを除外していたため、デーモンがループバックアドレスにバインドされませんでした。

Cephadm は、Ceph モニターストアのサイズ制限を超えた後、デバイス情報を複数のエントリーに分割するようになりました

以前は、cephadm はホストを更新できず、デバイス情報がモニターストアのデフォルトの最大サイズ制限である 64K を超えると、ほとんどの操作を完了できませんでした。これにより、エントリーサイズのエラーが発生しました。その結果、ディスクが多数あるホストがある場合には、デフォルトの制限を引き上げる必要がありました。

クラッシュデーモンがクラッシュイベントを正しく記録し、ストレージクラスターに報告するようになりました

以前は、クラッシュレポートをストレージクラスターに送信するときにクラッシュデーモンが適切に認証されなかったため、クラッシュイベントを正しく記録してクラスターに送信できませんでした。

cephadm.log のログローテーションで問題が発生しなくなりました。

以前は、/var/log/ceph ディレクトリーが cephadm 以外のもの (ceph-common や ceph-ansible など) によって作成された場合、logrotate コマンドで問題が発生していました。その結果、cephadm.log をローテーションできませんでした。

Cephadm のログ設定が更新されました。

以前は、cephadm スクリプトはすべての出力を stderr に記録していました。その結果、デプロイメントの成功を示す cephadm ブートストラップログも stdout ではなく stderr に送信されていました。

ネットワークチェックにより、ホストが監視ネットワークから除外されなくなりました

以前は、cephadm がホストネットワークと設定済みのパブリックネットワークの一部との正確な一致を探すため、ネットワークチェックが失敗していました。これにより、有効なネットワーク設定を持つホスト (public_network に属するインターフェイスを持つホスト) が監視ネットワークから除外されました。

cephadm は、ホストレベルで osd_memory_target 設定を削除しなくなる

以前は、osd_memory_target_autotune がグローバルにオフになっていた場合、cephadm はユーザーがホストレベルで osd_memory_target に設定した値を削除していました。さらに、FQDN 名を持つホストの場合、クラッシュマップで短い名前が使用されていても、cephadm は FQDN を使用して設定オプションを設定します。このため、ユーザーは osd_memory_target をホストレベルで手動で設定できず、osd_memory_target 自動チューニングは FQDN ホストでは機能しませんでした。

cephadm は Ceph OSD 設定ファイルを書き換えます

以前は、OSD の再デプロイ中に、cephadm は Ceph OSD に使用される設定を書き込まないため、Ceph モニターデーモンが追加または削除されたときに、OSD はその設定ファイルで更新されたモニター設定を取得しませんでした。

ユーザーは、明示的な配置にリストされているホストをドレインできるようになりました

以前は、明示的配置の一部としてリストされたホストを排出すると、ホストが適切に排出されず、排出が停止されるかホストが明示的配置から削除されるまで、トレースバックがログに記録されていました。

--apply -spec オプションがブートストラップ中に失敗すると、cephadm がゼロ以外のコードを返します

以前は、操作が完了した場合、cephadm ブートストラップは常にコード 0 を返しました。--apply-spec オプションを使用したデプロイでエラーが発生した場合、リターンコードにエラーが反映されませんでした。

複雑な OSD のデプロイメントや共有 DB デバイスとの交換を一度に行う必要がなくなりました。

以前のリリースでは、cephadm が OSD を作成するときに、以前の OSD の db デバイスとしてすでに使用されていたデバイスが、使用できないデバイスとして除外されました。その結果、全 OSD が DB としてデバイスを使用すべきであるにも拘らず、一度にデプロイされなかった複雑な OSD デプロイメントは、機能しなくなります。これは、OSD の仕様には沿っていませんが、後続の OSD を作成するときに DB デバイスがフィルタリングされてしまうためです。

cephadm によって無効な tuned-profile 仕様が検出された場合、適切なエラーが発生します

以前のリリースでは、cephadm は tuned-profile の YAML 仕様を検証しないため、無効な tuned-profile 仕様に無効なデータや欠落データを適用しても、エラーや警告が返されませんでした。