VMware NSX-T Data Center Plugin 3.1 for OpenStack Neutron | 2020 年 10 月 30 日

各リリース ノートで、追加および更新された機能をご確認ください。

リリース ノートの概要

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

リリースの互換性

  • 管理 API(命令型 API)とポリシー API(宣言型 API)の Neutron Plugin の互換性は次のとおりです。
    • OpenStack Stein および OpenStack Train と互換性があります。 
    • VIO 7.0.1 および VIO 6.0.1 と互換性があります。
  • NSX-T 3.1 OpenStack Neutron Plugin で公開されている新機能は、Stein および後方互換性モードの VIO 6.0.1 で使用できません。

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

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

  • 管理 API を使用する OpenStack 環境の NSX-T ポリシーの Neutron Plugin への変換:NSX-T 環境の OpenStack を管理 API からポリシー API に移行できます。これにより、NSX-T 2.5 より前の環境を最新の NSX-T Neutron Plugin に移行し、vRF-lite などの最新のプラットフォーム機能を利用できるようになります。
    この機能を使用するには、この機能をサポートする VIO バージョンが必要です。移行を続行する前に、NSX-T のバックアップを実行することを強くおすすめします。この処理は、完了後にロールバックできません。
     
  •  OpenStack Neutron Router での NAT とファイアウォールの適用順序の変更:NAT と FWLL 間で環境内の操作の順序を選択できるようになります。OpenStack Neutron Router レベル(NSX-T の Tier-1 にマッピング)で、操作の順序を NAT からファイアウォール、またはファイアウォールから NAT に定義できます。これは、特定の OpenStack プラットフォームとポリシー プラグインのみの機能に適用されるグローバル設定です
     
  • ステートフル DHCPv6 のサポート:3.0 および 2.5 で提供される IPv6 機能が追加され、IPv6 のワークロードを使用できるようになります。IP アドレスの指定で SLAAC と DHCPv6 を選択できるようになりました。これは、ポリシー プラグインのみの機能です。

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

既知の制限事項

  • 直接インストールされている場合は、Ubuntu 18.04 または RHEL 7.7 のいずれかを実行しているコントローラ ノードで、Train または Stein パッケージを実行する必要があります。
  • RHEL 8.2 には Python 3 パッケージが必要です。Ubuntu 20.04 は Train でサポートされていません。
  • VIO 7.0.0 は NSX-T 3.1.0 OpenStack Neutron Plugin と互換性がありません。VIO を VIO 7.0.1 に更新してください。
  • 設定された 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 を有効にすると、これらのプールのパーシステンス プロファイルの設定が無効になります。

解決した問題

  • FWaaS ルールが期待どおりに適用されない。NSX-v ドライバまたはリファレンス実装ドライバで正しく動作するルールの一部が、NSX-T Edge ファイアウォールで無視されているように見える

    NSX-T のファイアウォール動作は、NSX-T とリファレンス実装とで異なります。入力方向の場合は NAT の後、出力方向の場合は NAT の前に FWaaS が実行されます。

  • リスナーのデフォルト プールを設定した後、LB VIP がトラフィックを受信しない

    デフォルトのプールまたはリスナーの更新は、NSX-T では実装されていないアクションです。Neutron-LBaas で許可されていても、このアクションは実行されません。そのため、NSX-T 仮想サーバのプールが正しく更新されても、VS ID で NSX-T LBS が更新されません。

    VS が LBS と関連付けられていない場合、この関連付けは作成されません。

既知の問題

  • 仮想マシンの起動後、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 で追跡されています。

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

check-circle-line exclamation-circle-line close-line
Scroll to top icon