兼顧負載平衡/業務機器　半自動擴充關鍵服務容量

這幾年到客戶那邊進行方案介紹時，一個話題只要拋出來，即使客戶CIO已經站起來要去下一個會，都會重新坐下來再聽一下：企業的核心業務要怎麼做自動擴張（Auto-Scale）呢？而這個課題只有越來越熱的趨勢，大家整天都在新聞上看到好多人要抽什麼券、排什麼產品、搶什麼票、申請什麼方案，結果連線量太大讓服務掛掉的快報。對於CIO、服務負責人、IT管理者來說，這讓人心煩意亂，報告寫不完，半夜睡一睡還會驚醒過來想怎麼辦。

要做到Auto-Scale有何難處

如果核心服務在建置時，就設計為當連線量過大時能夠自動擴充容量，用量回到正常後就自動縮回把資源釋出，這不是一個非常理想的狀況嗎？當然如此，但之所以這個話題談了這麼久，被諸多的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）？

‧NSX ALB作為核心業務前的重要構件，可以看到哪些業務相關的參數，並據以發動自動擴充流程？

‧NSX ALB如何呼叫後端的服務進行擴充（Server Auto-Scale）？

因此，本文想先和大家討論一下如何快速地進行「手動擴充」的條件。咦，這與本系列投稿好像訴求不同。但去除「自動」這兩個字聽起來很性感，如果自身的商業目的是在需要時，於短時間快速地擴充業務處理容量，即使有少部分地方得要管理者手動介入，應該都還是能符合企業需求的。

請先回想一下實際的每天狀況，企業的業務真的會毫無原因地突然超級大量往上衝，讓IT毫無準備只能眼睜睜看著環境被打垮嗎？或許偶而有，但絕大部分的時刻，是能「預先知道」在哪時業務量會大量增加的。每個月哪幾天是會員日，下週三可以開始預約熱門票券，下下週會有新促銷方案開賣。交易量會衝到多少或許難以預測，但許多時候，其實有一段前置量時間可以預先進行準備，而不是站在沙灘上不能動，眼睜睜看到大浪已經打到眼前。

假設有一週，或是更短只有一天，此時要怎麼進行「手動橫向擴充」（Manual Scale-Out/In）？如果大家的環境已經有NSX Advanced Load Balancer，而且已經虛擬化、容器化、運作在公有雲上，其實真的不會很麻煩。可從「負載平衡器容量的橫向擴充」、「業務機器的橫向擴充」兩個點進行討論。

負載平衡器容量的橫向擴充

負載平衡器容量的橫向擴充很重要的原因是，很多交易瓶頸其實就是卡在前端的負載平衡器效能，例如要進行SSL-Offload，或把Web-Application-Firewall開起來，連線量大時都相當吃資源。如果目前的負載平衡器是硬體的，但買得不夠大台，估計容量會不夠，此時怎麼辦？不怎麼辦，快去借貨借個大台的啊！期盼在期限前能拿到貨、上架、接線、開始配置。總算趕上了，促銷活動結束了，記得機器要拆下來還人家。

筆者在多次NSX Advanced Load Balancer文章中不斷強調，NSX ALB方案兩個與傳統負載平衡器極為不同的核心差異在於：

‧透過Active-Active架構，單一應用可以由多台負載平衡機器（在NSX ALB內稱做「服務引擎」）上同時提供服務。

‧NSX ALB的控制器（Controller）可以指揮公私雲平台直接進行服務引擎的安裝與配置。

以前提過了，但再老調重彈。如圖1所示，在NSX ALB的管理介面內可以看到nginx-vs服務僅運作在Avi-se-orfrk這台服務引擎內。如果管理者覺得效能不太夠，此時可以「手動」啟動Scale Out的流程。

啟用Scale Out時，管理者要求要建立新的服務引擎。此時，Controller告知vCenter要做這件事，到vCenter介面內，可以看到一個新的虛機Avi-se-mtrtw開始自行部署，如圖2所示。這邊的動作是完全自動的，管理者不需要手動匯入OVA，不需要接網路配IP，不需要下額外的配置指令。

過了三分鐘，可看到nginx-vs這個應用已經是同時由兩個服務引擎提供服務，如圖3所示。

上面的整個流程要花多久？了不起五分鐘吧！在採用NSX Advanced Load Balancer這種軟體定義並完整整合雲平台的方案時，手動新增一台服務引擎也不過就是幾分鐘的時間，不需要去找設備找預算、上架、接線。即使明天新的產品就要上線，也有充裕的時間可以快速進行負載平衡構件的擴充，這與以前的傳統硬體架構，變更動輒要幾個星期甚至幾個月的時間相比，已經是極大的改善了。

當然大家會說，底下得要先有虛擬化∕公有雲架構，且有空置的容量，才能做到這邊的即時擴充啊？

沒錯，這也呼應了在前篇文章談到的，為什麼把架構改成虛擬化、運作在公私有雲環境上如此地重要，因為這樣才有機會做到「即時取用」資源。

業務機器的橫向擴充

前端負載平衡方案擴充了，但業務效能瓶頸也可能就是發生在後端機器本身的能力不夠。沒錯，因此底層架構上是否可以快速地建立業務機器，當然也相當重要。這裡不想多談，但相關的機制應該包括：

‧怎麼在虛擬化資源池或公有雲內快速由樣本（Template）產出虛機，並進行需求的自動客製化（Guest OS Customization）。

‧透過組態管理工具如SaltStack、Ansible在虛機內安裝需求的軟體構件。

‧或更直接地，把業務機器做成容器Image，在Kubernetes的Deployment內直接部署，以Scale機制來新增或減少相關的Pod。

‧最後，記得在前端負載平衡器的Server Pool內把擴充的業務機器加進來。

也就這樣，要花多少時間？容器這種幾乎是秒級產生的就不談了，即使是個大虛機，從複製、作業系統客製化、軟體安裝等等動作，也就幾十分鐘而已。只要軟體架構有支援橫向擴充，方案採用虛機或容器，上述的作業就算要手動配置，也不花太多時間。

結語

先寫到這，但即使不斷強調，在已經轉移至虛擬化、軟體定義架構下，「手動橫向擴充」其實也不會花太多時間，大家應該還是覺得，這樣就是不夠帥，拿不到預算。所以下篇文章要進入本系列投稿文的核心重點：如何進行NSX ALB服務引擎的自動橫向擴充。

＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化、軟體定義網路、微分段安全防護技術，以及新應用遞送方案的介紹與推廣。＞