之前已經詳細介紹了NSX Advanced Load Balancer的功能與使用效益，若想要採用，勢必得面臨安裝過程，本文將說明其安裝準備與流程。建置前需要準備好什麼環境？大致上安裝的流程是如何？需要考量到的細節，這裡都會做說明。
在多篇去年的系列文章中，已經介紹過NSX Advanced Load Balancer（後續簡稱為NSX ALB或是Avi）的功能與效益，以及對應Web Application Firewall內的功能。
筆者身為VMware的技術顧問，時常收到客戶的詢問想進行功能驗測，不少企業甚至在使用順暢的狀況下就直接買授權，把生產應用拉進來使用。但此時，肯定就需要先討論，無論是直接安裝在生產環境或只是PoC，建置前大家要準備好什麼環境？大致上安裝的流程是如何？
因此，接下來的數篇文章想和大家討論NSX ALB的安裝準備與流程，並藉此機會也說明每個需要配置的構件有何功用，安裝與配置時可能得考量的細節等等。本系列內，會陸續與大家說明下列的主題：
‧什麼是Avi裡面的Cloud？NSX Advanced Load Balancer的南向整合機制是如何？
‧Controller的需求與安裝準備
‧服務引擎（Service Engine）的需求以及服務引擎群組（Service Engine Group）
‧不同Avi Cloud內配置前底層網路需求準備
‧安裝流程簡述
‧重要邏輯構件包含Pool/Virtual Service的配置討論
首先，請參考如圖1所示的Avi架構。
圖1 Avi的架構說明。
與傳統應用遞送方案不同，NSX Advanced Load Balancer是純軟體、集中配置、可透過API編程的Software-Defined架構。在Avi內，管理者需要先建立控制層這邊的Controllers。接著，再把各個可受Avi配置的底層環境（Cloud）接上Controllers，就能夠自動地配置實際上提供應用遞送功能的轉發層構件：服務引擎虛機（Service Engine）。
但也因為如此，當企業想嘗試使用Avi時也會感到疑惑：與傳統應用遞送方案的安裝方式很不一樣。並不是採買兩台硬體設備，然後安裝、上架接線、配網路。為什麼要安裝Controller？如果構件放在虛擬環境內，有什麼特殊需要考慮，哪些資源需要準備？網路的配置與實體的配置方法有什麼不同呢？
建置前須考慮的前置作業
通常在建置前，管理者需要考慮的前置作業可能包括但不限於下面這些：
要安裝在哪個環境？
‧要把整體環境配置在哪個Cloud內？是自己擁有的vSphere平台，還是選定的公有雲？
‧環境內有沒有SDN方案？（所以除了虛擬化環境外，Avi還可以直接配合SDN進行配置）
‧如果是自建環境如VMware，是否有任何的版本限制？
需要準備好多少資源？
‧控制器需要幾台？會耗用到多少底層的資源（如CPU、Memory、Storage）？
‧服務引擎需要用實體機還是虛機呢？需要幾台呢？每台需要的CPU、Memory、Storage又是多少？
‧底層網路需要什麼準備？要預先建立哪些網段？配置好多少IP位址？
大致上的安裝流程為何？
其實單純談到安裝的流程是很快的，大致上會是下列的步驟，如圖2所示。一般來說，在前期環境有準備好的狀況下，其實從安裝到可以開始實際配置Application需求的Pool、Virtual Service大概約一兩個小時到頂多半天即可。
圖2 安裝流程示意圖。
首先進入第一個主題：什麼是NSX Advanced Load Balancer裡面提到的「Cloud」？在進行Avi的實際部署前，必須知道要把相關的構件建立在哪一個「環境」裡面，這個對於不同種類「環境」的定義，在Avi內就叫做Cloud。
Avi的Cloud代表一個可以由Avi控制器透過API進行服務引擎安裝與配置的資源池環境。在這個Cloud裡面通常包含了用戶的實際業務機器虛機，有CPU、Memory、Storage資源可以進行服務引擎的配置，可以抓取有哪些業務網路來放置如Virtual IP的位置並連接到後端Backend Server，以及Controller、Service Engine的管理網段等。
簡而言之，Cloud是Avi已經支援，可以呼叫的不同私有雲或公有雲環境。目前在本文寫作時的Avi 20.1版內已支援八種Cloud，包括VMware、Openstack、Linux Server、三大公有雲、No Orchestrator，以及最新的NSX-T Cloud，如圖3所示。
圖3 目前Avi可呼叫的不同私有雲或公有雲環境。
Avi已支援的Cloud
接下來，簡單地對不同種類的「Cloud」進行說明：
VMware vCenter/vSphere ESX Cloud
VMware vCenter/vSphere ESX Cloud是大家最熟悉的VMware虛擬化環境。Avi Controller可透過標準API接取到vCenter，抓取企業虛擬化環境內的Inventory（有哪些虛機、哪些網路等等），也可以直接把服務引擎部署在指定的vSphere資源池內。圖4所示是配置vCenter/vSphere Cloud時的介面，可看到需要輸入vCenter管理者的相關資訊。
圖4 配置vCenter/vSphere Cloud時的介面。
Avi可以安裝在vCenter/vSphere 5.5之後的版本，但當然，本文寫作時，包含6.0以前的vCenter/vSphere都已經End-of-Support了，請不要再使用。在虛擬化環境內，Avi支援採用vSS（vSphere Standard Switch）或是vDS（vSphere Distributed Switch）均可。但台灣有許多企業除了採用vCenter/vSphere外，也會於底層改用NSX Data Center來進行網路與安全的配置。如果是一個有NSX-T環境的資料中心，可採用下面第二種選擇：NSX-T Cloud。
NSX-T Cloud
NSX-T Cloud代表客戶有採用NSX-T與vCenter/vSphere打造的虛擬化，且包含整個NSX Overlay網路架構（Logical Segment/T0 & T1 Gateway）的全自動化軟體定義資料中心。Avi不僅可接取vCenter，也可直接與NSX-T Manager進行溝通與配置，無論是用戶的應用，以及Avi要部署的Service Engine本身，都可以直接位於NSX-T Overlay網路之內。
在此環境中，NSX-T必須是2.5、3.0或之後的版本，而vCenter/vSphere僅支援6.7之後的對應版本。
圖5是NSX-T Cloud的基本配置畫面，在後面的系列文章中還會再做說明。
圖5 NSX-T Cloud基本配置。
Openstack Cloud
何謂Openstack Cloud，就是可於Openstack內運作的Avi環境。
公有雲
目前NSX Advanced Load Balancer支援AWS、Azure、GCP三大公有雲。當企業應用是放在公有雲上，可以直接由控制器在公有雲上配置需求的服務引擎以及相關的應用遞送功能。圖6內是AWS Cloud的配置示例，可以看到這裡能夠選擇要接取到哪個AWS Region，以及連接的Access/Secret Access Key等。
圖6 AWS Cloud相關配置。
Linux Server Cloud
Linux Server Cloud的使用情境是指管理者預先裝好數台實體機（Bare-Metal Server）並在上面安裝完成Linux。配置Linux Server Cloud，管理者可選擇要登入這些Server的SSH用戶、密碼或公鑰。Avi Controller會直接以這個帳戶登入各台Linux Server，並在上面安裝需求的Service Engine軟體，以及需求的底層網路配置。一般來說，在用戶想採用實體伺服器作為服務引擎（以取得較好效能）的時候，會採用Linux Server Cloud。
若是採用實體伺服器來提供服務引擎配置，Linux的版本以及伺服器硬體規格會有限制，可參考「https://avinetworks.com/docs/20.1/system-requirements-ecosystem/」頁面來找尋合適的設備。
No Orchestrator Cloud
No Orchestrator Cloud的意思是要採用虛機來作為服務引擎的部署，但因為種種原因，沒有要連接這些私有虛擬化環境的中心端管控介面（如vCenter/vSphere Cloud、Openstack Cloud）。所以在這裡，僅需要Avi提供這些虛擬化環境內服務引擎的OVA/qcow2檔案，然後管理者自行進行服務引擎的手動安裝（到vSphere/KVM環境內匯入這些虛機）以及對應的網路配置，然後把這些虛機手動註冊到Avi Controller內。
在這裡要特別花上面的篇幅解釋各種Cloud的原因很簡單：Avi要部署在哪種環境內，一開始就需要決定，準備的環境不同，後續的安裝步驟也會不一樣。在後面的投稿文章中，主要僅會專注在vCenter/vSphere Cloud以及NSX-T Cloud這兩種環境的部署流程。
確定要在哪種環境內部署後，接下來討論NSX Advanced Load Balancer內的管理構件Controller。不厭其煩地，這裡把Avi的方案架構再貼出來一次，如圖7所示。
圖7 Avi架構示意圖。
作為軟體定義應用遞送方案的核心，Avi Controller僅作為架構內的控制層（Control-Plane）而非轉發層（Data-Plane）。Controller不進行實際的用戶連線負載平衡、代理、加解密等作業，上述的功能會由服務引擎（Service Engine）來執行。而Avi Controller的主要功能為：
‧管理者可以透過網頁、API、SDK、Orchestration-Configuration Tool、CLI來連接Controller，提供集中化的組態與自動化管理，並將企業業務需求建立的Pool、Virtual Server等配置需求發送至服務引擎。
‧Controller可透過各個平台的接取機制，南向連往不同的Cloud，抓取Cloud內的環境資訊，如網路、虛機的狀態。
‧Controller提供服務引擎本身的維運管理，包含自動配置服務引擎，擴充、服務轉置、刪除、確認服務引擎的健康狀態、HA切換控制等作業。
‧Controller收集來自服務引擎對於應用遞送服務的相關日誌與效能資訊，統計分析公管理者進行後續查找。
在PoC環境，Controller單台即可運作。但當然，任何與生產環境相關的配置，會請各位務必要考慮Avi Controller的Cluster部署架構。與NSX-T Manager相同，Avi Controller同樣是採3台的Quorum機制，以2+1方式備援，如圖8所示。
圖8 Avi Controller採3台的Quorum機制，以2+1方式備援。
在Cluster架構內，相關部署情況如下：
‧當三台Controller都正常運作的時候，管理者可連往任一台Controller進行配置，或是連往這三台Controller配置出的Cluster IP。
‧任何一台Controller如果失效，剩下兩台透過相互通訊與投票會確認本身為Cluster內持續運作的Controller。此時，無論是管理者的配置以及底層的服務都不會受到影響。
‧若有兩台Controllers失效，剩餘一台Controller因為小於Quorum環境的一半，會直接進入Headless Mode。在此種模式下，管理者無法進行配置，但底層服務引擎持續提供運作。如果管理者在短期內沒有辦法讓其他兩台Controller恢復運作，可以採用指令手動解除Quorum機制，讓剩下的單台Controller進行管理作業。
‧三台Controllers均失效的狀況下，如同壞掉兩台，管理者無法進行配置，但底層服務引擎持續提供運作。
‧在兩台以上Controller失效時，服務引擎無法把相關的日誌送往Controller進行處理，會在本身先進行Cache。如果中斷的時間過長，就會出現日誌資料遺失的狀況。
因此，無論採用哪種Cloud，生產環境內的Controller的備援部署請進行下列考量：
‧要三台，不多不少。
‧三台的配置位置要避免同時有兩台以上失效。比如說，如果是採用虛機，利用Anti-Affinity機制把Controller VM放到不同的vSphere上，而且透過HA等機制進行保護。
‧進行Backup/Restore防護機制，確保最差狀況在出現兩台以上Controller失效，且無法回復時，可以重新部署並且把組態重新配置回來。
‧應該採用Cluster IP，避免單台Controller失效時，外部自動化系統不知道其他兩台Controller在哪邊，造成組態配置等作業中斷。如果要採用此種機制，三個Controller必須要放在同一個網段內，並且另外指定一個同網段IP作為Cluster IP使用。
那接下來，Controller實際上要怎麼放呢？文章前面強調了Avi可以支援多種不同的私有雲公有雲環境。Controller的建置當然也是如此，可以用虛機的方式建立（強烈建議就採用這種，不必考慮別的），可以安裝在實體機上以容器執行，可配置在公有雲內，例如由公有雲Market Place直接拉出來建置。但無論如何，下列幾點在部署前請列入考慮：
‧Avi Controller部署的地方與實際服務引擎∕業務應用所存在的地方，不需要一樣，型態也無須相同。可以服務引擎採用Bare-Metal實體機，但是Controller採用虛機。或是服務引擎在AWS上，但是Controller在企業地端私有雲內。
‧但不管怎麼樣，三台Controller必須要部署在同一個資料中心內。或精確地說，Controller之間內部通訊的延遲時間不可以超過5毫秒（ms）。各位要考慮Site備援把Controller放到建築物不同的樓層，或是Campus內不同的機房，沒問題！但是Controller之間延時要低，就可以。
‧如前段落所述，建議在Controller上啟用Cluster IP機制，但此機制限制Controller的部署應該要在同一個大二層網段內。
‧Controller與服務引擎（Service Engine）可以在不同地點，但當然，管理網路要互相連得到。此外，Controller與服務引擎間的Network Latency不應該高於40毫秒。譬如企業有兩個機房在台北與台中，台中的Service Engine可以讓台北的Controller來管理，但這兩個機房間需要有VPN或是直連網路讓Controller與服務引擎可連通，而且延時要在40毫秒之內。不難吧！但如果Service Engine在新加坡，Controller在台北，延時過大，就不適宜了。
再來，Controller在建置時，是否有大小的選擇以支援不同的環境？有的，首先是CPU與記憶體的建議配置，通常以下列三種來比較，可支援不同由小到大的Virtual Service以及底層的Service Engine數量，如表1所示。
而在底層Storage部分，若可以採用SSD這類的高IOPS儲存當然是最好。而Controller上應該要保持足夠的Storage空間，提供包含Virtual Service的Log/Metrics收集使用。基本上，建議的配置值大概如表2所示。
當以虛機的方式匯入Controller OVA檔到vSphere上時，預設的大小是8 CPU、24GB Memory、128GB Storage。但如果需要調整，在虛機匯入後，只需要將Controller關機，調整需求的CPU、Memory、Storage大小，然後重新開機，Avi Controller就會自動地利用更大的資源。而當然，在一個Controller Cluster內，三台的系統資源配置應該是要做成一樣的。
前面討論了Avi Controller的功能與架構，寫這麼多，是否有簡單的整理呢？下列是筆者個人的建議：
1. Avi Controller就是裝三台。
2. 放同一個網段裡，啟用Cluster IP。
3.用vSphere虛機形式即可。初期採用預設值大小，大規模使用時，再調整Controller Sizing。
4. 除非特殊必要，把Controller以及所管理的Cloud、配置的Service Engine都放在同一個資料中心內。
5. 定時進行組態備份。
本篇文長，先止於此。下一篇文章就NSX Advanced Load Balancer的另一個核心構件：Avi的Service Engine進行討論。
＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，持有VCIX-NV、VCAP-DTD、CCIE、CISSP等證照，目前致力於網路虛擬化、軟體定義網路暨分散式安全防護技術方案的介紹與推廣。＞