虛擬雲網路

網路虛擬化NSX 技術文章系列二百四十六: NSX Advanced Load Balancer:來談一談 Auto-Scale(六)

作者: 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馬上秒級建立。但當然,核心應用架構就必須改成能在容器環境內以雲原生方式運作了。

相关文章

评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注

This site uses Akismet to reduce spam. Learn how your comment data is processed.