虛擬雲網路

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

作者: 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應該會是怎麼做。

相关文章

评论

发表评论

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

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