適用於 OpenStack Neutron 的 VMware NSX-T Data Center 外掛程式 3.1 | 2020 年 10 月 30 日

查看這些版本說明的新增項目和更新。

版本說明的內容

此版本說明涵蓋下列主題:

版本相容性

  • 用於管理 API (命令式 API) 和原則 API (宣告 API) 的 Neutron 外掛程式為:
    • 與 OpenStack Stein 和 OpenStack Train 相容 
    • 與 VIO 7.0.1 和 VIO 6.0.1 相容
  • 由 NSX-T 3.1 OpenStack Neutron 外掛程式公開的新功能無法與 Stein 或 VIO 6.0.1 搭配使用 (這些新功能處於回溯相容性模式)。

如需相容性和系統需求的詳細資料,請參閱《VMware NSX OpenStack 外掛程式安裝和組態指南》和《NSX-T Data Center 安裝指南》

適用於 OpenStack Neutron 的 VMware NSX-T Data Center 外掛程式的新增功能

  • 轉換為使用管理 API 的 OpenStack 環境所適用的 NSX-T 原則 Neutron 外掛程式:可讓您將具有 NSX-T 環境的 OpenStack 從管理 API 移至原則 API。這可讓您能夠將在 NSX-T 2.5 之前部署的環境移至最新的 NSX-T Neutron 外掛程式,並使用最新的平台功能,例如 vRF-lite。
    此功能需要 VIO 版本才能受到支援。強烈建議您先執行 NSX-T 備份再繼續進行移轉,因為此程序在完成後即無法復原。
     
  •  能夠在 OpenStack Neutron 路由器上變更 NAT 和防火牆強制執行的順序:這可讓您在部署中選擇 NAT 與 FWLL 之間的作業順序。在 OpenStack Neutron 路由器層級 (對應至 NSX-T 中的第 1 層),作業的順序可以定義為 NAT -> 防火牆或是防火牆 -> NAT。這是指定 OpenStack 平台的全域設定,且是僅限原則外掛程式的功能。
     
  • 可設定狀態的 DHCPv6 的支援:這會新增至在 3.0 和 2.5 中提供的 IPv6 功能,讓您能夠使用 IPv6 工作負載。您現在可以選擇 SLAAC 與 DHCPv6 以進行 IP 定址。這是僅限原則外掛程式的功能。

檢視先前版本的版本說明:

已知限制

  • 如果直接安裝,則 Train 或 Stein 套件必須在執行 Ubuntu 18.04 或 RHEL 7.7 的控制器節點上執行。
  • (RHEL 8.2 需要 Python 3 套件,且 Ubuntu 20.04 不支援 Train。)
  • VIO 7.0.0 與 NSX-T 3.1.0 OpenStack Neutron 外掛程式不相容。請將 VIO 更新為 VIO 7.0.1。
  • 如果所設定的 Edge 上行設定檔「傳輸 VLAN」和所部署的 VLAN 網路同時設定了相同的 VLAN 識別碼集,則可能會產生中斷副作用。請勿使用此組態。「傳輸 VLAN」與所部署的 VLAN 網路之間若設定了重疊的 VLAN 識別碼,將會導致 MDProxy 和 DHCP 發生所見到的問題,而不是只看到 0。 
  • 無法將多個已啟用 DHCP 的子網路新增至網路。 
  • 無法為指定的 Neutron 連接埠設定來自相同子網路的多個位址。
  • 無法將兩個路由器新增至相同網路。 
  • 每個連接埠最多只能關聯 24 個安全群組。由於平台中最多只能有 30 個標籤/連接埠,所以有此限制。SG 可使用 24 個。
  • 中繼資料只支援連接埠 3000-9000。
  • IPv6 僅支援用於原則 (NSXP) 的 NSX-T OpenStack Neutron 外掛程式,而不支援用於管理平面 API (非原則) 的 NSX-T OpenStack Neutron 外掛程式。
  • QoS 目前可對 ESXi 和 KVM 支援「控管」和「DSCP 標記」(既不支援「CoS 標記」,也不支援「最小 BW」)。
  • 會針對離開 Hypervisor (而非內部 Hypervisor) 的流量強制執行 QoS。
  • 在相同 Neutron 路由器上,下行介面之間的 E/W 流量不會強制執行 FWaaS。
  • 只有在防火牆、nat 和 VIP 之間的順序允許時,才會在來自 VIP 的流量上強制執行 FWaaS 規則。
  • NSX-T Data Center 不支援每一集區的工作階段持續性設定檔。當第 7 層規則啟用 VIP 以將流量路由傳送至多個集區時,這些集區上的持續性設定檔設定將不會有作用。

已解決的問題

  • FWaaS 規則未如預期般強制執行。可與 NSX-v 驅動程式或參考實作驅動程式正確搭配運作的某些規則,似乎已遭到 NSX-T Edge 防火牆忽略。

    NSX-T 的防火牆行為與 NSX-v 和參考實作不同:入口會在 NAT 後進行 FWaaS,出口則會在 NAT 之前進行 FWaaS。

  • 設定接聽程式的預設集區之後,LB VIP 不會接收到任何流量。

    即使 Neutron-LBaas 允許,更新預設集區或接聽程式的動作也不會在 NSX-T 中實作。因此,即使會正確更新 NSX-T 虛擬伺服器上的集區,也不會使用 VS 識別碼來更新 NSX-T LBS。

    因此,如果 VS 尚未與 LBS 相關聯,則系統將不會建立該關聯。

已知問題

  • 虛擬機器開機時,會從 DHCP 伺服器正確取得 IP,但無法傳送/接收任何流量;實際的虛擬機器 IP 與 Neutron 所報告的 IP 不同

    當 DHCP 轉送啟用時,SpoofGuard 可能會封鎖來自虛擬機器的輸出流量。

    因應措施:在每個網路上停用連接埠安全性。

  • 為了允許來自 LB VIP 的流量而明確新增 DFW 規則並沒有用。

    OpenStack 會使用 SNAT 自動對應模式來設定 NSX-T 虛擬伺服器。必須這麼做才能滿足下列使用案例:LB 連線會從位於與目標成員相同之第 1 層路由器後方的用戶端建立。

    在此模式下,來自負載平衡器的流量,其來源 IP 並非 VIP 本身,而是內部傳送網路上的位址。這不會對 OpenStack 整合造成任何問題。

    因應措施:

    1. 將進入安全群組的流量列入白名單。
    2. 在 NSX-T 上尋找 LB VS 所用傳送網路上的 IP。建立至少包含此位址的 DFW 規則。 
    3. 將來自內部子網路 CIDR 的流量列入白名單。
  • 使用 neutron l2-gateway-update 時無法更新裝置名稱。

    作業
    neutron l2-gateway-update <l2_gw_id>--device name=<device_name>,interface_names=<interface_name>
    一律會失敗 (如果尚未定義 <device_name> 的話)。實際上確實會想使用此作業來更新現有裝置上的介面。

    因應措施:如果需要使用不同的閘道裝置,則必須在 Neutron 上刪除並重新建立第 2 層閘道,因為 Neutron l2gw 功能不會提供用來更新閘道裝置的解決方案。

  • 新增接聽程式後,Openstack 負載平衡器會進入錯誤狀態。已在相同的負載平衡器上設定一致數目的接聽程式。

    發生此情況的原因是,已超過 NSX-T 負載平衡器服務上允許的虛擬伺服器數目上限。允許的數目上限取決於 NSX-T 版本和負載平衡器服務的大小。如需允許上限的詳細資料,請參閱 NSX-T 的組態上限值。

    Octavia 服務只會報告負載平衡器已進入錯誤狀態的事實。無法透過 Octavia 擷取到後端失敗的相關資訊。此資訊只能在 Neutron 記錄中取得。

    因應措施:此問題沒有因應措施。

    在 Octavia 中,當負載平衡器進入 ERROR 狀態時,該負載平衡器就會變為不可變的狀態,且不允許在其上執行進一步的作業。

    但現有接聽程式仍會繼續運作。

  • 在「內部」子網路上建立 OpenStack 負載平衡器時,相關的邏輯交換器會有一個已關閉而沒有作用的邏輯連接埠。

    Openstack 負載平衡器 (Neutron LBaaS v2 和 Octavia) 都有「網路驅動程式」,此驅動程式一律會為負載平衡器建立 Neutron 邏輯連接埠。

    但是,由於會在第 1 層路由器上實作 NSX-T 負載平衡器服務,因此,從 Neutron LBaaSv2 或 Octavia 指定的 VIP 子網路上不會有邏輯連接埠。

    因此,會有未使用的邏輯連接埠,並會在刪除負載平衡器時加以移除。

    因應措施:這個處於「關閉」運作狀態的邏輯連接埠並無危害,因此可以忽略。

  • 在 Octaivia 中,使用以 Cookie 為基礎的工作階段持續性來更新 L4 負載平衡器,將會以 ERROR 狀態傳送負載平衡器。

    將集區中的工作階段持續性設定檔從來源 IP 更新為以 Cookie 為基礎時,負載平衡器會進入 ERROR 狀態,並變為不可變的狀態。

    很遺憾,Octavia 服務不會驗證是否已將適當的工作階段持續性類型套用至集區。

    因此,使用錯誤資訊 (在 TCP 虛擬伺服器上要求以 HTTP Cookie 為基礎的工作階段持續性) 來更新 NSX-T 時,NSX-T 就會傳回錯誤,然後以錯誤狀態傳送 Octavia 負載平衡器。

    很遺憾,Octavia 無法顯示驅動程式錯誤的相關詳細資料。

    因應措施:此問題沒有因應措施。負載平衡器一旦進入 ERROR 狀態,就會變為不可變的狀態,且無法加以復原。

  • 在移轉至原則後,「VIP 連接埠」將會在原則管理程式上顯示為區段連接埠。

    Neutron LB 驅動程式在 MP 上建立的邏輯連接埠會移轉至原則,即使 OpenStack 與 NSX-T 原則的整合未建立 VIP 的區段連接埠,仍是如此。

    因應措施:沒有可用的因應措施。這個額外的區段連接埠不相關,且會被 Neutron NSX-T 原則外掛程式忽略。您可以在移轉後安全地加以移除。

  • LB 健全狀況監視器刪除失敗,並出現伺服器端錯誤:"「NoneType」物件沒有屬性「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