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

這篇網誌文字不多，我想抓幾張圖給大家看一下Avi方案內的服務Scale-Out / Scale-In是怎麼做。下面這張圖是在Avi的Controller GUI內。管理者可以點入一個Virtual Service，我們可以看到目前這個 Virtual Service底層是由兩台Service Engine來服務：Avi-se-miyey與Avi-se-wtkyc。這邊採用的是前端所提的dispatcher機制，因此Avi-se-miyey目前是Primary的角色，Virtual IP長在這台虛機上。

 

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

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

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

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

在這邊幾個重點想和大家討論：

 

  • 上面的動作是由管理者驅動，透過Avi Controller對私有雲的API呼叫，『自動』進行服務引擎部署等Scale-Out / Scale-In作業的

 

  • 上述的動作當然可以用其他的自動化編排工具或是利用API呼叫，也可以在達成某些條件時（比如說同時連線數到達某個門檻以上）來啟用

 

  • 上述的作業可以在很短的時間，比如說數分鐘內完成。

 

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

 

下一篇我們要回應前面文章的問題，在Avi架構內，當我們可以採用Active / Active、多台引擎的架構時，對於應用遞送服務的規劃上會有什麼不同。