Red Hat AMQ Broker 7.9 のリリースノート

Red Hat AMQ 2021.Q3

AMQ Broker のリリースノート

概要

本リリースノートには、AMQ Broker 7.9 リリースに含まれる新機能、改良された機能、修正、および問題に関する最新情報が含まれています。

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージをご覧ください。

第1章 改良された機能

ここでは、AMQ Broker 7.9 で強調表示された拡張機能および新機能のセットを説明します。リリースの拡張機能の完全リストは、「AMQ Broker 7.9.0 Enhancements」を参照してください。

注記

最新の AMQ Broker Long Term Support (LTS) リリースバージョンが必要な場合は、「AMQ Broker 7.8」を参照してください。

AMQP サーバー接続
ブローカーは AMQP プロトコルを使用して他のエンドポイントへの接続を開始することができます。たとえば、ブローカーは他の AMQP サーバーに接続し、それらの接続で要素を作成できます。この機能は、「 AMQ Broker の設定 」で説明されているように <broker-connection> 要素を使用して実装されます。
Operator は、すべてまたは複数の namespace の監視をサポートします。

以前のリリースでは、ブローカーのデプロイメントが必要なすべての namespace に AMQ Broker Operator がインストールされています。7.9 以降、AMQ Broker Operator はブローカーカスタムリソースの all または 複数の namespace の監視をサポートします。詳細は、『Deploying AMQ Broker for On-Premise』を参照してください。

注記

古いバージョンの AMQ Broker Operator がクラスターの namespace にすでにインストールされている場合、Red Hat は AMQ Broker Operator 7.9 バージョンをインストールし、競合の可能性を回避するためにその namespace をインストールしないことが推奨されます。

一時キュー namespace
AMQ Broker 7.9 では、broker.xml 設定ファイルで temporary-queue-namespace を指定できます。次に、namespace に一致するアドレス設定を指定し、ブローカーはそれらの設定をすべての一時キューに適用することができます。一時キュー namespace が存在しない場合、一時キューは他のキューと同じアドレス設定を使用します。詳細は、『 AMQ Broker の設定』の「一時キューへの特定のアドレス設定の適用 を参照してください。
Operator チャンネル

AMQ Broker Operator Red Hat Integration - AMQ Broker for RHEL 8(Multiarch) は以下のチャンネルで利用できます。

  • 7.x - このチャンネルは、利用可能な場合に 7.9 をインストールし、7. 7.10 にアップデートします。
  • 7.8.x - Long Term Support (LTS) チャンネルです。

選択する Operator を判別するには、「Red Hat Enterprise Linux Container Compatibility Matrix」を参照してください。

デフォルトで検証されるホスト
コネクターに適用されると verifyHost のデフォルト値は false から true に変更になりました。ブローカー間接続はすべて、デフォルトでホストを検証するようになりました。アクセプターのデフォルト値は false のままです。
CR を使用した Prometheus プラグインの有効化
環境変数を使用してプラグインを有効にする他に、CR を使用して OpenShift で Prometheus プラグインを有効にすることができます。どちらのオプションも、オンプレミス型 AMQ Broker のデプロイ に記載されています

第2章 削除された機能

以下の機能は以前のリリースで非推奨となり、7.9 で利用できなくなりました。

テンプレートベースのインストール
OpenShift Container Platform での AMQ Broker をデプロイするためのアプリケーションテンプレートの使用は以前のリリースで非推奨になり、削除されました。「AMQ Broker Operator を使用した OpenShift Container Platform での AMQ Broker のデプロイ」の説明にしたがって、AMQ Broker Operator を使用します。
OpenShift Container Platform 3.11
OpenShift Container Platform 3.11 での AMQ Broker のデプロイはサポートされなくなりました。AMQ Broker は OpenShift Container Platform 4.6、4.7、または 4.8 でサポートされます。
RHEL 7 ベースのイメージ
OpenShift Container Platform での AMQ Broker のすべてのデプロイメントで、RHEL 8 ベースのイメージが使用されるようになりました。
ドキュメント
AMQ Broker での JON の使用』は、AMQ Broker ドキュメントの一部として公開されなくなりました。ただし、AMQ Broker 7.8 ドキュメント の一部として、最後に公開されたバージョンにアクセスできます。

第3章 非推奨の機能

ここでは、サポートされる機能について説明しますが、AMQ Broker で非推奨となった機能について説明します。

OpenWire プロトコル
7.9 以降、OpenWire プロトコルは非推奨の機能です。新しい AMQ Broker ベースのシステムを作成する場合は、サポートされるプロトコルの 1 つを使用してください。この機能は今後のリリースで削除されます。
Hawtio のディスパッチコンソールプラグイン
7.3 以降、AMQ Broker には Hawtio ディスパッチコンソールプラグインである dispatch-hawtio-console.war に同梱されなくなりました。以前のバージョンでは、AMQ Interconnect の管理にディスパッチコンソールを使用していました。ただし、AMQ Interconnect は独自のスタンドアロン Web コンソールを使用するようになりました。
ネットワーク pinger
7.5 以降では、ネットワークの ping は非推奨にされています。ネットワークの ping は、ネットワークの分離の問題からブローカークラスターを保護することができません。これにより、修復不能なメッセージが失われることがあります。この機能は今後のリリースで削除されます。Red Hat では、ネットワークの ping を使用する既存の AMQ Broker デプロイメントは引き続きサポートされます。ただし、Red Hat は、新しいデプロイメントでネットワーク ping を使用することは推奨しません。高可用性を確保するためにブローカークラスターを設定する方法や、ネットワーク分離の問題を回避するために、『 AMQ Broker の設定』の「高可用性の実装」を参照してください。

第4章 テクノロジープレビュー

ここでは、AMQ Broker 7.9 のテクノロジープレビュー機能について説明します。

重要

テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあります。Red Hat は、実稼働環境での使用は推奨していません。詳細は、「テクノロジプレビュー機能のサポート範囲」を参照してください。

クォーラムの投票の強化
以前のバージョンの AMQ Broker では、クォーラム投票を使用するように 3 つ以上のライブ/バックアップのペアを設定し、レプリケーション高可用性 (HA) ポリシーを使用する場合は 2 つのライブブローカーが必要になりました。7.9 以降では、フェイルオーバーを設定して、Apache Curator および Apache ZooKeeper を使用して、2 つのブローカーを使用してクォーラム voting を提供できます。この機能の使用に関する情報は、Apache ActiveMQ Artemis ドキュメントの「High Availability and Failover」を参照してください。
クライアント接続の分散の改善
以前のリリースでは、クライアント接続のサーバー側のバランスを取る方法はありませんでした。7.9 以降では、クライアント接続のバランスを取るためのブローカーおよびポリシーのプールを指定できます。たとえば、クライアントが最も少ないアクティブな接続でブローカーにリダイレクトされるように、LE AST_CONNECTIONS ポリシーを指定できます。この機能の使用に関する情報は、Apache ActiveMQ Artemis ドキュメントの「Broker Balancers」を参照してください。
Fuse Console でのブローカーの表示

Operator ベースのブローカーのデプロイメントを、AMQ Management Console ではなく OpenShift に Fuse Console を使用するように設定できます。ブローカーのデプロイメントを適切に設定すると、Fuse Console はブローカーを検出し、専用の Artemis タブに表示されます。詳細は、『OpenShift での AMQ Broker のデプロイ』の「Fuse Console でのブローカーの表示」を参照してください。

注記

Fuse Console でのブローカーの表示は、Fuse 7.8 のテクノロジープレビューの機能です。

第5章 修正された問題

リリースで修正された問題の完全リストは、「AMQ Broker 7.9.0 Fixed Issues」および「 AMQ Broker - 7.9.x Resolved Issues 」を参照してください。

第6章 修正された Common Vulnerabilities and Exposures (CVE)

本セクションでは、AMQ Broker 7.9 リリースで修正された CVE (Common Vulnerabilities and Exposures) の詳細を説明します。

  • ENTMQBR-4071: CVE-2020-13956 httpclient: リクエスト URI での不適切な authority コンポーネントへの対処が正しくない
  • ENTMQBR-4677: CVE-2021-21290 netty: ローカルシステムの一時ディレクトリーを介した情報の公開
  • ENTMQBR-4775: CVE-2020-27223 jetty: 複数の Accept ヘッダーが含まれ、多数の "quality" パラメーターが含まれるリクエストにより DoS が発生する可能性あり
  • ENTMQBR-4779 - CVE-2021-3425 broker: Red Hat AMQ Broker: アプリケーションログファイルで JDBC ユーザー名とパスワードを開示
  • ENTMQBR-4795: CVE-2021-21295 netty: 検証の欠落により HTTP/2 でのリクエストスマグリングの可能性
  • ENTMQBR-4829: CVE-2021-21409 netty: content-length ヘッダーを使用した要求スマグリング
  • ENTMQBR-4907: CVE-2021-28163 jetty-server: Symlink による webapp ディレクトリーの内容公開
  • ENTMQBR-4911: CVE-2021-28165 jetty-server: jetty: サイズが大きく、無効な TLS フレームを受信すると、リソースが枯渇する
  • ENTMQBR-4912: CVE-2021-28164 jetty-server: jetty: あいまいなパスが WEB-INF にアクセス可能。
  • ENTMQBR-4960: CVE-2021-29425 commons-io: apache-commons-io: Apache Commons IO 2.2 から 2.6 への制限されたパストラバーサル
  • ENTMQBR-5118: CVE-2021-28169 jetty-server: jetty: ConcatServlet および WelcomeFilter への要求が WEB-INF ディレクトリー内の保護されているリソースにアクセスできる
  • ENTMQBR-5165: CVE-2021-34428 jetty-server: jetty: SessionListener により、セッションがログアウトの破損を非検証しなくなる
  • ENTMQBR-5229 - CVE-2021-20289 resteasy-jaxrs: resteasy: エラーメッセージによりエンドポイントクラス情報が開示
  • ENTMQBR-5250 - CVE-2021-34429 jetty-server: jetty: crafted URI によりセキュリティー制約が迂回可能
  • ENTMQBR-5398 - CVE-2021-3763 AMQ Broker 7: Incorrect privilege in Management Console

第7章 既知の問題

ここでは、AMQ Broker 7.9 の既知の問題について説明します。

  • ENTMQBR-5749 - OperatorHub に表示されるサポート対象外演算子の削除

    「OperatorHub への Operator のインストール」で説明されている Operator および Operator チャネルのみがサポートされます。Operator のパブリケーションに関連する技術的な理由により、他の Operator およびチャネルが OperatorHub に表示され、無視される必要があります。参照については、以下の一覧に、ベブルはあるが、サポートされていない Operator を示します。

    • Red Hat Integration - AMQ Broker LTS - すべてのチャネル
    • Red Hat Integration - AMQ Broker - alpha、current、および current-76
  • ENTMQBR-5615 - artemis.profile で想定外の重大な変更が「init container image」のアプローチを阻止する

    JVM オプション -Dhawtio.role を使用して artemis_profile ファイルの $JAVA_ARGS セクションの一部としてユーザーロールを設定すると、ユーザーはブローカーコンソールにアクセスできない可能性があります。

    この問題は、- Dhawtio.role によって設定されたすべての値を上書きする新しいプロパティー HAWTIO_ROLE によって生じます。この問題を回避するには、etc /artemis.profile ファイルの HAWTIO_ROLE プロパティーを使用して適切なロールを設定します。

  • ENTMQBR-17 - AMQ222117: クラスター接続を開始できない

    IPv6 をサポートする環境では、ブローカークラスターが適切に初期化に失敗することがあります。この失敗は、ログメッセージ Can’t assign requested address で示される SocketException が原因となります。この問題を回避するには、java.net.preferIPv4Stack システムプロパティーを true に設定します。

  • ENTMQBR-520: 別のアドレスにバインドされたキューと同じ名前のアドレスから受信することはできません。

    アドレスと同じ名前のキューは、アドレスにのみ割り当てる必要があります。既存のアドレスと同じ名前で、異なる名前のアドレスにバインドされるキューを作成することは、無効な構成です。これにより、誤ったメッセージがキューにルーティングされる可能性があります。

  • ENTMQBR-569: ID の OpenWire から AMQP に変換すると、ID がバイナリーとして送信されます。

    A-MQ 6 OpenWire クライアントから AMQP クライアントに相互プロトコルを通信する場合、追加の情報はアプリケーションメッセージプロパティーにエンコードされます。これは、ブローカーによって内部で使用される無害な情報であり、無視することができます。

  • ENTMQBR-599: Artemis cli によるトラストストアとキーストアの定義

    --ssl-key--ssl-key-password--ssl-trust、および --ssl-trust-password パラメーターを使用したブローカーインスタンスの作成は機能しません。この問題を回避するには、ブローカーの作成後に bootstrap.xml で対応するプロパティーを手動で設定します。

  • ENTMQBR-636 - perf load(mpt)の下で、ジャーナルが破損し、JavaNullPointerException が発生する

    ブローカーが高負荷を管理しているときに IO 関連の問題が発生しないようにするには、JVM に十分なメモリーとヒープ領域が割り当てられていることを確認してください。ActiveMQ Artemis ドキュメントの「Performance Tuning」章の「Tuning the VM」項を参照してください。

  • ENTMQBR-648 - JMS Openwire クライアントは、定義された purgeOnNoConsumer またはキュー フィルターを持つキューにメッセージを送信できない

    A-MQ 6 JMS クライアントを使用して、purgeOnNoConsumer を持つキューが true に設定されたアドレスにメッセージを送信します。キューにコンシューマーがない場合は失敗します。A-MQ 6 JMS クライアントを使用する場合は、purgeOnNoConsumer オプションを設定しないことが推奨されます。

  • ENTMQBR-652 - 既知の amq-jon-plugin のバグの一覧

    amq-jon-plugin のこのバージョンでは、ブローカーおよびキューの MBean の既知の問題があります。

    ブローカーの MBean の問題:

    • 接続を閉じると java.net.SocketTimeoutException 例外が発生する
    • listSessions()java.lang.ClassCastException を出力する
    • アドレス設定を追加すると java.lang.IllegalArgumentException が発生する
    • getConnectorServices() 操作が見つからない
    • listConsumersAsJSON() 操作が見つからない
    • getDivertNames() 操作が見つからない
    • ネットワークトポロジーの一覧表示で IllegalArgumentException が発生する
    • 削除アドレス設定で、パラメーター名が間違っている

    キュー MBean の問題:

    • expireMessage() で引数型の不一致例外が発生する
    • listDeliveringMessages()IllegalArgumentException を出力する
    • listMessages()java.lang.Exception を出力する
    • エラーメッセージの引数型不一致で moveMessages()IllegalArgumentException を出力する
    • エラーメッセージの引数型不一致で removeMessage()IllegalArgumentException を出力する
    • removeMessages() が、Can’t find operation removeMessage with 2 arguments の例外を出力する
    • retryMessage() が引数型の不一致 IllegalArgumentException を出力する
  • ENTMQBR-655 - [AMQP] populate-validated-user が有効になっている場合にメッセージを送信できない

    設定オプション populate-validated-user は、AMQP プロトコルを使用して生成されたメッセージではサポートされません。

  • ENTMQBR-897 - 宛先名の特殊文字による Openwire クライアント/プロトコルの問題

    現在、AMQ OpenWire JMS クライアントは、その名前にコンマ (',')、ハッシュ ('#')、および空白を含むキューおよびアドレスにアクセスできません。

  • ENTMQBR-944 - [A-MQ7, Hawtio, RBAC] ユーザーは、オペレーションアクセスが RBAC によって拒否された場合に、ユーザーはフィードバックを受けなくなります

    コンソールには、承認されていないユーザーが試行した操作に成功したことを示すことができます。

  • ENTMQBR-1875 - [AMQ 7, ha, replicated store] バックアップブローカーが、- ActiveMQIllegalStateException errorType=ILLEGAL_STATE message=AMQ119026: Backup Server がライブと同期状態でなかった後で、ライブになるか、シャットダウンする

    バックアップブローカーがマスターブローカーと同期しようとしている間に、マスターブローカーのページングディスクを削除すると、マスターが失敗します。さらに、バックアップブローカーはマスターとの同期を試みるため、ライブになりません。

  • ENTMQBR-2068: HA フェイルオーバーのシナリオ中に受信されていないメッセージがある。フェイルバックのシナリオ

    現在、OpenWire クライアントがメッセージを送信している間にブローカーがスレーブにフェールオーバーすると、フェイルオーバー時にブローカーへ配信されるメッセージが失われる可能性があります。この問題を回避するには、承認前にブローカーがメッセージを永続化していることを確認します。

  • ENTMQBR-2928: Broker Operator が CR の変更から回復できず誤った状態が生じる

    AMQ Broker Operator がカスタムリソース (CR) の更新を適用する際にエラーが発生した場合、Operator は復旧しません。具体的には、Operator が CR への追加の更新について予想通りに応答しなくなりました。

    たとえば、メインのブローカー CR の image 属性の値に誤りがあると、ブローカー Pod は ImagePullBackOff の関連エラーメッセージでデプロイに失敗します。その後、誤りを修正して CR の変更を適用すると、Operator は指定された数のブローカー Pod をデプロイしません。さらに、Operator は追加の CR 変更に応答しません。

    この問題を回避するには、最初にデプロイした CR を削除してから、それらを再デプロイする必要があります。既存の CR を削除するには、oc delete -f <CR name> などのコマンドを使用します。

  • ENTMQBR-3846 - MQTT クライアントがブローカーの再起動時に再接続されない

    ブローカーを再起動するか、ブローカーがフェイルオーバーすると、アクティブなブローカーは、以前に接続された MQTT クライアントの接続を復元しません。この問題を回避するには、MQTT クライアントを再接続するのに、クライアントで subscribe() メソッドを手動で呼び出す必要があります。

  • ENTMQBR-4023 - AMQ Broker Operator: Pod Status の Pod 名が、実際のものとは異なる

    特定の OpenShift プロジェクトでの Operator ベースのブローカーデプロイメントの場合、oc get pod コマンドを使用してブローカー Pod を一覧表示すると、Pd の順序値は 0 から始まります (例: amq-operator-test-broker-ss-0)。ただし、oc describe コマンドを使用して、activemqartmises カスタムリソース (oc describe activemqartemises) から作成されたブローカー Pod のステータスを取得した場合、Pod の順序値は誤って 1 から開始します (例: amq-operator-test-broker-ss-1)。この問題を回避する方法はありません。

  • ENTMQBR-4127 - AMQ Broker Operator: Operator によって生成されるルート (Route) 名が OpenShift で長すぎる可能性がある

    Operator ベースのデプロイメントのブローカー Pod ごとに、Operator が AMQ Broker 管理コンソールにアクセスするために作成するルートのデフォルト名には、カスタムリソース (CR) インスタンスの名前、OpenShift プロジェクトの名前、および OpenShift クラスターの名前が含まれます。たとえば、my-broker-deployment-wconsj-0-svc-rte-my-openshift-project.my-openshift-domain になります。これらの名前の一部が長い場合、デフォルトのルート名は OpenShift が実施する 63 文字の制限を超えている可能性があります。この場合、OpenShift Container Platform Web コンソールでは、ルートに表示されるステータスが Rejected になります。

    この問題を回避するには、OpenShift Container Platform Web コンソールを使用してルートの名前を手動で編集します。コンソールでルートをクリックします。右上の Actions ドロップダウンメニューで、Edit Route を選択します。YAML エディターで spec.host プロパティーを見つけ、値を編集します。

  • ENTMQBR-4140 - AMQ Broker Operator: storage.size が正しくないとインストールが使用できなくなる

    カスタムリソース (CR) インスタンスの storage.size プロパティーを設定し、永続ストレージのデプロイメントでブローカーに必要な Persistent Volume Claim (PVC) のサイズを指定すると、Operator のインストールがこの値を適切に指定しない場合に使用できなくなります。たとえば、storage.size の値を 1 (つまり、単位を指定しない) に設定したとします。この場合、Operator は CR を使用してブローカーデプロイメントを作成できません。さらに、CR を削除し、storage.size が正しく指定された新規バージョンをデプロイする場合でも、Operator はこの CR を使用して予想通りにデプロイメントを作成することはできません。

    この問題を回避するには、まず Operator を停止します。OpenShift Container Platform Web コンソールで Deployments をクリックします。AMQ Broker Operator に対応する Pod の More options (3 つの垂直ドット) をクリックします。Edit Pod Count をクリックし、値を 0 に設定します。Operator Pod が停止すると、storage.size を正しく指定した CR の新規バージョンを作成します。次に、Operator を再起動するには、Edit Pod Count を再度クリックし、値を 1 に戻します。

  • ENTMQBR-4141 - AMQ Broker Operator: ステートフルセットを再作成した後も手動の関与が必要になる

    デプロイメントのブローカーで必要な Persistent Volume Claim (PVC) のサイズを大きくしようとすると、手動でのステップを加えずに変更は反映されません。たとえば、カスタムリソース (CR) インスタンスの storage.size プロパティーに、PVC の初期サイズを指定するとします。CR を変更して storage.size別の 値を指定する場合、既存のブローカーは元の PVC サイズを引き続き使用します。これは、デプロイメントをゼロブローカーに縮小してから元の数に戻した場合でも当てはまります。ただし、デプロイメントのサイズを拡大してブローカーを追加すると、新しいブローカーは新しい PVC サイズを使用します。

    この問題を回避し、デプロイメント内のすべてのブローカーが同じ PVC サイズを使用するようにするには、OpenShift Container Platform Web コンソールを使用してデプロイメントで使用される PVC サイズを拡張します。コンソールで、StoragePersistent Volume Claims をクリックします。デプロイメントをクリックします。右上の Actions ドロップダウンメニューで Expand PVC を選択し、新規の値を入力します。