第8章 AMQ Streams のアップグレード
AMQ Streams をバージョン 2.0 にアップグレードすると、新機能および改良された機能、パフォーマンスの向上、およびセキュリティーオプションを利用できます。
このアップグレード中に、Kafka をサポートされる最新バージョンにアップグレードします。各 Kafka リリースによって、AMQ Streams デプロイメントに新機能、改善点、およびバグ修正が導入されます。
新しいバージョンで問題が発生した場合は、AMQ Streams を以前のバージョンに ダウングレード できます。
リリースされた AMQ Streams バージョンの一覧は、Red Hat カスタマーポータルの「製品ダウンロード」で確認できます。
アップグレードパス
2 つのアップグレードパスが可能です。
- インクリメント
- AMQ Streams を以前のマイナーバージョンからバージョン 2.0 にアップグレードします。
- マルチバージョン
AMQ Streams を 1 回で古いバージョンからバージョン 2.0 にアップグレードします (1 つ以上の中間バージョンを飛ばします)。
たとえば、AMQ Streams 1.7 から直接 AMQ Streams 2.0 にアップグレードします。
Kafka バージョンのサポート
Kafka バージョン の表には、AMQ Streams 2.0 でサポートされる Kafka バージョンが記載されています。この表では以下に注意してください。
- 最新の Kafka バージョンは実稼働でサポートされます。
- 最新バージョンより前の Kafka バージョンは、AMQ Streams 2.0 へのアップグレードの目的でのみサポートされます。
AMQ Streams のアップグレードプロセスを開始する前に、アップグレードする Kafka バージョンを決定します。
ご使用のバージョンの AMQ Streams によってサポートされれば、上位バージョンの Kafka にアップグレードできます。サポートされる下位バージョンの Kafka にダウングレードできる場合もあります。
ダウンタイムと可用性
高可用性に対してトピックが設定されている場合、AMQ Streams をアップグレードしても、これらのトピックからデータをパブリッシュおよび読み取るコンシューマーとプロデューサーのダウンタイムは発生しません。高可用性トピックのレプリケーション係数は 3 以上であり、パーティションはブローカー間で均等に分散されます。
AMQ Streams をアップグレードするとローリングアップデートがトリガーされ、プロセスのさまざまな段階ですべてのブローカーが順に再起動されます。ローリングアップデート中に、すべてのブローカーがオンライン状態ではないため、クラスター全体の可用性 は一時的に低下します。クラスターの可用性が低下すると、ブローカーの障害によってメッセージが失われる可能性が高くなります。
8.1. 必要なアップグレードシーケンス リンクのコピーリンクがクリップボードにコピーされました!
ダウンタイムなしでブローカーとクライアントをアップグレードするには、以下の順序でアップグレード手順を 必ず 完了してください。
Kubernetes クラスターのバージョンがサポートされていることを確認してください。
AMQ Streams 2.0 は、OpenShift 4.6 から 4.9 でサポートされます。
-
AMQ Streams を 1.7 以前からアップグレードする場合は、既存のカスタムリソースを更新して、
v1beta2API バージョンをサポートします。 - Cluster Operator を新しい AMQ Streams バージョンに更新します。
- サポートされる最新の Kafka バージョンに、すべての Kafka ブローカーとクライアントアプリケーションをアップグレードします。
- オプション: パーティションの再分散に Incremental Cooperative Rebalance プロトコルを使用するために、コンシューマーと Kafka Streams アプリケーションをアップグレードします。
8.1.1. Cluster Operator のアップグレードオプション リンクのコピーリンクがクリップボードにコピーされました!
Cluster Operator のアップグレード方法は、デプロイ方法によって異なります。
- インストールファイルの使用
- インストール用の YAML ファイルを使用して Cluster Operator をデプロイした場合は、「Cluster Operator のアップグレード」の説明に従って、Operator のインストールファイルを変更してアップグレードを実行します。
- OperatorHub の使用
OperatorHub から AMQ Streams をデプロイした場合は、Operator Lifecycle Manager (OLM) を使用して AMQ Streams Operator の更新チャネルを新しい AMQ Streams バージョンに変更します。
選択したアップグレードストラテジーに応じて、チャネルの更新後に以下のいずれかを実行します。
- 自動アップグレードが開始されます。
手動アップグレードでは、インストールを開始する前に承認が必要です。
OperatorHub を使用した Operator のアップグレードについての詳細は、OpenShift ドキュメントの「Upgrading installed Operators」を参照してください。
8.1.2. OperatorHub を使用した AMQ Streams 1.7 以前からのアップグレード リンクのコピーリンクがクリップボードにコピーされました!
OperatorHub を使用して AMQ Streams 1.7 以前からアップグレードする場合に必要となるアクション
Red Hat Integration - AMQ Streams Operator は、v1beta2 カスタムリソースのみをサポートします。OperatorHub で AMQ Streams Operator をバージョン 2.0 に アップグレードする前 に、カスタムリソースを v1beta2 にアップグレードする必要があります。
すべてのカスタムリソースの v1beta2 API バージョンが AMQ Streams 1.7 で導入されました。AMQ Streams 1.8 では、KafkaTopic および KafkaUser を除くすべての AMQ Streams カスタムリソースから v1alpha1 および v1beta1 API バージョンが削除されました。
バージョン 1.7 より前の AMQ Streams バージョンからアップグレードする場合は、以下を行います。
- AMQ Streams 1.7 へのアップグレード
- AMQ Streams ダウンロードサイト から、AMQ Streams 1.8 で提供される Red Hat AMQ Streams API Conversion Tool をダウンロードします。
カスタムリソースおよび CRD を
v1beta2に変換します。詳細は、AMQ Streams 1.7 upgrade documentation を参照してください。
- OperatorHub で、Red Hat Integration - AMQ Streams Operator のバージョン 1.7.0 を削除します。
存在する場合は、Red Hat Integration - AMQ Streams Operator のバージョン 2.0.0 を削除します。
存在しない場合は、次のステップに進みます。
AMQ Streams Operator の Approval Strategy が Automatic に設定されている場合、Operator のバージョン 2.0.0 がすでにクラスターに存在する可能性があります。リリース前にカスタムリソースおよび CRD を
v1beta2API バージョンに 変換しなかった 場合、Operator が管理するカスタムリソースおよび CRD は古い API バージョンを使用します。その結果、2.0.0 Operator は Pending ステータスで停止します。このような場合、Red Hat Integration - AMQ Streams Operator のバージョン 2.0.0 およびバージョン 1.7.0 を削除する必要があります。両方の Operator を削除すると、新しい Operator バージョンがインストールされるまで、調整は一時停止されます。カスタムリソースへの変更が遅延しないように、次の手順を直ちに実行します。
OperatorHub で、Red Hat Integration - AMQ Streams Operator のバージョン 2.0.0 を即時にインストールします。
インストールされた 2.0.0 Operator はクラスターの監視を開始し、ローリングアップデートを実行します。このプロセス中に、クラスターのパフォーマンスが一時的に低下する場合があります。
別の方法として、バージョン 1.7 からカスタムリソースをインストールし、リソースを変換してから 1.8 以降にアップグレードすることもできます。