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