RSS
 

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

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

版本說明的內容

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

版本相容性

  • 與 OpenStack Stein 和 OpenStack Rocky 相容 
  • 與 VIO 6.0、VIO 5.1.0.3、VIO 4.1.2.3 和 RHOSP 13 相容 (後續可能會新增其他廠商的 OpenStack 版本)。

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

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

  • 支援 Stein 和 Rocky。
    新功能會在 Stein 外掛程式中公開，Rocky 外掛程式則會提供現有外掛程式與 2.5 的相容性。
     
  • 新的 Neutron 外掛程式支援 NSX-T 原則 API。
    除了現有的 Neutron 外掛程式，NSX-T 2.5 還引入了新的原則外掛程式，此外掛程式會耗用 NSX-T 原則 API。
     
  • 適用於 NSX-T 原則 API 的 Neutron 外掛程式支援 IPv6。
    這涉及靜態 IPv6 位址繫結、Neutron 安全群組、使用 IPv6 位址的 FWaaS、Neutron 路由器 IPv6 介面、Neutron 路由器雙堆疊介面、使用 IPv6 的 Neutron 路由器無 SNAT 路由重新分配、使用 IPv6 的 Neutron 路由器靜態路由、使用 IPv6 的 Neutron 連接埠安全性，以及 SLAAC。
    僅適用於原則的 NSX-T Neutron 外掛程式。
     
  • OpenStack Neutron 路由器部署最佳化。
    OpenStack Neutron 路由器會轉譯為第 1 層。以前，其一律會建立第 1 層 DR (分散式路由器) 和第 1 層 SR (在 Edge 節點上建立的服務路由器)。現在，外掛程式只會在需要時建立第 1 層 SR (即啟用服務時)，並在不需要時將其移除。這可提高輸送量並將資源使用量最佳化。
    兩個 NSX-T Neutron 外掛程式 (管理平面 API 和原則 API) 都適用  
     
  • OpenStack Neutron 路由器放置最佳化。
    OpenStack 建立的第 1 層路由器可放置在與第 0 層路由器不同的叢集中。 
    兩個 NSX-T Neutron 外掛程式 (管理平面 API 和原則 API) 都適用
     
  • 支援 Octavia 負載平衡服務
    兩個 NSX-T Neutron 外掛程式 (管理平面 API 和原則 API) 都適用。Octavia 支援僅適用於 Stein 的 Neutron 外掛程式版本。
     
  • 支援 FWaaSv2
    兩個 NSX-T Neutron 外掛程式 (管理平面 API 和原則 API) 都適用
     
  • 將 L2 橋接器移到 Edge 叢集。
    L2 橋接器現在由 Edge 叢集提供，因此可讓非 ESXi 客戶在其環境中實作橋接器。
    僅適用於管理平面 API 的 NSX-T Neutron 外掛程式。

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

NSX-T OpenStack Neutron 外掛程式 2.5 限制

  • 如果所設定的 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 以將流量路由傳送至多個集區時，這些集區上的持續性設定檔設定將不會有作用。

已解決的問題

  • 將 NSX-T 從 2.3 升級至 2.4 後，VIO5 上會發生 Neutron 外掛程式失敗。建立安全群組規則一律會失敗，並顯示 500 錯誤。

    將 NSX-T 升級至 2.4 後，無法建立安全群組規則。每次嘗試都會失敗，並顯示回應代碼 500。

    完成 NSX-T 升級後，重新啟動 Neutron 伺服器。

    重新啟動時，Neutron 伺服器會讀取正確的 NSX-T 版本，並將 DFW 規則要求適當地格式化。

已知問題

  • 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