SDN NSX 軟體定義網路 Active-Active

深入新世代應用遞送服務 Scale-Out/Scale-In分解示範

實戰NSX ALB負載平衡 快速打造雙活A/A架構

2020-09-22
延續上期所介紹的NSX Advanced Load Balancer,此次將介紹NSX Advanced Load Balancer如何透過原生派送機制、搭配網路路由/SDN的機制、DNS派送機制等三種方式來提供Active/Active架構。然後,將以實例來說明如何進行Scale-Out/Scale-In作業。

 

前篇投稿內說明了NSX Advanced Load Balancer的系統架構,並且討論NSX ALB可以利用Active/Active機制,讓一個需要大量負載平衡效能的服務,可以平行在多台服務引擎上執行。但要怎麼做到呢?這就是在本篇希望與大家說明的重點。

NSX Advanced Load Balancer目前可以透過三種方式來提供Active/Active架構,以下分成三大單元來分別說明:

原生派送機制

在原生派送機制內,一個服務會選定一台服務引擎作為Primary SE。所有這個服務的入口(Virtual IP,VIP)都是在這台Primary SE上,如圖1所示。

圖1  原生派送機制。

當Primary SE(Dispatcher)收到用戶連線要求時,可以選擇自己處理(自行進行負載平衡),也可以把這個要求轉交給另外的服務引擎,由其他服務引擎進行負載平衡。由於服務引擎在進行負載平衡轉送時,會把連線的來源IP以SNAT轉為自己,所以無論是哪台SE被指派作為此連線的負載平衡,後端的Server都會把連線回送給同一台SE。

而在SE要把這個連線回送給原本的用戶時,依據不同的環境,有兩種處理方式:

1. 在傳統網路架構時,Service Engine會將回應直接回傳給用戶,不會送給原本的Dispatcher再回傳。這是圖1左邊的Direct SE Return模式。

2. 在某些SDN架構下,SDN方案要維持Flow-state,同一個Flow的回傳不能來自不同的MAC-address。此時,回傳的連線會先回送給Dispatcher,再由Primary SE回傳。這是圖1右邊的Tunnel Return模式。

無論左邊或右邊,應該很清楚地看到,Primary SE的壓力一定是最大,整個服務的瓶頸會鎖在這台引擎的能力上。因此,原生派送機制的Scale比較小,一般建議Active/Active的範圍不要超過四台Service Engines。

搭配網路路由/SDN的機制

在這類機制內,多台服務引擎前端的網路設備可以負責做連線負載的分派。對應到指定的服務,Virtual IP在前端網路設備會知道可以分派到後端多台的Service Engine上來做處理。如圖2所示,處理的機制同樣可分成兩種: 

圖2  搭配網路路由/SDN的機制。

1. 傳統網路架構下,各台Service Engine要與前端網路設備跑標準BGP,並且透過Route Health Injection機制告知這個Virtual IP可以往本身送。因此,前端網路設備透過ECMP(Equal Cost Multi-Path)機制,在有用戶要連線到這個Virtual IP時,分派到不同的Service Engine上,這是圖2左邊的機制。

2. 在SDN架構下,NSX ALB會與SDN Controller透過API溝通,告知如果要到指定的VIP,後端請用ECMP轉送給不同的服務引擎,這就是圖2右邊的機制。

這個機制是在大型環境的建議方案,可以配置到多台引擎同時服務(限制在BGP/SDN可以允許的ECMP上限,比如說一個Virtual IP可以對應到64個後端引擎)。用圖2左邊或右邊的架構,就要看環境,是否有支援BGP,或者是否與NSX Advanced Load Balancer有整合的SDN方案可以搭配。

DNS派送機制

如同名稱,DNS派送機制是當用戶在連往服務入口前,直接於查詢時由DNS控制進行分派,告知用戶連往哪台服務引擎。

如圖3所示,在這個架構下,NSX ALB Controller會透過API來配置DNS,對應到指定服務FQDN可以回應不同的Virtual IP(對應到不同的Service Engines)。

圖3  DNS派送機制。

所以,不同的用戶同樣要連到VS-A.example.com,有些用戶會取得vip1,有些用戶會取得vip2,以此類推,就能夠多台同時服務了。如果服務引擎失效,Controller偵測到這樣的狀態,同樣透過API去編輯DNS紀錄,把死掉的服務引擎上對應的VIP紀錄移除。

此架構的限制在於NSX ALB必須要能夠透過API去控制DNS紀錄。目前,只有支援NSX ALB本身提供的DNS服務,以及AWS的Route 53。

無論採用以上哪種架構,對應到單一服務,Persistence Table都會在各台引擎間同步(若選擇採用如Source-IP Persistence、TLS Persistence等等方法)。因此,即使在Active/Active架構內出現服務引擎失效,用戶連線轉到其他台引擎服務的狀況,連線也不會中斷。

聽起來,採用Active/Active的架構非常棒,但有沒有限制呢?要運作這樣的架構確實有一個前提:「Active/Active架構需要採用Reverse-Proxy/SNAT模式來運作」。也就是說,用戶連線的來源IP會被修改成服務引擎本身的網路位置。在這種模式內,如果應用系統需要知道用戶真實來源IP,必須採用以下兩種方式之一:

‧HTTP表頭內的X-Forwarded-For欄位

‧採用Proxy Protocol協議

如果新應用系統可以支援SNAT模式,且可以透過上述方式來抓取用戶地址,此時NSX ALB的Active/Active架構就非常棒了。但如果對於傳統業務,一定只能用網路層看用戶來源IP,那就只能用Active-Standby機制。NSX ALB可支援Active-Standby機制,但這就不是此方案的特殊強項,使用市面上的傳統應用遞送方案就可以做得非常出色。

Scale-Out/Scale-In實作

抓幾張圖給大家看一下NSX Advanced Load Balancer方案內的服務Scale-Out/Scale-In是怎麼做。圖4是在NSX ALB的Controller GUI內,管理者可以點入一個Virtual Service,將看到目前這個Virtual Service底層是由Avi-se-miyey與Avi-se-wtkyc這兩台Service Engine來服務。這邊採用的是前端所提的Dispatcher機制,因此Avi-se-miyey目前是Primary的角色,Virtual IP長在這台虛機上。

圖4  點入一個Virtual Service。

上面有Scale Out的選項。如果管理者覺得目前的兩台Service Engine效能不夠,可以直接點擊這個選項。

此時,選項內會詢問哪個VIP要擴張等資訊。當管理者希望將Virtual Service擴張到其他服務引擎時,NSX ALB Controller會尋找是否有空的Service Engine可以提供服務。或者,也可以勾選「Create Service Engine」,強制要求產出新的服務引擎,如圖5所示。

圖5  可勾選「Create Service Engine」,來強制要求產出新的服務引擎。

在這個範例內,因為原本在vCenter內僅有部署Avi-se-miyey、Avi-se-wtkyc兩台服務引擎虛機,沒有其他的服務引擎。因此,當管理者要求將上述的Virtual Service再Scale-Out時,Controller發現沒有現成的引擎可以使用。所以,NSX ALB Controller透過南向對vCenter的API,要求在vCenter內部署新的服務引擎。在圖6中,可以看到目前vCenter自動產生一台新的虛機叫做Avi-se-cyqfk。

圖6  vCenter自動產生一台新的虛機。

上述的虛機產生後,會自動與Avi Controller通訊。接著,管理者要求的Virtual Service Scale-Out作業就可以在新的服務引擎上生效,如圖7所示。

圖7  Virtual Service Scale-Out作業已經可以在新服務引擎上生效。

在這邊,有幾個重點想和大家討論一下:

‧上面的動作是由管理者驅動,透過NSX ALB Controller對私有雲或公有雲的API呼叫,「自動」進行服務引擎部署等Scale-Out/Scale-In作業。

‧上述的動作當然可以用其他的自動化編排工具或是利用API呼叫,也可以在達成某些條件時(例如同時連線數到達某個門檻以上)來啟用。

‧上述的作業可以在很短的時間,例如數分鐘內完成。

請大家思考一下這樣的方式與硬體架構的差別。坊間的方案當然也有一些特殊的Active-Active運作機制,比如說一台大型設備內配置多張板卡提供平行服務,或是以LACP的方式讓多台硬體設備同時進行負載平衡處理。但回到原點:採用這些特殊方案的方式就是要採用這些廠商的「硬體」。也就是說,如果發現目前的負載平衡效能不足,就算不是把原本的硬體設備打掉重買,擴充的過程仍然包含了規劃、硬體採購、設備到貨、安裝上架、網路底層配置等等。上面講的是幾個星期幾個月的時間,而不是像前面展示的,只要有底層的虛擬化或公有雲資源池,隨時可以快速擴充。對於要求速度、能快速因應業務需求的環境來說,採用硬體的彈性還是不足夠的。

估算Avi的效能需求

本文最後來討論一個前面文章內詢問的問題。一般來說,在部署一個新業務前,業務團隊很難準確回答應用的連線需求量。但假設其實業務團隊可以抓準需求量呢?那當然很好,就可以用下面討論的方式來估算Avi的效能需求。通常負載平衡器對應Web應用,最重要的效能指標有兩項:

‧SSL TPS(Transactions Per Second):用白話文講,每秒新增的交易連線量。舉例來說,之前與一個著名的客戶聊天時,他們說當他們長官下令一個新的促銷活動時,從活動開始幾分鐘內,連線量就衝到六七十萬筆。在這種狀況下,每秒新增的連線量至少也有個一兩萬沒有問題

‧SSL Throughput:顧名思義,對於這個應用南北向的流量頻寬估算。

對負載平衡器來說,真正在吃CPU效能的不是封包轉送、NAT這些東西,而是加解密。所以,雖然廠商的Datasheet上面各種規格洋洋灑灑列了一大堆,通常在比較效能時,看上面這兩項就可以:負載平衡器需要做加解密時(跑SSL),可支撐的加密頻寬大小,以及每秒新增的連線量有多少。

這裡不想長篇大論地做規劃機制說明,但由圖8內簡單的舉例做討論:假設可以從業務團隊得到效能規格:這個業務需要每秒可以新增10,000個交易,而且南北向的頻寬規劃為3Gbps。此時,需要多大的服務引擎容量呢?

圖8  NSX ALB2的規劃方式與效益示意圖。

以粗略估算的方式來討論。業務團隊通常提出的效能要求是由外部用戶到負載平衡的這一段,也就是圖8右上角的A/B部分。這邊如果是採用HTTPS,在需要每秒10,000個SSL新連線的狀況下,如果採用資源耗用較少的ECC機制,每個服務引擎的Core約可處理每秒2,500個新連線。因此,在TPS部分,需要4個Core。

而以SSL Throughput的需求,若業務需要3Gbps的南北向流量,每個服務引擎的Core約可處理1Gbps的加解密流量,因此這邊需要3個Core。

但同樣地,需要估算由負載平衡器到伺服器端的流量處理需求,也就是圖8右上角的C/D部分。這裡假設就不加密了,只有HTTP。但因為負載平衡器會讀取並處理HTTP 7層封包,即使不加密,也要花效能來提供資源。NSX ALB約抓每個Core可以處理3Gbps,因此這邊也要耗費1個Core。

所以加起來,需要8個Core的運算能力。那這時候要怎麼來規劃需要的服務引擎呢?

如果採用傳統的Active-Standby模式,那這個服務需要有2個Service Engine,一個Service Engine需要8個Core,另一個備援。這樣,需要總共16個Core的資源。

如果採用推薦的Active-Active模式,那這個服務的規劃方式就很多元了。假設每個Service Engine採用2個Core,那麼8個Core的運算能力需要同時有4個引擎來服務,另外再加一個備援。此時,只需要準備10個Core的資源(共5個引擎,每個2 Core)。

這邊看到在NSX Advanced Load Balancer Active/Active架構下的特點:

在這種架構下,可以用比較少的硬體資源與軟體授權,達成相同的效能要求(上面的16 Core與10 Core)。如果這裡的說明還太複雜,請大家想像一下,有一堆硬碟,要做RAID 1或是RAID 5,哪個可以使用的磁碟空間比較大?這是很類似的比較。其次,就算規劃得不準,也沒關係。NSX ALB的架構是有彈性的,如果規劃太多,那可以把服務引擎的Core數減少,把多餘的授權拿去別的地方用。而如果規劃得不夠,多買一些授權,把現有的服務引擎再Scale Up/Scale Out就好了。這比原來硬體的方式彈性太多了吧!

花了兩篇文章討論NSX Advanced Load Balancer的架構與AA機制。下篇文章要將討論另外一個新話題:NSX Advanced Load Balancer方案的分析功能。

<本文作者:饒康立,VMware資深技術顧問,主要負責VMware NSX產品線,持有VCIX-NV、VCAP-DTD、CCIE、CISSP等證照,目前致力於網路虛擬化、軟體定義網路暨分散式安全防護技術方案的介紹與推廣。>

 


追蹤我們Featrue us

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!