虛擬雲網路

網路虛擬化NSX 技術文章系列二百四十八: NSX Advanced Load Balancer:與傳統應用遞送方案的差異(二)

作者: 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不一定適合使用的應用遞送場景。

相关文章

评论

发表评论

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

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