之前三篇文章已經陸續介紹了NSX Advanced Load Balancer的構件，怎樣規劃建置NSX ALB，以及配置多樣SEG樣版，自動部署服務引擎，並講解如何做好底層網路準備。本文將延續同一個主題，接著針對每個步驟在安裝時的考量，做一詳盡的說明。
在本系列文章中已經陸續逐步說明過各個NSX Advanced Load Balancer（Avi Networks）的核心構件及底層網路架構，因此本文將針對每個步驟在安裝時的考量與大家討論。本文並不是一個Step-by-Step Guide，若大家有需要，可以參考Avi相關的文件，或是與VMware的代理商或經銷商進行聯繫。請參考圖1這張NSX Advanced Load Balancer的安裝流程圖，對應到不同的環境，細部配置當然不一樣，但大致上的流程是下面這樣。
圖1 NSX Advanced Load Balancer安裝流程圖。
建立/確認現行環境與需求網段已準備完成
如同前幾篇文章所介紹，在這個步驟最重要的是確認Controller與Service Engine是要安裝在哪個環境上。私有雲還是公有雲？虛機還是實體機？然後到Avi的網站尋找相關的安裝文件，確認需求的資源，並且準備底層需求的網路配置（前述的管理網段、VIP網段、後端Server網段等）。
Avi Controller匯入及Controller Cluster建立
例如，在vCenter/vSphere環境內要進行下列作業：
‧把三個Controller的虛機匯入。
‧在第一個Controller上，需要輸入管理者帳戶密碼、輸入授權、設定Backup密碼等。
‧把第二個第三個Controller納入此Cluster，並且指定Cluster IP。
‧接後續流程，設定第一個Cloud。
南向之Cloud連結
通常在開始配置Controller時，介面就會請管理者設定第一個Default Cloud。當然，管理者後續也可以把其他的Cloud加進來，例如同一組Controller內可能會連接兩個不同的vCenter/vSphere環境（生產區與測試區），有些應用要採用實體機（因此要配置Linux Server Cloud），有些應用放在公有雲上，像是這些工作。
在這裡，通常基本上要配置的是：
‧設定與Cloud的連接，例如vCenter的FQDN、帳戶、密碼等等。
‧設定Read/Write Access。Read Access代表Avi Controller僅會讀取這個Cloud上的現有配置（有哪些網路、哪些虛機等等），但不會進行任何配置異動。Write Access代表Avi Controller可以在需要時進行服務引擎虛機的主動安裝，設定安全群組等作業。若要發揮Avi的方案效益來提供自動化、快速部署的環境，採用Write Access是建議的做法。
‧配置這個Cloud是否要整合Avi本身的IPAM、DNS等服務，此時採用這個雲的Virtual Service可以從指定的Pool內自動拿IP，並且註冊到DNS上。
‧設定Avi可以管理這個Cloud裡面的哪個資源，例如vCenter內的哪組Data Center，或是AWS裡面指定Region內的哪個VPC。
‧設定管理網路（服務引擎使用）是哪一個。
IP Pool及對應路由配置
在前述配置的管理網路以及VIP/Backend等業務網路內，當服務引擎要連接這些網路，需要配置接取的IP地址。這邊的動態配置可以透過DHCP或是IP Pool方式完成。若採用DHCP，管理者應該在第一步驟中確保相關網路內有DHCP Server/DHCP Relay的設定。若採用IP Pool，管理者可以在Avi介面，於選定的網路上設定一段IP範圍來配置。
此外，也需要進行如管理網路或是對後端Backend Server網段的Gateway配置。這些同樣在Avi UI內Infrastructure - Gateway的介面中可進行
Service Engine Group配置
接下來對應各個指定的Cloud，可以調整裡面的Default Service Engine Group，或者另外設定新的Service Engine Group來因應不同的Virtual Service服務需求。如前面文章所述，在不同的Service Engine Group內，可以指定：
‧不同的High-Availability等級
‧服務引擎的CPU、Memory、Storage等資源需求。
‧進階設定如Log、多少個Virtual Service可以放上來、怎麼放等等細部配置。
到這邊，其實已經算是方案安裝完成了。接下來，其實是應用遞送方案進行應用本身配置細節的部分，像是後面的Server有哪些、Health Check機制用哪種、應用本身要採用哪種Profile來進行分析等等。
對應到Avi的名詞，接下來要配置的是後端的「Pool」以及前端的「Virtual Service」。
配置完成後，Controller會依據管理者的指示，將這些應用遞送的需求放到Service Engine上。此時，如果Service Engine Group內已經有現有的服務引擎且具備足夠的資源，Virtual Service就會直接在現有的服務引擎上運作。但如果還沒產出服務引擎，或是現在服務引擎的資源已經不足，此時Controller就會依據Service Engine Group的配置產出新的服務引擎虛機來提供需求的功能。因此，接著和大家說明的就是「Pool」和「Virtual Service」這兩個業務對應的配置元件。
在Avi的名詞內，「Pool」代表的是與後端Backend Server的配置連接。有哪些伺服器？Health Check如何進行？要不要進行連線堅持？這些與後端真正應用伺服器相關的配置會建立在Pool裡面。而「Virtual Service」代表的是面對用戶的前端介面。用戶要往哪個Virtual IP哪個Port連接？這個應用是哪一種？要不要放憑證？要不要進行安全防護以及HTTP這邊的控制與改寫？這些配置就是放在Virtual Service內。
Pool配置元件
先從Pool的相關配置做介紹。在不同Cloud裡面Pool的設定會有些許的不同，但一般管理者在設定時，會有三個主要的頁面：
通常對應到這個Pool最主要的相關設定，如圖2所示。基本上，幾個最重要的參數都是在這裡配置：
圖2 Pool的Settings設定頁面。
‧Pool的名稱
‧在Server需要關閉中斷連線時，Graceful Disable（逐步將現有用戶連線中止）的等待時間。
‧選擇這個應用指定的Load Balancing機制，像是Least Connection、Round-Robin、Consistent Hash等等。
‧在公有雲上，要不要對應AutoScale機制來自動增減後端的Server（如AWS的AutoScaling Group）。
‧連線堅持（Session Persistence）的配置方式，如對應不同的Client IP，或者針對HTTP Cookie或Application Cookie讓用戶連線都可以持續連到後段的單一Server上。
‧Server健康檢查（Health Check）的配置選擇，管理者可以在這裡選用系統的HTTP、HTTPS、Ping等等不同的預設機制，或是在Avi的UI介面內，自訂出一個Health Check的機制（例如要檢查哪個網頁、HTTP回應值應該是多少、TCP哪個Port），然後再配置到此。
‧對後端伺服器是否要啟用SSL。對於HTTPS應用，管理者可能考慮只需要在用戶到LB端之間採用HTTPS，LB到Backend Server跑HTTP就好（SSL Offload）。但也有許多客戶由於安全考量，LB端到Backend Server間也要跑HTTPS。此時，這裡就可以啟用往後端的SSL，且設定對應的SSL Profile等。
如圖3所示，在此選擇後端有哪些Servers。可以一個一個IP來設定Server的網路位址、用FQDN反查，或是直接輸入一段IP範圍亦可。在某些Cloud裡面，可以直接選Network，然後Avi會將接到這個Network上的所有虛機列出來，讓管理者來勾選。
圖3 Pool的Servers設定頁面。
同時，在不同Cloud內，Server也可能是透過群組的方式進行配置。如果環境內有NSX-T（NSX-T Cloud）、NSX for vSphere（整合在vCenter Cloud內），Server的選擇可以直接是一個Security Group。AWS的環境內，這裡可以直接是EC2內的一個Auto Scaling Group。
在每一個Server內，可以選擇應用是要連接到哪個Port（如果與預設值不同），並且配置對應的Ratio，也就是依據Server本身的效能給予不同權重的概念。
通常這裡會建議管理者直接指定這個Pool是對應在哪個Network裡（圖4），此時提供服務的Service Engine就會伸一隻腳到這個Network來。Avi通常可以自動依據Backend Server的IP地址來自行調配，可是若管理者可以明確指定當然是最好。
圖4 Pool的Advanced設定頁面。
其他在這邊的相關配置有包括像是如果整個Pool都失效了，是單純將用戶連線關閉，或是回應什麼訊息、轉址到哪些地方。還有，是否要將用戶的連線做SNAT到自己身上。如前面文章有討論，Avi的預設模式是Proxy機制，用戶到Avi的連線預設會改用Avi自己的IP再連往後端Backend Server。但對於某些特定的舊型應用，一定要看到網路層用戶IP的，Avi還是可以改用路由模式，然後不做SNAT。
上述的說明討論如何利用「Pool」元件來指定提供重要應用服務的伺服器，也就是在負載平衡方案的「後端」，定義了往後端Backend Server的配置連接相關設定。但要怎麼樣進行對應的負載平衡以及服務遞送呢？接著，就來討論「前端」的「Virtual Service」配置。
在Avi內，Virtual Service代表一個面對用戶的前端介面，在不同的應用遞送方案，可能會被稱為Virtual Server、Virtual IP等等這些不同的Term。基本上，要遞送什麼樣的「Service」給客戶呢？在Avi的介面內相關的設定就是在Virtual Service的配置介面內。
Virtual Service配置元件
標準的Virtual Service內至少會有四個工作頁面需要設定，分別介紹如下：
對應到這個Virtual Service最基礎的應用相關設定。如圖5所示，簡單把幾個最重要的參數大致說明如下：
圖5 Virtual Service的Settings設定頁面。
‧Virtual Service的名稱，Virtual Service是否要啟用。
‧這個Virtual Service是不是一個SNI（Server Name Indication）內的Parent/Child VS。Avi支援在同一個VIP上可以支援多個不同的FQDN站台，採用不同的憑證。若要運作，就會利用Parent/Child VS機制來達成。
‧這個Virtual Service所對應的Virtual IP地址。可以手動指定，而如果在Avi內有配置IPAM（IP Address Management）的相關機制，也可以直接由Avi自行配發（搭配DNS的自動註冊）。
‧所謂的Application Domain Name是如果Avi內有預先配置DNS的整合或是Avi自行管理DNS，管理者就可以在介面內指定這個Virtual Service的FQDN，且在對應DNS內會自動發布這個FQDN與VIP之間的名稱與地址對應關係。
‧Application Profile：這個Virtual Service是要對應哪一類的應用模組？HTTPS、HTTP、DNS等等這種L7應用，或是TCP/UDP的標準L4應用呢？不同的Application Profile代表Avi會利用對應的方式去對應用進行識別與遞送處理。可以選定標準預設定義的Profile形式，當然也可以自行進行定義。Avi預設的Application Profile，可以到「https://avinetworks.com/docs/20.1/application-profile/」內進行參考。
‧TCP/UDP Profile：對應到上面的Application Profile，是否要特殊針對TCP/UDP等參數進行修正，例如Session Idle Timeout時間要多長，是否支援Direct Server Return等等不同的機制。
‧WAF Policy：如果是HTTP/HTTPS這類應用，要不要把Web Application Firewall功能開起來？
‧Error Page Profile表示如果Virtual Service出問題了（例如沒有服務引擎可以提供服務、後端Pool內Server都倒了等等），那是不是要導向一個客製的頁面來對用戶進行回應？
‧Service Port內可配置對應到這個應用的網路服務Port（圖6）。通常在選Application Profile時，這裡就會把預設值帶進來，例如HTTPS採用TCP 443。但如果想要換Port，例如HTTPS要跑在9443上，這邊就可設定。選項內在必要時也可設定多個Port，或是針對單一Port把TCP/UDP Protocol都打開，例如DNS或Syslog這類服務。
圖6 Virtual Service的Settings設定頁面。
‧Pool這裡就是選定這個Virtual Service與在前篇裡面設定的Pool的對應。可以選擇單一的一個Pool，也可以選擇一個Pool Group。一個Pool Group裡面可以含多個Pools，然後用Priority選擇優先往哪個Pool送，或是權重的方式分配用戶的連線要按比例轉到哪個Pool裡面。
‧如果是採用HTTPS或是選擇SSL Application，此時當然就會有對應到如SSL Profile（要採用哪種加解密方式、要不要啟用PFS、TLS要用第幾版等等），以及憑證的選擇這些配置。
在Policies內主要做兩件事，包括這個Virtual Service本身的安全防護，以及對應到HTTP應用需要進行的轉送或是回應控制如圖7所示：
圖7 Virtual Service的Policies設定頁面。
‧在Network Security內對應到不同的來源IP或是國別（整合Geo-IP資料庫），限制用戶可否連接，或是進行需求的連線數限制等。這邊也可整合IP Reputation資料庫，對於紀錄有問題的來源地址進行阻擋。
‧HTTP Security則是可以除了網路資訊（IP/Protocol/Port）之外，針對HTTP表頭內的Path、Cookie、HTTP Method、Version等等進行控制，像是要阻擋、轉址、產出特殊回應等等。
‧HTTP Request/Response則是在HTTP應用內對於請求與回應進行的客製化處理，例如轉址、改寫表頭、往哪個CDN廠商送這類的機制。
‧可以把DataScript看成就是Avi的iRule，當然語法等完全不一樣。如果有些作業在UI介面上就是找不到，該怎麼做？最後的方式就是利用DataScript以程序化的方式來進行需求作業。
Analytics頁面內設定的是關於這個Virtual Service日誌與效能收集的相關配置（圖8）。例如，日誌是要全部都記錄下來，還是只要記錄有問題的部分。如何定義一個日誌有問題，是否要修改？日誌要不要送到外面的Syslog Server去？Virtual Service本身的metrics（連線數、回應時間）是不是要即時收集發送？還是過一段時間後就每5分鐘定期收集就好？像是這些配置等等。
圖8 Virtual Service的Analytics設定頁面。
Advanced進階配置內可以做一些效能上與QoS的限制，例如這個Virtual Service的總連線數限制、流量限制等等。但真正重要的是下面這邊的頁面（圖9），幾個常需要進行的配置包括：
圖9 Virtual Service的Advanced設定頁面。
‧這個Virtual Service前端的VIP要接到哪個Network。Avi可以自動判斷VIP所在的網段，放到正確的底層網路上，但如果需要明確或是指定的配置，就可在此進行選擇。
‧要用哪個IP來進行SNAT的轉址？要不要把Virtual IP等以BGP送往前端路由器（達成BGP Route Health Injection的A/A架構）？是不是啟用Auto Gateway，自動將回應送往來源端的MAC地址，避免複雜的路由設定？
‧（最常用）這個Virtual Service要配置到哪個Service Engine Group內。如果沒有設定，Virtual Service就會放到Default Group。但如同在前幾篇所介紹的，不同的Service Engine Group可以定義不同的應用服務等級，例如High-Availability要用哪種機制、Service Engine要用大的還小的等等的這些配置。如果管理者要指定服務放到哪個Group內，就是在此選擇。
前面已把Pool、Virtual Service的配置大致介紹過一遍，各個配置細節當然請大家可以再到Avi網站內做進一步的查詢。當管理者配好Pool，在Virtual Service內定義了應用遞送的方法並把Pool指定出來，並且指定了Service Engine Group，此時Avi Controller就會把這個Virtual Service放到具有資源的底層服務引擎上，順利的話，應用就可以正常運作了。
結語
本系列相關投稿共有四篇，從不同NSX Advanced Load Balancer實體構件到邏輯構件的解釋，以及安裝到配置的流程，與大家進行了簡要的介紹。看起來很多，但無論是進行PoC或真正生產環境的安裝，如果底層環境預先都已經檢視且準備好，用戶的應用行為也事先確認討論。一般來說，經銷夥伴在客戶那邊大概最多半天就能把整個方案安裝完成，並且讓客戶選定的業務開始運作需求的負載平衡功能。希望相關文章能讓大家對VMware先進的應用遞送方案NSX Advanced Load Balancer有進一步的認識。
＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，持有VCIX-NV、VCAP-DTD、CCIE、CISSP等證照，目前致力於網路虛擬化、軟體定義網路暨分散式安全防護技術方案的介紹與推廣。＞