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

這幾年我們去客戶那邊進行方案介紹時，一個話題只要拋出來，即使客戶 CIO 已經站起來要去下一個會，都會重新坐下來再聽一下：企業的核心業務要怎麼做自動擴張 (Auto-Scale) 呢？而這個課題只有越來越熱的趨勢，大家整天都在新聞上看到好多人要抽什麼券、排什麼產品、搶什麼票、申請什麼方案，結果連線量太大讓服務掛掉的快報了吧。對於 CIO、服務負責人、IT 管理者來說這讓人心煩意亂，報告寫不完，半夜睡一睡還會驚醒過來想怎麼辦。而如果，我們的核心服務在建置時，就設計為當連線量過大時就能夠自動擴充容量，用量回到正常後就自動縮回把資源釋出，這不是一個非常理想的狀況嗎？

當然如此，但之所以這個話題談了這麼久，被諸多的 IT 技術人員當作話題，就是因為『不好做』。略舉幾點：

  • 容量與資源要自動長出來，那硬體機器是會自動飛進機架內自己接線嗎？
  • 軟體架構與構件可以支持嗎？我們把Web Server擴充了，後端現有的資料庫有辦法擴充嗎？
  • 長出來的新構件，要怎麼進行配置？告訴應用管理者機器裝好了，趕緊連進去裝軟體與上 Patch嗎？
  • 用什麼判斷現在應該要擴充了？連線量過高？用戶回應時間過長？CPU過高？Memory 不足？

說真的，很多客戶轉向虛擬化、再改為容器、邁向公有雲、大幅改寫應用為雲原生方案，要做到服務本身可 “Auto-Scale” 是個業務上的終極需求。得怎麼達成？簡單分析一下各需求的對應方案：

  • 要能夠快速生出核心業務擴充時需求的資源，底層環境必須是雲的型態，至少也必須是虛擬化資源池的架構。需要CPU / Memory / 連線容量時，服務可以由所在的雲 / 資源池內快速拿到新增加的虛機 / 容器等構件
  • 應用內構件必須支持可解構、可分散化、可橫向擴充。各服務構件可以在需求時長出新構件，並透過負載平衡或叢集機制來協調運作。各個服務構件間的呼叫方式需要可以支持這種可解構、透過網路連線的運作方式
  • 不能用傳統裝伺服器的方法手動配置。需要機器時，要能夠快速從樣板長出虛機再搭配自動配置檔，或更直接：由image生出容器直接開始運作
  • 必須要能夠監控服務，或個別構件的運作情況。在對應的參數 (metrics) 超過門檻時，能夠自動啟動整個服務擴充的流程

身為一名 Presale 我很想和大家長篇大論說上面的需求 VMware 結合內部各方案都能夠做到，但以本系列文的主要目的，我們要專注談的是 NSX Advanced Load Balancer (Avi Networks) 方案在核心服務 Auto-Scale 的需求上能夠做什麼事。在系列文內，我想把重點放在下列幾點：

  • 能做到自動擴充前，可以怎麼在短時間內先做到手動擴充？
  • 作為負載平衡器方案，在負載平衡器本身碰到因為用戶連線數過高，加密容量不夠等等問題時，怎麼自動進行服務引擎的本體擴充 (Service Engine Auto-Rebalance) ？
  • Avi作為核心業務前的重要構件，可以看到哪些業務相關的參數，並據以發動自動擴充流程？
  • Avi 如何呼叫後端的服務進行擴充 (Server Auto-Scale)？

因此下篇系列文我想先把『自動』兩字拉開，討論一下要能夠做到快速『手動擴充』 (manual scale) 的前置需求。