雲原生應用遞送機制　隨需編排不僅只負載平衡

在2019年7月，VMware正式宣布收購Avi Networks，並改名為NSX Advanced Load Balancer，為VMware的網路暨安全產品線增加了一名強力生力軍。Avi Networks是應用遞送方案（Application Delivery Controller，ADC）市場內技術非常革新的公司，對於導入新雲原生應用，需要高流量負載平衡、採用自動化編排、部署於虛機容器混合環境、甚至公有雲的企業來說，是非常值得考慮的方案。在接下來的文章中，將就NSX Advanced Load Balancer方案的效益、架構、功能等進行相關說明。

回憶應用遞送方案的歷史，大約是在上個世紀末開始到現在超過二十年，幾乎每個台灣的中、大型客戶應該都有採購並部署應用遞送方案。各企業的資料中心內可能已經使用了相關的解決方案，但是傳統的遞送應用方案有許多早期的設計與包袱，雖然在傳統應用架構內運作順暢，但對應到新一代雲原生應用的擴充性、隨需部署、自動化編排等現代化需求上就有所不足了。

因應新應用架構變化 新方案須考量AP面需求

近三、五年，因應雲原生架構轉變，新資訊系統需要被自動化、快速部署與更版、在不同的公有雲私有雲部署等需求大幅提升。而不僅是應用遞送方案，現在企業對於任何的IT底層基礎方案，其實都應該要對應新型態應用架構，在購買前考量如圖1所示的事項。那麼在台灣已經有超過兩百個客戶進行NSX Data Center設計方案的生產環境部署，是否符合了上面的要求呢？

第一，企業希望將網路與安全的配置能自動化編排，易於快速部署、異動、刪除、Scale Up/Down、Scale Out/In。要達成這樣的需求，首要必須要把網路與安全構件的管理集中化（NSX Management Cluster），提供現代化的API（支援Swagger - OpenAPI，以宣告式方式進行呼叫）以及SDK，而且可以很容易地被自動化工具調用（vRealize Automation/Ansible/Terraform）。

其次，NSX Data Center能夠同時管理虛機與容器，無論用戶的應用會採用哪種底層，都能讓維運團隊可以統合管理，並且容易橫向擴充。而且功能應該要資源池化隨需調用，不鎖定特定硬體才能部署。

第三，NSX Data Center不僅在企業私有雲環境內可以使用，也可以擴充到公有雲環境（VMC on AWS, NSX Cloud）。

簡單來說，上述的要求（易於自動化、原生就可以支援虛機∕容器環境、能夠部署至不同公有雲）已經是企業導入各種新IT方案前都應考量的項目。

而在理解NSX Advanced Load Balancer的方案與架構時，可以很直接地說，上述的需求都已被納入設計。NSX ALB的架構根本與NSX Data Center如出一轍，甚至在幾個地方走得更前面，與VMware產品的願景與理念是天作之合。

而且應用遞送服務是企業IT環境重要的一環，但這卻是原本VMware的網路系列產品較為欠缺的。原本NSX Data Center方案內，應用遞送服務僅有基礎本地負載平衡的功能。但如圖2所示，可以看到NSX Advanced Load Balancer的完整功能列表：

‧本地負載平衡功能（Local Load Balancing）：四層七層負載平衡、SSL Offload、基於URL的轉址及安全防護、Web Cache/Compression。

‧全域負載平衡（Global Load Balancing）

‧Web Application Firewall與安全功能：OWASP弱點的防護，連線數∕連線頻寬限制、來源地址限制。

‧連線日誌與分析：做得極為完整，後面會對此進行詳盡的介紹。

‧以軟體定義的方式，在私有雲、公有雲以及集中管理的方式部署，並提供完整的API及自動化編排工具整合。

‧完整多租戶支援

以目前NSX Advanced Load Balancer與其他的傳統應用遞送方案或是Application Switch等比較，功能面上大概沒有做的就是SSL-VPN與WAN-Link Load-Balancer。但這反而不是在資料中心內「應用遞送」的需求重點。

現有傳統應用遞送方案（負載平衡器）存在某些限制。請大家回憶目前標準採購負載平衡器是怎麼做？一對一對買。需要買負載平衡器的「盒子」，上架、接線、配置。而且，基本上一定是買一對，因為擔心單台硬體失效，此時另一台要馬上進行接手。

舉例來說，當企業要導入新應用，比如新一代行動網銀。這個時候，Web業務的前端需要一對Load Balancer，Application Server前面也要一對。而重要應用需要測試區，測試區內的Web/AP前也要至少各一台。災備中心也得規劃，那也要至少各一台。而重要應用不會只有一種，可能好幾組，因此在機房內就會如圖3所示這樣，有很多對負載平衡器擺著。

購買負載平衡器時的考量

這種傳統架構，從負載平衡器面世到現在幾乎都是這樣子，功能上當然相當成熟，運作沒問題。但從以前到現在，有幾個經常會是企業在購買負載平衡器時考量，但不易解決的問題：

以大筆預算購買負載平衡器，但容量都只能用一半

在生產環境中，負載平衡器後面就是最重要的核心業務，設備失效中斷幾個小時沒有人能承擔。而在傳統的Active-Standby架構下，採購的兩台設備就是需要有一台當備援用，因此有至少一半的容量空著。

導入新應用，容量不易規劃，負載平衡器常須購買過大的型號

如果專案團隊很清楚應用需求的效能規格，當然可以基於設備的規格文件（Datasheet）進行需求型號的規劃配置。這裡通常要詢問的問題包括：業務規劃的交易容量是多少？同時最多連線數大概多少？每秒新增連線數大概多少？頻寬需求又大概是多少呢？

但尤其是新的業務系統，上線前大家真的清楚需求效能嗎？而且風險是如果設備買太小，結果應用的流量比規劃的大。負載平衡器的「硬體」應該沒法直接加CPU加RAM來提升效能，只好重買新的。

所以，規劃單位通常希望降低風險，會抓Buffer買較大的型號。此時，常常就會發現設備擺在那裡，但真正使用的效能其實沒有那麼多。

業務系統因應促銷活動，結果現有設備容量撐不住，但無法提升

而與前面相反，現在的Internet服務可能因為業務單位的促銷活動、搶票，或是週期性的某些時候就是交易量較大。在這些業務交易量短期突衝時，如果超過了負載平衡器硬體的能力，企業無法拿其他台空閒的設備過來幫忙。

因應新業務架構，企業要導入自動化流水線，負載平衡也要整合在應用部署流程中，怎麼做？

應用遞送方案已經很成熟並且運用多年。但要因應自動化業務敏捷時部署，經常需要從產品本身架構做改變，例如做成軟體定義（Software-defined）並將方案的控制層與轉發層區分，提供集中管理且有易於呼叫的宣告式（Declarative）開放API。而在傳統的友商方案內，雖然都能宣稱有提供API，但是呼叫方式以及支援範圍都較難以方便使用及整合。

應用遞送架構快速回應變化

這裡想要說明的是，在傳統的Client/Server或三層式應用架構業務系統中，原本的負載平衡方案沒有什麼問題，交易需求的容量也較能夠規劃及預測。但在新型態的雲原生架構內，早期的容量估算方式早就不合適了。新的雲原生應用常會有下面這幾種特性：

‧應用的流量與以前相比，更難估算，峰值與平均值差異極大。能快速因應業務需求擴充（Scale Up/Scale Out）越來越重要。

‧業務上線下線異動頻繁，支援自動化編排機制已經不再是加分項目，而是必要需求。

‧應用不再僅部署於私有雲與虛機，也需要在不同的公有雲環境可以支援，也可能是虛機或容器。

因此，一個支援雲原生方案、能夠快速回應變化的應用遞送架構，可說是企業越來越需要的，而NSX Advanced Load Balancer可以因應這樣的趨勢。

在後續的投稿文章內，會陸續介紹的主題包括：NSX Advanced Load Balancer方案的技術架構簡述、NSX Advanced Load Balancer方案在大型Internet應用上的效益、NSX Advanced Load Balancer方案的應用分析與日誌、NSX Advanced Load Balancer方案在公有雲上的應用、NSX Advanced Load Balancer方案在自動化編排上的優勢與多租戶架構。

結語

目前，Avi Vantage方案已經在VMware正式更名為NSX Advanced Load Balancer。因此在本系列文章，無論是談論Avi、NSX Advanced Load Balancer或NSX ALB等等，都是指同一個方案。此外，如果本身已經是NSX Data Center的用戶，一定會詢問原本NSX DC內的Load Balancer功能還會支援嗎？請不用擔心，NSX DC內的負載平衡功能都會持續提供與維護，但如果是進階的新功能，後續主要就放在NSX Advanced Load Balancer產品內。

＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，持有VCIX-NV、VCAP-DTD、CCIE、CISSP等證照，目前致力於網路虛擬化、軟體定義網路暨分散式安全防護技術方案的介紹與推廣。＞