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

前篇文章內討論一個重點：雖然與傳統方案相同都是提供應用遞送服務，NSX Advanced Load Balancer並不是定位成一個『網路設備』，而是以軟體提供應用遞送功能的『服務構件』。NSX Advanced Load Balancer非常適合運用於新型態、雲原生架構應用上，提供易於彈性擴充、跨平台、支持自動化、多租戶的應用遞送方案，但當然由於架構的不同，部分在傳統方案可以完善支持的場景，就不見得是NSX ALB的強項了。在本篇內我要非常坦然地與大家討論這些場景以及功能需求，如果專案重點或是現行架構限制不幸與這邊的場景符合，且短期內無法改變，我也不會執著地建議客戶必須要採用NSX ALB來提供解決方案。

因此在進行應用遞送需求討論與方案規劃時，下面列出的這些點是請大家要特別注意的：

網路架構上，NSX ALB主要採用SNAT機制進行流量導流，不適合採用路由或inline模式

NSX Advanced Load Balancer最主要的運作方式是採用SNAT / Reverse-Proxy，當用戶連線到在服務引擎上的Virtual Server後，再以服務引擎本身的IP再去連線到後端的伺服器。這個運作模式能夠讓NSX ALB可以支持快速部署、Active-Active橫向擴充等架構，也是我們最推薦客戶使用的模式。

同時，NSX ALB也可支持Direct Server Return (DSR) 運作模式，不採用SNAT（不修改來源IP），將來源端用戶連線直接轉送給後端Server，後端Server直接回應給來源用戶，像是三角形的傳輸架構 ( https://avinetworks.com/docs/21.1/direct-server-return/ )。這也是多個用戶有採用的機制，但應用場景略有限制，比如說Application Profile可能僅能採用L4 TCP / UDP 而非七層模式，需要與應用團隊進一步討論。

但我也常碰到客戶希望是採用『網路設備』的模式，將負載均衡器直接放在業務前端，作為後端伺服器的預設閘道（Load Balancer作為路由器），或甚至作為一個Layer 2交換器inline攔截應用封包，直接進行負載均衡處理。這兩種方式若客戶堅持，我會直接告知不適合使用NSX ALB：

  • 雖然NSX ALB可以作為路由器，但配置麻煩、路由功能不強大、並且僅能以Active-Standby方式運作，採用NSX ALB的好處直接少了一大半。
  • NSX ALB並未支持inline模式，後續的roadmap也沒有（並非產品發展重點）

在應用上，若採用NAT是否會造成來源IP無法稽核？

接續上段討論，在部署NSX ALB時最建議的方式是採用SNAT，以代理方式重新去連接後端Server。因此在網路層，後端Server看到的連線IP地址會來自服務引擎，而非真實的用戶IP。這樣是否會造成用戶在應用維運或稽核上的困擾？

NSX Advanced Load Balancer目前版本可以透過下列兩種機制，在採用代理模式時，仍能將用戶原始IP地址進行記錄

  • 若應用為HTTP/S，NSX ALB支持採用X-Forwarded-For機制 ( https://avinetworks.com/docs/21.1/x-forwarded-for-header-insertion/ )
  • NSX ALB也支持較新的Proxy Protocol ( https://avinetworks.com/docs/21.1/proxy-protocol-support/ )，即使四層服務也可記錄用戶來源地址

此外，如果可以採用Direct Server Return架構，DSR機制就沒有做SNAT，因此來源用戶地址保留，也是另一種可以考慮的方式。

但無論採用哪種方式，一個前提都是『應用要能支持』。很多舊應用在短期內可能無法修改（比如說不支持X-Forwarded-For），但又有要記錄網路層來源IP作為維運或稽核使用的硬需求，此時在架構上的可選性就大幅減少，討論到最後，就很可能非得用傳統網路設備型態的負載平衡器不可了。

必須說，絕大部分的應用遞送方案討論到後期，上述的架構設計確認都是絕對避不掉的。但這幾年其實在與不同客戶討論時，可以感受到大家基本上都清楚這樣的限制，而且不僅NSX Advanced Load Balancer，甚至在不少傳統負載平衡器部署時也都會進行考量。我們已經看到很多客戶在新應用開發時，都把HTTP/S內要支持X-Forwarded-For作為基礎設計要求，這類應用後續要放在NSX Advanced Load Balancer內使用就完全沒有問題了。

另外想特別討論一點，在NSX Advanced Load Balancer 21.1.X的後續版本內已經規劃，於採用NSX-T Cloud的方案內，可以支持保留用戶來源IP的inline Load Balancing這個功能。架構大致如下圖，簡而言之，透過NSX Advanced Load Balancer與NSX-T Manager的溝通，可以在需求時自動於Tier-1 Gateway內加上redirect-rule，解決在不修改來源IP下的封包轉送問題。在這樣的機制內，前面討論的兩個問題就都解決了，無需採用Source-NAT，來源IP也可保留，唯一的架構要求就是必須底層要有NSX-T Data Center環境。因為這還是Roadmap feature，我不確定在本文刊出時是否產品已經可支援，但也請大家期待。

先到此，下篇我們繼續討論其他NSX Advanced Load Balancer不一定適合使用的應用遞送場景。