第3章 リリースの情報

以前は、インスタンスにアタッチされているポートで binding:vnic_type を変更すると、再起動時に nova_compute が再起動ループに入りました。

この更新により、インスタンスにアタッチされているポートの binding:vnic_type は変更できなくなります。

この更新の前は、IPv6 専用ネットワークで作成された仮想マシンインスタンスは、コンピュートメタデータサービスにアクセスできませんでした。メタデータエージェントは、コンピュートメタデータサービスへのアクセスに使用される namespace のプロビジョニング時に、IPv6 アドレスの可能性を考慮していませんでした。RHOSP 17.1.4 では、この問題は修正されました。メタデータエージェントは、コンピュートメタデータサービスへのアクセスに使用される namespace のプロビジョニング時に、IPv6 アドレスを考慮するように変更されました。その結果、IPv6 専用ネットワークで作成されたインスタンスはコンピュートメタデータサービスにアクセスできます。

この更新の前は、Virtual Data Optimizer (VDO) パッケージがあることで checkvdo Leapp アクターが失敗し、Leapp のアップグレードが失敗していました。

RHOSP 17.1.4 では、VDO パッケージが削除され、Leapp のアップグレードが成功するようになりました。

この更新の前は、Lenovo UEFI ファームウェアはデプロイメント後にブートレコードをリセットしていました。デプロイメント中に、サーバーの最初の起動に失敗し、有効な起動デバイスがないことを示すブルースクリーンが表示されました。

RHOSP 17.1.4 では、この問題は解決されました。デプロイメント時に、Lenovo UEFI ファームウェアはデプロイメント後にブートレコードをリセットしなくなり、手動による回避策は不要になりました。

この更新の前は、python3-dns パッケージバージョン 2.x で RHOSP DNS サービス (designate) との非互換性が発生していました。この非互換性により、Transaction Signature (TSIG) キーが関係する一部のゾーン転送が失敗し、ログメッセージ AttributeError: 'TsigKeyring' object has no attribute 'name' が表示されていました。

RHOSP 17.1.4 では、この問題は解決されました。TSIG キーを含むゾーン転送が正しく動作するようになりました。

複数の CephFS ファイルシステムを持つ外部 Red Hat Ceph Storage クラスターで Shared File Systems サービス (manila) を使用する場合は、認可および認可取り消しのコンテキストでファイルシステム名を指定する必要があります。

この更新の前は、NFS の認可ワークフローでファイルシステム名を指名しないため、NFS-Ganesha サービスで NFS エクスポートが失敗していました。この更新により、Shared File Systems サービスは CephFS-NFS クライアントの認可時にファイルシステム名を指定し、NFS-Ganesha サービスで NFS エクスポートが成功するようになりました。

この更新の前は、Shared File Systems サービス (manila) と CephFS-NFS で設定された外部 Red Hat Ceph Storage クラスターがデプロイメントに含まれている場合、エクスポート設定が上書きされていました。RHOSP 17.1 オーバークラウドへのアップグレードまたは更新後、CephFS-NFS サービス (NFS-Ganesha) がエクスポート設定なしで起動し、クライアントが共有にアクセスできなくなっていました。

この更新により、ディレクターはエクスポート設定の有無を確認し、オーバークラウドのアップグレードおよび更新中にそれらを保持するようになりました。CephFS-NFS クライアントは、アップグレード手順と更新手順、および手順中の定期的な復元操作を通じて、引き続きデータにアクセスできます。

この RHOSP 17.1.4 更新では、特定の状況でパケット転送遅延を引き起こすバグが修正されています。

このバグ修正の前は、RHOSP 17.1 デプロイメントに nft または iptables のフィルタールールと LOG アクションが含まれ、カーネルコマンドライン (/proc/cmdline) に console=tty50 がある場合、ロギングアクションによってパケット転送に大幅な遅延が発生する可能性がありました。

このバグ修正により、バグが修正され、遅延が解消されます。17.1.x から 17.1.4 への更新では、この修正は自動的に適用されません。修正が必要な場合は、17.1.4 に更新する前に、ナレッジベースソリューション Sometimes receiving packet(e.g. ICMP echo) has latency, around 190 ms に記載されている手順を実行してください。

この更新の前は、Red Hat Ceph Storage の健全性検証中に 'cephadm command not found' エラーが発生し、RHOSP 16.2 から 17.1 へのアップグレードが失敗する可能性がありました。

このエラーを回避するために、cephadm ツールがインストールされていない場合は、Red Hat Ceph Storage の健全性検証は 'podman run' を使用して実行されるようになりました。

この更新の前は、Shared File Systems サービス (manila) の共有ネットワークとして外部ネットワークを使用した場合、OVN の非互換性により、外部ストレージシステムにアタッチされた外部スイッチ上に作成されたポートに対して誤った ARP 応答が発生していました。仮想マシン、コンテナー、ベアメタルノードなどのクライアントマシンは、外部ネットワークにエクスポートされた共有にアクセスできませんでした。

この更新により、Shared File Systems サービスは OpenStack ネットワークポートのステータスを DOWN に設定し、OVN が Networking サービス (neutron) ポートを介して ARP 応答を設定できないようにします。代わりに、MAC アドレスは外部ポートから学習されます。クライアントマシンは、外部ネットワークにエクスポートされた共有にアクセスでき、Shared File Systems サービスにアクセス制御リスト (ACL) がある場合は共有をマウントできます。

以前の RHOSP リリースでは、IPv4 ロードバランサーへの接続が中断される可能性がありました。この問題は、IPv6 ロードバランサーの ip_port_mappings パラメーターで使用される誤った形式を修正するメンテナンスタスクの実行中に発生しました。このタスクでは、IPv6 ロードバランサーの誤った形式が修正されましたが、IPv4 ロードバランサーの ip_port_mappings パラメーターも誤って変更されました。

この問題は解決され、メンテナンスタスクの実行後に IPv4 ロードバランサーの接続が中断されることはなくなりました。

この更新では、一部の IPv6 デプロイメントで Neutron の障害と接続の喪失を引き起こしていたバグが修正されています。

一部の IPv6 デプロイメントでは、resolv.conf はスコープが (fe80::5054:ff:fe96:8af7%eth2) の IPv6 ネットワークを使用します。このスコープは、Neutron で使用される一部のライブラリーと互換性がありません。

この更新により、スコープを除外するためにアドレスがトリミングされ、非互換性が回避されます。

今回の更新以前は、DNS ネームサーバーに変更があった場合や、ドメイン名を変更するたびに、os-net-config スクリプトでホストインターフェイスを再起動する必要がありました。これは、RHOSP 17.1.4 から RHOSO 18.0.x データプレーンの導入時に問題となっていました。

RHOSP 17.1.4 では、DNS サーバーの IP アドレスと検索ドメインが以前の設定に限られる場合にのみ、インターフェイスを再起動せずに DNS サーバーと検索ドメインをオンザフライで変更できるようになりました。DNS ネームサーバーと検索ドメインは ifcfg ファイルに書き込まれ、/etc/resolv.conf が更新されます。

これにより、異なるテナントネットワーク上のインスタンス間のメッシュにおけるフラッディングを防止するように設定できる拡張機能が導入されます。

この更新の前は、DVR が有効で、VLAN テナントネットワークを使用する OVN または OVS メカニズムドライバーを備えた RHOSP 環境では、異なるテナントネットワークに接続されたインスタンス間の east/west トラフィックがファブリックにフラッディングされていました。

OVN メカニズムドライバーを使用する環境でこのフラッディングを防ぐために、パラメーター OVNControllerGarpMaxTimeout を設定できるようになりました。これにより、VLAN テナントネットワーク上のポートの MAC アドレスを通知する Gratuitous ARP パケットの送信頻度を、ovn-controller が制御できるようになりました。

このパラメーターは、OVS メカニズムドライバーを使用する環境では使用できません。

Shared File Systems サービス (manila) に、VAST Data Platform をサポートするストレージドライバーが含まれるようになりました。このドライバーを使用すると、スナップショットを通じて NFS 共有とポイントインタイムバックアップのプロビジョニングおよび管理を行えます。

このドライバーは、Red Hat OpenStack Services on OpenShift バージョン 18.0.4 に追加されます。

RHOSP 17.1.4 では、リンクがオーバーサブスクライブされた場合に OVS-DPDK ボンディングでリンクフラッピングを回避するテクノロジープレビュー機能を使用できます。この機能拡張は、DPDK ボンディングのすべてのメンバーに rx-steering=lacp+rss オプションを設定することで使用できます。

$ ovs-vsctl add-bond br-dpdk0 dpdkbond0 dpdk0 dpdk1 -- \
set interface dpdk0 type=dpdk options:dpdk-devargs=0000:ca:00.0 \
options:rx-steering=rss+lacp -- \
set interface dpdk1 type=dpdk options:dpdk-devargs=0000:ca:00.1 \
options:rx-steering=rss+lacp

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

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

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

この更新では、新しいサンプル OVN ユーザー定義ルーターフレーバードライバー (neutron/neutron/services/ovn_l3/service_providers/user_defined.py の UserDefinedNoLsp クラス) が導入されました。

このドライバーにより、基盤となる論理スイッチポートが関連付けられていないルーターインターフェイスの作成が可能になります。このシナリオでは、Neutron はルーターインターフェイスの IP アドレスマネージャーとしてのみ機能します。これにより、ユーザー定義のルーターフレーバーは、OVN 処理をバイパスしながら、ルーターインターフェイスを通過するトラフィックを完全に制御できるようになります。

この更新では、"[ovn]" 設定セクションに broadcast_arps_to_all_routers という設定オプションが追加されます。

このオプションは、OVN 23.06 で使用可能になった broadcast-arps-to-all-routers 設定オプションを使用して外部ネットワークを設定します。このオプションはデフォルトで有効になっています。これにより、OVN はネットワーク上のすべての接続ポートに ARP 要求をフラッディングします。

[ovn]
broadcast_arps_to_all_routers=true

Broadcast_arps_to_all_routers を無効にすると、ターゲット MAC アドレスが一致する場合に限り ARP 要求がネットワーク上のルーターに送信されます。ルーターに一致しない ARP 要求は、ルーター以外のポートにのみ転送されます。

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

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

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

現在、IPv6 環境では、os-net-config で生成された ifcfg-* ファイル内の IPv6 キーと値のペア IPV6_AUTOCONF=no によって、システムがルーター広告に応答してデフォルトルートを設定することを妨げられないという既知の問題があります。

回避策: この問題を修正するには、次の手順を実行します。

RHOSP 16.2 から 17.1 にアップグレードする場合、環境に事前プロビジョニングされたノードが含まれていると、事前プロビジョニングされたノードが baremetal-deployment.yaml ファイルで正しく定義されていないため、openstack overcloud node provision コマンドは失敗します。

回避策: Red Hat ナレッジベースアーティクル LEAPP upgrade from 16.2 to 17.1 fails during overcloud node provisioning step when adding pre-provisioned nodes を参照してください。

この更新では、パラメーター fdb_removal_limit および mac_binding_removal_limit の値が OVN データベースに適用されないバグが修正されています。値は解析されましたが、適用されませんでした。

現在は、値がデータベースに適用されるようになりました。

RHOSP 16.2 から 17.1 にアップグレードする場合、既知の問題により、システムのアップグレード中に GRUB に RHEL 8 エントリーではなく RHEL 7 エントリーが格納されます。その結果、ホストを再起動できなくなります。この問題は、RHOSP 13.0 以前を実行していた環境に影響します。

回避策: Red Hat ナレッジベースソリューション Openstack 16 to 17 FFU - During LEAPP upgrade UEFI systems do not boot due to invalid /boot/grub2/grub.cfg を参照してください。

RHOSP 17.1 動的ルーティング環境では、Free Range Routing (FRR) コンテナーを再起動すると、予期しないネットワークの中断が発生する可能性があります。この中断は、再起動中に、一部の OVN BGP エージェントと FRR 設定がネットワークパケットを転送するためのルートを誤って削除し、設定がこれらのルートを再学習する必要があるために発生します。

回避策:

RHOSP 17.1 では、OVS エージェントを削除しても、Networking サービス (neutron) は ovsdb から対応する VXLAN エンドポイントを削除しません。この状況により、削除されたエージェントが実行されていたノードがまだアクティブであると誤って認識するという問題が L3 HA ルーターで発生する可能性があります。

回避策: FIPs stopped working after network/controller node replacement を参照してください。

IPv6 サブネットを作成する場合は、ネットワークの MTU が 1280 オクテット以上であることを確認してください。

IPv6 サブネットには少なくとも 1280 オクテットの MTU が必要ですが、RHOSP にはその要件を強制する検証プロセスが含まれていません。