3.4. Red Hat OpenStack Platform 17.1.1 メンテナンスリリース (2023 年 9 月 20 日)

今回の更新により、ブートストラップコントローラーノードの置き換え後に OVN データベース操作に悪影響を及ぼすバグが修正されました。この更新の前は、名前の再利用が原因で OVN データベース RAFT クラスターで問題が発生したため、元のブートストラップコントローラーノードのホスト名と IP アドレスを、代わりのコントローラーノードに使用できませんでした。

これで、交換用コントローラーノードに元のホスト名と IP アドレスを使用できるようになります。

この更新前は、OVN サービスプロバイダードライバーで負荷分散サービス (octavia) を使用していた RHOSP 17.1 環境では、Floating IP アドレス (FIP) のロードバランサーヘルスチェックにプロトコルポートが正しく設定されませんでした。FIP へのリクエストが、`ERROR` 状態にあるロードバランサーメンバーに誤って分散されました。

この更新により、この問題は解決され、Floating IP アドレス (FIP) の新しいロードバランサーヘルスチェックにプロトコルポートが適切に設定されるようになりました。この更新をデプロイする前にヘルスモニターを作成した場合は、それらを再作成してポートの問題を解決する必要があります。

RHOSP 17.1.1 では、tripleo_frr_bgp_peers ロール固有パラメーターを使用して、ピアリングする Free Range Routing (FRR) の IP アドレスまたはホスト名のリストを指定できるようになりました。

例

  ControllerRack1ExtraGroupVars:
    tripleo_frr_bgp_peers: ["172.16.0.1", "172.16.0.2"]

このリリースには、カスタムルーターフレーバーを定義し、カスタムルーターフレーバーを使用してルーターを作成するために使用できるオプション機能のテクノロジープレビュー機能が含まれています。

詳細は、ルーターフレーバーを使用したカスタム仮想ルーターの作成 参照してください。

OVN メカニズムドライバーへの移行中に IPv6 を使用してインスタンスに接続する場合、ML2/OVS サービスが停止すると、インスタンスへの接続が最大数分間中断される可能性があります。

IPv6 のルーターアドバタイズメントデーモン radvd は、OVN メカニズムドライバーへの移行中に停止します。radvd が停止している間、ルーターアドバタイズメントはブロードキャストされません。このブロードキャストの中断により、IPv6 経由のインスタンス接続が失われます。新しい ML2/OVN サービスが開始されると、IPv6 通信は自動的に復元されます。

回避策: 中断の発生を回避するには、代わりに IPv4 を使用してください。

RHOSP 17.1.1 では、director を使用して親の NS レコードと一致するように NS レコードを自動的に設定できません。回避策: 自動化された回避策が将来のリリースで提供されるまで、管理者はアンダークラウドの /usr/share/ansible/roles/designate_bind_pool/templates/ にあるオーケストレーションサービス (heat) テンプレートファイルを手動で変更できます。Jinja テンプレート pools.yaml.j2 で、ns_records を含む行に続くコードを次の空行 (13 - 16 行目) まで削除し、そのインフラストラクチャーに適切な値を挿入します。最後に、管理者はオーバークラウドを再デプロイする必要があります。

例

  ns_records:
    - hostname: ns1.desiexample.com
      priority: 1
    - hostname: ns2.desiexample.com
      priority: 2

BGP 動的ルーティングを使用する RHOSP 17.1 環境では、現在、Floating IP (FIP) ポート転送が失敗するという既知の問題があります。

FIP ポート転送が設定されている場合、FIP と同じ宛先 IP を持つ特定の宛先ポートに送信されたパケットは、RHOSP Networking サービス (neutron) ポートから内部 IP にリダイレクトされます。これは、使用されているプロトコル (TCP、UDP など) に関係なく発生します。

BGP 動的ルーティングが設定されている場合、FIP ポート転送の実行に使用される FIP へのルートは公開されず、これらのパケットは最終的な宛先に到達できません。

現在、回避策はありません。

RHOSP 17.1.1 では、新規デプロイメント中に、agent-notification サービスの初期化中に RHOSP Identity サービス (keystone) が利用できない場合が多いという既知の問題があります。これにより、ceilometer が gnocchi エンドポイントを検出できなくなります。その結果、メトリクスは gnocchi に送信されません。

回避策: コントローラーノードで agent-notification サービスを再起動します。

$ sudo systemctl restart tripleo_ceilometer_agent_notification.service

Pacemaker によって制御される ceph-nfs リソースには、一部のプロセスデータを保存するためのランタイムディレクトリーが必要です。このディレクトリーは、RHOSP をインストールまたはアップグレードするときに作成されます。現在、コントローラーノードを再起動するとディレクトリーが削除され、コントローラーノードを再起動しても ceph-nfs サービスは回復しません。すべてのコントローラーノードが再起動されると、ceph-nfs サービスは永続的に失敗します。

回避策: コントローラーノードを再起動する場合は、コントローラーノードにログインして /var/run/ceph ディレクトリーを作成します。

$ mkdir -p /var/run/ceph

再起動されたすべてのコントローラーノードでこの手順を繰り返します。ceph-nfs-pacemaker サービスが失敗としてマークされている場合は、ディレクトリーを作成した後、いずれかのコントローラーノードから以下のコマンドを実行します。

$ pcs resource cleanup

現在、Logrotate がすべてのログファイルを 1 日 1 回アーカイブすると、rsyslog は Elasticsearch へのログの送信を停止します。

回避策: Rsyslog がログローテーション時にすべてのログファイルを再度開くように、デプロイメント中に環境ファイルに "RsyslogReopenOnTruncate: true" を追加します。

現在、RHOSP 17.1 には puppet-rsyslog モジュールが同梱されているため、director で rsyslog が正しく設定されません。

回避策: デプロイする前に、/usr/share/openstack-tripleo-heat-templates/deployment/logging/rsyslog-container-puppet.yaml のパッチ [1] を手動で適用して Rsyslog を正しく設定します。

[1] https://github.com/openstack/tripleo-heat-templates/commit/ce0e3a9a94a4fce84dd70b6098867db1c86477fb

DVR が有効で VLAN テナントネットワークを使用する ML2/OVN または ML2/OVS を備えた RHOSP 環境では、異なるテナントネットワークに接続されたインスタンス間の East/West トラフィックがファブリックにフラッディングされます。

その結果、それらのインスタンス間のパケットは、それらのインスタンスが実行されている Compute ノードだけでなく、他のオーバークラウドノードにも到達します。

これはネットワークに影響を与える可能性があり、ファブリックがトラフィックをあらゆる場所に送信するため、セキュリティー上のリスクとなる可能性があります。

このバグは、今後の FDP リリースで修正される予定です。FDP 修正を入手するために RHOSP 更新を実行する必要はありません。

現在、RHEL 9.2 の Retbleed 脆弱性軽減策により、Intel Skylake CPU 上の Data Plane Development Kit (OVS-DPDK) を使用した Open vSwitch のパフォーマンスが低下する可能性があります。

パフォーマンスの低下は、BIOS で C-states が無効、およびハイパースレッディングが有効になっており、さらに OVS-DPDK が特定のコアのハイパースレッドを 1 つだけ使用している場合にのみ発生します。

回避策: NFV 設定ガイドで推奨されているように、コアの両方のハイパースレッドを OVS-DPDK または DPDK が実行されている SRIOV ゲストに割り当てます。

セキュリティーグループの過剰なログエントリーをバッファーするロギングキューは、指定された制限に達する前にエントリーの受け入れを停止することがあります。回避策として、キューの長さを保持したいエントリー数よりも長く設定できます。

NeutronOVNLoggingRateLimit パラメーターを使用して、1 秒あたりのログエントリーの最大数を設定できます。ログエントリーの作成がそのレートを超える場合、超過分は NeutronOVNLoggingBurstLimit で指定したログエントリー数までキューにバッファーされます。

この問題は、バーストの最初の 1 秒で特に顕著です。60 秒などの長いバーストでは、レート制限の影響が大きくなり、バースト制限の不正確さを補填します。したがって、この問題は短いバーストに最大の比例負荷をもたらします。

回避策: NeutronOVNLoggingBurstLimit をターゲット値よりも高い値に設定します。経過を観察し、必要に応じて調整します。

UDP プールの TCP ヘルスモニターは、モニターで使用されるポート番号によっては期待どおりに動作しない場合があります。また、プールメンバーとヘルスモニターのステータスも正しくありません。これは、UDP プールの特定のポート番号で TCP ヘルスモニターの使用を妨げる SELinux ルールが原因で発生します。

回避策 (ある場合): 現時点では回避策はありません。

OVN メカニズムドライバーを備えた RHOSP 17.1 は、ポートごとのフローイベントのロギングや、network log create コマンドの --target オプションの使用をサポートしていません。

RHOSP 17.1 は、network log create コマンドの --resource オプションを使用して、セキュリティーグループごとのフローイベントのロギングをサポートします。RHOSP によるネットワーク の「セキュリティーグループアクションのログ記録」を参照してください。

RHOSP 17.1 GA では、セキュアなロールベースのアクセス制御 (sRBAC) が有効になっている場合、DNS サービス (designate) が誤って設定されます。現在の sRBAC ポリシーには、designate に関する誤ったルールが含まれているため、designate が正しく機能するには修正する必要があります。考えられる回避策は、アンダークラウドサーバーに次のパッチを適用し、オーバークラウドを再デプロイすることです。

https://review.opendev.org/c/openstack/tripleo-heat-templates/+/888159

RHOSP 17.1 には一時的なパケット損失の既知の問題があり、ハードウェア割り込み要求 (IRQ) が原因で OVS-DPDK PMD スレッドまたは DPDK アプリケーションを実行しているゲストで非自発的なコンテキストスイッチが発生します。

この問題は、デプロイメント中に多数の VF をプロビジョニングすると発生します。VF には IRQ が必要で、それぞれが物理 CPU にバインドされている必要があります。IRQ の容量を処理するのに十分なハウスキーピング CPU がない場合、irqbalance はすべての IRQ のバインドに失敗し、分離された CPU で IRQ がオーバーフローします。

回避策: 次のアクションを 1 つ以上試してください。

DNS サービス (designate) を実行する RHOSP 17.1 では、設定が変更された場合に、bind9 サービスと unbound サービスが再起動されないという既知の問題があります。

回避策: 各コントローラーで次のコマンドを実行して、コンテナーを手動で再起動します。

$ sudo systemctl restart tripleo_designate_backend_bind9
$ sudo systemctl restart tripleo_unbound

RHOSP DNS サービス (designate) を実行する IPv6 ネットワークを使用する RHOSP 17.1.1 環境では、BIND 9 バックエンドサーバーが DNS 通知メッセージを拒否する可能性があります。この問題は、同じインターフェイス上の同じネットワークに複数の IP アドレスが存在することが多く、メッセージが指定されたワーカーサービス以外のソースから発信されているように見えることが原因で発生します。

回避策: 以下のパッチを適用します。

現在、以下のデプロイメントアーキテクチャーでは Multi-RHEL はサポートされていません。

RHOSP 16.2 から 17.1 GA へのインプレースアップグレードを実行する際の既知の問題があります。収集エージェント collectd-sensubility は、RHEL 8 Compute ノードで実行できません。

回避策: 影響を受けるノードでファイル /var/lib/container-config-scripts/collectd_check_health.py を編集し、26 行目の "healthy: .State.Health.Status}" を "healthy: .State.Healthcheck.Status}"/ に置き換えます。

ML2/OVN メカニズムドライバーを使用する RHOSP 17.1 GA 環境では、Floating IP ポート転送が正しく機能しないという既知の問題があります。この問題は、FIP 使用時に VLAN およびフラットネットワークが north-south ネットワークトラフィックを分散させ、代わりに FIP ポート転送をコントローラーノードまたはネットワーカーノードに集中させる必要があるために発生します。

回避策: この問題を解決し、集中型ゲートウェイノード経由で FIP ポート転送を強制するには、RHOSP オーケストレーションサービス (heat) パラメーター NeutronEnableDVR を false に設定するか、VLAN またはフラットプロジェクトネットワークの代わりに Geneve を使用します。

この RHOSP リリースには、iavf ドライバーで Intel X710 および E810 シリーズのコントローラー仮想機能 (VF) を使用する SR-IOV インターフェイスで、リンクステータスのフラッピングを伴うネットワーク接続の問題が発生する可能性があるという既知の問題があります。影響を受けるゲストカーネルのバージョンは次のとおりです。

メタデータエージェントが誤動作している HAProxy 子コンテナーを起動しようとして複数回失敗すると、メタデータサービスが利用できなくなることがあります。メタデータエージェントは、`ProcessExecutionError: Exit code: 125; Stdin: ; Stdout: Starting a new child container neutron-haproxy-ovnmeta-<uuid>” のようなエラーメッセージをログに記録します。

回避策: podman kill <_container name_> を実行して、問題のある haproxy 子コンテナーを停止します。

OVNAvailabilityZone Role パラメーターは予想通りに認識されないため、OVN でアベイラビリティーゾーン設定が失敗します。

回避策: OVNCMSOptions パラメーターを使用して、OVN アベイラビリティゾーンを設定します。以下に例を示します。

ControllerParameters:
  OVNCMSOptions: 'enable-chassis-as-gw,availability-zones=az1'

動的ルーティングを使用する RHOSP 17.1 環境では、RHOSP 17.1.1 への更新が正しく機能しません。具体的には、Free Range Routing (FRR) コンポーネントは更新されません。

回避策: RHOSP 17.1 を更新する前に、アンダークラウドに次のパッチを適用します。

ヘルスモニターを備えた OVN プロバイダードライバーで負荷分散サービス (octavia) を使用する RHOSP 17.1.1 環境では、プールの負荷分散ステータスで偽りのメンバーが誤って ONLINE と表示されます。ヘルスモニターが使用されていない場合、ステータスが偽りのメンバーは NO_MONITOR という通常の動作を表示します。

偽りの負荷分散プールメンバーは、メンバーの IP アドレスにタイプミスがある場合など、メンバーが無効な場合に発生する可能性があります。プールに設定されたヘルスモニターは偽りのメンバーに対してヘルスチェックを実行せず、グローバル動作ステータスはプールのステータスを計算するときに偽りのメンバーを誤って ONLINE と見なします。さらに、プール内の他のすべてのメンバーが ERROR 動作ステータスにある場合、プールのメンバーは誤った ONLINE ステータスを持つ偽りのメンバーであるため、プールには ERROR ではなく誤った DEGRADED 動作ステータスが割り当てられます。

回避策: 現時点では、この問題に対する回避策はありません。

ネットワークサービス (neutron) では、ネットワークプロファイルがルーターによって使用されているフレーバーの一部である場合でも、ネットワークプロファイルを無効にしたり削除したりすることができます。プロファイルを無効化または削除すると、ルーターの適切な動作が中断される可能性があります。

回避策: ネットワークプロファイルを無効化または削除する前に、そのプロファイルが現在ルーターで使用されているフレーバーの一部ではないことを確認してください。