第3章 リリースの情報

フラグ live_migration_wait_for_vif_plug がデフォルトで有効なので、Red Hat OpenStack Platform 16.0 では、OVN を有効にした状態でライブマイグレーションが成功するようになりました。

以前のリリースでは、OpenStack Networking (neutron) が vif_plugged の通知を送信するのをシステムが待機するため、ライブマイグレーションに失敗していました。

今回の機能拡張により、SR-IOV ベースの neutron インターフェースが設定されたインスタンスのライブマイグレーションがサポートされるようになりました。neutron SR-IOV インターフェースは、直接モードと間接モードという 2 つのカテゴリーにグループ分けすることができます。直接モードの SR-IOV インターフェースは、ゲストに直接接続され、ゲスト OS に公開されます。間接モードの SR-IOV インターフェースは、ゲストと SR-IOV デバイス間に macvtap 等のソフトウェアインターフェースを持ちます。この機能により、間接モードの SR-IOV デバイスを持つインスタンスの透過的なライブマイグレーションが可能になります。ライブマイグレーション中にハードウェアの状態をコピーする一般的な方法がないため、直接モードの移行はゲストに対して透過的ではありません。直接モードのインターフェースの場合には、既存の休止/再開のワークフローを模擬します。たとえば、SR-IOV デバイスを使用する場合には、移行前に直接モードのインターフェースの接続を解除し、移行後に再度接続します。その結果、ライブマイグレーションの可能なインターフェースとのボンディングをゲスト内に作成しない限り、直接モードの SR-IOV ポートを持つインスタンスでは、移行中にネットワーク接続が失われます。

以前のリリースでは、SR-IOV ベースのネットワークインターフェースが設定されたインスタンスのライブマイグレーションを行うことはできませんでした。ホストのメンテナンス等にライブマイグレーションが頻繁に使用されているため、このことが問題となっていました。以前のリリースでは、コールドマイグレーションでインスタンスを移行する必要がありましたが、ゲストにダウンタイムが発生していました。

今回の機能拡張により、SR-IOV ベースのネットワークインターフェースが設定されたインスタンスのライブマイグレーションが可能になりました。

Red Hat OpenStack Platform 16.0 では、ローカルレジストリーのイメージをプッシュ、一覧表示、削除、および表示 (メタデータの表示) できるようになりました。

Red Hat OpenStack Platform 16.0 では、Orchestration サービス (heat) の新たなデプロイメントパラメーターを利用することができ、管理者はセルコントローラーで nova メタデータサービスを有効にすることができます。

parameter_defaults:
   NovaLocalMetadataPerCell: True

この新たなパラメーターにより、セルコンピュートの OVN メタデータエージェントからセルコントローラーがホストする nova メタデータ API サービスに、トラフィックが自動的に転送されます。

RHOSP トポロジーによっては、セルコントローラーでメタデータサービスを実行する機能により、中央のコントロールプレーンのトラフィックを減らすことができます。

今回の機能拡張により、以下のパラメーターを使用して、同じコンピュートノードで専用の (ピニングされた) インスタンスと共有の (ピニングされていない) インスタンスをスケジューリングできるようになりました。

複数のルーティングテーブルを定義し、ルートを特定のテーブルに割り当てる機能は、Red Hat OpenStack Platform 16.0 のテクノロジープレビューです。

複数のリンクを持つホストでは、ポリシーベースのルーティングはルーティングテーブルを使用し、送信元のアドレスに応じて特定のインターフェース経由でトラフィックを送信することができます。

また、以下の例に示すように、インターフェースごとにルーティングルールを定義することもできます。

network_config:
  -
    type: route_table
    name: custom
    table_id: 200
  -
    type: interface
    name: em1
    use_dhcp: false
    addresses:
    -
      ip_netmask: 192.0.2.1/24
    routes:
      -
        ip_netmask: 10.1.3.0/24
        next_hop: 192.0.2.5
        table: 200  # Use table ID or table name
    rules:
      - rule: "iif em1 table 200"
        comment: "Route incoming traffic to em1 with table 200"
      - rule: "from 192.0.2.0/24 table 200"
        comment: "Route all traffic from 192.0.2.0/24 with table 200"
      - rule: "add blackhole from 172.19.40.0/24 table 200"
      - rule: "add unreachable iif em1 from 192.168.1.0/24"

Red Hat OpenStack Platform 16.0 では、Bare Metal Provisioning サービス (ironic) を使用して仮想メディアからベアメタルマシンを起動することができるように、テクノロジープレビュー機能が追加されています。

マシンのベースボード管理コントローラー (BMC) が Redfish ハードウェア管理プロトコルおよび仮想メディアサービスをサポートする場合には、ブート可能イメージをプルしてそれをノード上の仮想ドライブに「挿入」するように、ironic は BMC に指示することができます。次に、ノードはその仮想ドライブからイメージ上のオペレーティングシステムにブートすることができます。Redfish API に基づく Ironic ハードウェア種別は、(ユーザー) イメージのデプロイ、レスキュー (制限あり)、および仮想メディアを通じたブートをサポートします。

仮想メディアを通じたブートの主要なメリットは、PXE ブートプロトコルスイートのセキュアではない信頼性に欠ける TFTP イメージ転送フェーズが、セキュアな HTTP トランスポートに置き換えられることです。

Red Hat OpenStack Platform 16.0 では、テクノロジープレビュー機能の Workflow サービス (mistral) タスクにより、以下の手順に従ってパスワードのローテーションを実装することができます。

rotate-password ワークフローを実行し、新しいパスワードを生成してそれをプラン環境に保管する。

オーバークラウドを再デプロイする。

パスワードの変更後にパスワードを取得することもできます。

パスワードのローテーションを実装するには、以下の手順に従います。

Red Hat OpenStack Platform 16.0 では、rsyslog の変更に対応することができるように、Orchestration サービス (heat) にテクノロジープレビュー機能が追加されています。

Red Hat OpenStack Platform 16.0 では、director を使用してサービステンプレートにインフライトの自動検証を含めることができます。この機能は RHOSP 16.0 ではテクノロジープレビューです。追加設定は、確認するステップの最後、または次のステップの最初に挿入することができます。

以下の例では、デプロイメント後の rabbitmq サービスが動作していることを確認する検証が実行されます。

deploy_steps_tasks:
  # rabbitmq container is supposed to be started during step 1
  # so we want to ensure it's running during step 2
  - name: validate rabbitmq state
    when: step|int == 2
    tags:
      - opendev-validation
      - opendev-validation-rabbitmq
    wait_for_connection:
      host: {get_param: [ServiceNetMap, RabbitmqNetwork]}
      port: 5672
      delay: 10

heat では、openstack-tripleo-validations ロールの既存の検証を含めることができます。

deploy_steps_tasks:
  - name: some validation
    when: step|int == 2
    tags:
      - opendev-validation
      - opendev-validation-rabbitmq
    include_role:
      role: rabbitmq-limits
    # We can pass vars to included role, in this example
    # we override the default min_fd_limit value:
    vars:
      min_fd_limit: 32768

rabbitmq-limits ロールの定義は、https://opendev.org/openstack/tripleo-validations/src/branch/stable/train/roles/rabbitmq_limits/tasks/main.ymlを参照してください。

既存のサービスヘルスチェックを使用する例を以下に示します。

deploy_steps_tasks:
  # rabbitmq container is supposed to be started during step 1
  # so we want to ensure it's running during step 2
  - name: validate rabbitmq state
    when: step|int == 2
    tags:
      - opendev-validation
      - opendev-validation-rabbitmq
    command: >
      podman exec rabbitmq /openstack/healthcheck

Red Hat OpenStack Platform 16.0 では、Orchestration サービス (heat) にテクノロジープレビュー機能が追加されています。新たに追加されたパラメーター NovaSchedulerQueryImageType により、イメージの種別に応じて Compute サービス (nova) の配置およびスケジューラーコンポーネントクエリーの配置が制御されます (scheduler/query_placement_for_image_type_support)。

true に設定すると (デフォルト)、NovaSchedulerQueryImageType はブート要求で使用されるイメージのディスク形式をサポートしないコンピュートノードを除外します。

たとえば、libvirt ドライバーはエフェメラルバックエンドに Red Hat Ceph Storage を使用し、qcow2 イメージをサポートしません (非常にコストのかかる変換ステップを経ない場合)。この場合には、NovaSchedulerQueryImageType を有効にすると、スケジューラーは Red Hat Ceph Storage を使用するコンピュートノードには qcow2 イメージをブートする要求を送信しません。

TCP、UDP、または Floating IP アドレスのその他のプロトコルポートから、TCP、UDP、または neutron ポートの Fixed IP アドレスのいずれかに関連付けられたその他のプロトコルポートに、トラフィックを転送できるようになりました。転送されたトラフィックは、neutron API に対する機能拡張および OpenStack Networking プラグインにより管理されます。Floating IP アドレスには、複数の転送定義を設定することができます。ただし、すでに OpenStack Networking ポートと関連のある IP アドレスのトラフィックを転送することはできません。転送することができるのは、ネットワーク上の集中ルーター (レガシー、HA、および DVR+HA) によって管理される Floating IP アドレスのトラフィックだけです。

Floating IP アドレスのポートのトラフィックを転送するには、以下の OpenStack Networking プラグインコマンドを使用します。

openstack floating ip port forwarding create
--internal-ip-address <internal-ip-address>
--port <port>
--internal-protocol-port <port-number>
--external-protocol-port <port-number>
--protocol <protocol>
<floating-ip>

--internal-ip-address <internal-ip-address>: 転送されたトラフィックを受信する neutron ポートの内部 Fixed IP アドレス (IPv4)。

--port <port>: 転送されたトラフィックを受信する neutron ポートの名前または ID。

--internal-protocol-port <port-number>: 転送されたトラフィックを受信する neutron ポート Fixed IP アドレスのプロトコルポート番号。

--external-protocol-port <port-number> トラフィックの転送元である Floating IP アドレスのポートのプロトコルポート番号。

--protocol <protocol>: Floating IP アドレスのポートが使用するプロトコル (例: TCP、UDP)。

<floating-ip>: トラフィックの転送元であるポートの Floating IP (IP アドレスまたは ID)。

以下は例です。

openstack floating ip port forwarding create \
    --internal-ip-address 192.168.1.2 \
    --port f7a08fe4-e79e-4b67-bbb8-a5002455a493 \
    --internal-protocol-port 18343 \
    --external-protocol-port 8343 \
    --protocol tcp \
    10.0.0.100

nova-compute ironic ドライバーは、BM ノードのクリーンアップ中にノードの更新を試みます。クリーンアップには約 5 分間かかりますが、nova-compute は約 2 分間しかノードの更新を試みません。タイムアウト後、nova-compute は停止し、nova インスタンスを ERROR 状態にします。

回避策は、nova-compute サービスに以下の設定オプションを定義することです。

[ironic]
api_max_retries = 180

その結果、nova-compute はより長時間 BM ノードの更新を試み続け、最終的に成功します。

ML2/OVS から OVN への移行に失敗するという既知の問題があります。この失敗は、Red Hat OpenStack Platform director の新たな保護メカニズム (メカニズムドライバーを変更している間はアップグレードを拒否する) によるものです。

回避策は、『Networking with Open Virtual Network』の「Preparing for the migration」を参照してください。

Linux ブリッジ ML2 ドライバーおよびエージェントを使用する Red Hat OpenStack Platform デプロイメントは、アドレス解決プロトコル (ARP) スプーフィングに対して保護されません。Red Hat Enterprise Linux 8 に含まれる Ethernet bridge frame table 管理 (ebtables) のバージョンは、Linux ブリッジ ML2 ドライバーと互換性がありません。

Linux ブリッジ ML2 ドライバーおよびエージェントは Red Hat OpenStack Platform 11 で非推奨になりました。したがって、使用すべきではありません。

Red Hat では、その代わりに ML2 Open Virtual Network (OVN) ドライバーおよびサービス (Red Hat OpenStack Platform director によりデプロイされるデフォルト) の使用を推奨します。

オーバークラウドコントローラーを置き換えると、swift のリングがノード間で一貫性を失う可能性があります。これにより、Object Storage サービスの可用性が低下する場合があります。その場合には、SSH を使用してそれまで存在していたコントローラーノードにログインして更新されたリングをデプロイし、Object Storage コンテナーを再起動します。

(undercloud) [stack@undercloud-0 ~]$ source stackrc
(undercloud) [stack@undercloud-0 ~]$ nova list
...
| 3fab687e-99c2-4e66-805f-3106fb41d868 | controller-1 | ACTIVE | -          | Running     | ctlplane=192.168.24.17 |
| a87276ea-8682-4f27-9426-6b272955b486 | controller-2 | ACTIVE | -          | Running     | ctlplane=192.168.24.38 |
| a000b156-9adc-4d37-8169-c1af7800788b | controller-3 | ACTIVE | -          | Running     | ctlplane=192.168.24.35 |
...

(undercloud) [stack@undercloud-0 ~]$ for ip in 192.168.24.17 192.168.24.38 192.168.24.35; do ssh $ip 'sudo podman restart swift_copy_rings ; sudo podman restart $(sudo podman ps -a --format="{{.Names}}" --filter="name=swift_*")'; done

Red Hat OpenStack Platform 16.0 には、OpenStack インスタンスの設定に必要なメタデータ情報が利用できず、ネットワークに接続されていない状態でインスタンスが起動するという既知の問題があります。

順序付けの問題が原因で、ovn_metadata_agent の haproxy ラッパーが更新されません。

クラウドオペレーターが実施することのできる回避策は、更新後に以下の Ansible コマンドを実行して、選択したノードの ovn_metadata_agent を再起動することです。これにより、ovn_metadata_agent は更新バージョンの haproxy ラッパースクリプトを使用するようになります。

`ansible -b <nodes> -i /usr/bin/tripleo-ansible-inventory -m shell -a "status=`sudo systemctl is-active tripleo_ovn_metadata_agent`; if test \"$status\" == \"active\"; then sudo systemctl restart tripleo_ovn_metadata_agent; echo restarted; fi"`

上記の Ansible コマンドで、nodes を単一のノード (例: compute-0)、すべてのコンピュート (例: compute*)、または「all」に設定します。

ovn_metadata_agent はコンピュートノードで最も一般的に使用されているので、以下の Ansible コマンドにより、クラウド内のすべてのコンピュートノードのエージェントが再起動されます。

`ansible -b compute* -i /usr/bin/tripleo-ansible-inventory -m shell -a "status=`sudo systemctl is-active tripleo_ovn_metadata_agent`; if test \"$status\" == \"active\"; then sudo systemctl restart tripleo_ovn_metadata_agent; echo restarted; fi"`

ovn_metadata_agent サービスを再起動すると、更新された haproxy ラッパースクリプトが使用され、仮想マシンの起動時にメタデータを提供することができます。すでに実行中の問題のある仮想マシンは、回避策の適用後に再起動すると、通常どおりに動作するはずです。

Red Hat OpenStack 16.0 には、同時マルチスレッド (SMT) 制御が無効でない限り、IBM POWER8 システム上では KVM ゲストが起動しないという既知の問題があります。SMT は自動的に無効になりません。

回避策は、オーバークラウドのデプロイおよびそれ以降の再起動後に、いずれかの IBM POWER8 コンピュートノードで sudo ppc64_cpu --smt=off を実行することです。

Red Hat OpenStack 16.0 には、実際には OVN エージェントが正常でクラウドが動作状態にあるにもかかわらず、コマンド「openstack network agent list」により、エージェントがダウンしていることを示す出力が断続的に表示されるという既知の問題があります。

該当するエージェントは、OVN Controller エージェント、OVN Metadata エージェント、および OVN Controller Gateway エージェントです。

現在、この問題に対する回避策はありません。「openstack network agent list」コマンドの出力を無視する必要があります。

OpenStack Networking (neutron) には、作成されたすべてのインスタンスが、内部 DNS に設定された dns_domain の値ではなく、ネットワークに関連付けられた dns_domain の値を継承するという既知の問題があります。

この問題の原因は、ネットワークの dns_domain 属性が neutron の dns_domain 設定オプションを上書きすることです。

この問題を回避するには、内部 DNS 機能を使用する際に、ネットワークの dns_domain 属性を設定しないでください。

neutron_api サービスがコントローラーノードにデプロイされた Placement サービスにアクセスできるようにするには (Novacontrol ロールを使用する際に必要)、以下の hieradata 設定をコントローラー環境ファイルに追加します。

service_config_settings:
     placement:
         neutron::server::placement::password: <Nova password>
  neutron::server::placement::www_authenticate_uri: <Keystone Internal API URL>
  neutron::server::placement::project_domain_name: 'Default'
  neutron::server::placement::project_name: 'service'
  neutron::server::placement::user_domain_name: 'Default'
  neutron::server::placement::username: nova
  neutron::server::placement::auth_url: <Keystone Internal API URL>
  neutron::server::placement::auth_type: 'password'
  neutron::server::placement::region_name: <Keystone Region>

Puppet を使用したロール用 hieradata カスタマイズの詳細は、『オーバークラウドの高度なカスタマイズ』の「Puppet: ロール用 hieradata のカスタマイズ」を参照してください。

Red Hat OpenStack Platform Load-balancing サービスには、ノードのリブート時にコンテナー octavia_api および octavia_driver_agent が起動に失敗するという既知の問題があります

この問題の原因は、ノードのリブート時にディレクトリー /var/run/octavia が存在しないことです。

この問題を修正するには、以下の行をファイル /etc/tmpfiles.d/var-run-octavia.conf に追加します。

d /var/run/octavia 0755 root root - -

Red Hat OpenStack Platform 16.0 には、オーバークラウドノードの設定中に ansible-playbook が正常に動作しない場合があるという既知の問題があります。この問題の原因は、tripleo-admin ユーザーの ssh 使用が許可されないことです。さらに、openstack overcloud deploy コマンドの引数 --stack-only が、tripleo-admin ユーザーを許可するための enable ssh admin ワークフローを実行しなくなりました。

回避策は、--stack-only を使用する場合には、openstack overcloud admin authorize コマンドを使用して enable ssh admin ワークフローを独自に実行すると共に、手動の config- download コマンドを実行することです。詳細は、『director のインストールと使用方法』の「プロビジョニングプロセスと設定プロセスの分離」を参照してください。

Red Hat OpenStack Platform 16.0 には、ハードな（強制的な）シャットダウン状態にあるノードが、以前動作していたコンテナーが podman で再びオンに戻る際に podman で「Created」状態になるという既知の問題があります。

この問題の原因は、コンテナーがすでに「Created」の状態で存在しているので、メタデータエージェントが新しいコンテナーを提供できないことです。haproxy side-car コンテナーラッパースクリプトは、コンテナーが「Exited」の状態であることしか想定せず、「Created」の状態にあるコンテナーをクリーンアップしません。

クラウドオペレーターが実施することのできる回避策は、以下の Ansible ad-hoc コマンドを実行して「Created」の状態にあるすべての haproxy コンテナーをクリーンアップすることです。この Ansible ad-hoc コマンドは、アンダークラウドの特定ノード、ノードのグループ、またはクラスター全体から実行する必要があります。

`ansible -b <nodes> -i /usr/bin/tripleo-ansible-inventory -m shell -a "podman ps -a --format {{'{{'}}.ID{{'}}'}} -f name=haproxy,status=created | xargs podman rm -f || :"`

上記の Ansible ad-hoc コマンドで、nodes をインベントリーからの単一のホスト、ホストのグループ、または「all」に設定します。

以下は、compute-0 でコマンドを実行する例です。

`ansible -b compute-0 -i /usr/bin/tripleo-ansible-inventory -m shell -a "podman ps -a --format {{'{{'}}.ID{{'}}'}} -f name=haproxy,status=created | xargs podman rm -f || :"`

Ansible ad-hoc コマンドを実行すると、metadata-agent は指定されたネットワーク用に新しいコンテナーを提供するはずです。

Red Hat OpenStack Platform 16.0 では、controller-v6.yaml ファイルが廃止されました。controller-v6.yaml で定義されていたルートは、controller.yaml で定義されるようになりました。(controller.yaml ファイルは、roles_data.yaml で設定される値からレンダリングされる NIC 設定ファイルです。)

以前のバージョンの Red Hat OpenStack Platform director には、2 つのデフォルトルートが含まれていました (外部ネットワーク上の IPv6 用ルートおよびコントロールプレーン上の IPv4 用ルート)。

両方のデフォルトルートを使用するには、roles_data.yaml のコントローラー定義の default_route_networks に、両方のネットワークが含まれるようにしてください (例: default_route_networks: ['External', 'ControlPlane'])。

Red Hat OpenStack Platform 16.0 では、環境ファイル /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-bootstrap-environment-rhel.yaml が廃止されています。

従来、この環境ファイルは、事前にプロビジョニングされたノードを使用する場合に使用されていました。このファイルは RHOSP の以前のリリースで非推奨となり、今回廃止されました。