リリースノート

この更新により、Red Hat の Multi-RHEL サポートが拡張され、次のデプロイメントアーキテクチャーが含まれるようになりました。

この更新の前は、コンテナー設定が変更されていない場合でも、コンピュートノード上の libvirt 関連のコンテナーは、デプロイメント、更新、スケーリング操作中に不必要に再起動されていました。

この更新により、設定変更のない libvirt 関連のコンテナーは、デプロイメント、更新、およびスケーリング操作中に再起動されなくなります。

この更新の前は、アップグレード中に Red Hat Ceph Storage の導入が成功するたびに、ceph-ansible パッケージがデフォルトで削除されていました。

この更新では、ceph-ansible を削除するタスクに cleanup_cephansible タグが導入されています。削除を回避するには、採用 Playbook の実行中に --skip-tags とともにこのタグを使用します。

この更新の前は、複数のスタックを持つセットアップ上のノードの DCN FFU システムアップグレード中に、Red Hat Ceph Storage タスクの Set noout flag が適切なホストで ceph コマンドを実行できないことがありました。

更新後、マルチスタック設定内の任意のノードでシステムをアップグレードすると、Red Hat Ceph Storage タスクの Set noout flag が関連するホストに委任され、ceph コマンドが特定のクラスターで実行されるようになりました。

この更新では、ロードバランシングサービス (octavia) ヘルスモニターポートと OVN メタデータポートが意図せず削除されるバグが修正されています。

この更新の前は、以前のバージョンのロードバランシングサービスのヘルスモニターポートを使用していた RHOSP 環境では、neutron-db-sync-tool を実行すると、既存のポートまたは OVN メタデータポートがランダムに削除されることがありました。この意図しないポートの削除により、ヘルスモニターの容量が失われたり、影響を受けるインスタンスとの通信が失われたりしました。

この更新により競合が解決されます。OVN ロードバランシングサービスのヘルスモニターポートの device_owner フィールドに新しい値 ovn-lb-hm:distributed を使用します。古い OVN ロードバランシングサービスのヘルスモニターポートは、このバージョンで自動的に更新されます。

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

この更新によりこの問題は解決され、ユーザーが共有に "アクセスルール" を設定した場合に、Shared File System サービス (manila) が適切に動作するようになりました。

この更新前は、ユーザーが文書化されたアップグレード手順に従わなかった場合、FFU 手順で誤った Red Hat Ceph Storage イメージが使用されることがありました。

この更新により、FFU 手順では常に正しい Red Hat Ceph Storage イメージが使用されるようになりました。multi-rhel-container-image-prepare.py スクリプトは正しいデフォルトを使用するように更新され、バージョン検証チェックが FFU プロセスに追加されました。

この更新では、ML2/OVN 環境の IPv6 ネットワーク上の一部のロードバランシングサービス (octavia) プールメンバーでトラフィックのロードバランシングが妨げられるバグが修正されます。

この更新の前は、プールに 2 番目の listener+pool+member を追加すると、プールは ERROR 状態になり、そのプール内のトラフィックは負荷分散されませんでした。

この更新により、トラフィックは期待どおりにすべてのメンバーに負荷分散されます。

この更新は、アップグレード後にワークロードの中断を引き起こす可能性のある libvirt 設定での RHOSP 16.2 から RHOSP 17.1 へのアップグレードを防ぎます。

この更新前は、Red Hat Enterprise Linux (RHEL) 8 上の libvirt のモジュール式デプロイメントが含まれているか、RHEL 8 上で libvirt UBI9 を実行している RHOSP 16.2 環境から RHOSP 17.1 へのアップグレードを実行した場合、これらの設定によってワークロードが中断されることがありました。

この更新により、RHOSP 16.2 環境に Red Hat Enterprise Linux (RHEL) 8 上の libvirt のモジュール式デプロイメントが含まれている場合、または RHEL 8 上で libvirt UBI9 を実行している場合、RHOSP 16.2 から 17.1 へのアップグレードは失敗します。

この更新では、ML2/OVN デプロイメントの IPv6 ネットワーク上で OVN Health Monitoring for Load-balancing サービス (octavia) の操作を妨げるバグを修正しました。

以前は、OVN ヘルスモニターサービスは、バックエンドメンバーの ONLINE および OFFLINE ステータスを正しく識別していませんでした。

この更新により、負荷分散が期待どおりに機能し、OVN ヘルスモニターはバックエンドメンバーの ONLINE および OFFLINE ステータスを正しく識別します。

この更新の前は、RHOSP 17.1 へのアップグレード中および 17.1 のマイナーバージョン間の更新中に、ML2/OVN メカニズムドライバーを使用する Networking サービス (neutron) 環境では、一定期間、OVN データベースからの更新の受信が停止していました。RAFT リーダーを含むコントローラーノードも更新されると、メカニズムドライバーは OVN データベースから更新を受信します。

今回の更新で、この問題が修正されています。現在、RHOSP の更新およびアップグレード中に、ML2/OVN メカニズムドライバーを使用する Networking サービスが適切に動作するようになりました。

RHOSP 17.1.3 では、Open Virtual Network (OVN) バージョン 23.09 に含まれる localnet_learn_fdb オプションを通じて学習された MAC アドレスの新しいエージングメカニズムがサポートされるようになりました。この新しいエージングメカニズムは、fdb_age_thhreshold と fdb_removal_limit という 2 つの新しいオプションで設定されています。

fdb_age_thhreshold オプションを使用すると、学習した MAC が FDB テーブルに留まる最大時間 (秒単位) を設定できます。

fdb_removal_limit オプションは、OVN が一度に大量の FDB テーブルエントリーを削除することを防ぎます。

これらの新しいオプションを localnet_learn_fdb で使用すると、大規模なプロバイダーネットワークを持つ RHOSP 環境でよく発生する問題である、FDB テーブルが大きくなりすぎることによるパフォーマンスとスケーラビリティーの問題が発生する可能性が軽減されます。

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

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

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

現在、BGP 動的ルーティングを使用する RHOSP 17.1 環境では、RHOSP コンピュートサービスはこれらのインスタンスのいずれかから送信されたパケットをマルチキャスト IP アドレスの宛先にルーティングできません。したがって、マルチキャストグループに登録されているインスタンスは、送信されたパケットを受信できません。原因は、BGP マルチキャストルーティングがオーバークラウドノードで適切に設定されていないことです。

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

サブネットが 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 つだけ使用している場合にのみ発生します。

回避策:ネットワーク機能仮想化の設定 で推奨されているように、両方の論理コアを OVS-DPDK または DPDK が実行している SR-IOV ゲストに割り当てます。

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

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

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

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

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

回避策:

複数のファイルシステムを持つ外部 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 コマンドに含めてください。

libvirt での cgroups の管理方法は、RHEL リリース間で変更されました。その結果、virsh cpu-stats は Red Hat OpenStack Platform (RHOSP) 製品で公式にサポートされている部分ではありません。この機能は、RHEL から受信した libvirt の基盤となるバージョンによって提供されます。Greenfield RHOSP 17.x は、cgroups v2 を使用する RHEL 9 でのみサポートされます。cgroups v2 API は、virsh cpu-stats API をサポートするために必要な API を提供しないため、RHEL 9 で 17.1 を使用する場合、この機能は使用できません。

RHEL 16.2 からの混合 RHEL アップグレード中にサポートされる RHEL 8 上の RHOSP 17.1 が更新され、rhel 8.4 で実行中に virsh cpu-stats が機能するようになりました。その結果、virsh cpu-stats 機能は RHEL 8 ホスト上で復元されましたが、完全にアップグレードされた RHEL 9 ホスト上では使用できません。

Lenovo SR650 サーバーを使用する環境で RHOSP 16.2 を 17.1 にアップグレードすると、サーバーは最初の起動時に失敗し、有効な起動デバイスが不足していることを示すブルースクリーンが表示されます。

この問題は、Lenovo UEFI ファームウェアがデプロイメント後にブートレコードをリセットすることによって発生します。RHOSP director は、UEFI ファームウェア設定に 2 つの変更を要求します。ただし、Lenovo ハードウェアは再起動前に 1 つの要求しか処理できません。

回避策: Lenovo サーバーを手動で再起動して、目的のオペレーティングシステムに戻す必要があります。

動的ルーティングと、OVN プロバイダードライバーを使用した OpenStack ロードバランシングサービス (octavia) を使用する RHOSP 17.1 環境では、ロードバランシング仮想 IP が削除されるという既知の問題があります。削除は、OVN BGP エージェントとロードバランシングサービスを同期するプロセスによって発生します。

回避策: 回避策としては、調整間隔を非常に高い値に増やします。カスタム環境 YAML ファイルを作成し、次の値を追加します。

parameter_defaults:
  FrrOvnBgpAgentReconcileInterval: 999999

詳細は、4.11. スパイン/リーフ対応のオーバークラウドのデプロイ を参照してください。

動的ルーティングを使用する RHOSP 環境では、マイナー更新中に、Free Range Routing (FRR) が 2 回連続して再起動されます。これは、次のシナリオでの更新中に発生します。

この更新により、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 フィールドに値が入力されます。

以前は、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 を参照してください。

今回の更新により、ブートストラップコントローラーノードの置き換え後に 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) では、ネットワークプロファイルがルーターによって使用されているフレーバーの一部である場合でも、ネットワークプロファイルを無効にしたり削除したりすることができます。プロファイルを無効化または削除すると、ルーターの適切な動作が中断される可能性があります。

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

この更新までは、ベアメタルのオーバークラウドノードは削除後も metalsmith ツールによってアクティブとしてリストされていました。これは、ノードの命名スキームがオーバークラウドのロール命名スキームと重複している環境で発生し、アンデプロイ時に間違ったノードのプロビジョニングが解除される可能性がありました。metalsmith ツールは最初に割り当て名 (ホスト名) を使用してベアメタルノードのステータスを検索するため、削除済みノードがアクティブとして検出されることがありました。

今回の更新により、プロビジョニングが解除されるノードは割り当て名 (ホスト名) で参照されるようになり、常に正しいノードのプロビジョニングが解除されるようになります。つまりノードは、ホスト名が存在しない場合に限りノード名で参照されます。

この更新までは、データベースが宛先ホストの詳細で更新されなかったため、ライブマイグレーションが失敗する可能性がありました。

今回の更新により、ライブマイグレーション中に、データベース内のインスタンスホストの値が宛先ホストに設定されます。

この更新までは、ロードバランサー仮想 IP (VIP) に関連付けられた Floating IP (FIP) を使用している場合、Open Virtual Network (OVN) ロードバランサーのヘルスチェックは実行されず、FIP を使用している場合はトラフィックがエラー状態のメンバーにリダイレクトされていました。

この更新により、Load Balancer Virtual IP (VIP) に関連付けられた Floating IP (FIP) を使用する場合、FIP 用に新しいロードバランサーヘルスチェックが作成され、トラフィックはエラー状態のメンバーにリダイレクトされなくなります。

この更新までは、/home/stack/config-download/overcloud/cephadm の cephadm-ansible ログはローテーションされませんでした。cephadm_command.log はオーバークラウドデプロイメントごとに追加され、サイズが増加しました。また、openstack overcloud ceph spec 操作ごとに、ログ /home/stack/ansible.log はローテーションされませんでした。

現在、すべてのオーバークラウドデプロイメントとすべての Ceph spec 操作に対して、日付ありのログが次の形式で生成されます。

この更新までは、Compute サービス (nova) は、仮想マシンディスク (VMDK) イメージファイルの内容の信頼性チェックを行いませんでした。特別に作成された VMDK イメージを使用すると、ホストファイルシステム上の機密ファイルが、その VMDK イメージで起動されたゲストに公開される可能性がありました。今回の更新により、Compute サービスが VMDK ファイルの信頼性をチェックし、リーク動作が依存する VMDK 機能が禁止されます。つまり、悪用目的で作成された VMDK ファイルを使用して、ホストファイルシステムの機密性の高いコンテンツをリークすることは不可能になります。このバグ修正は、CVE-2022-47951 に対処するものです。

この更新までは、rgw_max_attr_size のデフォルト値は 256 で、大きなイメージをアップロードするときに OpenStack 上の OpenShift で問題が発生していました。今回の更新により、rgw_max_attr_size のデフォルト値は 1024 になりました。

値を変更するには、オーバークラウドデプロイメントに含める環境ファイルに次の設定を追加します。

parameters_default:
  CephConfigOverrides:
    rgw_max_attr_size: <new value>

この更新までは、OVS インターフェイスのネットワーク設定のリグレッションがネットワークパフォーマンスに悪影響を及ぼしていました。今回の更新により、os-vif OVS プラグインが強化され、非 Windows インスタンスの OVS インターフェイスにおけるネットワークパフォーマンスが向上しました。

この更新までは、RHOSP 動的ルーティングを使用する RHOSP 17.1 環境では、OVN BGP エージェントが使用する Autonomous System Number (ASN) のデフォルト値が FRRouting (FRR) が使用する ASN と異なるという既知の問題がありました。

17.1 GA では、この問題は解決されています。FrrOvnBgpAgentAsn および FrrBgpAsn のデフォルト値は有効であり、変更せずに使用できます。

このリリースより前は、hw_machine_type イメージプロパティーを持たないインスタンスのマシンタイプは、ハードリブートまたは移行後に新しく設定されたマシンタイプを使用するため、RHOSP デプロイメントの有効期間中に NovaHWMachineType を変更できませんでした。インスタンスの基盤となるマシンタイプを変更すると、インスタンスの内部 ABI が破損する可能性があります。

今回のリリースでは、インスタンスの起動時に、Compute サービスがインスタンスのシステムメタデータ内にインスタンスのマシンタイプを記録します。そのため、既存インスタンスのマシンタイプに影響を及ぼすことなく、RHOSP デプロイメントの有効期間中に NovaHWMachineType を変更できるようになりました。

今回の更新では、セキュリティーグループのロギングが導入されます。インスタンスに出入りするトラフィックフローと試行を監視するには、セキュリティーグループのネットワーキングサービスパケットログを設定できます。

インスタンスポートを 1 つ以上のセキュリティーグループに関連付け、各セキュリティーグループに 1 つ以上のルールを定義できます。たとえば、ファイナンスセキュリティーグループ内の任意のインスタンスにインバウンド SSH トラフィックをドロップするルールを作成できます。さらに、そのグループ内のインスタンスが ICMP (ping) メッセージを送信および応答できるようにするために、別のルールを作成できます。

次に、パケットロギングを設定して、受け入れられたパケットフローとドロップされたパケットフローの組み合わせを記録できます。

セキュリティーグループのロギングは、ステートフルセキュリティーグループとステートレスセキュリティーグループの両方に使用できます。

ログに記録されたイベントは、インスタンスをホストする Compute ノードの /var/log/containers/stdouts/ovn_controller.log ファイルに保存されます。

この機能拡張は、クラウドユーザーがアクティブなインスタンスにアクセスできない理由が、インスタンスをホストする Compute ノードに到達できないためかどうかを判断するのに役立ちます。RHOSP 管理者は、次のパラメーターを設定できるようになりました。これにより、クラウドユーザーが openstack showserverdetails コマンドを実行する際にホストの Compute ノードに到達できない場合は host_status フィールドにステータスを入力するカスタムポリシーを有効にできます。

今回の更新により、個別のセルデータベースからリソースをカウントする代わりに、API データベースのインスタンスマッピングからリソース使用量とインスタンスの配置をクエリーすることで、コアと RAM のクォータ使用量をカウントするように、RHOSP デプロイメントを設定できます。これにより、一時的なセルの停止やマルチセル環境でのセルのパフォーマンス低下に対して、割り当て使用量のカウントが回復します。

次の設定オプションを設定して、配置から割り当て使用量をカウントします。

parameter_defaults:
  ControllerExtraConfig:
    nova::config::nova_config:
      quota/count_usage_from_placement:
        value: 'True'

今回の更新により、バックアップおよび復元手順のワークフローで検証フレームワークを使用して、復元されたシステムのステータスを検証できるようになります。これには、次の検証が含まれています。

この機能拡張により、クラウド管理者は、Shared File Systems サービス (manila) バックエンドストレージを設定するときに、director を介してストレージバックエンドごとにアベイラビリティゾーン (AZ) を指定できるようになります。

今回の更新により、管理者は AZ アノテーションを使用してストレージプロビジョニング要求を論理的に分離し、障害ドメインを示すことができます。管理者によって設定された AZ は、Shared File Systems サービスによってエンドユーザーに公開されます。エンドユーザーは、必要に応じてワークロードを特定の AZ にスケジュールするように要求できます。複数のストレージバックエンドを設定する場合、管理者は、すべてのバックエンドに対して単一の AZ を示すのではなく、各バックエンドに対して異なる AZ をタグ付けする場合もあります。

director には、ストレージ AZ を示す新しいオプションがあります。各オプションは、サポートされているストレージバックエンドドライバーに対応します。AZ の詳細は、永続ストレージの設定 を参照してください。

今回の更新により、それぞれのフェンシングリソースを定義することで、tripleo を介した他のフェンシングデバイスと同様に、sbd を使用する fence_watchdog を設定できるようになります。

parameter_defaults:
  EnableFencing: true
  FencingConfig:
    devices:
    - agent: fence_watchdog
      host_mac: 52:54:00:74:f7:51

operator は、sbd を有効にし、ウォッチドッグタイムアウトを設定する必要があります。

parameter_defaults:
  ExtraConfig:
    pacemaker::corosync::enable_sbd: true
    tripleo::fencing::watchdog_timeout: 20

この機能拡張により、ディスク全体のオーバークラウドイメージである overcloud-hardened-uefi-full.qcow2 によりインストールされた LVM ボリュームが、シンプールによってバックアップされるようになりました。ボリュームは、引き続き利用可能な物理ストレージを消費するために拡張されますが、デフォルトではオーバープロビジョニングされません。

シンプロビジョニングされた論理ボリュームの利点は次のとおりです。

この更新では、失敗したライブマイグレーションへの対処に影響を及ぼす可能性のある問題を修正するスクリプト neutron-remove-duplicated-port-bindings が導入されています。

ライブマイグレーションが失敗すると、Compute サービス (Nova) はマイグレーションを元に戻します。移行を元に戻すと、データベースまたは送信先コンピュートノードで作成されたオブジェクトが削除されます。

ただし、場合によっては、失敗したライブマイグレーションを元に戻した後もポートに重複したポートバインドが残ることがありました。

neutron-remove-duplicated-port-bindings スクリプトは、重複したポートバインディングを検出し、非アクティブのバインディングを削除します。ライブマイグレーションの失敗によりポートバインドが重複する場合は、スクリプトを実行できます。

この機能拡張により、operator は Pacemaker が管理する仮想 IP (VIP) の run_arping 機能を有効にして、クラスターが重複 IP を事前にチェックできます。

これを行うには、次の設定を環境ファイルに追加する必要があります。

  ExtraConfig:
    pacemaker::resource::ip::run_arping: true

重複が見つかった場合、次のエラーが /var/log/pacemaker/pacemaker.log ファイルに記録されます。

Sep 07 05:54:54  IPaddr2(ip-172.17.3.115)[209771]:    ERROR: IPv4 address collision 172.17.3.115 [DAD]
Sep 07 05:54:54  IPaddr2(ip-172.17.3.115)[209771]:    ERROR: Failed to add 172.17.3.115

今回の更新により、出力データ収集サービス (ceilometer) メトリクスにプロジェクト名フィールドとユーザー名フィールドを追加できるようになりました。これまでは、クラウド管理者はプロジェクトとユーザーの UUID に依存してテナントを識別する必要がありました。現在は、UUID ではなく、プロジェクトとユーザーの名前リストをを表示できるようになりました。

この機能拡張により、ユーザーは RHOSP 16.2 から RHOSP 17.1 にアップグレードし、RHEL 9 を実行しているノードと Red Hat Enterprise Linux (RHEL) 8 ベースのオペレーティングシステムの組み合わせを、Compute ノード上で維持できるようになります。

コントロールプレーンノードとストレージノードをアップグレードする必要があります。デフォルトの動作では、明示的に設定されていない限り、すべてのノードが RHEL 9 にアップグレードされます。

RHOSP のネットワーク環境では、仮想マシンインスタンスを作成する際に、インスタンスを仮想ポート (vport) にバインドしないでください。代わりに、IP アドレスが別のポートの許可するアドレスペアのメンバーではないポートを使用します。

vport をインスタンスにバインドすると、インスタンスが生成されなくなり、次のようなエラーメッセージが表示されます。

WARNING nova.virt.libvirt.driver [req-XXXX - - - default default] [instance: XXXXXXXXX] Timeout waiting for [('network-vif-plugged', 'XXXXXXXXXX')] for instance with vm_state building and task_state spawning.: eventlet.timeout.Timeout: 300 seconds

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

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

中断の可能性を回避するには、代わりに IPv4 を使用してください。

現時点において、ML2/OVS デプロイメントにおける Open vSwitch (OVS) は、skb_priority、skb_mark、または出力キューフィールドが設定されている OpenFlow ルールのオフロードをサポートしていません。これらのフィールドは、virtio ポートの Quality of Service (QoS) サポートに必要です。

virtio ポートに最小帯域幅ルールを設定すると、Networking サービス (neutron) OVS エージェントは、Packet Mark フィールドを使用してこのポートのトラフィックをマークします。その場合、このトラフィックはオフロードできず、他のポートのトラフィックに影響します。帯域幅制限ルールを設定すると、すべてのトラフィックがデフォルトの 0 キューでマークされます。これは、トラフィックをオフロードできないことを意味します。

回避策として、環境に OVS ハードウェアオフロードポートが含まれている場合は、ハードウェアオフロードが必要なノードでパケットマーキングを無効にします。パケットマーキングを無効にすると、virtio ポートのレート制限ルールは設定できなくなります。ただし、Differentiated Services Code Point (DSCP) のマーキングルールは引き続き使用できます。

設定ファイルで、disable_packet_marking フラグを true に設定します。設定ファイルを編集する場合、neutron_ovs_agent コンテナーを再起動する必要があります。以下に例を示します。

$ cat `/var/lib/config-data/puppet-generated/neutron/etc/neutron/plugins/ml2/openvswitch_agent.ini`
  [ovs]
  disable_packet_marking=True

RHOSP 17.1 では、DNS サービス (designate) がデプロイされている場合、オーバークラウドが削除されても、アンダークラウド上に作成された Networking サービス (neutron) ポートは削除されません。これらのポートは、DNS サービスの有無にかかわらず、オーバークラウドの再作成時に動作上の問題を引き起こしません。

回避策: オーバークラウドを削除した後、openstack port delete コマンドを使用してポートを手動で削除します。

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

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

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

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

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 へのログ送信を停止します。回避策: デプロイするときに環境ファイルに "RsyslogReopenOnTruncate: true" を追加して、Rsyslog がログローテーション時にすべてのログファイルを再度開くようにします。

現在、RHOSP 17.1 は、Rsyslog が正しく設定されていない古い puppet-rsyslog モジュールを使用しています。回避策: デプロイする前に、/usr/share/openstack-tripleo-heat-templates/deployment/logging/rsyslog-container-puppet.yaml のパッチ [1] を手動で適用して Rsyslog を正しく設定します。

現在、オフロード (switchdev) ポートを備えた Mellanox ConnectX-5、ConnectX-6、および Bluefield-2 NIC を使用するゲストインスタンスには既知の問題があります。たとえば、コマンド sudo systemctl reboot --reboot-arg=now を使用して、ゲストからオペレーティングシステムを直接再起動すると、システムの初期化に時間がかかります。インスタンスが同じ物理機能 (PF) の 2 つの仮想機能 (VF) で設定されている場合、VF の 1 つの初期化が失敗し、初期化時間が長くなる可能性があります。

回避策: ゲストインスタンスを直接再起動するのではなく、OpenStack API を使用してゲストインスタンスを適時に再起動します。

RHOSP 17.1 では、次の BIOS 設定を使用している場合、UEFI ブートモードを使用する一部の AMD プラットフォーム上での NFV デプロイメントで、オーバークラウドノードのプロビジョニングが失敗する場合があります。

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

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

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

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

現在、Dashboard サービス (horizon) はデフォルトでクライアント TLS 証明書を検証するように設定されているため、すべての TLS everywhere (TLS-e) デプロイメントでダッシュボードサービスが機能しません。

回避策:

現在、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 をターゲット値よりも高い値に設定します。経過を観察し、必要に応じて調整します。

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

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

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 つ以上試してください。

現在、ブートストラップコントローラーノードが交換されると、OVN データベースクラスターはパーティション化され、2 つのデータベースクラスターがノースバウンドデータベースとサウスバウンドデータベース用に作成されます。この状況ではインスタンスが使用できなくなります。

ブートストラップコントローラーノードの名前を確認するには、次のコマンドを実行します。

ssh tripleo-admin@CONTROLLER_IP "sudo hiera -c /etc/puppet/hiera.yaml pacemaker_short_bootstrap_node_name"

回避策: Red Hat KCS ソリューション 7024434: Recover from partitioned clustered OVN database で説明されている手順を実行します。

現在、以下のデプロイメントアーキテクチャーでは 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 インターフェイスで、リンクステータスのフラッピングを伴うネットワーク接続の問題が発生する可能性があるという既知の問題があります。影響を受けるゲストカーネルのバージョンは次のとおりです。

現在、ボリュームに Red Hat Ceph Storage (RHCS) バックエンドを使用すると、インスタンスの再起動が妨げられ、データ破損につながる可能性があるという既知の問題があります。これは、次の条件がすべて満たされる場合に発生します。

回避策: 上記の条件をすべて満たす in-use ボリュームの種別は変更しないでください。

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

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

RHOSP 17.1.0 GA を入手可能になった時点から数日以内にダウンロードすると、次の例に示すように、/etc/rhosp/release ファイル内のバージョン説明に誤ってベータ指定が含まれている場合があります。

(overcloud) [stack@undercloud-0 ~]$ cat /etc/rhosp-release
Red Hat OpenStack Platform release
17.1.0 Beta (Wallaby)

回避策: 使用している GA デプロイメントが影響を受ける場合は、# dnf -y update rhosp-release コマンドを実行します。

RHOSP 17.1.0 GA を入手可能になった時点から数日以内にダウンロードすると、次の例に示すように、/etc/rhosp/release ファイル内のバージョン説明に誤ってベータ指定が含まれている場合があります。

(overcloud) [stack@undercloud-0 ~]$ cat /etc/rhosp-release
Red Hat OpenStack Platform release
17.1.0 Beta (Ussri)

回避策: 使用している GA デプロイメントが影響を受ける場合は、# dnf -y update rhosp-release コマンドを実行します。

ML2/OVS メカニズムドライバーは、RHOSP 17.0 以降で非推奨になりました。

いくつかのリリースで、Red Hat は ML2/OVS を ML2/OVN に置き換えています。たとえば、RHOSP 15 以降では、ML2/OVN がデフォルトのメカニズムドライバーになりました。

非推奨の ML2/OVS メカニズムドライバーは、RHOSP 17 リリースでサポートされます。この間、ML2/OVS ドライバーはメンテナンスモードのままで、バグ修正と通常のサポートを受け、ほとんどの新機能開発は ML2/OVN メカニズムドライバーで行われます。

RHOSP 18.0 では、Red Hat は ML2/OVS メカニズムドライバーを完全に削除し、サポートを停止する予定です。

既存の RHOSP デプロイメントで ML2/OVS メカニズムドライバーを使用している場合は、今すぐメカニズムドライバーの移行計画の評価を開始してください。移行は、RHOSP 16.2 および RHOSP 17.1 でサポートされています。

ML2/OVS から ML2/OVN への移行を試みる前に、プロアクティブケースを作成する必要があります。プロアクティブケースを作成しない場合、Red Hat では移行をサポートしません。How to open a proactive case for a planned activity on Red Hat OpenStack Platform? を参照してください。

sensubility を使用して Podman 経由で行う API ヘルスステータスのモニタリングは、RHOSP 17.1 で非推奨になりました。

sensubility レイヤーのみが非推奨になりました。API ヘルスチェックは引き続きサポートされます。sensubility レイヤーは、サポート対象外となった Sensu とのインターフェイスとして存在しています。

この更新までは、データベースが宛先ホストの詳細で更新されなかったため、ライブマイグレーションが失敗する可能性がありました。

今回の更新により、ライブマイグレーション中に、データベース内のインスタンスホストの値が宛先ホストに設定されます。

この更新までは、ロードバランサー仮想 IP (VIP) に関連付けられた Floating IP (FIP) を使用している場合、Open Virtual Network (OVN) ロードバランサーのヘルスチェックは実行されず、FIP を使用している場合はトラフィックがエラー状態のメンバーにリダイレクトされていました。

この更新により、Load Balancer Virtual IP (VIP) に関連付けられた Floating IP (FIP) を使用する場合、FIP 用に新しいロードバランサーヘルスチェックが作成され、トラフィックはエラー状態のメンバーにリダイレクトされなくなります。

この更新までは、Compute サービス (nova) は、仮想マシンディスク (VMDK) イメージファイルの内容の信頼性チェックを行いませんでした。特別に作成された VMDK イメージを使用すると、ホストファイルシステム上の機密ファイルが、その VMDK イメージで起動されたゲストに公開される可能性がありました。今回の更新により、Compute サービスが VMDK ファイルの信頼性をチェックし、リーク動作が依存する VMDK 機能が禁止されます。つまり、悪用目的で作成された VMDK ファイルを使用して、ホストファイルシステムの機密性の高いコンテンツをリークすることは不可能になります。

この更新までは、rgw_max_attr_size のデフォルト値は 256 で、大きなイメージをアップロードするときに OpenStack 上の OpenShift で問題が発生していました。今回の更新により、rgw_max_attr_size のデフォルト値は 1024 になりました。

値を変更するには、オーバークラウドデプロイメントに含める環境ファイルに次の設定を追加します。

parameters_default:
  CephConfigOverrides:
    rgw_max_attr_size: <new value>

このリリースより前は、hw_machine_type イメージプロパティーを持たないインスタンスのマシンタイプは、ハードリブートまたは移行後に新しく設定されたマシンタイプを使用するため、RHOSP デプロイメントの有効期間中に NovaHWMachineType を変更できませんでした。インスタンスの基盤となるマシンタイプを変更すると、インスタンスの内部 ABI が破損する可能性があります。

今回のリリースでは、インスタンスの起動時に、Compute サービスがインスタンスのシステムメタデータ内にインスタンスのマシンタイプを記録します。そのため、既存インスタンスのマシンタイプに影響を及ぼすことなく、RHOSP デプロイメントの有効期間中に NovaHWMachineType を変更できるようになりました。

今回の更新では、セキュリティーグループのロギングが導入されます。仮想マシンインスタンスに出入りするトラフィックフローと試行を監視するには、セキュリティーグループのネットワーキングサービスパケットログを設定できます。

仮想マシンインスタンスポートを 1 つ以上のセキュリティーグループに関連付け、各セキュリティーグループに 1 つ以上のルールを定義できます。たとえば、ファイナンスセキュリティーグループ内の任意の仮想マシンにインバウンド SSH トラフィックをドロップするルールを作成できます。さらに、そのグループ内の仮想マシンが ICMP (ping) メッセージを送信および応答できるようにするために、別のルールを作成できます。

次に、パケットロギングを設定して、受け入れられたパケットフローとドロップされたパケットフローの組み合わせを記録できます。

セキュリティーグループのロギングは、ステートフルセキュリティーグループとステートレスセキュリティーグループの両方に使用できます。

ログに記録されたイベントは、仮想マシンをホストするコンピュートノードの /var/log/containers/stdouts/ovn_controller.log ファイルに保存されます。

この機能拡張は、クラウドユーザーがアクティブなインスタンスにアクセスできない理由が、インスタンスをホストする Compute ノードに到達できないためかどうかを判断するのに役立ちます。RHOSP 管理者は、次のパラメーターを設定できるようになりました。これにより、クラウドユーザーが openstack showserverdetails コマンドを実行する際にホストの Compute ノードに到達できない場合は host_status フィールドにステータスを入力するカスタムポリシーを有効にできます。

今回の更新により、バックアップおよび復元手順のワークフローで検証フレームワークを使用して、復元されたシステムのステータスを検証できるようになります。これには、次の検証が含まれています。

この機能拡張により、ディスク全体のオーバークラウドイメージである overcloud-hardened-uefi-full.qcow2 によりインストールされた LVM ボリュームが、シンプールによってバックアップされるようになりました。ボリュームは、引き続き利用可能な物理ストレージを消費するために拡張されますが、デフォルトではオーバープロビジョニングされません。

シンプロビジョニングされた論理ボリュームの利点は次のとおりです。

RHOSP 17.1 では、Red Hat は、同じ NIC ハードウェア上のすべての物理機能 (PF) が同一空間にあるドライバーを使用することを推奨しています。同じ NIC 上の PF はすべて、ユーザー空間またはカーネル空間のいずれかで実行されるドライバーを使用する必要があります。

たとえば、NIC1 の PF1 が DPDK PMD ドライバーによって使用されている場合、NIC1 の PF2 はカーネルドライバーを使用するべきではありません。この例では、NIC1 の PF は両方とも DPDK PMD ドライバーを使用するか、両方ともカーネルドライバーを使用する必要があります。

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

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

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

現時点において、ML2/OVS デプロイメントにおける Open vSwitch (OVS) は、skb_priority、skb_mark、または出力キューフィールドが設定されている OpenFlow ルールのオフロードをサポートしていません。これらのフィールドは、virtio ポートの Quality of Service (QoS) サポートに必要です。

virtio ポートに最小帯域幅ルールを設定すると、Networking サービス (neutron) OVS エージェントは、Packet Mark フィールドを使用してこのポートのトラフィックをマークします。その場合、このトラフィックはオフロードできず、他のポートのトラフィックに影響します。帯域幅制限ルールを設定すると、すべてのトラフィックがデフォルトの 0 キューでマークされます。これは、トラフィックをオフロードできないことを意味します。

回避策として、環境に OVS ハードウェアオフロードポートが含まれている場合は、ハードウェアオフロードが必要なノードでパケットマーキングを無効にします。パケットマーキングを無効にすると、virtio ポートのレート制限ルールは設定できなくなります。ただし、Differentiated Services Code Point (DSCP) のマーキングルールは引き続き使用できます。

設定ファイルで、disable_packet_marking フラグを true に設定します。設定ファイルを編集する場合、neutron_ovs_agent コンテナーを再起動する必要があります。以下に例を示します。

$ cat `/var/lib/config-data/puppet-generated/neutron/etc/neutron/plugins/ml2/openvswitch_agent.ini`
  [ovs]
  disable_packet_marking=True

RHOSP 17.0 では、DNS サービス (designate) と負荷分散サービス (octavia) が高可用性のために正しく設定されていません。これらのサービスの RHOSP オーケストレーションサービス (heat) テンプレートは、Redis テンプレートの非 Pacemaker バージョンを使用します。

回避策: 環境ファイル enable-designate.yaml および octavia.yaml の後に、environments/ha-redis.yaml を overcloud deploy コマンドに含めます。

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

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

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

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

Red Hat は、AMD プロセッサーを使用する NFV デプロイメント上で RHOSP 17.1 Beta リリースを検証していません。現在テストが進められており、将来のリリースでアプリケーションを検証する予定です。

Red Hat がアプリケーションを検証するまでは、実稼働用の AMD ハードウェアで RHOSP 17.1 NFV デプロイメントを使用しないでください。この事前テスト済みのアプリケーションを使用すると、意図しない結果が生じる危険があります。

ML2/OVN、DVR が有効で、VLAN テナントネットワークを使用する RHOSP 17.1 環境では、異なるテナントネットワークに接続されている仮想マシン間の east/west トラフィックがファブリックにフラッディングされます。

その結果、それらの仮想マシン間のパケットは、それらの仮想マシンが実行されているコンピュートノードだけでなく、他のオーバークラウドノードにも到達します。

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

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

現在、Red Hat Ceph Storage (RHCS) 6.0 の Ceph RADOS Gateway コンポーネントに関する既知の問題が原因で、Identity サービス (keystone) トークンによる認証が失敗します。https://bugzilla.redhat.com/2188266 を参照してください。

その結果、RADOS Gateway をオブジェクトストアサーバーとして使用して Red Hat Ceph Storage でデプロイメントを設定すると、Object Storage サービス (swift) クライアントが失敗し、コード 403/Unauthorized を返します。この問題は、2023 年 6 月 15 日に一般提供を開始した RHCS 6.1 のプレリリースバージョンをデプロイしたテストでは発生しませんでした。

また、デフォルト設定では RADOS Gateway が使用されているため、OpenStack 上の OpenShift 統合はベータ版では検証されていません。以下の回避策を行うことで、問題が軽減され、OpenStack での OpenShift 統合による予備テストが可能になることが期待されます。

回避策: 永続的なブロックストレージサービス (cinder)、またはイメージサービス (glance) ストレージおよび一時的な Compute サービス (nova) ストレージ用に Ceph Storage を有効にする場合でも、RADOS ゲートウェイの代わりに Object Storage サービス (swift) をオブジェクトストアサーバーとしてデプロイします。これを行うには、デプロイメントコマンドラインで cephadm.yaml 環境ファイルを cephadm-rbd-only.yaml に置き換えます。

オブジェクトストアサーバーとして、RADOS Gateway ではなく Object Storage サービス (swift) を使用して OpenStack 環境を設定すると、Object Storage サービス (swift) クライアントは期待どおりに動作します。

OVN で BGP 動的ルーティングを使用する RHOSP 17.1 環境では、OVN BGP エージェントが使用する Autonomous System Number (ASN) のデフォルト値が、FRRouting (FRR) が使用する ASN と異なるという既知の問題があります。

回避策: アンダークラウドとオーバークラウドの設定で使用される tripleo パラメーターの値 (FrrBgpAsn と FrrOvnBgpAgentAsn) が同じであることを確認してください。

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

現在、BGP 動的ルーティングを使用する RHOSP 17.1 環境では、出荷されたライブラリー (pyroute2) のバグが原因で、オーバークラウドノードで実行されている OVN BGP エージェントが失敗するという既知の問題があります。この問題が発生すると、影響を受けるノードから新しいルートがアドバタイズされず、新しい仮想マシン、移行された仮想マシン、新しい新しいロードバランサーなどとの接続が失われる可能性があります。

回避策: 次の行を containers-prepare-parameter.yaml に追加して、更新されたバージョンの pyroute2 を ovn_bgp_agent コンテナーにインストールします。

ContainerImagePrepare:
- push_destination: true
  ...
  includes:
  - nova-compute
  modify_role: tripleo-modify-image
  modify_append_tag: "-hotfix"
  modify_vars:
    tasks_from: rpm_install.yml
    rpms_path: /home/stack/nova-hotfix-pkgs
  ...

詳細は、コンテナーイメージへの追加 RPM ファイルのインストール を参照してください。

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

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

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

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

現在、セキュアなロールベースのアクセス制御 (SRBAC) が有効になっている場合、DNS-as-a-Service (designate) が誤って設定されています。SRBAC と DNS-as-a-Service の両方を設定すると、RHOSP のデプロイメントは失敗します。回避策: デプロイを成功させるには、アンダークラウドサーバーに次のパッチを適用します。

ML2/OVS メカニズムドライバーは、RHOSP 17.0 以降で非推奨になりました。

いくつかのリリースで、Red Hat は ML2/OVS を ML2/OVN に置き換えています。たとえば、RHOSP 15 以降では、ML2/OVN がデフォルトのメカニズムドライバーになりました。

非推奨の ML2/OVS メカニズムドライバーは、RHOSP 17 リリースでサポートされます。この間、ML2/OVS ドライバーはメンテナンスモードのままで、バグ修正と通常のサポートを受け、ほとんどの新機能開発は ML2/OVN メカニズムドライバーで行われます。

RHOSP 18.0 では、Red Hat は ML2/OVS メカニズムドライバーを完全に削除し、サポートを停止する予定です。

既存の RHOSP デプロイメントで ML2/OVS メカニズムドライバーを使用している場合は、今すぐメカニズムドライバーの移行計画の評価を開始してください。移行は、RHOSP 16.2 および RHOSP 17.1 でサポートされています。

ML2/OVS から ML2/OVN への移行を試みる前に、プロアクティブケースを作成する必要があります。プロアクティブケースを作成しない場合、Red Hat では移行をサポートしません。事前ケースを送信する方法を参照してください。

sensubility を使用して Podman 経由で行う API ヘルスステータスのモニタリングは、RHOSP 17.1 で非推奨になりました。

sensubility レイヤーのみが非推奨になりました。API ヘルスチェックは引き続きサポートされます。sensubility レイヤーは、サポート対象外となった Sensu とのインターフェイスとして存在しています。

派生パラメーター機能は削除されました。派生パラメーター機能は、openstack overcloud deploy コマンドの --plan-environment-file オプションを使用して設定されます。

回避策/移行手順

NFV および HCI オーバークラウドには、システムの調整が必要です。システムのチューニングにはさまざまなオプションがあります。派生パラメーター機能は、ハードウェア検査データを検査に使用して director を使用するシステムを調整し、openstack overcloud deploy コマンドの --plan-environment-file オプションを使用して調整パラメーターを設定しました。派生パラメーター機能は 17.1 で削除されました。

次のパラメーターは、この機能によって調整されました。