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

接續前篇。當NSX Advanced Load Balancer設置了適當的Alert並在服務量大發出告警後，即可觸發後續的Server自動部署動作。這邊的配置略為複雜沒有這麼直覺，看文件時常搞不懂構件之間的關聯，用下圖簡單解釋一下

配置AutoScale條件監控Alert

通常會定義兩個Alert，一個負責Scale-Out的指標，另一個負責Scale-In的指標，以定義要發動相關動作的觸動條件。在這些Alert內我們通常至少會需要配置

  • 這個Alert監控的對象，比如說針對後端的哪個Server Pool，或是哪個Virtual Service等等
  • 這個Alert對應的效能指標門檻，比如說往Server連線數目每秒超過了1000次
  • 指定這個Alert是”AutoScale Alert”，要使用於後面配置的AutoScale Policy內

建立AutoScale Policy

AutoScale Policy內可配置Server AutoScale的相關參數並連結前面配置的Alert，包含當後端的Pool要做Auto-Scale時，最多幾台Server，最少幾台Server，Scale-Out與Scale-In動作的觸動條件（前述定義的Alert）這些

（公有雲環境）AutoScale Launch Config

如果我們要配置在AWS / Azure這些公有雲上的Server AutoScale，在AutoScale Launch Config內其實只做一件事，就是告訴Pool說要做Autoscale時，請直接呼叫Pool內配置，對應這個公有雲的autoscale群組 (ASG, autoscale-group)

Pool

在Pool內，需要指定前面已經定義的Autoscale-Policy，才會啟動自動擴張功能。而如果是對應到AWS / Azure的環境，需同時指定AutoScale Launch Config要採用公有雲內的autoscale group，同時在Servers的定義內也需要指定對應的autoscale group。

（其他環境）另配置Alert監控Auto-Scale事件，並發動ControlScript

在其他型態環境，其實並沒有如公有雲般的Autoscale群組機制，如AWS EC2 Auto Scaling，或是Azure的Virtual Machine Scale Set。此時目前Avi就是提供基於Python的客製化做法，大家自己刻吧。流程是建立另外一個Alert，這個Alert要監控的是”Server Autoscale Out” 這個事件（上面的事件在前述效能指標到達時會產生），然後呼叫一個內有ControlScript的Alert Action來發動後續作業。而ControlScript要怎麼寫，大家就可以自行發揮了。

上面寫這些，主要是如果大家想要嘗試相關的方法，閱讀Avi的文件時可能因為有過多名詞搞不清楚，因此整理一下相關資訊。好，如果大家真的對使用NSX Advanced Load Balancer做Server Autoscale有興趣，幾個相關文件：

在AWS及Azure環境：

在公有雲的server autoscale機制簡述：https://avinetworks.com/docs/21.1/autoscaling-in-public-clouds/

AWS環境的詳細配置流程：https://avinetworks.com/docs/21.1/configuration-and-metric-collection-for-aws-server-autoscaling/

Azure環境的詳細配置流程：https://avinetworks.com/docs/21.1/azure-vm-scale-sets/

在VMware環境：

我必須先強調由於相關產品尚未整合，目前Avi要調用vCenter/vSphere資源進行Server autoscale還是採用非常原始的方式。Avi由18.1.5版本後有內建Python的pyVmomi SDK，可用來呼叫vCenter/vSphere進行作業。如果大家『真的自己想刻Python Code』並且『自己想做Python troubleshooting』，一個在VMware環境的範例作法在 https://avinetworks.com/docs/21.1/pool-server-autoscaling-in-vmware-clouds/ 。相關youtube影片也可參考 https://youtu.be/e8L-6OTkgEw

但還是要再強調，上面的方法過於原始且非常容易出錯。更好的做法其實是需要Avi和vRealize Automation進行整合，要做Auto-Scale作業時直接透過workflow來要求server擴張部署。但在寫作目前時間點，這邊的整合尚未完成。

作為本系列文的最後一篇，我想在此對前後六篇談Auto-Scale機制的內容做一個簡單的總結：

  • 要能夠做服務的快速Scale-Out / Scale-In，應用本身、底層環境、相關構件必須要有對應的環境配合，透過虛擬化、容器、公有雲架構等，讓管理者能夠在短時間以隨需取用的方式，快速進行相關構件擴充
  • NSX Advanced Load Balancer完全支持在虛擬化環境或公有雲內，以手動或自動的方式進行服務引擎（負載平衡器）的擴充。搭配auto-rebalance機制，在服務引擎CPU、流量、封包數等過高時，Avi可自行在短時間內快速生成服務引擎，並將Virtual Service在多台Service Engine內同時運作並分散負載
  • NSX Advanced Load Balancer整合雲平台，可以同時看到應用連線、服務引擎、以及後端伺服器效能等狀態，可據以建立監控指標並發出告警
  • NSX Advanced Load Balancer可直接整合公有雲之autoscale-group進行server之擴充，或搭配基於Python的ControlScripts透過客製化方式呼叫其他平台進行需求部署作業

最後提一點個人的感想。如果真的要完全達成核心業務的快速Scale-Out，以NSX Advanced Load Balancer搭配Kubernetes架構應該是最簡單的。負載平衡器 (Avi Service Engine) 本身非常容易擴張，後端K8S deployment也是一鍵按下，Pod馬上秒級建立。但當然，核心應用架構就必須改成能在容器環境內以雲原生方式運作了。