先前已經介紹NSX Advanced Load Balancer的功能與使用效益，而且也說明了其安裝準備與流程，示範了大致的安裝流程，以及需要考量到的細節。因此，本文將詳細討論真正用來提供應用遞送服務轉發層的服務引擎（Service Engine）。
本系列內和大家就NSX Advanced Load Balancer（後續簡稱為NSX ALB或Avi）在核心構件以及安裝步驟進行相關說明。接續前篇投稿內關於部署環境「Cloud」，以及控制層核心「Controller」的討論，本篇內專注討論的是真正用來提供應用遞送服務轉發層的服務引擎（Service Engine），請回憶一下圖1的方案架構。
認識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的配置上面。
還要討論一點，圖1內有提到服務引擎可以用「容器」的方式運作。Avi方案在早期確實有此架構，於Kubernetes Cloud內用Pod的方式部署Service Engine來提供應用遞送。但此架構在最新的20.1版本內已經不支援，主要原因在於以容器作為服務引擎效能的支援上仍有限制。目前，Avi方案最新支援Kubernetes環境的架構叫做AKO（Avi Kubernetes Operator），Kubernetes需求的Ingress、Load Balancer等北向機制會由外部的服務引擎，也就是「虛機」或「實體機」的Service Engine來提供服務，而非使用內部容器。
圖1 NSX Advanced Load Balancer架構示意圖。
在之前的文章中已就Avi服務引擎的Sizing、Active-Active架構、Scale-Out/Scale-In、ECMP等等機制做過討論，這裡就不再贅述，請連到下面兩篇鏈結參考：
‧服務引擎效能：https://www.netadmin.com.tw/netadmin/zh-tw/technology/D3963573EF2C42CA9B954B42B91DA1EC ‧服務引擎的Active/Active架構以及Scale-Out：https://www.netadmin.com.tw/netadmin/zh-tw/technology/CA37FAD1531145279CAA5C89F783E4B9
但這裡一個實際安裝部署上的問題就出來了：我們決定了要採用多少台服務引擎，也初估了服務引擎的大小。同時，對於服務引擎是要兩台做Active/Standby還是多台Active-Active也有了初步的想法。那麼，怎麼配，要放在什麼地方？服務引擎的配置不是能夠自動化嗎？應該不會要一台一台去調整吧？
是的，當然不用一台一台調。當選擇要用「自動」而非「手動」的方式來部署服務引擎時，此時需要一個樣版來說明當這些服務引擎被產出時的基礎配置方式，這個樣版叫做Service Engine Group（SEG）。在配置NSX Advanced Load Balancer時，每個Cloud裡面都會有一個預設的Service Engine Group，而管理者也可以自訂特殊規格的Service Engine Group出來。
運用Service Engine Group
通常會在Service Engine Group內配置的主要參數，包含了以下這些：
‧服務引擎的大小，如配置的CPU、Memory、Storage多寡，資源要不要保留。或是在公有雲像是AWS內，選擇服務引擎採用的Instance Flavor Type（例如服務引擎要選定採用t3.large這樣的大小）。
‧當應用（Virtual Service）放到這組服務引擎上時採用的High Availability形式，是可橫向擴充的Active/Active，無須即時備援的N+M，或傳統的Active/Standby，以及各種HA架構下的參數，還有像是這組服務引擎上可以放置的Virtual Service上限等等。
‧如果服務引擎可以自動橫向擴充（Scale-Out），最多可以長到幾台。
圖2是採用vCenter/vSphere Cloud時的服務引擎配置範例。可以看到主要的幾個配置包含在這一組Service Engine Group內：HA的模式要採用Active/Active，有多個Virtual Service要放置在服務引擎上時，儘量放在一起（Compact）。每台服務引擎的大小應該是vCPU x2、Memory x10、Storage x50GB，且Memory應該在vSphere上預先保留。當這組服務引擎橫向擴張時，最多不能超過10台（Max Number of Service Engine），諸如此類的配置。
圖2 採用vCenter/vSphere Cloud時的服務引擎配置。
當建立好Service Engine Group，就可以把應用服務（Virtual Service）安排到指定的SEG內。這與傳統的硬體應用遞送方案極不相同，在Avi環境內，Virtual Service/Pool等應用遞送的配置，與底層提供遞送的實體（Service Engine），是解構分開（Decouple）的。也就是說，管理者可以配置出多組不同的Service Engine Group，而上層的Virtual Service選擇要配置到哪一組Service Engine Group，就可以得到不同的服務等級，如同前面談到的：
‧High Availability的模式選擇（AA、AS、不要備援），是否可以Scale-Out。
‧底層服務引擎的效能（CPU、Memory、Storage）多寡
當Virtual Service被安排到Service Engine Group內，Avi Controller就會檢查在這組SEG內是否有足夠的資源（Service Engine）來提供服務。如果不足夠，Avi Controller就會呼叫vCenter、AWS等等，自動長出新的服務引擎虛機。而反過來，如果有些服務引擎目前沒有Virtual Service在上面運作，Controller也會自動告知底層雲平台，刪除服務引擎以節省資源（或公有雲租用費用）。
透過Service Engine Group的配置與High Availability的概念，管理者可以輕易地在必要時提升重要業務的應用遞送效能，也就是Scale-Out/Scale-Up的概念。在先前的文章內談論過Scale-Out，譬如在圖3內，目前的Virtual Service有兩台服務引擎提供A/A的負載平衡服務，但如果需要有第三台同時來提供，管理者可以按下〔Scale-Out〕進行Service Engine的橫向擴充。
圖3 按下〔Scale-Out〕進行Service Engine的橫向擴充。
但有些狀況，例如其實用兩台服務引擎也好好的，但希望增加一些資源，此時用Scale-Up也是個選擇。舉個例子，一個Web服務在初期時流量與連線數不多，用兩台服務引擎2x CPU、4G Memory就足夠了，但管理者發現大家越用越開心，服務引擎Memory不足夠，但因為授權與資源等等考量，也不想增加機器，但Memory加到8G應該足夠，此時可以做以下這些事情：
1. 到這個Web Virtual Service使用的Service Engine Group裡面，把服務引擎的樣版改為2x CPU、8G Memory。
2. 此時現有的服務引擎不會被更改。但可以到Virtual Service內選擇Migrate，並要求產出新的Service Engine。
3. 此時產出的新服務引擎就會是8G Memory，而且應用服務就新產出的大服務引擎上運作，而且轉移過程中服務也不會中斷。
4. 再將這個Web服務的另一台服務引擎也Migrate到新的服務引擎上，完成後，把舊的4G Memory的服務引擎移除，就可以了。
結語
本文較短，先停於此。在前篇與本篇投稿內討論了Avi核心構件的Controller與Service Engine，可以部署在哪些環境、需求的資源等等。
但在實際開始部署前還要解決一個問題：底層網路的準備。在不同的雲環境，底層需求的網路準備是不同的，下篇文章會針對此問題與大家進行詳細討論。
＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，持有VCIX-NV、VCAP-DTD、CCIE、CISSP等證照，目前致力於網路虛擬化、軟體定義網路暨分散式安全防護技術方案的介紹與推廣。＞