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

當我們選擇要用『自動』而非『手動』的方式來部署服務引擎時，此時需要一個樣版，來說明當這些服務引擎被產出時的基礎配置方式。這個樣板叫做Service Engine Group (SEG)。在配置NSX Advanced Load Balancer (Avi Networks) 時，每個Cloud裡面都會有一個預設的Service Engine Group，而管理者也可以自訂特殊規格的Service Engine Group出來。

 

通常我們會在Service Engine Group內配置的主要參數包含了

 

  • 服務引擎的大小，如配置的CPU / Memory / Storage多寡，資源要不要保留。或是在公有雲比如說AWS內，選擇服務引擎採用的Instance Flavor Type（比如說服務引擎要選定採用large這樣大小）。

 

  • 當應用 (Virtual Service) 放到這組服務引擎上時採用的High Availability形式，是可橫向擴充的Active / Active，無需即時備援的N+M，或傳統的Active / Standby，以及各種HA架構下的參數，還有像是這組服務引擎上可以放置的 Virtual Service上限等等。

 

  • 如果服務引擎可以自動橫向擴充 (Scale-Out) ，最多可以長到幾台

 

下圖是採用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)。諸如此類的配置。

當我們建立好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，比如說在下圖，目前的Virtual Service有兩台服務引擎提供A/A的負載平衡服務，但如果需要有第三台同時來提供，管理者可以按下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。

 

  1. 此時現有的服務引擎不會被更改。但我們可以到Virtual Service內選擇Migrate，並要求產出新的Service Engine

 

  1. 此時產出的新服務引擎就會是8G Memory了，而且轉移過程中服務也不會中斷。

 

  1. 再將這個Web服務的另一台服務引擎也Migrate到新的服務引擎上，完成後，把舊的4G Memory的服務引擎移除，就可以了。

 

解釋完服務引擎以及服務引擎群組，接下來要和大家討論在不同的Cloud架構內，網路的配置方式。