Octavia就是將用戶的API請求經過邏輯處理，轉換成Haproxy或者Nginx的配置參數，下發到amphora虛機中。
Octavia的內部實現中，邏輯流程的處理主要使用TaskFlow庫。
【基本概念】
·LBaas
Load Balancing as a Service，在openstack平臺上，LB被作爲一種服務提供給用戶，用戶可以按需獲取可配置的業務負載分擔方案。
·loadbalancer
負載均衡服務的跟對象，一般爲虛機，用戶基於此對負載均衡進行配置和操作。
·VIP
與LB關聯的IP地址，作爲外部訪問後端服務的入口。
·Listener
監聽器，用戶可通過其配置外部對VIP訪問的端口，算法，類型等等。
·Pool
負責後端的虛擬機池。在Haproxy爲driver的情況下，一個Pool對應着一個獨立的network namespace中運行的HaProxy進程中管理的backend。
一個VIP只會有一個Pool。
·Member
Member 對應的是 pool 裏面處理網絡請求的一個 OpenStack Nova 虛機。
·Health monitor
它用來檢測pool裏面的member的狀態，支持很多種檢測方法，在neutron裏面是可選的。
·L7 Policy
七層轉發策略，描述數據包轉發動作。
·L7 Rule
七層轉發規則，描述數據包轉發的匹配域。（匹配部分雲主機）
基本概念之間的交互流程如下圖：
我們依舊從部分開始介紹：
·Amphora
負載均衡的載體，一般爲雲主機。（當然也可以使用物理機，將多個負載均衡配置到同一/兩臺Amphora節點上，提高數據包轉發效率，但是有單點故障隱患）
·manage-network
管理網絡，通常管理數據走這條線路，東側連接Amphora，西側連接Octavia服務進程。
·tenant-network
租戶網絡，內部通信使用，SLB轉發報文通過租戶網絡到各個後端服務器上。
·vip-network
服務地址，主要用於對外提供服務。
PS：vip-net和tenant-net可以是同一個網絡，但是在生產環境中建議分開，以便於更好得劃分網絡安全隔離。
·VM
後端服務器，用戶的真實服務器。
·health-manager
octavia裏面進行健康檢查的進程，主要有以下兩個作用：
1. 監聽來自amphora虛擬機發來的運行狀態數據，以此更新lb，listener，pool，member的狀態，同時更新listener_statistics表（可作爲計費依據），最重要的是更新amphora_health表。
2. 根據amphora_health數據表中的數據，找到異常狀態的amphora虛擬機，對該虛擬機進行更換操作。（即刪除舊的虛擬機，創建新的虛擬機並下發配置）
·house-keeping
名副其實的 Housekeeping（家政）服務，保障 Octavia 的健康運行。
主要實現三個功能：
SpareAmphora: 清理虛擬機的池子, 確保空閒的amphorae池大小。
DatabaseCleanup: 定期清理數據庫中已刪除的amphorae記錄。
CertRotation: 定期更新amphorae中的證書。
·Octavia Worker
負責完成 API 請求，是 Octavia 主幹功能的執行者。
主要作用是和nova，neutron等組件通信，用於虛擬機調度以及把對於虛擬機操作的指令下發給octavia agent。
基本流程如下：
【主要流程】
·創建loadbalancer
現支持single和active standby（主備雙活）兩種模式的loadbalancer。
P版本只支持single。
創建loadbalancer的參數中可以指定 vip 綁定的 port，如果沒有指定，octavia 會自動（在 API 層）創建：
普通創建 lb 時，在 API 層會創建 lb 和 vip 的數據庫記錄，然後把請求交由 worker 處理。
創建loadbalancer，Octavia會創建兩個虛擬機（active standby）。
如果配置enable_anti_affinity，則會針對這個 lb 先在Nova創建ServerGroup（這個ServerGroup的ID會記錄在DB中），兩個虛擬機就會創建在不同的host上。
虛擬機的flavor、image、network、security group、keypair信息都是從配置文件中獲取。
有了虛擬機後，同時在入參的subnet下給兩個虛擬機分別掛載網卡，並將VIP作爲address pair配置到網卡。
然後，向虛擬機發送REST API， 參數中有VIP所在 subnet 的 CIDR，網關 IP，vrrp port 的 mac 地址，vrrp port 的 IP 地址等信息。
向amphora發送消息配置 keepalived 服務（ active standby模式）。
至此，一個 loadbalancer 就創建結束了。基本上，後面創建listener、pool、member、health monitor，都是圍繞這兩個虛擬機，對haproxy（nginx）和keepalived進程進行配置。
在 octavia 中，資源之間的映射關係如下：
lb： 就是兩個管理員/租戶的虛擬機
listener： 虛擬機裏面的一個 haproxy （nginx）進程，frontend 配置
pool： haproxy （nginx）配置中的一個 backend
member： backend 配置中的一個 member
上文中，frontend指的是前端，定義一系列監聽套字節，接收客戶端請求；backend指的是後端，定義一系列後端服務器，請求轉發。
創建完 lb，登錄 amphora 驗證創建 lb 後的網絡配置，可以看到默認只能看到管理 IP，只有在 namespace 中才能看到 vrrp 網卡信息。
amphora-agent 啓動腳本是 octavia repo 中 cmd 目錄下的 agent.py。
amphora-agent 還做一件事，定時向 health-monitor 發送haproxy的運行時信息，該信息是通過向haproxy進程發送socket查詢命令獲取到。
·創建 listener 流程
在Octavia中，一個listener就對應amphorae 中一個haproxy進程。
首先生成haproxy配置文件，向amp發送消息，生成對應該 listener 的 haproxy 服務腳本。
再次向 amphorae 發送消息啓動 haproxy 服務：
先確定listener的配置目錄（/var/lib/octavia/{listener-id}/）在不在
如果是active standby，更新keepalived對各個haproxy的check腳本，
/var/lib/octavia/vrrp/check_scripts/haproxy_check_script.sh
啓動haproxy服務，service haproxy-{listener_id} start
·創建pool
創建 pool 的實現基本跟創建 listener 一致，在 amphorae 中僅僅是在 haproxy 的配置文件增加backend配置。
·添加 member
在添加 member 之前，amphorae 虛擬機上已經有管理 port 和 vrrp port，其中 vrrp port 在命名空間中。