VMware Integrated OpenStack 4.0 | 2017 年 9 月 19 日 | 組建編號 6437860
VMware Integrated OpenStack with Kubernetes 4.0 | 2017 年 9 月 19 日 | 組建編號 6564406

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

版本說明的內容

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

關於 VMware Integrated OpenStack

VMware Integrated OpenStack 透過精簡整合程序,大幅簡化了 OpenStack 雲端基礎結構的部署。VMware Integrated OpenStack 透過直接在 vCenter Server 中執行的部署管理員 vApp,提供了立即可用的 OpenStack 功能和簡單的組態工作流程。

國際化

VMware Integrated OpenStack 4.0 版提供英文及其他 7 種語言版本:簡體中文、繁體中文、日文、韓文、法文、德文及西班牙文。ASCII 字元必須用於 OpenStack 資源 (例如專案名稱、使用者名稱、映像名稱等) 與基層的基礎結構元件 (例如 ESXi 主機名稱、虛擬交換器連接埠群組名稱、資料中心名稱、資料存放區名稱等) 的所有輸入和命名慣例。 

新增功能

此版本以最新 OpenStack Ocata 版本為基礎並提供下列新功能和增強功能:

  • 支援最新版本的 VMware 產品。VMware Integrated OpenStack 4.0 支援 VMware vSphere 6.5 Update 1、VMware NSX for vSphere 6.3.3 和 VMware NSX-T 2.0,並與其完全相容。
  • SR-IOV 增強功能現在支援使用 direct vnic 類型建立指示 SR-IOV 虛擬功能的連接埠。使用 direct vnic 類型建立的 Neutron 連接埠可在 OpenStack 執行個體啟動階段期間加以使用。此增強功能還新增了將具有多個 vnic 類型的執行個體開機的功能,例如,將同時具有 directnormal vnic 類型的執行個體開機。
  • 多 VC 支援。您可以新增額外運算 vCenter Server 執行個體至 NSX-T VMware Integrated OpenStack 部署。
  • vRealize Automation 整合。您可以透過 vRealize Automation 入口網站中的內嵌式 VMware Integrated OpenStack 索引標籤管理 OpenStack 部署,以及設計 OpenStack XaaS 藍圖。
  • VMware Integrated OpenStack with Kubernetes。從 VMware Integrated OpenStack 4.0 開始,將包含並完全支援 Kubernetes 上建置的容器協調平台。  
  • 主控台記錄。nova console-log 命令現在可用於使用 VMware Integrated OpenStack 4.0 部署的所有虛擬機器。
  • 安全多租用戶。VMware Integrated OpenStack 4.0 採用了提供多租用戶的全新承租人虛擬資料中心結構,這是 OpenStack 發行版中的關鍵區別。此結構提供了為每個承租人配置 CPU 和記憶體資源的功能,這在多承租人環境中提供了資源保證與隔離。管理員透過新引入的 viocli 指令及建立承租人特定類別來設定安全的多租用戶。
  • VLAN 透明度。適用於 vSphere Distributed Switch 的 VMware NSX 外掛程式和 NSX for vSphere 現在支援 VLAN 透明度延伸。此功能允許建立啟用了透明度旗標的 Neutron 網路。
  • 即時調整大小。您可以垂直擴充 VNF 資源,無需停機時間來執行調整大小作業。您可以使用映像中繼資料 os_live_resize 以允許即時調整磁碟、記憶體和 vCPU 的大小。
  • 新授權模式。VMware Integrated OpenStack 4.0 採用了資料中心版本和電信業者版本的授權模式,必須在安裝解決方案後進行套用。如需有關取得有效授權的詳細資訊,請參閱 https://www.vmware.com/products/openstack.html#pricing
  • 完全支援 NUMA。VMware Integrated OpenStack 4.0 在基礎 vSphere 平台上支援 NUMA 感知放置。此功能為電信環境中執行的虛擬網路功能 (VNF) 提供了低延遲和高輸送量。

VMware Integrated OpenStack with Kubernetes

Kubernetes 上建置的容器協調平台現隨附於 VMware Integrated OpenStack,可讓應用程式開發人員佈建完整基礎結構堆疊。此平台提供下列功能:

  • 支援最新版本的 Kubernetes。VMware Integrated OpenStack 4.0 包含並完全支援 Kubernetes 1.7 版。
  • 使用 VMware Integrated OpenStack 順暢部署。容器平台在 VMware Integrated OpenStack 上快速安裝,以取得整合式體驗。
  • 簡單易用的作業 UI。管理 UI 可讓管理員和使用者快速存取 Kubernetes 管理作業。
  • 允許共用或獨佔叢集類型。可採用獨佔模式或共用模式部署叢集。在獨佔模式下,所有授權的使用者均可以管理命名空間;在共用模式下,會嚴格強制執行多租用戶。
  • 企業就緒儲存區和網路。與 VMware Integrated OpenStack 整合可將基於 vSAN 和 NSX 的企業級儲存區和網路延伸至 Kubernetes。
  • 立即可用的 LDAP/AD 整合。使用 Keystone,立即支援將 AD 和 LDAP 與完整多租用戶整合。

相容性

《VMware 產品互通性對照表》提供有關目前版本之 VMware Integrated OpenStack 與 VMware vSphere 元件 (包括 ESXi、VMware vCenter Server、vSphere Web Client 及選用 VMware 產品) 之間相容性的詳細資料。安裝 VMware Integrated OpenStack 或其他 VMware 產品之前,亦請查看《VMware 產品互通性對照表》中有關支援的管理與備份代理程式的資訊。

升級至 VMware Integrated OpenStack 4.0

您可以從 VMware Integrated OpenStack 3.1 部署直接升級至 VMware Integrated OpenStack 4.0。

您可以直接在 VMware Integrated OpenStack 管理員中執行升級程序。《VMware Integrated OpenStack 管理員指南》中對完整的多步程序做出了詳細說明。

VMware Integrated OpenStack 4.0 的開放原始碼元件

產品下載頁面的 [開放原始碼] 索引標籤中提供了適用於 VMware Integrated OpenStack 4.0 中散佈的開放原始碼軟體元件的版權聲明與授權。您也可以針對任意 GPL、LGPL、需要原始碼或需要修改原始碼的其他相似授權下載來源檔案,使其適用於 VMware Integrated OpenStack 的最新可用版本。

已知問題

已知問題分類如下。

VMware Integrated OpenStack
  • 如果未輸入傳輸區域的 UUID,則透過 Horizon 建立提供者網路會失敗

    建立 VLAN 類型的網路時,必須在 Horizon 的 provider_network 文字方塊中提供傳輸區域的 UUID 值。如果未輸入任何值,則建立網路會失敗。

    因應措施:請查看 VMware NSX 介面中傳輸區域的 UUID,然後在 provider_network 文字方塊中輸入該值。

  • 分散式邏輯路由器上 DHCP 停用的子網路無法存取中繼資料

    如果已使用分散式邏輯路由器,則 DHCP 停用的子網路上的執行個體無法透過介面或路由器存取中繼資料。共用和獨佔路由器不遵守此行為。這可能是預期行為,因為相同邏輯網絡 (例如 中繼資料網絡) 無法連結至多個分散式邏輯路由器。

    因應措施:無。

  • 當您從使用 Ubuntu Xenial OVA 建立的 Glance 映像開機時,作業系統無法開機

    作業系統無法開機,並顯示下列錯誤:

    錯誤: 找不到檔案 `/boot/grub/i386-pc/efi_gop.mod'
    錯誤: 找不到檔案 `/boot/grub/i386-pc/efi_uga.mod'

    這是依照 Ubuntu 雲端映像專案中的錯誤追蹤的 Xenial 雲端 OVA 相關問題,如需詳細資訊,請參閱 https://bugs.launchpad.net/cloud-images/+bug/1615875

    因應措施:直到已解決 Ubuntu 錯誤且發佈新的 OVA,才使用 Xenial ISO 映像。

  • 當您將成員新增至使用 --loadbalancer 選項建立的集區時,LBaaS v2 會失敗

    OpenStack LBaaS v2 提供兩個選項來設定負載平衡器集區:--loadbalancer 和 --listener。必須至少指定兩個選項之一來建立集區。
    如果您使用 --loadbalancer 選項為 OpenStack LBaaS v2 建立集區,則新增成員會失敗且負載平衡器會進入 ERROR 狀態。

    因應措施:使用 --listener 選項建立集區。

  • 重新命名的 OpenStack 執行個體出現在 vCenter Server 中的舊名稱下

    如果您使用 nova rename 命令重新命名 OpenStack 執行個體,則變更僅出現在 OpenStack 資料庫中。您的 vCenter Server 執行個體顯示舊名稱。

    因應措施:無

  • 可用性區域組態可能無法成功套用

    修改可用性區域的組態後,在刪除備份 Edge 並重新建立之前,可能無法套用新的組態。

    例如,nsx.ini 檔案中的下列組態提供具有備份 Edge 的可用性區域:
    zone3:resgroup-163:datastore-12:true:datastore-21
    如果您變更區域的資源集區並重新啟動 Neutron,備份 Edge 將不會更新。如果您部署新路由器或網路,其會使用過期的備份 Edge,從而導致可用性區域組態不一致。

    請在變更可用性區域的組態後與重新啟動 Neutron 前,呼叫管理員公用程式:

    1. 修改 nsx.ini 檔案中的可用性區域組態。
    2. 連續刪除所有備份 Edge。
      nsxadmin -r backup-edges -o clean --property edge-id=edge-XX
    3. 重新啟動 Neutron。
    4. 驗證新組態。
      availability-zone-list
  • 當您部署新 OpenStack 執行個體時,憑證不在 CA 存放區中,且可能會顯示錯誤

    當您使用已連線至 vRealize Automation 之其他執行個體所使用的 IP 位址部署新 VMware Integrated OpenStack 執行個體時,可能會遇到憑證錯誤:
    無法執行要求: ; java.security.cert.CertificateException: 憑證不在 CA 存放區中。(工作流程: 叫用 REST 作業/REST 呼叫 (item0)#35)

    因應措施:刪除舊 VMware Integrated OpenStack 執行個體的憑證,然後透過在 vRealize Orchestrator 中執行相關工作流程匯入新憑證。

    1. 登入 vRealize Orchestrator。
    2. 前往程式庫> 組態 > SSL Trust Manager
    3. 執行工作流程以刪除舊 VMware Integrated OpenStack 執行個體的受信任憑證。
    4. 執行工作流程以從 URL 匯入新執行個體的憑證。
  • 部署後無法在 VMware Integrated OpenStack Manager 介面中修改 Syslog 設定

    部署 VIO 後,您無法使用 VIO Manager 介面 (VMware Integrated OpenStack > 管理伺服器 > 編輯設定 > vApp 選項) 中的設定修改 syslog 伺服器組態。

    因應措施:在此修改組態:VMware Integrated OpenStack > OpenStack 叢集 > 管理 > Syslog 伺服器

  • 儀表板可能會將某個磁碟區顯示為已連結,即使其無法連結
    這是已知的 OpenStack 問題,最初報告於 Icehouse 版本。

  • 映像上傳時間過長導致 NotAuthenticated 失敗
    這是已知的 OpenStack 問題 (https://bugs.launchpad.net/glance/+bug/1371121),最初報告於 Icehouse 版本。

  • Glance (映像服務) 不支援包含特殊字元的資料存放區名稱
    如果資料存放區名稱包含非英數字元 (例如冒號、& 符號或逗點),則資料存放區無法新增到 Glance 服務。具體來說,下列字元不允許用於 Glance 資料存放區名稱 (因為它們已保留用於其他目的),否則將會影響組態:: , / $ (冒號、逗號、正斜線、貨幣)。

    因應措施:請勿使用這些符號。

  • 如果其中一個控制器虛擬機器重新開機,高可用性可能會受到影響

    一個控制器失敗時,另一個控制器繼續提供服務。但是,當初始控制器重新開機時,可能無法再提供服務,因此,如果另一個控制器也失敗,則無法使用。

    因應措施:如果控制器失敗並叫用 HA,請檢閱您的部署以確保兩個控制器都能在失敗的控制器重新開機後提供服務。如需有關如何啟動和停止VMware Integrated OpenStack 部署的詳細資訊,請參閱 VMware 知識庫文章2148892

  • 在使用無閘道選項建立的子網路上無法存取中繼資料服務

    使用 NSX 6.2.2 或更早版本的部署不支援 no-gateway 網路;Edge 用於 Edge 路由網路,且 DHCP 用於 VDR 網路。使用 NSX 6.2.3 或更新版本的部署不支援 no-gatewayno-dhcp 網路;DHCP 用於任何 DHCP 網路,且 Edge 用於非 DHCP 網路。在 2.x 中,已關閉 Edge 虛擬機器的自動組態。如果適用,DHCP 會設定閘道,並透過此閘道 Edge 提供中繼資料。因此,使用 no-gateway 選項建立子網路時,不存在擷取中繼資料流量的路由器 Edge。

    因應措施:對於使用無閘道選項的網路,設定 169.254.169.254/32 的路由,將流量轉送到 DHCP Edge IP。

  • 在 Firefox 瀏覽器中上傳修補程式檔案時出現問題

    如果您是使用 Firefox 更新 VMware Integrated OpenStack 的修補程式,則當 Firefox 使用 19 版 Adobe Flash 外掛程式時,上傳將失敗。

    因應措施:使用 CLI 取得修補程式。您也可以使用其他瀏覽器或將 Firefox 瀏覽器中的 Flash 外掛程式還原到舊版 (15、16、17 或 18),即可解決此問題。

  • OpenStack 管理服務未自動重新啟動
    在特定條件下,OpenStack 管理服務未自動重新啟動。例如,在容錯移轉事件後,所有 OpenStack 服務成功重新啟動,但管理服務保持為無法連線。

    因應措施:在 vSphere Web Client 中手動重新啟動 VMware Integrated OpenStack vApp。以滑鼠右鍵按一下 [詳細目錄] 頁面中的圖示,然後選取 [關閉]。所有服務關閉後,開啟 vApp 電源。檢查 OpenStack 管理員記錄,以確認重新啟動成功。

    附註:重新啟動會中斷服務。

  • 執行 Heat 範本時,網路建立可能會失敗

    發生於使用 NSX 6.2.2 的 VMware Integrated OpenStack 部署中。當執行多個 Heat 範本時,在後端,反覆的網路建立有時會失敗。

    已在 NSX 6.2.3 及更高版本中解決。

  • 復原作業傳回「節點已存在」錯誤

    在特定條件下,如果明顯的作業中斷,則執行 viocli recovery - <DB name> 命令會失敗。因此,資料庫節點會保留並會造成錯誤。

    因應措施:手動移除節點並再次執行 viocli recovery 命令。

  • LBaaS v2 移轉:未與集區關聯的健全狀況監視器不會移轉
    在 LBaaS v2 中,健全狀況監視器需要指定並連結至集區。在 LBaaS v1 中,健全狀況監視器可在無集區關聯的情況下建立,並可在單獨的程序中與某一集區關聯。

    因此,當移轉至 LBaaS v2 時,未關聯的健全狀況監視器會被排除。

    因應措施:移轉至 LBaaS v1 前,請將所有健全狀況監視器與某一集區相關聯,以確保其能成功移轉。安裝或升級至 VMware Integrated OpenStack 3.0 後,移轉程序是可選的。請參閱《VMware Integrated OpenStack 管理指南》

  • NSX LBaaS v2.0 承租人限制

    NSX for vSphere 負載平衡器僅為每個子網路支援一個承租人。一般情況下,這並不是問題,因為承租人會建立自己的負載平衡器。如果使用者嘗試建立負載平衡器並將其連結至子網路,則負載平衡器會在錯誤狀態下建立。

    因應措施:允許承租人建立自己的負載平衡器。請勿建立負載平衡器並將其連結至現有的子網路。

  • Heat 堆疊刪除失敗,發生「無法在 NSX Edge 上發佈組態」錯誤

    在使用 NSX v6.2.2 的部署中觀察到。在重壓狀況下,Heat 堆疊或 OpenStack API 可能會在後端失敗。

    因應措施:重試失敗的作業。

  • 映像必須是 VMX 10 版或更高版本
    此問題會影響 streamOptimized 映像及 OVA。例如,如果映像不是 VMX 10 版或更高版本,將其匯入並非難事,但透過此映像建立的 OpenStack 執行個體將不會運作。通常,在 OpenStack 運算節點部署於舊版 ESXi (如 5.5) 上時會發生此問題。您也無法透過修改映像中繼資料 (vmware_hw_version) 或類型模板中繼資料 (vmware:hw_version) 來修正此類映像。

  • 在 vSphere HA 事件顯示同步化且程序啟動失敗後復原

    如果 vSphere 出現 HA 事件,則可能會影響 VMware Integrated OpenStack 部署。復原後,在 VMware Integrated OpenStack 中執行 viocli deployment status -v 命令。如果產生的報告顯示任何同步化或程序啟動失敗,則使用以下因應措施。

    因應措施:使用 viocli services stop 命令停止所有 OpenStack 服務。使用 viocli services start 命令重新啟動所有 OpenStack 服務。重新啟動後,再次執行 viocli deployment status -v 命令。應該不會出現錯誤了。

  • 啟動 RabbitMQ 時,OpenStack 復原有時會失敗

    在少數情況中,VMware Integrated OpenStack 復原會在 RabbitMQ 啟動時失敗。

    因應措施:重複執行復原程序。這一次復原應會成功。

  • Heat 堆疊刪除無法刪除關聯的 Cinder 磁碟區

    在負載過重的情形下,刪除 Cinder 磁碟區的 Heat 堆疊後,有時會出現無法刪除 Cinder 磁碟區的情況,導致出現資料庫鎖死警告且 Cinder 效能降低。

    因應措施:尚無因應措施。

  • 無法在儀表板中修改 SQL 設定的使用者
    如果 VMware Integrated OpenStack 部署設定為使用 LDAP 進行使用者驗證,則無法在 OpenStack 儀表板 (Horizon) 中修改使用者定義,即使是源自 SQL 資料庫的也無法進行修改。

  • OpenStack 儀表板:路由器大小下拉式功能表遺失

    在 OpenStack 儀表板 (Horizon) 中,您可以在建立獨佔路由器時指定大小。不過,當您將路由器從共用修改為獨佔時,路由器大小下拉式功能表不會出現,因此您無法指定路由器大小。

    因應措施:還原預設值,然後重新將類型修改為獨佔。下拉式功能表即會出現。

  • 將防火牆連結到沒有閘道的路由器時,規則不會新增到 NSX 路由器

    防火牆即服務規則僅會新增至具有閘道的路由器,因為沒有閘道的路由器沒有要保護的相關流量,因此這些規則不會影響這些路由器。

    因應措施:若要新增規則,請為路由器設定閘道。

  • 對於 VMware NSX-T 部署,將防火牆連結到沒有閘道的路由器時,規則會新增到 NSX 路由器

    防火牆即服務規則會新增至沒有閘道的路由器,即使沒有符合這些規則的相關流量亦是如此。

    因應措施:若要啟動規則,請為路由器設定閘道。

  • 對於使用 NSX for vSphere 的部署,更新 admin_state 參數沒有影響

    將 Nova 連接埠的 admin_state 參數更新為 False 不會產生任何影響,因為 NSX for vSphere 不支援此參數。

    因應措施:尚無因應措施。

  • 對於 VMware NSX for vSphere 部署,在將閘道連結至 MDProxy 路由器後,NSX Edge (MDProxy Edge) vnic0 索引從 [虛擬機器網路] 變更為 [閘道網路連接埠群組] 

    從 OpenStack 執行個體擷取 md Proxy 伺服器期間,此組態可能會造成影響。Admin 承租人會將 mdproxy 路由器連結至閘道,這會導致從 OpenStack 執行個體存取中繼資料伺服器遭封鎖。

    因應措施:請勿將閘道連結至 MDProxy 路由器。

  • 升級至 4.0 的程序可能會失敗,並在 ansible.log 中顯示「ssh_exchange_identification: Connection closed by remote host」或「Can’t connect to MySQL server」錯誤

    由於基礎結構中的故障 (例如網路延遲或資源爭用),升級程序可能會失敗。

    因應措施:在 vSphere Web Client 中,按一下繼續升級以重試升級。

  • 〈建立物件儲存使用者、服務和端點〉說明文件顯示不正確的命令

    〈建立物件儲存使用者、服務和端點〉的步驟 3 顯示命令:keystone service-create。該命令不正確,並且會傳回錯誤:Keystone: 找不到命令

    因應措施:Keystone CLI 已被取代,以便 keystone service-create 不再有效。將該命令取代為:openstack service create。請參閱〈建立物件儲存使用者、服務和端點〉 (已針對 4.1 版更新)。

  • 在服務閘道 Edge 上,BGP 承租人網路中斷

    在 BGPSpeaker 與服務閘道之間建立 BGP 對等互連後,執行 neutron 命令 neutron bgp-speaker-network-remove 以解除關聯 BGPSpeaker 與外部/提供者網路,可能會導致服務閘道上的承租人路由遺失,即使已使用 neutron bgp-speaker-network-add 還原 BGPSpeaker 的外部/提供者網路亦是如此。導致出現此問題的原因是,Neutron 命令集同時觸發了切換 ECMP 旗標和設定 BGP。

    因應措施:ecmp_wait_time 參數的 2 秒預設值可能不夠長,必須增加到 5 秒。在依序執行一組相同的作業 bgp-speaker-network-removebgp-speaker-add 之後,此變更會修復遺失的路由。變更 nsxv.ini 檔案中的內容值。

  • 中繼資料代理程式與 Nova 伺服器的 HTTP 通訊存在安全性風險

    存在於 Edge 應用裝置上的中繼資料代理程式用作反向 Proxy 並連線到上游 Nova 伺服器,以收集有關 OpenStack 上 NSX 環境的中繼資料資訊。nginx 反向 Proxy 組態也支援純文字式通訊。缺少 TLS 加密會使機密資料洩漏,網路上的攻擊者也可以從站台修改傳輸中的資料。

    因應措施:使用具有 CA 支援的 HTTPS 而非 HTTP,以確保 MDProxy 和 Nova 伺服器之間的通訊安全。執行下列步驟。

    1. 透過新增下列參數至 nova.conf,啟用 Nova 中繼資料 HTTPS 支援。

      [DEFAULT]
      enabled_ssl_apis = metadata
      [wsgi]
      ssl_cert_file = <nova metadata https server certificate file path>
      ssl_key_file = <nova metadata https server private key file path>

    2. 登入 NSX Manager,前往系統 > 信任 > 憑證以根據需要匯入 CA 憑證或憑證鏈結,並記錄憑證的 UUID。
    3. 使用 REST 呼叫建立 HTTPS MDProxy 服務。
      1. 使用下列格式準備 https_mdproxy.json 檔案: 

        https_mdproxy.json json 格式如下:
        {
        "display_name" : "https_md_proxy",
        "resource_type" : "MetadataProxy",
        "metadata_server_url" : "https://10.117.5.179:8433",
        "metadata_server_ca_ids": ["4574853e-e312-4b02-a1c1-002b570c2aa8","940251c9-3500-4bcd-9761-b49d0c2a95d1"],
        "secret": "123",
        "edge_cluster_id" : "00aaf00d-a8ba-42b6-a3bf-9914c8567401"
        }

         
      2. 透過呼叫 REST 部署一個具有 CA 的 HTTPS MDProxy 服務,並等待 NSX Manager 傳回

        201 CREATE success 狀態。curl -i -k -u <nsx-mgr-admin:nsx-mgr-passwd>
        -H "content-type: application/json"
        -H "Accept: application/json"
        -X POST https://<nsx-mgr-ip>/api/v1/md-proxies
        -d "`cat ./https_mdproxy.json`

         

    4.  記錄 MDProxy 服務的 UUID,並使用此 MDProxy 服務做為 VMware Integrated OpenStack 中繼資料 Proxy 服務。現已透過 HTTPS 與憑證驗證確保 MDProxy 與 Nova 伺服器之間的通訊安全。

  • 對於 NSX-T 部署,新建立的第 0 層路由器不會在執行 router-gateway-set 期間連線到第 1 層路由器 

    如果您已設定第 0 層路由器,當您建立新的路由器時,新路由器的 UUID 不會自動填入 nsxv3.ini 檔案。您建立的新第 1 層路由器不會連線到新的第 0 層路由器。您必須手動更新 nsxv3.ini 檔案並重新建立外部網路,才能修正此問題。

    因應措施:執行下列步驟以解決此問題。

    1. 取得新的第 0 層路由器的 UUID。
    2. 開啟 /etc/neutron/plugin/vmware/nsxv3.ini 檔案並更新第 0 層路由器的 UUID。
    3. 重新啟動 Neutron 伺服器。
    4. 刪除現有外部網路並建立新的外部網路。
  • 當您移除已啟用 BGP 之共用路由器的閘道時,可能會觀察到其他已啟用 BGP 的共用路由器上出現短暫的網路中斷

    在共用路由器案例中,可在同一個 Edge 上主控多個路由器。其中一個路由器的閘道 IP 用作 BGP 案例中的路由器識別碼。清除此路由器的閘道時,外掛程式會挑選某些其他已啟用 BGP 之路由器的閘道 IP 做為路由器識別碼並修改此欄位。在此程序期間,由於為此 Edge 上主控的任何其他 BGP 路由器公告的路由遺失,對等互連發生中斷。重新建立對等互連後,對等互連會復原。

    因應措施:尚無因應措施。使用獨佔路由器可避免此問題。

  • 啟用 Neutron 中的 NSX 原則後,承租人流量可能會遭到封鎖

    在 Neutron 外掛程式中啟用安全群組原則後,NSX 防火牆區段順序可能不正確。正確順序必須為:

    1. NSX 原則
    2. 承租人安全群組
    3. 預設區段

    因應措施:設定 VMware Integrated OpenStack 之前,建立第一個 NSX 原則。如果您已進行設定,請移至 vSphere Web Client 的 [NSX 防火牆] 頁面並向上移動原則區段。

VMware Integrated OpenStack with Kubernetes
  • 重新開啟包含 SDDC 提供者之 VMware Integrated OpenStack with Kubernetes 虛擬機器的電源後,OpenStack 服務容器停止運作,並且不會自動重新啟動。

    如果 VMware Integrated OpenStack with Kubernetes 虛擬機器已部署一個 SDDC 提供者,並且虛擬機器已關閉電源後再開啟以解決諸如 ESXi 主機之類的問題,則虛擬機器會移轉到其他主機。針對提供者的後續作業 (例如 Kubernetes 叢集建立和擴充) 將失敗。

    因應措施:若要重新整理提供者,請執行下列步驟:

    1. 在 VMware Integrated OpenStack with Kubernetes 虛擬機器上,以 root 身分使用 OVA 部署期間設定的密碼登入:
      vkube login --insecure
    2. 取得 SDDC 提供者識別碼:
      vkube provider list --insecure
    3. 使用提供者識別碼重新整理 SDDC 提供者:
      vkube provider refresh sddc <provider_id> --insecure 

       

  • 變更管理員密碼後,使用者無法列出使用者和群組。

    快取的管理員密碼與新管理員密碼不同步。

    因應措施:若要更新快取的管理員密碼,請從 VMware GSS 取得 update_admin_pwd 指令碼。然後,在每個叢集上執行 update_admin_pwdvkube cluster update

  • 沒有任何 vSphere 叢集顯示在 SDDC 雲端提供者的 UI 中

    如果您在 UI 中建立 SDDC 雲端提供者並選擇上傳根 CA 檔案,則 [vSphere 叢集] 頁面上不會顯示任何叢集。這是由憑證驗證程序中的錯誤所致。如果您使用受信任的憑證授權機構核准的憑證保護 vCenter Server 或您選擇略過 vCenter Server 憑證驗證,則不會發生此問題。

    因應措施:執行下列其中一項工作。

    • 使用受信任的憑證授權機構核准的憑證保護 vCenter Server,然後建立 SDDC 雲端提供者。
    • 略過 vCenter Server 憑證驗證。為確保安全安裝,建議不要這麼做。
    • 使用 CLI 建立 SDDC 雲端提供者,並將根 CA 檔案做為 CLI 裝載中的 vcenter_certificate 內容傳遞。
  • 輸入提供者名稱後,UI 仍提示輸入提供者名稱

    建立 SDDC 或 OpenStack 雲端提供者時,UI 顯示錯誤「提供者名稱為必填。」,即使已在 [新增提供者] 精靈中指定提供者名稱。

    因應措施:第一次使用特定版本的瀏覽器載入 UI 會發生此問題。若要解決此問題,請關閉瀏覽器索引標籤。然後開啟新索引標籤,並再次連線至虛擬應用裝置。

  • 在 UI 中上傳檔案時顯示錯誤訊息「僅支援 {0} 個檔案」

    上傳錯誤的檔案類型時,UI 中會顯示此錯誤訊息。在下列情況下會發生此問題:

    • 建立雲端提供者或叢集時,您嘗試上傳先前在執行建立程序期間下載的裝載檔案。
    • 建立 SDDC 雲端提供者或 OpenStack 提供者時,您嘗試上傳 CA 憑證檔案。

    因應措施:套用與您情況相關的因應措施:

    • 如果嘗試上傳裝載檔案,請確認裝載檔案副檔名為 .json,並且具有有效的 JSON 內容。
    • 如果嘗試上傳 CA 憑證,請確認憑證檔案副檔名為 .crt。
  • SDDC 雲端提供者建立失敗,並顯示「dpkg: 無法復原的嚴重錯誤,正在中止:」

    建立 SDDC 雲端提供者失敗,並且虛擬應用裝置上的 column-api 容器記錄中會寫入錯誤。顯示的訊息與下列內容類似。

    - docker logs column-api -fTASK [bootstrap-os : Bootstrap | Install python 2.x and pip] *******************172.18.0.2 - - [06/Sep/2017 05:47:32] "GET /runs/46a74449-7123-4574-90c2-3404dfac6641 HTTP/1.1" 200 -fatal: [k8s-node-1-2393e79d-ec6a-4e63-8f63-c6308d72496e]: FAILED! => {"changed": true, "failed": true, "rc": 100, "stderr": "Shared connection to 192.168.0.3 closed.", "stdout": "........"dpkg: unrecoverable fatal error, aborting:", " files list file for package 'python-libxml2' is missing final newline", "E: Sub-process /usr/bin/dpkg returned an error code (2)"]}"

    因應措施:此錯誤是由 SDDC 雲端提供者建立期間檔案損毀所致。請刪除 SDDC 雲端提供者,然後重新建立。

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