server room electric 3d rendering
虛擬雲網路

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

作者: 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) 的前置需求。

相关文章

评论

发表评论

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

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