VMware收購了Avi Networks，並改名為NSX Advanced Load Balancer，變成了VMware在網路與應用遞送的新方案，上期文章已經詳細說明了該方案的效益、架構、功能，本期將重點放在方案架構介紹，說明其與傳統應用遞送方案的不同，以及採用此架構有那些好處。
在上期文章內與大家簡要介紹了VMware在網路與應用遞送的新方案NSX Advanced Load Balancer，也討論了傳統應用遞送方案的限制。NSX Advanced Load Balancer面向的是在Internet上運作的企業核心業務，除了能滿足應用遞送（如本地與全域負載平衡、Web Application Firewall等等）需求的同時，也達成易於自動化、原生支援虛機∕容器環境、可部署至不同公有雲等目前企業關注的重要需求。而本期文章要把重點放在NSX Advanced Load Balancer的方案架構上，說明與傳統應用遞送方案的不同，以及為何這個架構能取得上述的好處。
圖1 NSX Advanced Load Balancer架構示意圖。
NSX ALB方案架構說明
可用圖1來說明NSX Advanced Load Balancer的架構，分成控制器與服務引擎兩大部分。
控制器（Controllers）
首先要說明的是，方案需要先有控制器（Controllers）。NSX ALB的控制器具有下列的特性：
‧由三台構件組成，以2+1 Quorum的架構組成，同時間內允許單台失效。
‧控制器集中負責整個NSX ALB環境的配置、資訊查詢、自動化環境接取等作業。
‧所有管理者的連線都僅須連往控制器，管理者不必直接連往底層的服務引擎。控制器會將管理者要求的配置送往每一台服務引擎。
‧所有用戶實際的業務連線，只會在服務引擎上處理，不會到控制器。控制器失效，不會影響到現有的用戶連線。
‧一組控制器可以依據用戶實際需求，管理數十到數百台的服務引擎。
服務引擎（Service Engine）
NSX ALB的另一個核心構件則是服務引擎（Service Engine，SE）。服務引擎的特性如下：
‧NSX ALB方案內並沒有直接銷售硬體。服務引擎的方式是以軟體進行部署。服務引擎可以部署在用戶自行購置的x86伺服器上，或者以虛機、容器的方式運作均可。
‧NSX ALB的服務引擎除了部署於用戶自有環境內外，也可以在三大公有雲內部署建置。
‧服務引擎的配置由控制器下放，管理者除了極少數的Troubleshooting需求外，無須直接連到服務引擎。
‧用戶真實的業務連線是透過服務引擎進行服務。服務引擎可以透過Scale-Up或Scale-Out的方式，來提供大量的應用處理能力。
‧服務引擎當然可能會失效，NSX ALB架構內可以透過標準Active-Standby或是方案內的多台Active-Active架構來提供備援機制。
全新的軟體定義方案架構
相關的技術細節會在系列文章內繼續做說明，但大家可以看到，這樣的架構設計與傳統的應用遞送方案非常不同。標準的應用遞送方案都是銷售硬體盒子或板卡，亦即Active-Standby的架構。用戶在進行配置時就是連到各台硬體的Console內，用Command Line或是GUI的方式讓各台設備進行配置。而即使這些廠商都有所謂的「虛機」版本，但實際上也只是把在實體伺服器╱交換器上運作的功能核心轉放到虛機上面運作，配置的方式仍然相同。
同樣地，各家應用遞送方案廠商也可能會有對應的集中管理方案。但是，絕大部分的方案都只是做一個配置Portal的集中化。管理者登入到這個Portal，再連到不同的硬體或虛機設備，各自去一台台下設定。
但回到NSX Advanced Load Balancer架構，應該可以發現到，這與傳統的做法非常不同，而呼應全新的軟體定義方案架構，這包含了以下幾個重點：
‧控制層與轉發層分離：架構內控制與配置層集中，而應用轉發層是分散式的獨立構件。用戶是完全集中進行全系統配置、管理與分析，但同時轉發層可以依據實際需求進行擴充與異動。
‧用戶管理的方式支援GUI或是API/SDK的形式，採用宣告式呼叫，與不同自動化編排系統的整合也很完整。因為控制與轉發分離，無論管理者透過GUI、API或自動化編排系統，都只需要連接到集中的控制器來發送組態即可。
‧多元的部署方式：底層資源調用彈性，用戶可以配置服務引擎於實體機、虛機、容器，可以在私有雲或公有雲。用戶需求的應用處理資源不會限制在特定硬體，也不會限制於特定地點。
‧用戶的應用不再僅限於採用單台硬體Appliance，或是兩台Active-Standby的機制，或得要買個大冰箱內插多片板卡的方式來支援。單一用戶應用在NSX ALB內可以使用多台服務引擎，以Active/Active的方式來支援。
首先來討論一下NSX Advanced Load Balancer與其他競爭友商不同，完全採用軟體機制的這一點。以前在銷售負載平衡器的方案時，不同型號的Datasheet非常重要，在客戶的開標規格，大家必須列出買到的這台硬體可以提供的效能。比如幾個重要的參數：SSL TPS（進行SSL加密交易時的每秒可新增交易量）、SSL Throughput（進行SSL加密交易時的可支援頻寬）、Concurrent Sessions per Second（同時可支撐連線數）等等。不同的原廠會針對客戶需求提出要採用哪種型號的設備，也會特別說明因為有哪些特殊硬體晶片的設計，所以自己設備的效能特別強大等等。
也因此，不單單是在介紹NSX Advanced Load Balancer的時候，以前在賣NSX Data Center方案時，到現在也都還會被客戶問到，軟體吃CPU的效能，要怎麼與硬體來比呢？專用晶片的效能一定更好啊！
對的，但這只有在「單一設備」的比較下。在現在的軟體定義方案，底層傳輸層可以隨需求擴張，甚至分散到多台來處理。單台防火牆的硬體效能很強又如何？如果一個機櫃40台vSphere都可以提供防火牆功能，哪種效能好？單台負載平衡器的硬體晶片很棒又怎麼樣？如果一個應用服務可以分散到十台伺服器∕虛機上面做SSL加解密，哪個能力強呢？
購買授權後可用不同方式部署
在NSX Advanced Load Balancer方案內，並不是在賣硬體。用戶購買了授權之後，可以用虛機、實體機、容器等不同的方式進行部署，而部署的地點也可以是私有雲環境或公有雲環境（圖2）。請想像下面的狀況：
圖2 NSX ALB可以在一般商用伺服器硬體或公有雲上提供極高處理效能，並且是以中央控管與監控的機制。
以NSX ALB的簡易估算方式，單一CPU核心約能夠處理每秒新增2,500個SSL TPS交易的要求（若採用Elliptic Curve Cryptography，亦即ECC加密機制）。
既然NSX ALB沒有銷售硬體，假設用虛機部署。這個虛機如果是2個vCPU，就有5,000個SSL-TPS的運算能力，8個vCPU就可以支援每秒兩萬個新增交易，32個vCPU就是每秒八萬個。這代表著可以很容易去Scale-Up/Scale-Down服務引擎來因應核心業務的臨時需求。
更進一步地，NSX ALB方案可以透過Active/Active機制讓一個應用需求的負載平衡服務，同時在多台服務引擎上運作。如果有兩台1-vCPU的虛機做A/A，就是5,000個SSL-TPS，9個虛機的推斷容量就是22,500個SSL-TPS，這代表著可以很容易去Scale-Out/Scale-In多個服務引擎來因應需求。
既然不限定底層虛機∕實體機的規格，又可以多台部署，採用NSX Advanced Load Balancer就有可能打出很高的效能。目前NSX ALB自己的紀錄是在GCP可以打出12M SSL-TPS，4Tbps流量的能力，請想像一下，如果企業在短期內需要非常大量的交易量（如短期促銷、節日搶票等等），以下哪種做法比較好呢？一是購買一組很大很大很大的負載平衡器硬體，一年就用幾天；二是在需要的時候，短期內以Scale-Up/Scale-Out的方式取得大量的負載平衡處理能力，需求結束後再Scale-Down/Scale-In縮回來。
負載平衡規劃更靈活 隨時彈性調度資源
這種架構解決了一個長久以來常見的負載平衡規劃問題：在應用上線前，其實沒人能抓準到底需求效能是多少。在之前的硬體架構，因為害怕設備買太差撐不了應用需求，因此大家即使預算不足，也仍然忍痛要買大台的設備，結果平時設備的利用率都很低。而反過來，可能一年就某幾天需求量特別大，超過了購買的硬體設備規格，此時也沒法臨時加點CPU加點RAM就提升硬體的效能，那怎麼辦？重買更大的嗎？
而在NSX ALB的架構下，如果估算不對，初期配置的服務引擎太大，那麼只要把Service Engine縮小（Scale-Down），然後把多出來的Service Core給其他應用使用就好了。而反過來，如果配得太小，此時原本投資的也不用丟掉，只要增加服務效能，無論是Scale-Up（提升CPU）或是Scale-Out（增加服務引擎）均可。這在現代的電商服務、Internet應用上，都應該會帶給客戶很大的好處。
聽起來很完美，但要達成這樣的目的，一個技術前提要能達成：Active/Active的運作方式。要如何利用多台負載平衡器的效能同時提供單一服務運作？怎麼做Scale Out/Scale In呢？傳統標準的高可用度機制，如圖3所示：
圖3 高可用度機制實際運作比較。
‧兩台硬體為一對。兩台硬體中間透過RS232線路或是網路線偵測另一台的健康狀態。
‧用戶的Virtual Service跑在單台上。而同時，與這個服務相關的資訊（NAT Table/Session Persistence Table）也透過網路要同步到另一台備援的設備上。
‧當主要服務的Active設備失效，此時Standby的設備發現這個問題，就對外宣告各台Virtual Service的IP改在自己身上。
‧此時Standby設備就開始提供服務，同時因為各連線資訊之前有同步，用戶的連線也不會中斷。
這個架構可用、切換快速，而且非常穩定。這有兩個問題，首先容量就只剩一半，老闆覺得花了好多錢買兩台設備，結果就只有一台在動，不開心。當然也有些技術先進的廠商可以把服務分散在兩台上，有些服務的Active在左邊Standby在右邊，其他服務的Active在右邊Standby在左邊，對上面就宣稱其實兩台都有用。但實際狀況其實差不多，對於生產環境，就是必須要保留50%的容量準備。
第二個問題，就是單一服務最多同時使用單台硬體或虛機負載平衡器。當需要更多資源來提供單一服務的負載平衡處理能量，此時就只能買更大的設備了。
那NSX Advanced Load Balancer的架構可以怎麼樣呢？同樣地，這裡用圖4的圖例來說明。
圖4 NSX Advanced Load Balancer架構實際運作比較圖。
範例內總共有四個服務，App 1、App 3、App 4是測試用，或是營運等級沒有那麼高的次要服務，可以容忍較長的切換時間。此時，App 1/3/4都僅在單台服務引擎上提供服務，也無須將狀態（NAT Table、Persistence Table等等）送到其他台去。
App 2是非常重要的核心業務，政策上要求要分散到至少三台Service Engine來提供服務。圖例內可看到App 2在三台引擎上同時運作，且狀態也會在各台間同步。
此時中間的Service Engine失效了，例如底層的硬體出事，網路斷掉等等的。這時候原本在中間服務引擎上的App 2、App 3怎麼辦呢？
而App 3很單純，NSX ALB的服務器發現服務引擎失效沒有底層資源提供服務，就在其他台還有資源的服務引擎上重開。
當然，此時因為是整個重開，前面連線也沒有同步到其他台，將會需要幾秒鐘的時間恢復服務，而這些服務上的用戶也需要重新連線（因為原本連線的狀態不見了）。但因為這些是較不重要的應用，所以沒有關係。
App 2呢？此時雖然中間的服務引擎失效，但左右邊的還在。原本由中間SE服務的連線轉到左右邊來傳送，同時因為服務狀態有同步，所以用戶服務不會受影響。
但當然啦！各位可以看到左右邊的綠色變大了，代表原本用三台來提供App 2服務，現在只剩左右兩台，每台的連線數壓力變大。
緊接著，此時NSX ALB的控制器當然會知道有服務引擎死掉了。同時，控制器也會判斷下面兩個狀況：
1. 目前的服務承諾沒有達到：App 3應該要有三台引擎服務它，但此時只有兩個。
2. 服務引擎的壓力變大，可能超過了規劃的門檻。
NSX ALB的另一個特性是可以自動與南向的雲平台溝通，動態產出∕移除服務引擎。例如，這邊是在vSphere平台上，當目前的情況發生，ALB Conrtoller可以直接告知vCenter，要求部署出第四台服務引擎，如圖5所示。
圖5 要求部署出第四台服務引擎。
當嶄新的四號服務引擎自動產出，且與Controller回報後，此時依據實際的需求，Controller可以選擇把App 3再於四號引擎上重開，提供較分散、效能較好的服務。而App 2也可以在四號引擎上同時提供服務，此時就又同時有三個Service Engine提供重要的App 2服務運作了。
結語
限於篇幅，暫時到此為止。但仍沒有說明Active/Active機制是如何做到的，在下篇文章會就相關機制進一步與大家討論。
＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，持有VCIX-NV、VCAP-DTD、CCIE、CISSP等證照，目前致力於網路虛擬化、軟體定義網路暨分散式安全防護技術方案的介紹與推廣。＞