第7章 Red Hat Ceph Storage クラスターのアップグレード
ストレージ管理者は、Red Hat Ceph Storage クラスターを新しいメジャーバージョンまたは新しいマイナーバージョンにアップグレードしたり、現行バージョンに非同期更新を適用するだけで済みます。Ansible Playbook rolling_update.yml は、Red Hat Ceph Storage のベアメタルまたはコンテナー化されたデプロイメントのアップグレードを実行します。Ansible は Ceph ノードを以下の順序でアップグレードします。
- ノードの監視
- MGR ノード
- OSD ノード
- MDS ノード
- Ceph Object Gateway ノード
- その他すべての Ceph クライアントノード
Red Hat Ceph Storage 3.1 以降、Object Gateway および高速 NVMe ベースの SSD (および SATA SSD) を使用する場合のパフォーマンスのためにストレージを最適化するために、新しい Ansible Playbook が追加されました。Playbook は、ジャーナルとバケットインデックスを SSD にまとめて配置してこれを行います。これにより、1 つのデバイスにすべてのジャーナルがある場合よりもパフォーマンスが向上します。これらの Playbook は、Ceph のインストール時に使用されます。既存の OSD は動作し続け、アップグレード中に追加のステップは必要ありません。このようにストレージを最適化するために OSD を同時に再設定する際に、Ceph クラスターをアップグレードする方法はありません。ジャーナルまたはバケットインデックスに異なるデバイスを使用するには、OSD を再プロビジョニングする必要があります。実稼働向け Ceph Object Gateway ガイド の LVM での NVMe の最適な使用 を参照してください。
Red Hat Ceph Storage クラスターを以前のサポートされているバージョンからバージョン 4.2z2 にアップグレードすると、モニターがセキュアでない global_id の再要求を許可していると記載の HEALTH_WARN 状態のままアップグレードが完了します。これは、CVE のパッチ適用が原因で、詳細は CVE-2021-20288 を確認してください。この問題は Red Hat Ceph Storage 4.2z2 の CVE で修正されています。
ヘルスに関する警告をオフにすることを推奨します。
-
AUTH_INSECURE_GLOBAL_ID_RECLAIMの警告のceph ヘルス詳細の出力を確認して、更新されていないクライアントを特定します。 - すべてのクライアントを Red Hat Ceph Storage 4.2z2 リリースにアップグレードします。
すべてのクライアントが更新され、AUTH_INSECURE_GLOBAL_ID_RECLAIM 警告がクライアントに表示されなくなったことを確認してから、
auth_allow_insecure_global_id_reclaimをfalseに設定します。このオプションがfalseに設定されている場合には、パッチを適用していないクライアントは、ネットワークの断続的な障害によりモニターへの接続が切断された後にストレージクラスターに再接続できず、タイムアウト (デフォルトでは 72 時間) 時に認証チケットを更新できません。構文
ceph config set mon auth_allow_insecure_global_id_reclaim false
-
AUTH_INSECURE_GLOBAL_ID_RECLAIMの警告が表示されているクライアントがないことを確認してください。
Playbook rolling_update.yml には、同時に更新するノード数を調整する シリアル 変数が含まれます。Red Hat では、デフォルト値 (1) を使用することを強く推奨します。これにより、Ansible がクラスターノードを 1 つずつアップグレードします。
いずれかの時点でアップグレードが失敗した場合は、ceph status コマンドでクラスターの状態を確認して、アップグレードの失敗理由を把握します。不具合の原因や解決方法がわからない場合は、Red Hat サポート にお問い合わせください。
マルチサイト設定を RedHat Ceph Storage 3 から RedHat Ceph Storage 4 にアップグレードする場合は、以下の推奨事項に注意してください。そうしないと、レプリケーションが破損する可能性があります。rolling_update.yml を実行する前に、all.yml に rgw_multisite: false を設定します。アップグレード後に rgw_multisite を再度有効にしないでください。アップグレード後に新しいゲートウェイを追加する必要がある場合にのみ使用してください。バージョン 3.3z5 以降の Red Hat Ceph Storage 3 クラスターのみを Red Hat Ceph Storage 4 にアップグレードします。3.3z5 以降に更新できない場合は、クラスターをアップグレードする前にサイト間の同期を無効にします。同期を無効にするには、rgw_run_sync_thread = false を設定して、RADOS Gateway デーモンを再起動します。最初にプライマリークラスターをアップグレードします。Red Hat Ceph Storage 4.1 以降にアップグレードします。3.3z5 に関連するパッケージバージョンを確認するには、What are the Red Hat Ceph Storage releases and corresponding Ceph package versions? を参照してください。同期を無効にする方法については、RGW Multisite の同期を一時的に無効にする方法 を参照してください。
Ceph Object Gateway を使用して Red Hat Ceph Storage 3.x から Red Hat Ceph Storage 4.x にアップグレードする場合、フロントエンドは自動的に CivetWeb から Beast (新しいデフォルト) に変更されます。詳細は、オブジェクトのゲートウェイ設定および管理ガイド の 設定 を参照してください。
RADOS Gateway を使用している場合には、Ansible はフロントエンドを CivetWeb から Beast に切り替えます。この過程で、RGW のインスタンス名が rgw.HOSTNAME から rgw.HOSTNAME.rgw0 に変更されます。名前が変更されたため、Ansible は ceph.conf 内の既存の RGW 設定を更新せず、代わりにデフォルトの設定を追加して、以前の CivetWeb ベースの RGW 設定はそのままですが、これは使用されません。そうすると、RGW のカスタム設定の変更が失われ、RGW のサービスが中断される可能性があります。これを回避するには、アップグレードの前に、all.yml の ceph_conf_overrides セクションに既存の RGW 設定を追加します。ただし、.rgw0 を追加して RGW インスタンス名を変更し、RGW サービスを再起動します。これにより、アップグレード後もデフォルトではない RGW の設定変更が保持されます。ceph_conf_overrides の詳細は、Ceph のデフォルト設定の上書き を参照してください。
7.1. サポート対象の Red Hat Ceph Storage アップグレードシナリオ
Red Hat は、以下のアップグレードシナリオをサポートします。
ベアメタル、コンテナー化された の表を読み、特定のアップグレード後の状態に移行するためにクラスターがログインする必要のある状態を確認します。
ceph-ansible を使用して、ベアメタルまたはコンテナー化アップグレードを行います。この場合、ベアメタまたはホストのオペレーティングシステムのメジャーバージョンは変わりません。Red Hat Enterprise Linux 7 から RedHat Enterprise Linux 8 へのアップグレードは、ceph-ansible ではサポートされていません。Red Hat Ceph Storage のアップグレードの一環としてベアメタルオペレーティングシステムを Red Hat Enterprise Linux 7.9 から Red Hat Enterprise Linux 8.4 にアップグレードするには、Red Hat Ceph Storage インストールガイドの Red Hat Ceph Storage クラスターおよびオペレーティングシステムの手動アップグレード のセクションを参照してください。
Red Hat は、クラスターを Red Hat Ceph Storage 4 にアップグレードする場合に、クラスターが最新バージョンの Red Hat Ceph Storage 3 を使用していることを推奨しています。Red Hat Ceph Storage の最新バージョンを知るには、What are the Red Hat Ceph Storage releases? を参照してください。詳細は、ナレッジベースの記事を参照してください。
表7.1 ベアメタルデプロイメントでサポートされるアップグレードシナリオ
| アップグレード前の状態 | アップグレード後の状態 | ||
|---|---|---|---|
| Red Hat Enterprise Linux のバージョン | Red Hat Ceph Storage のバージョン | Red Hat Enterprise Linux のバージョン | Red Hat Ceph Storage のバージョン |
| 7.6 | 3.3 | 7.9 | 4.2 |
| 7.6 | 3.3 | 8.4 | 4.2 |
| 7.7 | 3.3 | 7.9 | 4.2 |
| 7.7 | 4.0 | 7.9 | 4.2 |
| 7.8 | 3.3 | 7.9 | 4.2 |
| 7.8 | 3.3 | 8.4 | 4.2 |
| 7.9 | 3.3 | 8.4 | 4.2 |
| 8.1 | 4.0 | 8.4 | 4.2 |
| 8.2 | 4.1 | 8.4 | 4.2 |
| 8.2 | 4.1 | 8.4 | 4.2 |
| 8.3 | 4.1 | 8.4 | 4.2 |
表7.2 コンテナー化されたデプロイメントでサポートされるアップグレードシナリオ
| アップグレード前の状態 | アップグレード後の状態 | ||||
|---|---|---|---|---|---|
| ホストの Red Hat Enterprise Linux のバージョン | コンテナーの Red Hat Enterprise Linux バージョン | Red Hat Ceph Storage のバージョン | ホストの Red Hat Enterprise Linux のバージョン | コンテナーの Red Hat Enterprise Linux バージョン | Red Hat Ceph Storage のバージョン |
| 7.6 | 7.8 | 3.3 | 7.9 | 8.4 | 4.2 |
| 7.7 | 7.8 | 3.3 | 7.9 | 8.4 | 4.2 |
| 7.7 | 8.1 | 4.0 | 7.9 | 8.4 | 4.2 |
| 7.8 | 7.8 | 3.3 | 7.9 | 8.4 | 4.2 |
| 8.1 | 8.1 | 4.0 | 8.4 | 8.4 | 4.2 |
| 8.2 | 8.2 | 4.1 | 8.4 | 8.4 | 4.2 |
| 8.3 | 8.3 | 4.1 | 8.4 | 8.4 | 4.2 |
