作者: Colin Jao 饒康立 – VMware資深技術顧問,主要負責VMware NSX產品線,目前致力於網路虛擬化、分散式安全防護技術與新應用遞送方案的介紹與推廣。
Avi的自動化編排整合是本篇網誌要討論的重點。Avi方案由架構設計一開始,就將近年 IT 界最重要的幾個潮流作為核心觀念進行設計:基於軟體定義設計的方案、可以易於快速部署與擴充、可以運作於公有雲環境。那當然,這樣的設計能夠非常容易取得的好處就是與常用自動化編排方案的整合,後面會與大家介紹。
首先請大家參考下圖。當我們在討論Avi整體方案的『自動化』時,會分成兩個方向說明:北向與管理端的自動化編排工具整合,以及南向與不同公、私雲平台的部署整合:
在前面幾篇網誌內我們已經陸續與大家展示了『南向』的自動化整合能力。Avi的負載平衡等功能是實現在轉發層的『服務引擎』上,而服務引擎可以是在公有雲或私有雲上的虛機或容器,當然也可以是實體機。此時,這些服務引擎的虛機或容器,需要由我們手動部署嗎?可以這樣做,但更常見的做法是,Avi能夠自動地在需要有服務引擎的資源時,透過API與各公有雲 (AWS / Azure / GCP)或是私有雲環境 (vCenter / Kubernetes or Openshift / Openstack)來要求自動產出需要的服務引擎。前面幾篇我們和大家展示過下面的例子:
- 在私有雲環境內管理者要求將Virtual Service Scale-Out,需要新的服務引擎並滿足Active-Active的方式進行運作,Avi Controller透過vCenter自動進行Service Engine虛機的部署
- 管理者需要在AWS上面部署Avi的負載平衡服務,Avi Controller透過正確的Access Key接取到對應AWS帳戶與Region後,可自動進行EC2內Service Engine Instance的部署
好的,那『北向』呢?北向這邊指的是管理者要如何下指令給Avi Controller,已產出我們需要的服務。當然最基本的方式就是透過Browser的連接,以GUI圖形介面的方式直接配置。但在現在的世界,帥的方法當然是要採用Infrastructure as Code,自動化編排的方式來做啊!Avi在這邊的支援有幾個特性:
- Avi的各項相關功能都有API支援,而且符合標準的OpenAPI / Swagger規格。因此管理者可以非常方便地使用不同有支援OpenAPI的工具來使用 / 閱讀Avi的API及對應文件
- Avi的相關功能都有對應的Terraform / Ansible模組。因此無論企業希望採用哪一種作為自動化編排工具,都可以很方便的來配置Avi的服務
- Avi有Python / GO 的SDK。相同的,相關功能要在程式內呼叫也很容易。
這邊我把幾個主要的相關文件鏈結提供在這邊:
- Avi API Guide:
https://avinetworks.com/docs/18.2/api-guide/
- Avi Ansible Modules:
https://docs.ansible.com/ansible/latest/modules/list_of_network_modules.html?extIdCarryOver=true&sc_cid=701f2000001OH7YAAW#avi
- Avi Terraform Provider:
https://www.terraform.io/docs/providers/avi/index.html
- Avi SDK:
https://github.com/avinetworks/sdk
但本篇最後我想討論一個重點。當在說明API時,每家廠商都會說他們有API。但Avi方案的重點其實不是在有沒有API或是支援相關的自動化編排方案上,而是Avi的配置方式就如同Kubernetes或是NSX的Policy API,是『宣告式』 (Declarative) 的。與大部分傳統方案採用的是『命令式』 (Imperative) ,要一步一步指示怎麼建置出服務不同,Avi的方案僅需要『宣告』需要的最終狀態,也就是說告知這個服務需要的各個變數,就能夠直接進行部署。
來討論一個例子:下面是我常和客戶進行展示的一組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例子內,
- 步驟0內,我們定義了要如何連接到Avi Controller,包含連接的IP、帳戶、密碼等等
- 步驟1裡建立了Server Pool,包含這個Pool的名稱、負載平衡演算法、各個後端Server的IP
- 步驟2裡說明了前端的Virtual IP是多少
- 步驟3內配置了Virtual Service,結合了前面定義的Server Pool與Virtual IP,並定義monitor的port
當然,上面的例子太過簡單,還有很多的變數可以設。但請問大家,要建立一個最基礎的負載平衡服務,上述的四個步驟都是該設的吧。各位在友商的方案內,可以用更少的步驟把服務配置出來嗎?
應該很難喔。其實這邊就是個傳統廠商與新的軟體定義方案間的大差異。包含Avi與NSX-T,都是採用『宣告式』的方式來進行配置。此時,因為架構上把控制層集中,而且宣告式API大幅度縮減了管理者的配置流程(只需把需求的狀態 / 變數輸入),自動化編排就會變得極度簡單與可執行。但傳統網路或負載平衡的方案,一方面得要一台一台的下指令(控制層沒有集中),而且指令得要一個一個步驟去下(想像一下要設定完一台傳統交換器的所有指令)。此時要做自動化編排就非常困難了。
下一篇我們簡單討論Avi方案內的租戶與管理者角色概念,並為這個系列做個簡單的總結。
Comments
0 Comments have been added so far