作者: Colin Jao 饒康立 – VMware資深技術顧問,主要負責VMware NSX產品線,目前致力於網路虛擬化、分散式安全防護技術與新應用遞送方案的介紹與推廣。
我們在前面有聊過,一般來說,業務Team是很難準確回答應用的連線需求量的。但假設其實業務團隊可以抓準需求量呢?那當然很好,我們就可以用本篇討論的方式來估算Avi的效能需求。
通常最重要的效能指標有兩項:
- SSL TPS (Transactions Per Second):用白話文講,每秒新增的交易連線量。舉例來說,之前和一個著名的客戶聊天時,他們說當他們長官下令一個新的促銷活動時,從活動開始幾分鐘內,連線量就衝到六七十萬筆。這狀況下,每秒新增的連線量至少也有個一兩萬沒有問題
- SSL Throughput :顧名思義,對於這個應用南北向的流量頻寬估算。
對於負載平衡器來說,真正在吃CPU效能的不是封包轉送、NAT這些東西,而是加解密。所以雖然友商的Datasheet上面各種規格洋洋灑灑列了一大堆,通常在比較效能時,看上面這兩項就可以:重點在於負載平衡器需要做加解密時(跑SSL),可支撐的加密頻寬大小以及每秒新增的連線量有多少。
我不想長篇大論地做規劃機制說明。但由下圖內簡單的舉例做討論:假設我們可以從業務團隊得到效能規格:這個業務需要每秒可以新增10,000個交易,而且南北向的頻寬規劃為3 Gbps。此時,我們需要多大的服務引擎容量呢?
以粗略估算的方式來討論。業務Team通常提出的效能要求是由外部用戶到負載平衡的這一段,也就是上圖右上角的A/B這部分。這邊如果是採用HTTPS,在需要每秒10,000個SSL新連線的狀況下,如果我們採用資源耗用較少的ECC機制,每個服務引擎的core約可處理每秒2500個新連線。因此在TPS部分,需要4個core。
而以SSL Throughput的需求,若業務需要3 Gbps的南北向流量,每個服務引擎的core約可處理1 Gbps的加解密流量,因此這邊需要3個core。
但同樣地我們需要估算由負載平衡器到伺服器端的流量處理需求,也就是右上角的C/D這邊。這邊我們假設就不加密了,只有HTTP。但因為負載平衡器會讀取並處理HTTP 7層封包,即使不加密,也要花效能來提供資源。Avi約抓每個core可以處理3 Gbps,因此這邊也要耗費1個core。
所以加起來,我們需要8個core的運算能力。好的,那這時我們要怎麼來規劃需要的服務引擎呢?
- 如果採用傳統的Active-Standby模式,那這個服務需要有兩個Service Engine,一個Service Engine需要8個core,另一個備援。這樣,我們需要總共16個core的資源。
- 如果採用推薦的Active-Active模式,那這個服務的規劃方式就很多元了。假設我們每個Service Engine採用兩個core,那麼8個core的運算能力需要同時有4個引擎來服務,另外再加一個備援。此時,我們只需要準備10個core的資源 (共5個引擎,每個2 core)。
這邊我們看到在Avi架構下的特點:
- 在這個Active/Active的架構下,我們可以用比較少的硬體資源與軟體授權,達成相同的效能要求(上面的16 core vs 10 core)。如果這幾篇的說明還太複雜,請大家想像一下,你有一堆硬碟,要做Raid 1或是Raid 5,哪個可以用的磁碟空間比較大?這邊是很類似的比較
- 其次,就算規劃得不準,也沒關係。Avi的架構是有彈性的,如果規劃太多,那我們可以把服務引擎的core數減少,把多餘的授權拿去別的地方用。而如果規劃得不夠,多買一些授權,把現有的服務引擎再Scale Up / Scale Out就好了
這比原來硬體的方式彈性太多了吧!
花了好幾篇討論Avi的架構,但在這個話題結束前,最後我們要討論一下:Avi方案支援不同種類的Active-Active運作方式,提供比傳統方案更大的應用遞送服務容量。感覺上超棒的,但這個方式有沒有缺點呢?
只有一個缺點:Active / Active架構一定要採用Reverse-Proxy / SNAT模式來運作。如果應用要知道用戶來源IP,需要透過HTTP內的X-Forwarded-For欄位。簡而言之,對於使用HTTP / HTTPS,且應用有支援X-Forwarded-For的新業務,Avi的架構非常棒。但如果對於傳統業務,一定只能用網路層看用戶來源IP的,那就只能用Active-Standby機制。Avi當然有支援Active-Standby機制,但這就不是我們的特殊強項,友商的傳統應用遞送方案就可以做得嚇嚇叫了。
下篇我們要開始討論另外一個新話題:Avi方案的分析功能。
Comments
0 Comments have been added so far