針對如何讓服務自動擴張（Auto-Scale）的主題，前面兩篇文章說明了NSX Advanced Load Balancer的服務引擎於需求時手動進行橫向擴充，以及能夠自動地在需要時擴充負載平衡容量的Auto-Rebalance機制，最後本文將接著說明如何在後端Server做Auto-Scale。
前篇投稿的重點在進行NSX Advanced Load Balancer本身Service Engine的Auto-scaleout。而在後端Server這邊要做Auto-Scale其實是個複雜的程序。如果分析一下相關的流程，可以看出其實有三大部分：
1.要有監控構件以及明確的指標，來確認什麼條件下需要新增後端機器，或是什麼時候可以移除。
2.當前述的監控指標到達門檻時，透過自動化機制呼叫指定雲平台，要求擴充∕移除後端機器。
3.當後端機器擴充∕移除後，更新負載平衡器內對應Pool內的資訊。
上面這些事情是否一定要用NSX Advanced Load Balancer才能做呢？當然不是。台灣幾個大型客戶在VMware環境內要做Server Auto-Scale時，常見到的運作流程是：
由vRealize Operation來監控包含現有Server上的效能指標如CPU負載，或是透過負載平衡方案的Plugin取得服務連線數目等資訊。
當相關指標超過指定門檻時，vRealize Operation會呼叫vRealize Orchestrator的Workflow。這個Workflow可透過vRealize Automation已經建立好的Blueprint，直接進行對應需求的機器擴充或是移除。
完成後，呼叫負載平衡器加入Server到Pool內。或是更簡單，預先把相關可能擴充的Server都加到Pool，當新建的Server產出後，負載平衡器健康檢查發現這台Server有回應了，後續連線就開始往新建Server送。
所以說真的，Server Auto-Scale本來就不是什麼新東西，而且VMware原有的產品本來就能做到。那NSX Advanced Load Balancer在這邊有什麼不同點呢？這裡想要特別跳出來先只談一項：NSX ALB如何監控服務，並提供明確的指標。NSX ALB有很完善的Alert機制可用來達成此要求，一個簡單的Alert運作流程如圖1所示。
圖1 Alert運作流程示意圖。
這裡簡單說明一下，在NSX ALB內可以配置一個Alert（Alert Config），這個Alert被觸動的條件可以是特定預先定義的事件（Event），或是某個管理者設定的指標（Metric）。當事件被觸發或是指標的門檻到達時，Alert就會產生，並且會執行此告警內指定的行動（Alert Action）。
在Alert Action內，管理者可以選擇提供告知（Notifications）的行動，這邊包含了寄出郵件、記錄Syslog，或是發送SNMP Trap等。但同時，管理者也可以設定要求執行ControlScript。在NSX ALB內，ControlScript是基於Python的管理者可自訂編程，用來觸發後續想要執行的Workflow。
說明這一些，與Server Autoscale有什麼關係呢？
在NSX Advanced Load Balancer內，有非常多樣化的Metrics選擇，可以用來檢視應用的連線狀況，以及後端Server的效能與容量。NSX ALB自己是負載平衡器，當然可以看到服務的連線與回應狀態。但同時，NSX ALB又能夠由雲平台取得虛機的效能、容量等資訊。這代表管理者可以用多種的指標來配置在什麼狀況下需要發出告警，進而觸動Auto-Scale的動作。
進一步討論，NSX ALB內可以支援的指標有下列這幾類：
‧Layer 4指標：網路連線第四層（TCP/UDP）的指標資訊，例如完成連線數、新建連線數、頻寬等等。
‧Layer 7指標：網路連線第七層HTTP/S的指標資訊，例如平均回應時間、完成回應連線數、SSL連線數等等。
‧服務引擎指標：服務引擎的CPU、Memory、頻寬使用。
‧虛機指標：藉由與雲平台的整合，NSX ALB可以透過vCenter/AWS CloudWatch，抓到後端虛機的CPU、網路使用量、Disk IO等等。
直接舉例說明，在圖2內設定的Alert是對應到名叫「npool」的Server Pool，如果Server L7的平均完成回應數目已經超過每秒1,000次，且持續10秒以上，就要發動告警。
圖2 設定發動告警的條件。
完整Avi Alert支持的指標可參考以下的網頁：
https://avinetworks.com/docs/21.1/metrics-list/
本篇寫這些的重點是什麼呢？NSX Advanced Load Balancer作為一個與雲平台完整結合的負載平衡方案，非常容易就能取得服務效能是否正常、需不需要擴充的相關資訊。在上面的討論中可以看到，無論是由Virtual Service本身的連線數目、往後端Server的連線資訊、後端Server本身的效能，在NSX ALB內都能取得。此時當相關效能指標超過門檻，NSX ALB即可發出Alert：
‧告知管理者服務承載量可能過高。管理者收到告警後可以選擇「手動」進行後端Server擴充。
‧透過客製化的Python程式碼，或是與雲平台的整合，「自動」觸發後續Server擴充動作。
當NSX Advanced Load Balancer設置了適當的Alert並在服務量大發出告警後，即可觸發後續的Server自動部署動作。這邊的配置略為複雜沒有這麼直覺，看文件時常搞不懂構件之間的關聯，用圖3簡單解釋一下。
圖3 觸發後續的Server自動部署示意圖。
配置AutoScale條件監控Alert
通常會定義兩個Alert，一個負責Scale-Out的指標，另一個負責Scale-In的指標，以定義要發動相關動作的觸動條件。如圖4所示，在這些Alert內，通常至少會需要進行以下的配置：
圖4 定義要發動相關動作的觸動條件。
‧這個Alert監控的對象，例如針對後端的哪個Server Pool，或是哪個Virtual Service等等。
‧這個Alert對應的效能指標門檻，例如往Server連線數目每秒超過了1,000次。
‧指定這個Alert是「AutoScale Alert」，要使用於後面配置的AutoScale Policy內。
建立AutoScale Policy
AutoScale Policy內可配置Server AutoScale的相關參數並連結前面配置的Alert，包含當後端的Pool要做Auto-Scale時，最多幾台Server、最少幾台Server，Scale-Out與Scale-In動作的觸動條件（前述定義的Alert）等等，如圖5所示。
圖5 建立AutoScale Policy。
配置公有雲環境的AutoScale Launch Config
如果要配置在AWS、Azure這些公有雲上的Server AutoScale，在AutoScale Launch Config內其實只做一件事，就是告訴Pool說要做Autoscale時直接呼叫Pool內配置，對應這個公有雲的autoscale群組（ASG，autoscale-group），如圖6所示。
圖6 設定AutoScale Launch Config。
配置Pool
在Pool中，必須指定前面已經定義的Autoscale-Policy，才會啟動自動擴張功能。而如果是對應到AWS/Azure的環境，須同時指定AutoScale Launch Config要採用公有雲內的Autoscale Group，同時在Servers的定義內也需要指定對應的Autoscale Group，如圖7所示。
圖7 配置Pool。
在其他環境另配置Alert監控Auto-Scale事件並發動ControlScript
在其他型態環境，其實並沒有如公有雲般的Autoscale群組機制，如AWS EC2 Auto Scaling，或是Azure的Virtual Machine Scale Set。此時，目前NSX ALB就是提供基於Python的客製化做法，大家自己刻Script吧！如圖8所示，流程是建立另外一個Alert，這個Alert要監控的是「Server Autoscale Out」事件（上面的事件在前述效能指標到達時會產生），然後呼叫一個內有ControlScript的Alert Action來發動後續作業。而ControlScript要怎麼寫，大家就可以自行發揮了。
圖8 配置Alert監控Auto-Scale事件。
參考相關文件
上面寫這些，主要是如果大家想要嘗試相關的方法，閱讀NSX ALB的文件時可能因為有過多名詞搞不清楚，因此整理一下相關資訊。如果大家真的對使用NSX Advanced Load Balancer做Server Autoscale有興趣，可參考以下幾個相關文件。
在AWS及Azure環境
在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環境
必須先強調的是，由於在本文寫作時相關產品尚未整合完成，目前NSX ALB要調用vCenter/vSphere資源進行Server Autoscale，還是採用非常原始的方式。NSX ALB從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」。
但還是要再強調，上面的方法過於原始且非常容易出錯。更好的做法其實是需要NSX ALB和vRealize Automation進行整合，要做Auto-Scale作業時，直接透過Workflow來要求Server擴張部署。但在寫作目前時間點，這邊的整合尚未完成。
結語
作為本系列投稿文的最後一篇，在此對前後數篇談Auto-Scale機制的內容做一個簡單的總結：
‧要能夠做服務的快速Scale-Out/Scale-In，應用本身、底層環境、相關構件必須要有對應的環境配合，透過虛擬化、容器、公有雲架構等，讓管理者能夠在短時間以隨需取用的方式快速地進行相關構件擴充。
‧NSX Advanced Load Balancer完全支援在虛擬化環境或公有雲內，以手動或自動的方式進行服務引擎（負載平衡器）的擴充。搭配Auto-Rebalance機制，在服務引擎CPU、流量、封包數等過高時，NSX ALB可自行在短時間內快速生成服務引擎，並將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馬上秒級建立。但當然，核心應用架構就必須改成能在容器環境內以雲原生方式運作了。
＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化、軟體定義網路、微分段安全防護技術，以及新應用遞送方案的介紹與推廣。＞