VMware NSX-T Data Center Plugin 3.2 for OpenStack Neutron リリース ノート

VMware NSX-T Data Center Plugin 3.2 for OpenStack Neutron | 2021 年 12 月 16 日 各リリース ノートで、追加および更新された機能をご確認ください。

リリース ノートの概要

このリリース ノートには、次のトピックが含まれています。

• リリースの互換性
• VMware NSX-T Data Center Plugin for OpenStack Neutron の新機能
• NSX-T OpenStack Neutron Plugin 3.1 の制限事項
• 既知の問題

リリースの互換性

• Neutron Plugin for Management API（命令型 API）の互換性は次のとおりです。
  • OpenStack Ussuri および OpenStack Train と互換性があります。 
  • VIO 7.2（今後リリースされる可能性がある VIO のバージョンを含む）と互換性があります。
• Neutron Plugin for Policy API（宣言型 API）の互換性は次のとおりです。
  • OpenStack Ussuri および OpenStack Train と互換性があります。 
  • VIO 7.2 および VIO 7.1（今後リリースされる可能性がある VIO のバージョンを含む）と互換性があります。

VIO の今後のバージョンは、リリース時に互換性リストに追加される可能性があります。

互換性とシステム要件の詳細については、『VMware NSX OpenStack Plugin Installation & Configuration Guide』と『NSX-T Data Center インストール ガイド』を参照してください。

OpenStack および KVM のサポートに関する注

3.x リリース シリーズは、KVM および非 VIO OpenStack ディストリビューションをサポートする最後のシリーズです。このディストリビューションには、RedHat OpenStack Platform、Canonical/Ubuntu OpenStack、SUSE OpenStack Cloud、Mirantis OpenStack、特定のベンダーに依存しないコミュニティ ベースの OpenStack などがありますが、これに限定されるものではありません。NSX で 非 VIO OpenStack を使用している場合は、代わりに環境で vRealize Automation または VMware Cloud Director を使用することをお勧めします。

VMware NSX-T Data Center Plugin for OpenStack Neutron の新機能

• VIO を使用した環境での NSX for vSphere から NSX-T への移行のサポート：
  この移行により、VIO/NSX for vSphere を VIO/NSX-T に移行できます。これは Migration Coordinator を使用したインプレース移行で、VIO から作成されたオブジェクトを移行します（VIO の外部で作成された構成は、移行前または移行後に手動で再作成する必要があります）。

以前のバージョンのリリース ノート：

• NSX-T 3.1
• NSX-T 3.0
• NSX-T 2.5
• NSX-T 2.4
• NSX-T 2.3
• NSX-T 2.2
• NSX-T 2.1
• NSX-T 2.0
• NSX-T 1.1

既知の制限事項

• VIO 7.1 は、NSX-T 3.2.0 OpenStack Neutron Plugin for Management API（命令型 API）と互換性がありません。 
• 構成された Edge アップリンク プロファイルのトランスポート VLAN と、展開された VLAN ネットワークに同じ VLAN ID セットが割り当てられていると、悪影響を及ぼす可能性があります。この構成は使用しないでください。トランスポート VLAN と展開された VLAN ネットワーク間で重複する VLAN ID が構成されているときに、0 ではなく MDProxy と DHCP を指定すると、問題が発生します。 
• DHCP が有効になっていると、複数のサブネットをネットワークに追加できません。 
• 特定の Neutron ポートに対して、同じサブネットから複数のアドレスを構成することはできません。
• 同じネットワークに 2 台のルーターを追加することはできません。 
• 1 つのポートに最大 24 個までセキュリティ グループを関連付けることができます。プラットフォームで使用できるタグ/ポートの上限が 30 個のため、このような制限があります。SG に使用できるのは 24 個までです。
• メタデータは、ポート 3000-9000 のみをサポートします。
• IPv6 は、NSX-T OpenStack Neutron Plugin for Policy (NSXP) でのみサポートされます。管理プレーン API 用の NSX-T OpenStack Neutron（ポリシー API 以外）ではサポートされません。
• ESXi と KVM の QoS で、シェーピングと DSCP マーキングはサポートされますが、CoS マーキングと最小 BW はサポートされません。
• QoS は、ハイパーバイザーから外部に送信されるトラフィックに適用されます。ハイパーバイザー内のトラフィックには適用されません。
• FWaaS は、同じ Neutron ルーター上のダウンリンク インターフェイス間の E/W トラフィックに適用されません。
• ファイアウォール、NAT、VIP 間の順序を設定できる場合にのみ、VIP からのトラフィックに FWaaS ルールが適用されます。
• NSX-T Data Center は、プールごとのセッション パーシステンス プロファイルをサポートしません。レイヤー 7 ルールで、複数のプールにトラフィックをルーティングする VIP を有効にすると、これらのプールのパーシステンス プロファイルの設定が無効になります。

既知の問題

• 仮想マシンの起動後、DHCP サーバから IP が正しく取得されているにもかかわらず、トラフィックの送受信ができない。また、実際の仮想マシンの IP が、Neutron から報告された値と異なる

  DHCP リレーが有効な場合、Spoofguard により、仮想マシンからの送信トラフィックがブロックされることがあります。

  回避策：すべてのネットワークでポート セキュリティを無効にします。

• LB VIP からのトラフィックを許可する DFW ルールを明示的に追加しても、有効にならない

  OpenStack は、SNAT 自動マップ モードで NSX-T 仮想サーバを構成します。これは、宛先のメンバーと同じ Tier-1 ルーターの背後にあるクライアントから LB 接続が発生する場合に対処するために必要でした。

  このモードでは、ロード バランサから受信するトラフィックの送信元 IP は VIP そのものではなく、内部で中継するアドレスになります。この状況が発生しても、OpenStack との統合に影響はありません。

  回避策：

  1. セキュリティ グループへのトラフィックをホワイトリストに登録します。
  2. NSX-T で、LB VS が使用する中継ネットワーク上の IP を検索します。このアドレスを含む DFW ルールを作成します。 
  3. 内部サブネットの CIDR からのトラフィックをホワイトリストに登録します。
• neutron l2-gateway-update でデバイス名を更新できない

  <device_name> が定義されていないと、
  neutron l2-gateway-update <l2_gw_id>--device name=<device_name>,interface_names=<interface_name>
  の操作は常に失敗します。この操作は、既存のデバイスのインターフェイスを更新することを意図しています。

  回避策：別のゲートウェイ デバイスを使用する必要がある場合は、neutron l2gw 機能にゲートウェイ デバイスを更新するソリューションがないため、Neutron でレイヤー 2 ゲートウェイを削除して再作成する必要があります。

• リスナーを追加すると、OpenStack ロード バランサがエラー状態になる。同じロード バランサ上で、同じ数のリスナーがすでに構成されている

  NSX-T ロード バランサ サービスで許可される仮想サーバの最大数を超えているため、この問題が発生しています。許可される最大数は、NSX-T のバージョンと loadbalancer サービスのサイズによって異なります。許可される最大値の詳細については、NSX-T 構成の上限を確認してください。

  Octavia サービスは、ロード バランサがエラー状態になったことのみを通知します。バックエンド障害に関する情報は Octavia から取得できません。この情報は、Neutron ログでのみ使用できます。

  回避策：この問題に回避策はありません。

  Octavia では、ロード バランサがエラー状態になると、ロード バランサが変更不能になり、それ以降の操作ができなくなります。

  ただし、既存のリスナーは引き続き動作します。

• 内部サブネットに OpenStack ロード バランサを作成すると、関連する論理スイッチの論理ポートが停止する

  OpenStack ロード バランサ（Neutron LBaaS v2 と Octavia の両方）のネットワーク ドライバは常に、ロード バランサ用に Neutron 論理ポートを作成します。

  NSX-T では、ロード バランサ サービスが Tier-1 ルーターに実装されるため、Neutron LBaaSv2 または Octavia から指定された VIP サブネット上に論理ポートがありません。

  このため、ロード バランサが削除されると、未使用の論理ポートが削除されます。

  回避策：この論理ポートの動作状態が「停止」になっていても問題ありません。この状態は無視できます。

• Octaivia で、Cookie ベースのセッション パーシステンスを使用して L4 ロード バランサを更新すると、ロード バランサがエラー状態になる

  プールのセッション パーシステンス プロファイルを送信元 IP から Cookie ベースに更新すると、ロード バランサがエラー状態になり、変更不能になります。

  Octavia サービスは、プールに適用されているセッション パーシステンスのタイプが適切かどうかを検証しません。

  そのため、誤った情報（TCP 仮想サーバでの HTTP Cookie ベースのセッション パーシステンスの要求）で NSX-T を更新すると、NSX-T はエラーを返し、Octavia ロード バランサがエラー状態になります。

  Octavia は、ドライバ エラーに関する詳細を表示しません。

  回避策：この問題に回避策はありません。ロード バランサがエラー状態になると、変更不能になり、リカバリできなくなります。

• ポリシーに移行した後、ポリシー マネージャで VIP ポートがセグメント ポートとして表示されます。

  NSX-T ポリシーと OpenStack の統合で VIP にセグメント ポートが作成されない場合でも、Neutron LB ドライバによって MP 上に作成された論理ポートはポリシーに移行されます。

  回避策：回避策はありません。この追加のセグメント ポートは無関係なため、Neutron NSX-T ポリシー プラグインによって無視されます。移行後は安全に削除できます。

• 次のエラーが発生し、LB 健全性モニターの削除が失敗します。Server-side error: 'NoneType' object has no attribute 'load_balancer_id'.

  これは Octavia サービスのバグで、VMware NSX プラグインに影響を与えます。Octavia サービスが健全性モニターに対応するプールの取得に失敗し、このエラーがトリガされることがあります。

  このバグは現在、https://storyboard.openstack.org/#!/story/2008231 で追跡されています。

  回避策：健全性モニターを削除すると、最終的に処理に成功します。