第4章 テクニカルノート

以前のリリースでは、暗号化された Block Storage サービス (cinder) ボリュームイメージが削除されても、対応する鍵は削除されませんでした。

Red Hat OpenStack Platform 16.0 では、この問題が解決されています。Image サービスが cinder ボリュームイメージを削除すると、そのイメージの鍵も削除されます。(BZ#1481814)

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 によりデプロイされるデフォルト) の使用を推奨します。(BZ#1779221)

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 (BZ#1749483)

今回の機能拡張により、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 ベースのネットワークインターフェースが設定されたインスタンスのライブマイグレーションが可能になりました。(BZ#1360970)

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

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

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

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

[ironic]
api_max_retries = 180

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

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 ラッパースクリプトが使用され、仮想マシンの起動時にメタデータを提供することができます。すでに実行中の問題のある仮想マシンは、回避策の適用後に再起動すると、通常どおりに動作するはずです。(BZ#1790467)

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

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'])。(BZ#1631508)

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

parameter_defaults:
   NovaLocalMetadataPerCell: True

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

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

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 イメージをブートする要求を送信しません。(BZ#1710634)

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

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

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