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

在前篇我們討論了NSX Advanced Load Balancer內可自動進行服務引擎擴充的Auto-Rebalance機制，以及相關的配置選項。本篇的重點是用一個實際lab運作的環境請大家看相關運作的效果。同前篇敘述，配置要求實例是這樣：

  • 啟用 auto_rebalance
  • 採用的指標是服務引擎的CPU使用率
  • CPU使用率的上限門檻是50%（超過50% CPU 後，則要擴充服務引擎），CPU使用率的下限門檻是20%（低於20% CPU 後，則要縮減服務引擎）

指令需要的話請參考前篇。在Avi Controller Command Line內輸入相關指令後，下圖內我們可以看到相關的配置有生效：

先看一下環境內測試Virtual Service的配置。為了要把CPU撐高，這個Virtual Service內我們採用L7的應用型態（要檢查HTTP表頭），開啟Secure HTTP（做SSL Offload），WAF也開起來（耗費大量的CPU 運算能力）。目前這個服務僅有運作在單一台服務引擎 Avi-se-orfrk上。

接著開始驗證，下圖內大家可看到，首先我們大約在9:16分時開始對這個服務發動壓測，約是每秒150個連線。跑一段時間後，在約9:24分時將連線數加大到每秒300個連線，然後就一直持續下去。

來看一下負責這個此Virtual Service的服務引擎。首先可以看到，在9:24分之前 (150 conn/sec) ，上述的連線要求造成了約35~40%的CPU使用率。而 9:24分之後 (300 conn/sec)，新連線造成了CPU壓力到達約70~80%的CPU使用率。但是在9:31分左右，CPU使用率又掉下來了，發生了什麼事呢？

看一下這個Virtual Service的事件。裡面可以看到，在連線量由150 conn/sec加大到300 conn/sec的時間（約9:24分）後不久，自動觸發了一個REBALANCE_VS_SCALEOUT事件。原因？我們設定服務引擎自動scaleout的門檻是CPU的50%，在大連線量時CPU過高就超過了。接著一路往後，Avi自動建立了一個新的服務引擎，並在建立完後將Virtual Service放到上面運作。約9:30分時相關的動作完成。

在vCenter內，我們也可看到一連串關於這個新產出的服務引擎虛機Avi-se-zxdnx的相關配置工作。

再回到Virtual Service內，我們可以看到除了原本的服務引擎Avi-se-orfrk外，又在新引擎Avi-se-zxdnx上也同時提供服務了。

去看第二台新產出服務引擎的效能圖，可以看到，我們持續在進行的連線要求，在第二台Service Engine內從開始提供服務後（約9:31分時），也花費了約40%上下的CPU。

但回頭看第一台服務引擎，可以看到在同時，CPU就掉下來了，橫向擴充機制完美地發揮效用。

上面看到了服務引擎自動擴充的展示，我們順便也把Scale-in也做一下。在大概9:47分的時候，我停止了對此Virtual Service的壓測連線。下圖內可看到連線數直接歸零：

連線數歸零當然也會對應讓服務引擎的CPU降低，當降到設定門檻20%以下一陣子後，下圖內我們看到約9:50分時自動觸發了REBALANCE_VS_SCALEIN事件，並且在很短的時間內完成。然後當我們再去看此Virtual Service的相關資訊時，很明確地可看到又只由一個Service Engine提供服務了。

在前後這兩篇我們花費了滿大的篇幅討論Avi本身服務引擎的自動擴充及縮減。雖然需要在command line以指令配置，但還算是個滿穩定的功能，大家可依據需求採用。下篇網誌內，我們要開始與大家討論後端Server的Auto-scale應該會是怎麼做。