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

Avi的Active / Active架構與其他友商相當不同。Avi可以透過三種方式來提供Active / Active的架構，我們分別與大家說明：

 

原生派送機制：

 

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

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

 

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

 

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

 

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

 

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

 

搭配網路路由 / SDN的機制：

 

這個機制內，多台服務引擎前端的網路設備可以負責做連線負載的分派。對應到指定的服務，Virtual IP在前端網路設備會知道可以分派到後端多台的Service Engine上來做處理。

 

處理的機制同樣可分成兩種：

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

 

  • SDN架構下，Avi會與SDN Controller透過API溝通，告知如果要到指定的VIP，後端請用ECMP轉送給不同的服務引擎。這是右邊的機制

 

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

 

DNS派送機制：

 

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

在這個架構下，

 

  • Avi Controller會透過API來配置DNS，對應到指定服務FQDN可以回應不同的Virtual IP（對應到不同的Service Engines）

 

  • 所以不同的用戶同樣要連到VS-A.example.com，有些用戶會取得vip1，有些用戶會取得vip2，以此類推，就能夠多台同時服務了

 

  • 如果服務引擎掛了，Avi Controller偵測到這樣的狀態，同樣透過API去編輯DNS紀錄，把死掉的服務引擎上對應的vip紀錄移除

 

這架構也很不錯吧，但是限制是在Avi必須要能夠透過API去控制DNS紀錄。目前只有支援Avi本身提供的DNS服務，以及AWS的Route 53。

 

無論我們是採用上面哪種架構，對應到單一服務，Persistence Table都會在各台引擎間同步（如果選擇採用如Source-IP Persistence / TLS Persistence等等方法的話）。因此即使在Active-Active架構內出現有服務引擎失效，用戶連線轉到其他台引擎服務的狀況，連線也不會中斷。

 

上面寫的很複雜嗎？下篇我們抓實際畫面讓大家體會一下Avi方案要做Scale-Out / Scale-In是多麽簡單的事情。