前期文章講解了NSX Advanced Load Balancer的服務引擎於需求時如何「手動」進行橫向擴充的方式，本期將接著介紹能夠「自動」地在需要時擴充負載平衡容量的Auto-Rebalance機制，如果啟動這個機制，管理者可以選擇依據不同指標來判斷是否要進行服務引擎的新增或是縮減。
在前期文章示範了如何把NSX Advanced Load Balancer的服務引擎於需求時由管理者手動進行橫向擴充的方式，但大家肯定覺得這樣不足夠。與老闆報告時更好的方法，肯定是設計時已有「自動」的機制在內。當應用交易量過大，剩餘資源不足時，不需要管理者手動介入，即使在三更半夜，NSX Advanced Load Balancer也能夠自動地於需要時擴充負載平衡容量。
行不行呢？當然可以。在NSX ALB方案內，上述的機制叫做Auto-Rebalance。如果啟動這個機制，管理者可以選擇要依據不同指標來判斷是否要進行服務引擎的新增或是縮減。當服務引擎上的使用量∕利用率超過了指定門檻的一定時間，Controller就自動新增服務引擎，並將應用之Virtual Service擴張到此新引擎上。而如果對應的使用量∕利用率低於指定門檻時，同樣地就可將應用所使用的服務引擎縮減，而未使用的服務引擎也可刪除掉以節省資源。
使用Auto-Rebalance
這裡再討論一下相關的配置細節。Auto-Rebalance功能目前不能使用UI介面，配置時管理者必須登入到Controller內並以Command Line下指令。相關配置的流程如下：
1. 以SSH登入Controller，輸入帳號密碼。
2. 鍵入Shell指令進入Avi Command Line。
3. 選定對應的租戶（Tenant）以及雲（Cloud），然後進入服務引擎群組（Service Engine Group），開始進行相關配置。
除此之外，有幾個主要的配置選項通常需要填寫：
‧在這組Service Engine Group內啟用Auto-Rebalance功能（auto_rebalance）。預設是沒有打開。
‧要採用哪種指標來判斷是否需要啟用擴充（auto_rebalance_criteria），NSX ALB目前支援的包括了服務引擎的CPU、流量（mbps）、封包數（pps），以及未完成的連線數目（open-connections）。
‧這個指標可以允許的最高上限（auto_rebalance_capacity_per_se）。
‧相對於上面的上限，要進行scale-out動作的門檻是多少百分比（max_cpu_usage），而要進行scale-in動作的門檻又是多少百分比（min_cpu_usage）。
‧如果上次auto_rebalance的擴充或縮減動作發動後，要至少相隔多久才能再次啟動（auto_rebalance_interval）。
配置參考範例
這邊直接提供一些配置參考範例，第一個是筆者直接在Lab內做接下來會展示的範例。在此配置內，切換到admin tenant，名稱叫做Scaleout-Cloud的這個雲環境，並配置環境內的Default-Group服務引擎群組。此群組內，將要求：
‧啟用auto_rebalance。
‧採用的指標是服務引擎的CPU使用率。
‧CPU使用率的上限門檻是50%（超過50% CPU後，則要擴充服務引擎），CPU使用率的下限門檻是20%（低於20% CPU後，則要縮減服務引擎）。
switchto tenant admin switchto cloud Scaleout-Cloud configure serviceenginegroup Default-Group auto_rebalance auto_rebalance_criteria se_auto_ rebalance_cpu max_cpu_usage 50 min_cpu_usage 20 save
再一個範例，此配置內管理者切換到Avi tenant，名稱叫做「azure」的雲環境，並配置環境內的Default-Group服務引擎群組。此群組內，管理者要求：
‧啟用auto_rebalance。
‧採用的指標是服務引擎的封包處理量（pps）。
‧封包處理量的上限訂為200,000 pps。
‧pps的上限門檻是70%（超過140,000 pps後，則要擴充服務引擎），下限門檻是30%（低於60,000 pps後，則要縮減服務引擎）。
switchto tenant Avi switchto cloud azure configure serviceenginegroup Default-Group auto_rebalance auto_rebalance_criteria se_auto_ rebalance_pps auto_rebalance_capacity_per_se 200000 max_cpu_usage 70 min_cpu_usage 30 save
相關的配置參數詳細說明如果大家有興趣，可參考Avi網站（https://avinetworks.com/docs/21.1/how-to-configure-auto-rebalance-using-avi-cli/）內的說明。
動手實戰演練 觀察運作效果
到這裡，只說明了相關的配置指令，相信大家看了沒有什麼感覺，因此使用一個實際Lab運作的環境讓大家看看相關運作的效果。同上面第一個範例，配置要求是這樣：
‧啟用auto_rebalance。
‧採用的指標是服務引擎的CPU使用率。
‧CPU使用率的上限門檻是50%（超過50% CPU後，則要擴充服務引擎），CPU使用率的下限門檻是20%（低於20% CPU後，則要縮減服務引擎）。
在Controller Command Line內輸入相關指令後，從圖1中可以看到相關的配置有生效。
圖1 相關配置已經生效。
先看一下環境內測試Virtual Service的配置。為了要把CPU撐高，這個Virtual Service採用L7的應用型態（要檢查HTTP表頭），開啟Secure HTTP（做SSL Offload），WAF也開起來（耗費大量的CPU運算能力），如圖2所示。目前這個服務僅有運作在單一台服務引擎Avi-se-orfrk上。
圖2 採用L7的應用型態，開啟Secure HTTP和WAF。
接著開始驗證，從圖3中會發現，大約在9:16分時開始對這個服務發動壓測，約是每秒150個連線。跑一段時間後，在約9:24分時將連線數加大到每秒300個連線，然後就一直持續下去。
圖3 進行驗證，在9:16分時開始對這個服務發動壓測。
來看一下負責此Virtual Service的服務引擎。如圖4所示，首先看到在9:24分之前（150 conn/sec），上述的連線要求造成約35～40%的CPU使用率，而9:24分之後（300 conn/sec），新連線造成CPU壓力到達約70～80%的CPU使用率。但是在9:31分左右，CPU使用率又掉下來了，發生了什麼事呢？
圖4 觀察負責此Virtual Service的服務引擎變化。
看一下這個Virtual Service的事件。裡面可以看到，在連線量由150 conn/sec加大到300 conn/sec的時間（約9:24分）後不久，自動觸發了一個REBALANCE_VS_SCALEOUT事件。原因為何？設定服務引擎自動Scaleout的門檻是CPU的50%，在大連線量時，CPU過高，就超過了。接著一路往後，NSX ALB自動建立了一個新的服務引擎，並在建立完後將Virtual Service放到上面運作，約9:30分時相關的動作完成，如圖5所示。
圖5 觀察Virtual Service的事件。
在vCenter內，也可看到一連串關於這個新產出的服務引擎虛機Avi-se-zxdnx的相關配置工作，如圖6所示。
圖6 查看新產出的服務引擎虛機Avi-se-zxdnx之相關配置。
再回到Virtual Service內，將發現除了原本的服務引擎Avi-se-orfrk外，在新引擎Avi-se-zxdnx上也同時提供服務了，如圖7所示。
圖7 除了原本的服務引擎Avi-se-orfrk外，新引擎Avi-se-zxdnx上也同時提供服務。
去看第二台新產出服務引擎的效能圖，可以看到，持續在進行的連線要求，在第二台Service Engine內從開始提供服務後（約9:31分時），也花費了約40%上下的CPU，如圖8所示。
圖8 第二台新產出服務引擎的效能圖。
但回頭看第一台服務引擎，同時，CPU就掉下來了，橫向擴充機制完美地發揮效用，如圖9所示。
圖9 觀察第一台服務引擎，CPU用量下降。
以上看到了服務引擎自動擴充的展示，這裡順便也把Scale-in做一下。在大概9:47分的時候，停止了對此Virtual Service的壓測連線，從圖10中可看到連線數直接歸零。
圖10 連線數直接歸零。
連線數歸零，當然也會對應讓服務引擎的CPU降低，當降到設定門檻20%以下一陣子後，圖11內看到約9:50分時自動觸發了REBALANCE_VS_SCALEIN事件，並且在很短的時間內完成。然後，再去看此Virtual Service的相關資訊時，如圖12所示，很明確地可以看到又只由一個Service Engine提供服務了。
圖11 自動觸發了REBALANCE_VS_SCALEIN事件。
圖12 只由一個Service Engine提供服務。
結語
NSX ALB本身服務引擎的自動擴充及縮減，雖然需要在Command Line以指令配置，但還算是個滿穩定的功能，大家可依據需求採用。下篇文章內，將與大家討論後端Server的Auto-scale應該會是怎麼做。
＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化、軟體定義網路、微分段安全防護技術，以及新應用遞送方案的介紹與推廣。＞