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

續前篇我們說明了NSX Advanced Load Balancer最適用的部署方式在可藉由SNAT / Reverse-Proxy運作的環境，且應用可透過X-Forwarded-For / Proxy Protocol的機制取得用戶端IP地址，但若應用不支持上述架構，就需要特別討論。而接下來本篇內繼續說明三個NSX Advanced Load Balancer因為設計上並非硬體網路設備，因此不是那麼適用的場景：

沒有必要拿NSX Advanced Load Balancer作為DDoS清洗設備使用

NSX ALB可不可以放在Internet最前端，作為DDoS清洗設備呢？功能上沒問題。但要不要這樣用？不建議這樣用。問題不是在功能上，而是CP值的考量。

NSX ALB支持不同種類的DDoS防禦機制，大家有興趣的話可以參考官網的描述 ( https://avinetworks.com/docs/21.1/ddos-attacks-mitigated/ )。如果大家想把NSX ALB放在Internet第一線作DDoS阻擋，沒問題，但是

  • 如前文討論，NSX ALB並非硬體設備，相關運作都是採用CPU（以運作於不同種類公私有雲及軟體平台），並未採用ASIC硬體晶片。
  • 當攻擊流量大時，NSX ALB的服務引擎當然可以不斷地橫向擴充來提供極大量處理效能，但越多服務引擎，當然就代表要使用越多的CPU
  • NSX ALB的授權方式採用Service Core，也就是服務引擎上使用的CPU core數。因此DDoS這些無意義的攻擊流量越大，若採用NSX ALB作為DDoS防禦設備，就要耗用極大量的授權（錢）在阻擋這些垃圾流量上。此時，DDoS流量成功地把你花大錢採購的授權花光，攻擊成功～～
  • 但在『傳統網路設備』這些友商，是可以用硬體晶片ASIC來做DDoS阻擋的，對應絕大部分低階的DDoS攻擊方式，都能有很好的防護表現以及相對低廉的購置成本。

基於上述理由，在與不同客戶進行NSX Advanced Load Balancer的使用情境討論時，我都會直接建議另外考量DDoS防護需求，用硬體設備來做DDoS流量清洗。但當然，如果相關攻擊已經走到NSX ALB上，我們絕對可以提供應用前，最後一線有效的防禦。

NSX Advanced Load Balancer不支持線路負載平衡 (Link Load-Balancing) 的機制

既然NSX ALB定位不是在網路設備，很多友商傳統硬體方案可提供的線路負載平衡機制也就不是NSX ALB的重點。舉例來說，可能企業資料中心對外線路有兩個不同的電信商，企業希望某些應用網路流走電信商Ａ，其他走電信商Ｂ，且設備可以持續以不同方式進行線路/電信商端健康狀態檢測，並且在任一段有問題時用其他線路備援。這是很合理的要求，但並非NSX ALB的使用情境。

而也要特別提到的還有Global Server Load Balancing的運作。因為沒有線路負載平衡與檢查機制，因此NSX ALB的GSLB方案主要僅採用基於DNS，以及對服務本身進行健康檢查的運作機制。如果企業IT要求GSLB的切換、檢測方式要包含線路、電信商連線等更複雜的機制在內，這邊就不是我們的GSLB方案能夠處理的部分了。

NSX Advanced Load Balancer不支持SSL-VPN

在這兩年由於疫情的關係，我們接受了客戶極為大量的詢問：NSX ALB有沒有支持SSL-VPN方案？嗯抱歉沒有，我也很希望要有，因為SSL-VPN這兩年真的很好賣，但短期內真的沒有…嗯就這樣。

所以更進一步討論，尤其是在搭配如 Horizon / Workspace One等終端用戶方案時，我們也會被問到除了SSL-VPN外，還有相關的接取控制需求，比如說限制只有哪些有授權的用戶或是裝置可以登入企業內網環境。這些功能在其他友商通常是叫做Access Gateway等等類似的名稱。當我們與客戶在銷售End-User-Computing相關方案時，如果客戶有接入安全等相關需求，因為NSX ALB並未支持相關功能，我們也會推薦採用其他合作友商的方案來達成。

在這三篇，我們討論了由於NSX Advanced Load Balancer並非硬體網路設備，因此適用場景與傳統負載平衡器上的不同情境。這兩種方案互相競爭嗎？或許某些場景是啦。但下一篇，我想更進一步與大家討論NSX Advanced Load Balancer的真正使用場景：放在核心應用前面，『東西向』的應用遞送服務。