第17章 OpenShift Data Foundation へのアップグレード
17.1. OpenShift Data Foundation 更新プロセスの概要
この章では、すべての Red Hat OpenShift Data Foundation デプロイメント (Internal、Internal-Attached、および External) のマイナーリリースおよび z-stream リリース間でアップグレードする方法を説明します。アップグレードプロセスは、すべてのデプロイメントで引き続き同じとなります。
OpenShift Data Foundation とそのコンポーネントは、4.14 と 4.15 のようなマイナーリリース間、または 4.15.0 と 4.15.1 のような z-stream 間更新で、自動更新を有効にするか (Operator のインストール時に行っていない場合)、手動で更新を行うことでアップグレードできます。z-stream の新規リリースが利用可能になると、更新ストラテジーが Automatic に設定されている場合、アップグレードプロセスが自動的にトリガーされます。
また、内部および外部モードのデプロイメントの両方で、以下の順序で Red Hat OpenShift Data Foundation のさまざまな部分をアップグレードする必要もあります。
- OpenShift Container Platform の クラスターの更新 ドキュメントに従って OpenShift Container Platform を更新します。
Red Hat OpenShift Data Foundation を更新します。
- 更新に非接続環境を準備する には、Operator Lifecycle Manager を制限されたネットワークで使用するための Operator ガイドを参照し、OpenShift Data Foundation およびローカルストレージ Operator を使用している場合はこれらを更新できるようにします。
- マイナーリリース間の更新 は、Red Hat OpenShift Data Foundation 4.14 から 4.15 への更新 を参照してください。
- z-stream リリース間の更新 は、Red Hat OpenShift Data Foundation 4.15.x の 4.15.y への更新 を参照してください。
- 外部モードのデプロイメントを更新する 場合は、Red Hat OpenShift Data Foundation 外部シークレットの更新 のセクションにある手順も実行する必要があります。
- ローカルストレージを使用する場合は、Local Storage Operator を更新します。不明な場合は、Local Storage Operator デプロイメントの確認 を参照してください。
障害復旧 (DR) が有効になっている OpenShift Data Foundation 4.12 の既存のセットアップがある場合は、環境内のすべてのクラスターを同時に更新し、単一のクラスターを更新しないようにしてください。これは、潜在的な問題を回避し、最適な互換性を維持するためです。すべての OpenShift Data Foundation DR インスタンス間で一貫性を維持することも重要です。
更新に関する考慮事項
開始する前に、以下の重要な考慮事項を確認してください。
Red Hat OpenShift Container Platform のバージョンは、Red Hat OpenShift Data Foundation と同じです。
OpenShift Container Platform および Red Hat OpenShift Data Foundation のサポートされる組み合わせの詳細は、Interoperability Matrix を参照してください。
- クラスターが内部モードまたは外部モードのどちらでデプロイされたかを確認するには、ODF クラスターに内部モードまたは外部モードのストレージがあるかどうかを判別する方法 に関する ナレッジベースの記事 を参照してください。
- ローカルストレージ Operator は、ローカルストレージ Operator のバージョンが Red Hat OpenShift Container Platform のバージョンと一致する場合にのみ完全にサポートされます。
- フレキシブルスケーリング機能は、OpenShift Data Foundation の新しいデプロイメントでのみ利用できます。詳細は、Scaling storage guide を参照してください。
Multicloud Object Gateway には、データベースのコピー (NooBaa DB) が 1 つだけあります。つまり、NooBaa DB PVC が破損し、回復できない場合は、Multicloud Object Gateway に存在するアプリケーションデータが完全に失われる可能性があります。このため、Red Hat では NooBaa DB PVC のバックアップを定期的に取ることを推奨しています。NooBaa DB に障害が発生して回復できない場合は、最新のバックアップバージョンに戻すことができます。NooBaa DB をバックアップする手順は、こちらのナレッジベースの記事 の手順に従ってください。