検索

第6章 バグ修正

download PDF

本セクションでは、今回リリースされた Red Hat Ceph Storage で修正されたユーザーに大きな影響を及ぼすバグを説明します。また、セクションでは、以前のバージョンで見つかり修正された既知の問題を説明します。

6.1. Ceph Ansible ユーティリティー

/targetsのURLは、Prometheusがダウンしていることを示している

以前は、PrometheusのターゲットURLはlocalhost値で設定されていました。localhost値により、ターゲットステータスがダウンしていると見なされたときに、Prometheusサービスがlocalhostアドレスをリッスンしませんでした。このリリースでは、ターゲットURL値にIPアドレスを使用するようにPrometheus構成ファイルが更新されました。その結果、Prometheusターゲットステータスは正しくレポートされています。

(BZ#1933560)

ceph-volumeは、Cephデプロイメント中にOSDを作成するときにメタデータの破損を引き起こす可能性がある

以前は、ceph-volumeがボリュームグループ、論理ボリュームの作成、タグの設定などのLVMコマンドを実行すると、Cephのデプロイ時にOSDを作成するときにメタデータが破損する可能性がありました。このリリースでは、ユーザーはホスト上のgroup_vars/all.ymlファイルでlvmetad_disabledパラメーターをtrueに設定することにより、条件付きでlvmetadサービスを無効にできるため、メタデータの破損が回避されます。

(BZ#1955040)

ceph-ansibleのロールceph-dashboardは、強制的に自己署名証明書のコモンネームをceph-dashboardに設定する

これまでは、ceph-ansibleで生成された自己署名証明書を使用すると、ceph-dashboardにコモンネーム(CN)が強制されるため、クライアントに証明書を送信するノードのホスト名の不一致により、Prometheusなどのアプリケーションがエラーになりました。

このリリースでは、ceph-ansibleがCNに適切な値を設定し、Prometheusが期待どおりに機能します。

(BZ#1978869)

Cephコンテナが配置されていると、ローリングアップグレードが失敗する

Ceph MonitorデーモンとCeph Object Gatewayデーモンがコンテナーと同じ場所に配置されている、およびマルチサイトCeph Object Gatewayが有効になっていると、rolling_update.yml Ansible Playbookは失敗します。この失敗は、アップグレードプロセス中にCeph Monitorコンテナーが停止したためにradosgw-adminコマンドを実行できないことが原因で発生しました。このリリースでは、ceph-handlerロール内のマルチサイトのCeph Object Gatewayコードは、アップグレードプロセス中にスキップされます。その結果、rolling_update.ymlAnsible Ansible Playbookは正常に実行されます。

(BZ#1984880)

コンテナ化されたデーモンに切り替えると、Ceph Monitorのクォーラムチェックが失敗する

リグレッションバグが、switch-from-non-containerized-to-containerized-ceph-daemons.yml Ansible Playbookで発生する。このリグレッションバグにより、現在のノードのホスト名がテストされていないため、Ceph Monitorクォーラムチェックが失敗しました。このリリースでは、現在のCeph Monitorノードからのansible_hostnameファクトが正しく使用されます。その結果、Ceph Monitorのクォーラムチェックが成功します。

(BZ#1990733)

アップグレードに失敗した場合に新たな Ceph Ojbect Gateway インスタンスを追加する

radosgw_frontend_port オプションでは、複数の Ceph Object Gateway インスタンスを考慮せず、全インスタンスに対してポート 8080 を設定していました。今回のリリースでは、各 Ceph Object Gateway インスタンスの radosgw_frontend_port オプションが増加し、複数の Ceph Object Gateway インスタンスを使用できるようになりました。

(BZ#1859872)

Ceph Ansible がソケットファイルを削除し、クラスターの再デプロイを有効化

以前のバージョンでは、*.asok ファイルはパージ Playbook の完了時に残っており、クラスターの再デプロイ時にエラーが発生していました。今回の更新により、ceph-ansible は存在する可能性のあるソケットファイルをすべて削除し、クラスターを安全に再デプロイできるようになりました。

(BZ#1861755)

コンテナー化された Red Hat Ceph Storage デプロイメントの tcmu-runner プロセスのログローテーションのサポートが追加される

以前のバージョンでは、iSCSI を使用する Red Hat Ceph Storage がコンテナーにデプロイされると、tcmu-runner プロセスのログローテーションがなければ、コンテナーのすべての領域が使用されていました。今回のリリースにより、ログローテーションのサポートが tcmu-runner プロセスに追加され、ログファイルが定期的にローテーションされるようになりました。これにより、使用される領域が少なくなります。

(BZ#1873915)

FileStore OSD と BlueStore OSD が混在する OSD ノードの場合に FileStore から BlueStore への移行プロセスが失敗する可能性がある

以前のバージョンでは、Red Hat Ceph Storage バージョン 3.2 よりも前のバージョンを実行するデプロイメントで、osd_objectstoregroup_varshost_vars、または inventory のいずれでも明示的に設定されない場合、そのデプロイメントには FileStore OSD が含まれました。FileStore は、Red Hat Ceph Storage 3.2 より前のデフォルトでした。

デプロイされたストレージクラスターを Red Hat Ceph Storage 3.2 にアップグレードした後に、既存の OSD ノードに追加された新規 OSD は新しいデフォルトとなった BlueStore バックエンドを使用します。これにより、同じノード上に FileStore および BlueStore の OSD が混在しました。特定のケースでは、FileStore OSD が BlueStore OSD とジャーナルまたは DB デバイスを共有する場合があります。そのような場合に、パーティションが lvm batch で渡せないことや、GPT ヘッダーがあることにより、すべての OSD が再デプロイされると ceph-volume エラーが発生します。

今回のリリースにより、FileStore および BlueStore 設定の組み合わせで OSD を移行する 2 つのオプションを使用できます。

  • filestore-to-bluestore.yml Playbook の実行時に追加の変数 force_filestore_to_bluestoretrue に設定します。この設定により、すでに BlueStore を使用するものであっても、Playbook によりすべての OSD が自動的に移行されます。
  • force_filestore_to_bluestore (デフォルトでは false) を設定せずに、filestore-to-bluestore.yml Playbook を実行します。これにより、Playbook は FileStore OSD と BlueStore OSD が混在するノードでの移行を自動的にスキップします。これは FileStore OSD のみを持つノードを移行します。Playbook の実行の最後に、スキップされたノードを表示するレポートが表示されます。

OSD を移行する最適な方法を判断するために、Red Hat Ceph Storage 3 から 4 にアップグレードする前に、手動でスキップした各ノードを手動で確認します。

(BZ#1875777)

特殊文字は Docker レジストリーのパスワードで設定可能

以前のバージョンでは、Docker レジストリーのパスワードで設定された特殊文字は正しく処理されませんでした。今回のリリースにより、特殊文字が Docker レジストリーパスワードで設定されている場合に Ansible Playbook は失敗しません。特殊文字を Docker レジストリーのパスワードで使用でき、Ansible Playbook が予想通りに機能するようになりました。

(BZ#1880252)

Ansible モジュール ceph-volume が、論理ボリュームおよびボリュームグループの正しい情報を報告

以前は、OSD 上で Red Hat Enterprise Linux 8 ベースのコンテナーを使用する Red Hat Enterprise Linux 7 ホストで ceph-volume lvm zap --destroy コマンドを適用すると、そのホストの lvm キャッシュが更新されず、存在する論理ボリュームおよびボリュームグループが依然として報告されていました。今回のリリースにより、Ansible モジュール ceph_volume により、ホスト上のコマンドがトリガーされ、lvm キャッシュが更新され、論理ボリュームおよびボリュームグループの正しい情報を報告するようになりました。

(BZ#1886534)

journalctl コマンドを使用して Ceph コンテナーログを表示可能

以前のリリースでは、Podman がデタッチモードおよび systemd タイプのフォークでコンテナーを実行するときにデフォルトのログドライバーとして Kubernetes ファイルを使用したため、Ceph コンテナーログはジャーナルに存在しませんでした。今回のリリースで、Ceph コンテナーは journald ログドライバーで設定され、ログは journalctl コマンドを使用して利用できるようになりました。

(BZ#1890439)

Ceph Ansible がファイルおよびディレクトリーの所有権の値を nobody:nobody に設定する

以前のバージョンでは、Ceph Ansible はファイルとディレクトリーの所有権の値を root:root に設定しました。これにより、alertmanager サービスおよび prometheus サービスのパーミッションの問題が生じました。

今回のリリースにより、Ceph Ansible が所有権を nobody:nobody に設定するようになりました。これにより、パーミッションの問題がなくなります。

(BZ#1901543)

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.