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

續前篇對於NSX Advanced Load Balancer (Avi Networks) 方案內Controller的討論，我們簡述了Controller的功能，也說明了Controller Cluster的2+1 Quorum備援架構。接下來，那Controller實際上要怎麼放呢？

 

前面相關網誌文章內我們不斷地強調Avi可以支援多種不同的私有雲公有雲環境。Controller的建置當然也是如此，可以用虛機的方式建立（我們強烈建議就用這種，不用考慮別的），可以安裝在實體機上以容器執行，可以配置在公有雲內比如說由公有雲Market Place直接拉出來建置。但無論如何，下列幾點在部署前請列入考慮：

 

  • Avi Controller部署的地方與實際服務引擎 / 業務應用所存在的地方，不需要一樣，型態也無需相同。可以服務引擎採用Bare-Metal實體機，但是Controller採用虛機。或是服務引擎在AWS上，但是Controller在企業地端私有雲內。

 

  • 但不管怎麼樣，三台Controller必須要部署在同一個資料中心內。或精確的說，Controller之間內部通信的延遲時間不可以超過5 ms。各位要考慮Site備援把Controller放到建築物不同的樓層，或是Campus內不同的機房，沒問題，但是Controller之間延時要低，就可以。

 

  • 在前篇有談到，我們建議在Controller上啟用Cluster IP機制，但此機制限制Controller的部署應該要在同一個大二層網段內。

 

  • Controller與服務引擎Service Engine可以在不同地點，但當然，管理網路要互相連的到。此外，Controller與服務引擎間的Network Latency不應該高於40 ms。比如說企業有兩個機房在台北與台中。台中的Service Engine可以讓台北的Controller來管，但這兩個機房間需要有VPN或是直連網路讓Controller與服務引擎可連通，而且延時要在40 ms之內。不難吧。但如果你的Service Engine在新加坡，Controller在台北，延時過大，就不適宜了。

 

接下來，Controller在建置時，是否有大小的選擇以支援不同的環境？有的，首先是CPU與記憶體的建議配置，通常以下列三種來比較，可支援不同由小到大的Virtual Service以及底層的Service Engine數量：

而在底層Storage部分，若可以採用SSD這類的高IOPS儲存當然是最好。而Controller上應該要保持足夠的Storage空間，提供包含Virtual Service的Log / Metrics收集使用。基本上，建議的配置值大概是下面這樣：

當我們以虛機的方式匯入controller OVA檔到vSphere上時，預設的大小是 8 CPU / 24-GB Memory / 128-GB Storage。但如果需要調整，在虛機匯入後，只需要將controller關機，調整需求的CPU / Memory / Storage大小，然後重新開機，Avi Controller就自動地會利用更大的資源。而當然，在一個controller cluster內，三台的系統資源配置應該是要做成一樣的。

 

好的，上面這兩篇討論Avi Controller的功能與架構，寫這麼多，是否有簡單的整理呢？下列是我個人的『親愛的客戶請不需要想太多了』建議：

 

  • Avi Controller就是裝三台。

 

  • 放同一個網段裡，啟用Cluster IP。

 

  • 用vSphere虛機形式即可。初期採用預設值大小，大規模使用時，再調整Controller Sizing。

 

  • 除非特殊必要，把Controller以及所管理的Cloud / 配置的Service Engine，都放在同一個資料中心內。

 

以上。下一篇我們來討論另一個核心構件： Avi的Service Engine。