公有雲上享用完整ADC　兼顧部署靈活操作一致

2020-11-17

饒康立

NSX Advanced Load Balancer的功能不少，在公有雲上可以非常方便地使用，對此本文將延續之前系列文章的相同主題，以Amazon Web Services公有雲為例，進行實際的操作演練，示範說明NSX Advanced Load Balancer如何與AWS完美整合，讓大家有一個確切的瞭解。

接續之前的NSX Advanced Load Balancer系列文章，本篇內容想與大家討論NSX ALB方案在公有雲環境內的應用。首先，要說明的是為什麼企業要在公有雲上面使用負載平衡功能？

第一，因為企業的核心業務已經逐步轉移或是All-in到公有雲環境內。既然重要業務機器都已經運作在雲端，負載平衡功能也在公有雲上運作是極為合理的。

第二，因為企業考量需要業務在全球不同環境運作，除了採用CDN方案外，在各地分別建立對應的業務資訊環境也是很合理的做法。此時，直接採用靠近當地的公有雲環境是極為彈性的選擇。

第三，因為電商業務交易量變動極大，可能在促銷活動、搶票等時間點會比平日的交易量高上數十倍。此時企業需要在短期內快速地擴增業務交易能力，但希望在活動結束後即可收回資源停止支出。除了業務系統本身的能力擴充外，負載平衡功能在此階段當然也需要能快速產出前端交易處理能力，若能夠在公有雲上運作，企業就不必考慮自行購買、安裝等問題，可以極為彈性且迅速地取得需要的負載平衡效能，並且不需要大量的資本支出。

上面的需求本身不證而明，大家應該都能馬上領會吧！但核心問題來了！目前各大公有雲運營商都有提供原生的負載平衡功能，而傳統的ADC方案廠商也都在公有雲上透過虛擬化方式運作各自開發的負載平衡機器。那此時，採用NSX Advanced Load Balancer方案要解決什麼問題呢？這裡分成下面兩個方向來進行討論：

若採用公有雲的原生負載平衡方案

若採用公有雲的原生負載平衡方案，對應到快速部署與彈性擴充的考量上，公有雲原生的負載平衡方案當然是沒有問題。

但用戶較為困擾的是這些方案本身的能力，若以企業需求的負載平衡功能來說比較原始。表面上看起來功能都有，但深入使用後，就會發現一些企業等級負載平衡的基本功能或是監控稽核上的需求，與專門的ADC方案比較，是不足夠或是限制過大。

目前，很多企業在公有雲上的使用相當成本導向。今天採用公有雲廠商A的環境，但經過精算後發現公有雲B的整體費用更為低廉，下年度就會直接開始進行業務在不同公有雲環境的轉換。這樣的考量以企業營運來說非常合理，但過程當中可能就會發現，在不同公有雲環境的介面、功能、自動化呼叫等需求上，方案轉移的工程會相當大，在負載平衡方面當然也是如此。

若在公有雲上採用傳統ADC廠商的負載平衡方案

如果在公有雲上採用傳統ADC廠商的負載平衡方案，則與前面的狀況相反。基本上，這裡使用的是這些ADC廠商大量銷售硬體的虛擬化版本，功能上絕對沒有問題，管理介面也是熟悉的。

但這代表與原本在私有雲中使用傳統方案內的限制也相同。例如，如果需要公有雲上非常大的交易處理量，這些傳統方案的負載平衡虛機要如何擴充？多個環境、多台設備時，配置是否會開始變得很複雜呢？

許多廠商在公有雲上的計價模式與傳統硬體是類似的。這代表若客戶僅在短期有限的時間內需要大量的負載平衡傳輸量，在公雲上採用這些傳統廠商的方案仍然需要大量的資本投資。

在與客戶進行訪談及互動討論時發現，會大量採用公有雲的客戶，有相當高的比例希望採用自動化、彈性編排的工具來部署基礎架構。公有雲本身的負載平衡功能在這裡完全沒有問題，但採用傳統廠商的方案在這裡就困難了，包含在常用的自動化編排工具上的整合、傳統舊式API的呼叫方式，以及架構上管理介面分散到多台設備的問題，都會是導入基礎架構自動化的問題點。

NSX ALB在公有雲的支援性

許多客戶採用NSX Advanced Load Balancer的重要因素便是在公有雲上的支援性，希望能夠在達成彈性擴充、費用減省等業務要求的同時，也能達到維運的一致性與功能的完整，取得較能兩全其美的結果。採用NSX ALB方案可以達成的效益包含：

‧三大公有雲的支援，在各公有雲以及企業私有雲環境間單一的配置介面、共通的自動化編排機制。

‧在公有雲上的彈性部署與快速擴充。

‧完整的ADC方案，包含四層七層負載平衡、全域負載平衡、網站應用程式防火牆（WAF）、連線分析等功能都可取得。

在圖1中，可以看到目前三大公有雲AWS、Azure、GCP都是在NSX Advanced Load Balancer方案的完整支援範圍內。

圖1 NSX Advanced Load Balancer方案完整支援AWS、Azure、GCP三大公有雲。

在AWS環境內運作NSX ALB

接下來，想讓大家看一看NSX ALB方案在AWS環境內的運作，以此體會一下NSX ALB能夠在公有雲上運作的強大能力。當需要在公有雲環境中使用NSX ALB負載平衡器時，基本上會包含下列的相關步驟：

一開始，必須在公有雲或是企業內的私有雲環境，將NSX ALB Controller Cluster安裝完成。當然，如果Controllers是配置在企業私有機房內，此時從私有機房到公有雲間應該要有藉由VPN或Direct Connect所建立的網路連線。接著，選擇建立一個新的Cloud，選擇AWS，並配置所要連接的AWS Region、Access Key以及對應的Secret Access Key。另外，也可以採用IAM Role的方式來配置。

然後，決定在這個Region內要使用哪一個VPC，還有NSX ALB服務引擎要配置到哪些Availability Zone，以及對應的管理網路。

如果希望特定的Service Engine Group，也可以直接選擇。Service Engine Group是NSX ALB方案內的特定名詞，當管理者建立一個Virtual Service提供負載平衡服務時，可以決定這個服務要採用Active/Active或是Active/Standby的保護等級，以及要把這個虛擬服務擺放到哪種等級的底層資源。例如在私有雲內，不同的Service Engine Group可以定義是提供不同CPU、Memory、Storage的虛機資源。而在AWS中，不同的Service Engine Group內可以定義底層的Service Engine是要採用c4.large或是t3.small等不同的Instance。

在圖2所示的展示環境中，在NSX ALB內建立了一個名為cjao-AWS的雲資源，並且連接到東京Region。

圖2 在NSX ALB內建立一個名為cjao-AWS的雲資源，並且連接到東京Region。

接著，如圖3所示，選擇要使用哪個已經預先建立好的VPC，以及在此VPC內所採用的AZ與管理網路。

NSX ALB在AWS提供負載平衡

基礎架構連接起來後，想展示一個很簡單的NSX ALB在AWS上提供負載平衡功能。

圖4是演示環境的說明，展示應用的虛機是放在私有雲環境內。這裡是在內湖的一個機房，但此機房與公有雲（AWS Tokyo Region）之間已建立VPN通道。但這個展示應用的負載平衡虛擬服務要求在AWS上提供服務，因此對應的NSX ALB服務引擎也會建立在AWS上。對應到這個負載平衡的虛擬服務可以配置一個Elastic IP（圖4的13.114.184.141），可透過這個外部IP連線到這個服務。

首先，可以看到在配置NSX ALB服務前的EC2環境，目前沒有任何Service Engine的Instance正在運作，如圖5所示。

接著，進行基本負載平衡的相關配置，包含建立一個Pool來定義後端要進行的伺服器有那些，以及一個新的Virtual Service，裡面選擇所要採用AWS Cloud，這個服務的Virtual IP要放到哪個網段內，而且前面需要有固定的Elastic IP可以連接，如圖6所示。

當這個Virtual Service要啟用時，NSX ALB Controller會尋找在對應的AWS Cloud內是否就有現成可用的服務引擎。如果沒有，此時Controller會自動透過AWS的API，要求在前面已經連接的環境內自動產出可用的服務引擎。從圖7～8中，可以看到新的AWS-LB-HTTP虛擬服務開始啟用，但同時也在等待服務引擎產生。而在AWS EC2內，當沒有手動參與，新的服務引擎自己跑出來了。當服務引擎建立完成後連接到控制器，NSX ALB Controller會將需求的Virtual Service配發到Service Engine來提供服務，從圖9可發現外部的Elastic IP被指定到對應的服務引擎上。