虛擬雲網路

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

作者: 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架構內,網路的配置方式。

 

相关文章

评论

发表评论

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