虛擬雲網路

網路虛擬化NSX 技術文章系列一百八十六: NSX Advanced Load Balancer:構件說明與安裝流程(四)

作者: 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。

 

 

相关文章

评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注