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

在前篇內我們說明了NSX Advanced Load Balancer的一個重要特性：採用軟體，可以依需求快速縱向Scale Up/Down；也支援以Active/Active架構進行Scale Out/In。我想如果大家都是長久使用Load Balancer的專家，此時一定會冒出問號？Active/Active？大部分方案都是採用Active/Standby的架構，Active/Active要怎麼做？

 

傳統應用遞送廠商的高可用度機制是下面這樣子：

  • 兩台硬體為一對。兩台硬體中間透過RS232線路或是網路線偵測另一台的健康狀態

 

  • 用戶的Virtual Service跑在單台上。而同時，與這個服務相關的資訊 (NAT Table / Session Persistence Table) 也透過網路要同步到另一台備援的設備上

 

  • 當主要服務的Active設備失效，此時Standby的設備發現這個問題，就對外宣告各台Virtual Service的IP改在自己身上。

 

  • 此時Standby設備就開始提供服務，同時因為各連線資訊之前有同步，用戶的連線也不會中斷。

 

這個架構可用、切換快速、而且非常穩定。唯一的問題是容量就只剩一半，老闆覺得花了好多錢買兩台設備，結果就只有一台在動，不開心。當然也有些技術先進的廠商可以把服務分散在兩台上，有些服務的Active在左邊Standby在右邊，其他服務的Active在右邊Standby在左邊，對上邊就忽悠其實兩台都有用。但實際狀況其實差不多，對於生產環境我們就是必須要保留50%的容量準備。

 

那Avi的架構可以怎麼樣呢？同樣地我們用下面的圖例來說明。

  • 總共有四個服務，App 1 / App 3 / App 4是測試用，或是營運等級沒有那麼高的次要服務，可以容忍較長的切換時間。此時，App 1/3/4都僅在單台服務引擎 (SE, Service Engine) 上提供服務，也無需將狀態 (NAT Table / Persistence Table…) 送到其他台去

 

  • App 2是非常重要的核心業務，政策上要求要分散到至少三台Service Engine來提供服務。圖例內大家可看到App 2在三台引擎上同時運作，且狀態也會在各台間同步。

 

  • 此時中間的Service Engine失效了，比如說底層的硬體出事啦，網路斷掉啦，等等的。此時原本在中間服務引擎上的App 2 / App 3怎麼辦呢？

 

  • App 3很單純，Avi的服務器發現服務引擎失效沒有底層資源提供服務，就在其他台還有資源的服務引擎上重開。當然，此時因為是整個重開，前面連線也沒有同步到其他台，會需要幾秒鐘的時間恢復服務，而這些服務上的用戶也需要重新連線（原本連線的狀態不見了）。但因為這些是較不重要的應用，所以沒有關係～

 

  • App 2呢？此時雖然中間的服務引擎掛了，但左右邊的還在。原本由中間SE服務的連線轉到左右邊來傳送，同時因為服務狀態有同步，所以用戶服務不受影響。但當然，各位可以看到左右邊的綠色變大了，代表原本用三台提供App 2服務，現在只剩左右兩台，每台的連線數壓力變大。

 

事情還沒完。Avi的控制器當然會知道有服務引擎死掉了。同時，控制器也會判斷下面兩個狀況：

 

  • 目前的服務承諾沒有達到：App 3應該要有三台引擎服務它，但此時只有兩個

 

  • 服務引擎的壓力變大，可能超過了規劃的門檻。

 

Avi的另一個特性是可以自動與南向的雲平台溝通，動態產出 / 移除服務引擎。比如說這邊是在vSphere平台上，當目前的情況發生，Avi可以直接告知vCenter，要求部署出第四台服務引擎，如下圖：

當嶄新的四號服務引擎產出，且與Controller回報後，此時

 

  • 依據實際的需求，Avi Controller可以選擇把App 3再於四號引擎上重開，提供較分散、效能較好的服務

 

  • 而App 2也可以在四號引擎上同時提供服務，此時就又同時有三個Service Engine提供重要的App 2服務運作了

 

很棒吧，超棒的。但我們還沒回答重要的問題：到底一個服務可以Active-Active，同時在多台Service Engine上面運作的機制是什麼？下篇我們要來討論這個問題。