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

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

版本說明的內容

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

版本相容性

  • 管理 API (命令式 API) 的 Neutron 外掛程式為:
    • 與 OpenStack Stein 和 OpenStack Rocky 相容 
    • 與 VIO 5.1.0.4、VIO 6.0.0.1 相容 (請參閱已知限制)
  • 原則 API (宣告式 API) 的 Neutron 外掛程式為:
    • 與 OpenStack Stein 相容 (後續可能會新增其他廠商 OpenStack 版本)。
    • 與 VIO 6.0.0.1 相容 (請參閱已知限制)
  • 與 VIO 6.0.0.1 互通性的已知問題會在已知限制區段中說明。
  • 由 NSX-T 3.0 OpenStack Neutron 外掛程式公開的新功能無法搭配 VIO 6.0.0.1 和 VIO 5.1.0.4 使用 (這些新功能處於回溯相容性模式)。

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

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

  • 在原則 API 的 Neutron 外掛程式中支援 IPv6 負載平衡器。
    這可讓您在使用 Octavia 或 LBaaSv2 時,在 OpenStack 整合中啟用 IPv6。
     
  • 在原則 API 的 Neutron 外掛程式中支援 IPv6 IP 區塊。
     
  • 在原則 API 的 Neutron 外掛程式中支援 VPNaaS。
    這可讓您在 OpenStack 的第 1 層閘道上耗用 NSX-T VPN 服務。
     
  • 在原則 API 的 Neutron 外掛程式中支援使用 vRF-lite 作為外部網路。
    在 NSX-T 3.0 中,第 0 層可以有多個 vRF-lite。在 OpenStack 中將第 0 層對應至外部網路的模型已延伸至第 0 層 vRF-lite,以便輕鬆執行多租戶並改善資源配置。
     
  • 能夠在原則 API 的 Neutron 外掛程式中通告 OpenStack Neutron 路由器 (無 NAT) 上的所有靜態路由。
    除了已連線的路由以外,另外提供了一項設定來通告無 NAT OpenStack Neutron 路由器的所有靜態路由。
     
  • 允許在原則 API 的 Neutron 外掛程式中,包含防火牆規則 Syslog 的專案資訊部分。
    NSX-T 允許將規則標籤作為防火牆資料平面 Syslog (允許/拒絕) 的一部分,以提供租用資訊。此增強功能可讓專案成為防火牆記錄的一部分。這可讓您以更簡易的方式依專案分級記錄以及管理多租戶。

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

已知限制

  • 與 NSX-T 3.0 搭配使用時,VIO 6.0.0.1 具有一些已知的限制。(這兩個問題都源於 VIO 6.0.0.1 所隨附未受管理 OpenStack Neutron 外掛程式的平台變更。)
    • 嘗試變更連接埠的管理狀態會導致行為不一致。基礎原因是在原則中新增管理狀態,而 VIO 6.0.0.1 中的 OpenStack Neutron 外掛程式並不會將其列入考量。
    • 有時在 DevOps 工作流程中刪除負載平衡器可能會失敗,且會同時建立/刪除並行堆疊 (使用 Terraform/Rally/Heat)。可用的因應措施是識別導致問題的負載平衡器,並將其再次刪除。
  • VIO 6.0.0.1 和 VIO 5.0.0.4 不支援 VDS 7.0 上的 NSX-T,且預期具有 N-VDS 的 NSX-T 部署。
  • 如果所設定的 Edge 上行設定檔「傳輸 VLAN」和所部署的 VLAN 網路同時設定了相同的 VLAN 識別碼集,則可能會產生中斷副作用。請勿使用此組態。「傳輸 VLAN」與所部署的 VLAN 網路之間若設定了重疊的 VLAN 識別碼,將會導致 MDProxy 和 DHCP 發生所見到的問題,而不是只看到 0。 
  • 無法將多個已啟用 DHCP 的子網路新增至網路。 
  • 無法將兩個路由器新增至相同網路。 
  • 每個連接埠最多只能關聯 9 個安全群組。由於平台中最多只能有 15 個標籤/連接埠,所以有此限制。SG 可使用 9 個。 
  • 中繼資料只支援連接埠 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。
  • 不會對來自 VIP 的流量強制執行 FWaaS 規則。
  • NSX-T Data Center 不支援每一集區的工作階段持續性設定檔。當第 7 層規則啟用 VIP 以將流量路由傳送至多個集區時,這些集區上的持續性設定檔設定將不會有作用。

已知問題

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

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

    因應措施:請確定在定義規則時有考慮以下事實:系統會在 SNAT 發生之前強制執行出口規則,而在 DNAT 發生之後強制執行入口規則。

    下列注意事項同時適用於 ALLOW 和 DENY 規則。 

    入口 FWaaS 規則 

    來源位於 NO-SNAT 路由器後方 

    • 來源 IP 應為內部伺服器 IP 或內部子網路 CIDR

    來源位於 SNAT 路由器後方 

    • 如果來源伺服器與浮動 IP 相關聯,請使用浮動 IP 位址 

    • 否則,請使用來源路由器的閘道 IP 

    外部來源 

    • 使用實際的來源 IP 位址或 CIDR 

    目的地

    • 由於系統會在 NAT 之後強制執行 NSX-T Edge 防火牆,因此請使用內部伺服器 IP 或內部子網路 CIDR 

    出口 FWaaS 規則 

    來源 IP 

    • 在此情況下,由於系統會在 NAT 之前強制執行 NSX-T Edge 防火牆,因此請使用內部伺服器 IP 或內部子網路 CIDR 

    目的地 IP 

    • 外部目的地,請使用實際的來源 IP 或 CIDR 

    • 目的地位於 NO-SNAT 路由器後方,目的地 IP 應為內部伺服器 IP 或內部子網路 CIDR 

    • 目的地位於 SNAT 路由器後方,目的地伺服器必須透過浮動 IP 公開。應使用浮動 IP 來作為 FWaaS 規則的目的地 IP。 

  • 虛擬機器開機時,會從 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 的流量列入白名單。
  • 設定接聽程式的預設集區之後,LB VIP 不會接收到任何流量。

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

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

    因應措施:

    1. 從接聽程式移除集區,或將其刪除。
    2. 在集區上設定接聽程式,或建立新集區來設定接聽程式識別碼。
  • 使用 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 狀態,就會變為不可變的狀態,且無法加以復原。

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