作者： Colin Jao 饒康立 – VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化、分散式安全防護技術與SD-WAN方案的介紹與推廣。

本篇我們要專注在NSX Data Center方案內Management Cluster的需求。以前在NSX for vSphere或是NSX-T 2.3版本之前，管理構件包含了NSX Manager與NSX Controllers分別各司其職。但從NSX-T 2.4版之後，生產環境內管理與控制層就是全部由三台虛機組成NSX Management Cluster。這個Cluster負責所有管理、控制、組態儲存等作業，會自動在內部進行資料庫同步。原本的NSX Manager / NSX Controller，以及後續新架構內的Policy配置等作業，都是由這三台虛機來提供。

 

安裝NSX Manager Cluster時，這些虛機有四種Size可以選擇：

 

  • Extra Small: 僅在特殊情境，如連接NSX Cloud方案內的Cloud Service Manager構件使用

 

  • Small: PoC環境

 

  • Medium: 這組Management Cluster管理 64 個 Host 以下的環境

 

  • Large: 這組Management Cluster需要管理 64 個 Host 以上的環境

 

基本上選擇不同的Size時，差異只在配置的vCPU / Memory。Medium / Large Size的Manager VM需求資源列於下表：

我建議大家不要浪費時間在考慮Extra Small或Small這兩種規格上，任何環境，PoC或中小型就用Medium，大型就用Large，簡單又好記。

 

除了需求資源外，Management Cluster配置時有下列這幾點要注意：

 

  • 在VMware的文件或是NSX PM這邊的正式回應，在NSX-T 2.4版的目前架構，NSX Management Cluster不支援跨Site。

 

  • 在這三台Manager VM間的Latency要求是需要低於10 ms。

 

  • 所以大家可能會想要詢問一個問題：如果我們建立一個Stretched Cluster，Cluster內延遲時間絕對低於10 ms，甚至同地不同中心內可能只有1~2 ms，此時還不能跨Site嗎？我個人只能說，說真的，看不出來這樣的配置會有任何問題。但當然，如果有這樣的需求，請與VMware的專業服務顧問討論並確認一下架構。

 

  • Management Cluster與Compute / Edge Node之間的延遲時間需要低於 150 ms。因此是的，Management Cluster可以遠端管理異地的NSX環境。

 

  • Management Cluster是2+1的備援機制，生產環境內，任何時間不應該有兩台以上的Manager失效。因此在正式環境內，請務必在Manager VM上配置Anti-Affinity Rule，避免同一台vSphere Host上面有兩台Managers，而在單台vSphere硬體失效時出現同時兩台以上Manager失效的狀況

 

  • 無論是否有獨立的 Management Cluster， Manager VM 應該要建立於一個有至少四台 Host 以上的 vSphere Cluster 上，並透過標準vSphere HA / DRS機制進行保護。此時在這個vSphere Cluster要進行任何維護、升級、硬體更換的作業時，不會影響Management Cluster運作。

 

大家會問如果真的出現兩台以上Manager失效的狀況，此時會有什麼影響呢？我們不希望這樣的狀況出現，但如果發生：

 

  • 現有的虛機 / 容器傳輸不受影響

 

  • 無法進行配置更新

 

  • 新產出的虛機 / 容器由於Control-Plane失效，無法更新這些虛機或容器的位置，會沒有網路連線

 

  • 現有的虛機會被禁止進行vMotion

 

另外在2.4版開始由於架構面變動有三台Manager VM了，此時我們的管理者或是外部的自動化系統要連到哪一台Manager來進行組態檢視或變更呢？大家有下列的不同架構方式進行選擇：

  • 左邊的方式是預設模式，管理者或外部自動化系統這三台你想連哪就連哪，三台間配置會自動同步。好處是隨便連，但壞處是沒有自動切換。比如說我們配置vRealize Automation要連到NSX時是連到Manager A的IP或是FQDN。如果Manager A失效了，此時vRA也不知道可以連到Manager B或是C。因此不然是等Manager A回復，不然就是管理者得要手動去重新配vRA上面的NSX參數（改成連B or C）

 

  • 中間的模式是我們可以在NSX上面設定一個Virtual IP。比如說上圖內，三台Manager分別是1.1.10 / 11 / 12，而設定一個Virtual IP是10.1.1.1（這些IP必須要在同一個網段內不能過routing）。此時NSX會自動配置所有往虛擬IP的連線由某一台Manager，比如說是B，來負責。但如果偵測到B失效了，NSX會再找另一台Manager比如說A來接手，但大家仍然是往10.1.1.1這個Virtual IP進行連線。此時好處就是可以自動切換，管理者不用手動去進行外部系統的連線異動了。

 

  • 最帥的方法是右邊，就是有一個外部的負載平衡器來建Virtual Server。管理者或自動化系統連到這個Virtual Server時，外部負載平衡器自動將不同連線各自派送到不同的Manager。這邊的好處是不僅自動切換，而且不同來源的自動化系統 / 管理者可以由不同的Manager VM來負責，系統scalability也擴大了。

 

  • 但右邊的問題是用戶得要準備一台外部的Load Balancer，比較貴。你問可不可以用NSX自己的？兄弟，此時NSX還沒建起來啊，怎麼啟用Load Balancer啊？

 

所以在大型生產環境，用右邊獨立負載平衡器的方式是架構上最好的。而一般的環境，採用內建Virtual IP的形式就綽綽有餘了。

 

因為Management Cluster就是用來乘載三個Manager VM（以及其他管理用的虛機，像是vCenter / vRealize Log Insight / vRealize Operations…等），在硬體規格上的要求不多。規劃上整理如下：

 

  • vSphere至少要可以支援VM version 10以上，也就是至少要5版。兄弟啊現在vSphere / vCenter大家都用6.5版以上了，也該換了吧～

 

  • 這個資源池應該要有至少四台獨立的vSphere伺服器，並透過標準 HA / vMotion / DRS機制進行保護。在任何時候，我們應該要能允許至少一台vSphere可以進入Maintenance Mode。因此，使用Enterprise Plus版本的vSphere是較為建議的（支援DRS）。

 

  • 實體伺服器的所有硬體沒有特殊需求，但應該要能符合VMware硬體相容性清單。

 

就到這邊。下篇網誌我們進入Edge Node的部分。