本系列六篇文章介紹了VMware全新NSX Advanced Load Balancer方案的不同面向與效益，本文為最後一篇，將說明NSX ALB整體方案「自動化」時，「北向」與「南向」自動化整合有何不同，並講解NSX的Policy API所採用的「宣告式」，以及何謂多租戶方案架構。
全新VMware NSX Advanced Load Balancer的自動化編排整合以及多租戶支援，是本篇文章所要討論的兩個重點。NSX Advanced Load Balancer方案由架構設計一開始，就將近年IT界最重要的幾個潮流作為核心觀念進行設計：基於軟體定義設計的方案、可以易於快速部署與擴充、可以運作於公有雲環境。那當然！這樣的設計能夠非常容易取得的好處就是與常用自動化編排方案的整合，接下來就與大家介紹。
首先請參考圖1 的內容，當討論NSX ALB整體方案的「自動化」時，會分成兩個方向說明：北向與管理端的自動化編排工具整合，以及南向與不同公、私雲平台的部署整合：
圖1 NSX ALB整體方案「自動化」示意圖。
「南向」的自動化整合
前面幾篇文章已經陸續向大家展示了「南向」的自動化整合能力。NSX ALB的負載平衡等功能是實現在轉發層的「服務引擎」上，而服務引擎可以是在公有雲或私有雲上的虛機或容器，當然也可以是實體機。此時，這些服務引擎的虛機或容器，需要手動部署嗎？可以這樣做，但更常見的做法是，NSX ALB能夠在需要有服務引擎時提供應用遞送服務，透過API與各公有雲（如AWS、Azure、GCP）或是私有雲環境（如vCenter、Kubernetes或Openshift、Openstack）「自動」要求產出需要的服務引擎。前面幾篇文章內跟大家展示過下面幾個例子：
‧在私有雲環境內，管理者要求將Virtual Service Scale-Out，需要新的服務引擎並滿足Active-Active的方式進行運作，NSX ALB Controller透過vCenter自動進行Service Engine虛機的部署。
‧管理者需要在AWS上面部署NSX ALB的負載平衡服務，Controller透過正確的Access Key接取到對應AWS帳戶與Region後，可自動進行EC2內Service Engine Instance的部署。
「北向」的自動化整合
那「北向」呢？北向這邊指的是管理者要如何下指令給NSX ALB Controller，以產出所需要的服務。最基本的方式就是透過瀏覽器連接，以圖形化使用者介面的方式直接配置。但在現在的世界，最流行的方法當然是採用Infrastructure as Code，自動化編排的方式來做！NSX Advanced Load Balancer在這裡的支援有幾個特性：
‧NSX Advanced Load Balancer的各項相關功能都有Restful API支援，而且符合標準的OpenAPI/Swagger規格。因此管理者能夠非常方便地使用不同可支援OpenAPI的工具來使用和閱讀NSX ALB的API及對應文件。
‧NSX ALB的相關功能都有對應的Terraform/Ansible模組。因此無論企業希望採用哪一種作為自動化編排工具，都可以很方便地配置NSX ALB的服務。
‧NSX ALB有Python/GO的SDK。相同地，相關功能要在程式內呼叫也很容易。
以下提供了幾個主要的相關文件鏈結：
‧NSX ALB API Guide：https://avinetworks.com/docs/18.2/api-guide/
‧NSX ALB Ansible Modules：https://docs.ansible.com/ansible/latest/modules/list_of_network_modules.html?extIdCarryOver=true&sc_cid=701f2000001OH7YAAW#avi
‧NSX ALB Terraform Provider：https://www.terraform.io/docs/providers/avi/index.html
‧NSX ALB SDK：https://github.com/avinetworks/sdk
宣告式 vs.命令式
但這裡特別想討論一個重點是，當用戶需要自動化接取時，每家廠商都會說他們有API。但NSX ALB方案的重點其實不僅在於有沒有API或是支援相關的自動化編排方案，而是NSX ALB的配置方式就如同Kubernetes或NSX的Policy API，是「宣告式」（Declarative）的。與大部分傳統方案採用的是「命令式」（Imperative），要一步一步指示怎麼建置出服務不同，NSX ALB方案僅須「宣告」需要的最終狀態，也就是說告知這個服務需要的各個變數，就能夠直接進行部署。
再來討論一個例子，下面是筆者經常向客戶進行展示的一組Ansible Playbook，寫得很醜，但做說明足夠了：
# # Step 0: 定義連接到 Avi Controller的方法 # - hosts: localhost vars: avi_credentials: controller: "172.16.6.214" username: "admin" password: "XXXXXXXXXX" api_version: "18.2.5" connection: local roles: - role: avinetworks.avisdk tasks: # # Step 1: 建立展示的 AVI-Pool # - name: Create AVI-Pool avi_pool: avi_credentials: "{{avi_credentials}}" state: present name: ansible-demo-pool lb_algorithm: "LB_ALGORITHM_ROUND_ROBIN" servers: - ip: addr: "172.16.16.211" type: "V4" - ip: addr: "172.16.16.212" type: "V4" - ip: addr: "172.16.16.213" type: "V4" - ip: addr: "172.16.22.214" type: "V4" # # Step 2: 建立對應的 Virtual IP # - name: Create Virtual IP avi_vsvip: avi_credentials: "{{avi_credentials}}" state: present name: ansible-demo-vip vip: - enabled: true ip_address: addr: "172.16.21.248" type: "V4" # # Step 3: 建立展示的 Virtual Service # - name: Create the Demo Virtual Service avi_virtualservice: avi_credentials: "{{avi_credentials}}" state: present name: ansible-demo-vs services: - port: "80" pool_ref: '/api/pool?name=ansible- demo-pool' vsvip_ref: '/api/vsvip/?name=ansible- demo-vip'
在上面的Ansible例子內，可分成以下幾個部分來加以說明。首先，Step 0定義要如何連接到Controller，包含所連接的IP、帳戶、密碼等等。接著，Step 1建立Server Pool，包含這個Pool的名稱、負載平衡演算法、各個後端Server的IP。而Step 2說明了前端的Virtual IP是多少。Step 3則配置了Virtual Service，結合了前面定義的Server Pool與Virtual IP，並定義monitor的Port。
當然，上面的例子太過簡單，還有很多的變數可以設定。但請問大家，要建立一個最基礎的負載平衡服務，上述的四個步驟都是需要設定的，也沒法更少了吧！各位在其他廠商的解決方案內，可以用更少的步驟把服務配置出來嗎？應該很難！其實這就是個傳統廠商與新的軟體定義方案間的大差異。包含NSX Advanced Load Balancer與NSX-T Data Center，都是採用「宣告式」的方式進行配置。管理者不用找二三十個API，從配置VLAN∕路由開始一步步往上設。此時，因為架構上把控制層統合（集中管理），而且宣告式API大幅度縮減了管理者的配置流程（只須把需求的狀態∕變數輸入），自動化編排就會變得極度簡單與可執行。但傳統網路或負載平衡的方案，一方面需要一台一台地下指令（控制層沒有集中），而且指令得要一個一個步驟去下（想像一下！要設定完一台傳統交換器∕傳統負載平衡器的所有指令）。此時，要做自動化編排就有難度了。
NSX ALB多租戶方案架構說明
以上是對於NSX Advanced Load Balancer自動化編排的快速介紹，而接下來想討論第二個課題：作為一個適合分散至不同公私有雲、不同機房內使用、但可以集中管理的軟體定義方案，支援多租戶可說是很重要的需求。在不同環境（生產、開發、災備，甚至不同子公司）內的負載平衡器可以透過同一組控制器（NSX ALB Controllers）進行集中配置，但是不同組織或身分的管理者可以自行透過圖形介面∕API接取的方式配置各自需求的負載平衡服務。
針對NSX Advanced Load Balancer的多租戶方案架構，簡述如下：
‧在同一組NSX ALB Controllers管控的範圍內，除了預設租戶（Default Tenant）外，管理者還可以配置多組不同的租戶。
‧每個用戶可以隸屬於一到多個租戶環境，並在不同的環境內具有不同的身分（Role）。用戶登入NSX ALB的介面後，可以切換到不同的租戶環境內進行操作。
‧不同的租戶間管理介面、虛擬服務（Virtual Service）、Pool等都是獨立的。但不同的租戶服務要運作於底層的服務引擎上時，管理者可以依據實際的需求，選擇讓各租戶各自去配置、擁有自己獨立的服務引擎，或是讓多個租戶共享底層的服務引擎資源。
接下來，就舉幾個圖例與大家進一步地討論。
首先，圖2內是系統管理者可以配置的Tenant設定。在圖2內，管理者可以選擇在NSX ALB環境內進行以下的部署：
圖2 配置Tenant設定。
‧不同的租戶擁有自己的IP Domain（也就是說，各租戶有自己的VRF，各租戶使用的IP是可以重複的），或是各個租戶共享同一組IP路由環境。
‧在服務引擎上，各租戶可以有自己獨享的服務引擎與自行配置的服務引擎群組。而另一種配置則是服務引擎相關設定由管理者配置（Provider Context），而服務引擎由各個租戶共享。
接著，用如圖3所示的架構做個舉例：假設環境有五組租戶，各租戶有自己的管理者。
圖3 租戶配置示意圖。
在該選擇內，所有租戶共享一組IP Domain，但各租戶有各自配置的網段，而各個租戶的服務可以在底層由同樣的服務引擎來提供服務。至於管理介面內配置，則如圖4所示。
圖4 管理介面內配置。
首先，可以看到當以不同的用戶（圖5內的admin/colin）登入各租戶環境（admin/Colin-Tenant）時，介面內僅顯示此租戶內的Virtual Service與Pool配置。首先是以admin登入admin租戶，其次是以colin用戶進入Colin-Tenant租戶環境。可看到各用戶都僅能看到在此租戶內部的服務配置，無法看到別人的，如圖6所示。
圖5 僅顯示此租戶內的Virtual Service與Pool配置。
圖6 各用戶都僅能看到在此租戶內部的服務配置。
而在上面的範例內，底層的服務引擎是設定要讓不同租戶可以共享的（當然如同前面所討論，也可以有Service Engine完全獨立的配置）。直接到vCenter內看NSX ALB Controller對服務引擎的配置。
在圖7中，在單一服務引擎上，虛機網卡有接到不同的租戶網路，這代表此服務引擎可以同時給多個租戶的服務共享。而當租戶的數目較多，單一服務引擎的網卡不夠接取，此時NSX ALB Controller也會自動產出新的服務引擎來提供各租戶需求的服務。
圖7 在單一服務引擎上，虛機網卡接到不同的租戶網路，這代表此服務引擎可以同時給多個租戶的服務共享。
結語
本系列六篇投稿其實只是就VMware全新的NSX Advanced Load Balancer方案的不同面向與效益做粗淺的介紹，後續有機會，或許會再就更細部的課題逐一進一步做報告。這裡以圖8和大家做個系列文的簡單總結：
圖8 採用NSX ALB的效益。
NSX Advanced Load Balancer是一個非常令人興奮的新產品，在企業環境逐步往新應用、容器與虛機、公有雲等方向大步轉換的這個關鍵時刻，NSX Advanced Load Balancer與原本的NSX Data Center均是VMware能夠與客戶齊力並進、創造大幅效益的重要方案。
＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，持有VCIX-NV、VCAP-DTD、CCIE、CISSP等證照，目前致力於網路虛擬化、軟體定義網路暨分散式安全防護技術方案的介紹與推廣。＞