虛擬雲網路

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

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

在前面兩篇我們討論了NSX Advanced Load Balancer (Avi Networks) 內,作為控制層核心的Controller功能及部署討論。接下來要談到的是真正用來提供應用遞送服務轉發層的服務引擎 (Service Engine),請回憶一下下圖的方案架構。

Service Engine實際上提供應用連線的遞送處理,包含了本地與全域負載平衡、連線轉發、SSL加解密 / Offload、WAF規則檢查、Log日誌以及metric效能產出等作業。但與其他傳統應用遞送方案友商不同,管理者無需實際上登入、連線去配置Service Engine。所有Service Engine的建立與管理作業,都可以透過Controller來進行,如同我們不斷地在系列文章內強調的,Avi是一個『控制』與『轉發』分離的架構,而轉發層即是由Service Engine來擔當。

 

Service Engine可以是下面的型態:

 

  • 企業私有雲環境裡面的虛擬機。管理者可以在啟用應用遞送服務之Virtual Service時,由Controller自動驅動vCenter / Openstack來產出需求的服務引擎虛機,甚至在必要時由管理者啟動 / Controller自動進行服務引擎的Scale-Out / Scale-In等作業。在少數的狀況,管理者也可以選擇『手動』建立服務引擎虛機(比如說匯入Service Engine的OVA檔到vSphere上),然後再將此服務引擎註冊到Controller內。當然,我們比較建議是採用自動配置的方式。

 

  • 公有雲環境內的虛擬機。Controller可透過接取之公有雲API,直接在公有雲環境內產出需求的Service Engine Instance。基本上在公有雲內都是採用自動化部署的方式。

 

  • 企業內部環境內的Bare-Metal實體機。某些特殊的原因內,比如說客戶可能不想要購買vSphere的授權,或是自己感覺使用Bare-Metal中間少一層虛擬層,效能應該比較好。此時就有可能會手動安裝x86伺服器以及特定Linux版本,由Controller接取後,將服務引擎的功能遠端安裝上去。但說實話,採用Bare-Metal真正的理由也就是省vSphere授權而已,真正的服務引擎效能差異主要還是在 CPU / Memory 的配置上面。

 

  • 還要討論一點,上面的圖內有畫服務引擎可以用『容器』的方式運作。Avi方案在早期確實有此架構,於Kubernetes Cloud內用pod的方式部署Service Engine來提供應用遞送。但此架構在最新的1版本內已經不支持了,主要原因在於以容器作為服務引擎效能的支持上仍有限制。目前Avi方案最新支持Kubernetes環境的架構叫做AKO (Avi Kubernetes Operator),Kubernetes需求的Ingress / LoadBalancer等北向機制會由外部的服務引擎,也就是『虛機』或『實體機』的Service Engine來提供服務,而非使用內部容器。

 

在幾篇前面的NSX Advanced Load Balancer系列文章157~161,我們有就服務引擎的Sizing / Scale-Out Scale-In / ECMP機制等做過討論,這邊就不再贅述,請大家到下面這幾篇鏈結參考:

 

 

 

 

 

 

但這邊一個實際安裝部署上的問題就出來了:我們決定了要採用多少台服務引擎,也初估了服務引擎的大小。同時,對於服務引擎是要兩台做Active / Standby還是多台Active-Active也有了初步的想法。那麼,怎麼配,要放在什麼地方?服務引擎的配置不是能夠自動化嗎?應該不會要我們一台一台去調整吧。

 

是的,當然不用一台一台調。因此下一篇,我們來討論一個Avi安裝與管理流程內的重要構件:Service Engine Group。

 

相关文章

评论

发表评论

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