3.2. Red Hat OpenStack Platform 17.1.2 メンテナンスリリース - 2024 年 1 月 16 日

この更新により、OVS メカニズムドライバーから OVN メカニズムドライバーへの移行中に IPv6 経由のインスタンスへの接続が中断される問題が修正されます。

インスタンスの接続を中断させることなく、IPv6 を使用して OVS から OVN に移行できるようになりました。

この更新により、すべてのコントローラーノードの再起動後に ceph-nfs サービスが失敗する原因となったバグが修正されます。

Pacemaker によって制御される ceph-nfs リソースには、一部のプロセスデータを保存するためのランタイムディレクトリーが必要です。

この更新の前は、RHOSP をインストールまたはアップグレードしたときにディレクトリーが作成されていました。しかし、コントローラーノードが再起動すると、ディレクトリーが削除されました。また、コントローラーノードが再起動しても、ceph-nfs サービスが回復しませんでした。すべてのコントローラーノードが再起動すると、ceph-nfs サービスが永続的に失敗していました。

この更新により、ceph-nfs サービスが生成される前にディレクトリーが作成され、cephfs-nfs サービスが再起動後も維持されるようになりました。

この更新により、ベアメタルノードを再起動した後に collectd sensubility が動作しなくなる原因となっていた権限の問題が修正されます。

ベアメタルノードを再起動した後も、collectd sensubility が機能し続けるようになりました。

この更新により、NeutronOVNLoggingRateLimit で設定された制限に達する前に、セキュリティーグループのロギングキューが時々エントリーの受け入れを停止する問題が修正されます。

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

この更新の前は、短いバースト中に、NeutronOVNLoggingBurstLimit で指定された制限に達する前に、キューがエントリーの受け入れを停止することがありました。

この更新により、NeutronOVNLoggingBurstLimit 値が予想どおりキュー制限に適用されるようになりました。

この更新の前は、puppet-ceilometer が Compute ノードの ceilometer 設定に tenant_name_discovery パラメーターを設定しませんでした。これにより、Project name と User name フィールドを識別できなくなりました。

この更新により、puppet-ceilometer の Compute 名前空間に tenant_name_discovery パラメーターが追加され、問題が解決されました。tenant_name_discovery パラメーターが true に設定されている場合、Project name フィールドと User name フィールドに値が入力されます。

今回の更新で、元の ML2/OVS 環境が iptables_hybrid ファイアウォールおよびトランクポートを使用した場合に、OVN メカニズムドライバーへの移行後に問題が発生するバグが修正されました。

以前は、元の ML2/OVS 環境で iptables_hybrid ファイアウォールとトランクポートが使用されていた場合、ハードリブート、起動、停止、またはノードの再起動などのイベント後にトランクを持つインスタンスを再作成すると、インスタンスのネットワークの問題が発生しました。

元の ML2/OVS 環境で iptables_hybrid ファイアウォールおよびトランクポートを使用している場合は、OVN メカニズムドライバーに移行しないでください。

以前は、RHEL 9.2 で Compute ノードを RHOSP 17.1 にアップグレードした後、nova_virtlogd コンテナーが期待どおりに ubi 8 から ubi 9 に更新されませんでした。コンテナーは、Compute ノードを再起動した後にのみ更新されました。

現在は、RHOSP のアップグレード前に、nova_virtlogd コンテナーが ubi 9 に更新されます。なお、RHOSP の今後の更新では、virtlogd コンテナーに変更を加えた後に Compute ノードを再起動する必要があります。再起動するとワークロードログにアクセスできなくなるためです。

この更新の前は、openstack overcloud deploy が OVNAvailabilityZone ロールパラメーターの値を OVS に渡しませんでした。

この更新により、OVNAvailabilityZone ロールパラメーターが、external-ids:ovn-cms-options の availability-zones 値として値を正しく渡すようになりました。

次の例は、環境ファイル内のパラメーターを使用して OVNAvailabilityZone を設定する方法を示しています。デプロイコマンドに環境ファイルを含めてください。

ControllerParameters:
  OVNAvailabilityZone: 'az1'

デプロイすると、availability-zones=az1 が OVS external-ids:ovn-cms-options に追加されます。

この更新により、OVS メカニズムドライバーから OVN メカニズムドライバーへの移行後、VXLAN から Geneve に変更されたテナントネットワークに間違った MTU 値が設定されるバグが修正されます。この更新の前は、cloud-init パッケージが DHCP サーバーによって正しく設定された値をオーバーライドしていました。

たとえば、VXLAN を使用する OVS メカニズムドライバーから、1442 MTU の Geneve を使用する OVN メカニズムドライバーに移行すると、cloud-init が MTU を 1500 にリセットしていました。

この更新により、DHCP サーバーによって設定された値が維持されるようになりました。

RHOSP 17.1 では、オフロードされたトラフィック/フローの NIC ハードウェアにおける負荷分散を可能にする VF-LAG 送信ハッシュポリシーをオフロードするテクノロジープレビューが利用可能です。このハッシュポリシーは、レイヤー 3+4 のベースハッシュでのみ使用できます。

テクノロジープレビュー機能を使用するには、次の例に示すように、xmit ハッシュポリシーを有効にするボンディングオプションパラメーターがテンプレートに含まれていることを確認します。

bonding_options: "mode=802.3ad miimon=100 lacp_rate=fast xmit_hash_policy=layer3+4"

1 つの物理機能 (PF) ごとに作成される仮想機能 (VF) が非常に多いと、RHOSP のデプロイが失敗する可能性があります。NetworkManager がそれらすべてに対して DHCP 要求を発行するため、NetworkManager サービスで障害が発生します。

たとえば、この問題は、4 つの PF に対して 256 の VF がデプロイ中に作成された場合に発生しました。

回避策: PF ごとに作成される VF の数が多くなりすぎないようにします。

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

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

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

回避策: 現時点では回避策はありません。

サブネットが Load-balancing サービス (octavia) アベイラビリティーゾーンにないロードバランサーメンバーを追加すると、ロードバランサーが ERROR になります。ERROR ステータスが原因でメンバーを削除できないため、ロードバランサーが使用できなくなります。

回避策: ロードバランサーを削除します。

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 ゲストに割り当てます。

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

RHOSP 17.1 は、network log create コマンドの --resource オプションを使用して、セキュリティーグループごとのフローイベントのロギングをサポートします。詳細は、Red Hat OpenStack Platform ネットワークの設定 の セキュリティーグループアクションのロギング を参照してください。

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

ML2/OVN メカニズムドライバーを使用する RHOSP 17.1 GA 環境では、Floating IP ポート転送が正しく機能しません。

FIP ポート転送は、コントローラーノードまたはネットワーカーノードに集中させる必要があります。しかし、FIP を使用すると、VLAN およびフラットネットワークが north-south ネットワークトラフィックを分散します。

回避策: この問題を解決し、集中型ゲートウェイノード経由で 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 子コンテナーを停止します。

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

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

Ceph Dashboard が Prometheus サービスエンドポイントに到達できず、404 not found エラーメッセージが表示されます。このエラーは、Prometheus サービスの仮想 IP の設定が正しくないために発生します。

回避策:

一部の AMD 環境では、組み込まれているカーネル引数 console=ttyS0 が原因で、overcloud-hardened-uefi-full.raw イメージを使用してプロビジョニングすると起動に失敗します。その結果、ブートシーケンスが、診断メッセージもエラーメッセージも表示されずに停止します。

回避策: 次のコマンドを実行してオーバークラウドイメージを編集します。

sudo yum install guestfs-tools -y

sudo systemctl start libvirtd

sudo virt-customize -a /var/lib/ironic/images/overcloud-hardened-uefi-full.raw \
    --run-command "sed -i 's/console=ttyS0 //g' /etc/default/grub" \
    --run-command "grub2-mkconfig -o /boot/grub2/grub.cfg" \
    --run-command "grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg"

これらのコマンドを実行した後、provision コマンドを使用して AMD ノードをプロビジョニングできます。

以前のバージョンの Load-balancing サービス (octavia) ヘルスモニターポートを含む RHOSP 17.1.2 環境で neutron-db-sync-tool を実行すると、それらの既存のポートまたは OVN メタデータポートがランダムに削除される可能性があります。この意図しないポートの削除により、ヘルスモニターの容量が失われるか、影響を受けるインスタンスとの通信が失われます。

回避策: 既存の Load-balancing サービスヘルスモニターポートの 'device_owner' フィールドを、ovn-lb-hm:distributed という値に手動で更新します。これにより、neutron-db-sync-tool が起動した場合に、ヘルスモニターや OVN メタデータポートが悪影響を受けないようになります。

複数のファイルシステムを持つ外部 Ceph クラスターがデプロイメントにある場合、期待どおりに Shared File System サービス (Manila) 共有を作成できません。

この状況を回避するために必要な cephfs_filesystem_name ドライバー設定パラメーターは、director の heat テンプレートパラメーターを使用して設定できません。

回避策: "cephfs_filesystem_name" パラメーターを設定して、Shared File System サービス (Manila) が "ExtraConfig" を介して使用する必要があるファイルシステムを指定します。

次の例に示すように、パラメーターを環境ファイルに追加します。

$ cat /home/stack/manila_cephfs_customization.yaml
parameter_defaults:
  ExtraConfig:
    manila::config::manila_config:
      cephfs/cephfs_filesystem_name:
        value: <filesystem>

<filesystem> の値は、適切な名前に置き換えます。この環境ファイルを openstack overcloud deploy コマンドに含めてください。

director のバグにより、RHOSP 17.1 バージョンへの更新またはアップグレード中に、クライアントのワークロードが中断またはクラッシュする可能性があります。このバグは、CephFS-via-NFS バックエンドを使用した RHOSP Shared File Systems サービス (manila) を有効にするデプロイメントに影響します。

このバグにより、更新またはアップグレード操作中に Ceph NFS エクスポート情報が削除されます。このエクスポート情報は、ユーザーが共有に "アクセスルール" を設定するときに、Shared File System サービス (manila) によって作成されます。

NFS サーバーが回復モードになると、NFS 共有に対してアクティブに読み取りまたは書き込みを行っていたクライアントのワークロードがハングし、最終的にはクラッシュする可能性があります。

回避策: Manila shares with Red Hat OpenStack 17.1 can be abruptly disconnected due to export information loss を参照してください。