Octavia is an open source, operator-scale load balancing solution designed to work with OpenStack.
自 Pike 以来 OpenStack 推荐使用 Octavia 代替 neutron-lbaas extension 作为 Load Balancing as a Service 的首选方案，并在 Queens 中将 neutron-lbaas 标记为废弃 —— Neutron-lbaas is now deprecated。
Octavia 在整个 OpenStack 堆栈中处于 Networking 的模块，提供数据流量分发功能。
社区推崇 Octavia 的原因有很多，它解决了 neutron-lbaas 遗留的历史包袱，能够对外提供独立而稳定的 API。简单的说，社区认为 neutron-lbaas 使 Neutron 的项目管理变得拖沓，LBaaS 应该作为一个独立项目得到长足的发展，事实也是如此。
《Octavia 分析与实现》系列基于 OpenStack Rocky 版本，主要记录、分析了 Octavia 作为 OpenStack LBaaS 的抽象设计，开发性设计及架构代码实现，从中感受社区开发者们对 Octavia 的寄予。
本文作为系列的开篇，希望能够从宏观的角度鸟瞰 Octavia 的全貌，由面及点，更利于后续理解 Octavia 的底层实现细节。
基本对象概念LBaaS：对于 OpenStack 云平台而言，LB（负载均衡）被作为一种服务提供给用户，用户得以按需地获取可配置的业务负载均衡方案，这就是所谓 Load Balancing as a Service。
LoadBalancer：负载均衡服务的根对象，用户对负载均衡的定义、配置和操作都基于此。
VIP：与 LoadBalancer 关联的虚拟 IP 地址，每个 LoadBalancer 最起码有一个 VIP 作为外部对后端业务集群访问的标准入口。
Listener：下属于 LoadBalancer 的监听器，可配置监听外部对 VIP 的访问类型（e.g. 协议、端口）。
Pool：后端的真实业务云主机集群域，一般的，用户会根据云主机的业务类型进行划分。
Member：业务云主机，下属于 Pool，对应传统负载均衡体系中的 Real Server。
Health Monitor：挂靠于 Pool，周期性对 Pool 中的 Member(s) 进行健康检查。
L7 Policy：七层转发策略，描述了数据包转发的动作（e.g. 转发至 Pool，转发至 URL 或拒绝转发）。
L7 Rule：七层转发规则，下属于 L7 Policy，描述了数据包转发的匹配域（e.g. 转发至 Pool 中所有以 webserver 开头的 Members）。
图1. Web 动静页面分离部署架构
图 1 是一个简易的，应用负载均衡技术实现 Web 动静页面分离的部署模型，辅助理解上述基础术语以及每个对象在系统中的位置。
网络架构图2. Octavia 网络架构图
图 2 是一个标准的 Octavia Amphorae LoadBalancer Provider 网络架构，吃透这张图 Octavia 就算看明白一半了。
Amphora(e)：实体为云主机，作为负载均衡器软件 HAProxy 和高可用支持 Keepalived 的运行载体。同时也运行着 amphora-agent service 对外提供 REST API。是 Octavia 的 Default Loadbalancer Provider。
OpenStack Management/API Network：OpenStack 管理网，上面运行着 Octavia、Nova、Neutron、Barbican 等项目服务。
LB Management Network：打通 OpenStack Management/API Network 和 Amphorae，是 Octavia Services 与 amphora-agent service 通信的网络，所以也是 Amphorae 的初始挂靠点。Admin Project 可见。
VIP Network：作为 VIP Pool 的网络，东侧接入 Amphorae 由 Keepalived 实现的 VRRP Protocol 支持具有高可用特性的虚拟 IP 地址。
Tenant Network：业务云主机所处的网络，东侧接入 Amphorae 由 HAProxy 为业务云主机提供负载均衡数据流量分发服务。普通租户可见。
NOTE 1：其中 VIP Network 和 Tenant Network 可以是同一个网络，但在生产环境中，我会建议分开，更有利于针对施加不同级别的安全策略，划分网络安全隔离域。
NOTE 2：Amphorae LoadBalancer Provider 依旧是 Rocky 版本官方推荐的实现，其他的 neutron-lbaas drivers 一直碍于缺少人手，迟迟未能迁移。所以，后续的内容依旧围绕 Amphorae 展开。
基本使用流程图3. 初始网络拓扑图
通过 Dashboard 创建一个 Loadbalancer：
Step 1. 设定 loadbalancer 的 VIP。不指定则由 DHCP 分配。
Step 2. 设定 listener 监听的协议及端口。监听
http://:8080/的外部访问。
Step 3. 设定 pool 的负载均衡算法。这里选择 RR 轮询分发算法。
Step 4. 设定 pool 下属的 members。设定 members 需要指定端口和权重，前者组成了接受数据转发的 socket，后者表示分发的优先级。
Step 5. 设定 health monitor 的健康检查规则。如果 members 出现 PING 不同的情况，则会被标记为故障，不再接受分发。
创建了 lb-1 之后的网络拓扑变更如图 4。可以看出，Amphorae 在之中起到了关键作用，通过端口挂载的方式将属于 3 个不同网络中的 VIP、Members 以及 Octava Services 等对象 “串连” 起来，Amphorae（双耳壶）也因此而得名。
图4. 创建 LoadBalancer 之后的网络架构图
再补充一下与 Octavia 相关的 image 和 security group 的内容。Launch Amphora Instance 需要使用特定的镜像，Octavia 提供了专门的镜像制作工具。暂支持 CentOS 和 Ubuntu 两种操作系统，也支持设定 password，不过在生产环境中还是建议使用 keypair 进行登录。至于安全组，从图 5 可见 Amphora 的安全组最起码要满足 ingress:TCP/9443 和 egress:UDP/5555 两条规则。
图5. 简易的 Octavia 通讯模型
使用 Amphora Image：
Step 1. 上传 image
$ /opt/rocky/octavia/diskimage-create/diskimage-create.sh -i ubuntu
$ openstack image create amphora-x64-haproxy \
--public \
--container-format=bare \
--disk-format qcow2 \
--file /opt/rocky/octavia/diskimage-create/amphora-x64-haproxy.qcow2 \
--tag amphora
Step 2. 配置使用
[controller_worker]
amp_image_owner_id =
amp_image_tag = amphora
...
使用 Amphora Security Group：
Step 1. 创建安全组
$ openstack security group create amphora-sec-grp --project
$ openstack security group rule create --remote-ip "0.0.0.0/0" --dst-port 9443 --protocol tcp --ingress --ethertype IPv4 --project amphora-sec-grp
$ openstack security group rule create --remote-ip "0.0.0.0/0" --dst-port 5555 --protocol udp --egress --ethertype IPv4 --project amphora-sec-grp
Step 2. 配置使用
[controller_worker]
amp_secgroup_list =
...
图6. Octavia 软件架构图
Octavia 的软件架构设计依旧是典型的「生产者-消费者」异步通讯模型，API 与 Worker 分离再通过 MessageQueens/DB 中间件进行通信。
Neutron Octavia Driver：neutron-lbaas drivers 之一，支持 LBaaS v2 API。如果用户希望在版本较旧（>Pike）的 OpenStack 中集成新版本的 Octavia 可以通过 Octavia Driver 来集成。
Octavia API：Rocky 版本默认启用 Octavia v2 API，是 LBaaS v2 API 的超集，完全向后兼容。 还是应用了新项目常见的 Pecan+WSME Web 框架。
Queue：RPC 通信队列，应用了 cotyledon+oslo_messaging 框架，对接 Octavia API 和 Octavia Controller Worker。
Octavia Controller Worker：Octavia 的核心，底层采用 Driver+Plugin 的设计来满足 OpenStack 所代表的开放性。底层抽象了 Amphora、Certificate、Compute、Network 四个驱动工具，用于支撑上层的 3 大功能模块。
Octavia Worker：负责完成 API 请求，是 Octavia 主干功能的执行者。
Health Manager：负责保证 LoadBalancer Provider 的高可用
Housekeeping Manager：名副其实的 Housekeeping（家政），保障 Octavia Services 清洁的运行环境。
服务进程清单和代码结构就是软件架构设计的具象表现。
octavia-api service
octaiva-worker service
octavia-health-manager service
octavia-housekeeping service
[root@control01 octavia]# tree -L 1 -C
.
├── amphorae
├── api
├── certificates
├── cmd
├── common
├── compute
├── controller
├── db
├── distributor
├── hacking
├── i18n.py
├── __init__.py
├── network
├── opts.py
├── policies
├── tests
└── version.py
amphora：AmphoraAPIClient 和 amphora-agent 的实现
api：Octavia API 的实现
certificates：CA 认证功能的实现，支持 LB Management Network 的安全通信
compute：实现了 Compute Driver 的抽象和 novaclient 的封装
network：实现了 Network Driver 的抽象和 neutronclient 的封装
db：ORM 层的封装实现
policies：定义了 API 请求的鉴权策略
[root@control01 octavia]# tree controller/ -L 2 -C
controller/
├── healthmanager
│ ├── health_drivers
│ ├── health_manager.py
│ ├── __init__.py
│ └── update_serializer.py
├── housekeeping
│ ├── house_keeping.py
│ └── __init__.py
├── __init__.py
├── queue
│ ├── consumer.py
│ ├── endpoint.py
│ ├── event_queue.py
│ └── __init__.py
└── worker
├── amphora_rate_limit.py
├── controller_worker.py
├── flows
├── __init__.py
├── tasks
└── task_utils.py
healthmanager：Health Manager 的实现
housekeeping：HouseKeeping Manager 的实现
queue：内部 RPC 通信实现
api/handlers/queue/producer.py
controller/queue/consumer.py
worker：Octavia Worker 的实现，应用了 TaskFlow 框架
flows：TaskFlow 中 Flows 的封装
tasks：TaskFlow 中 Tasks 的封装
TaskFlow is a Python library that helps to make task execution easy, consistent and reliable. A library to do [jobs, tasks, flows] in a highly available, easy to understand and declarative manner (and more!) to be used with OpenStack and other projects.
显然，对于 Octavia 而言 TaskFlow 是一个非常关键的工具。TaskFlow 能够控制代码中任务的暂停、重启、回滚以及恢复，简单高效的保证了长业务流程执行的可靠性和一致性。简而言之，将多个 Tasks 以特定的 Flow（e.g. 线性流、并行流、图流）执行起来，就是 Task-Flow。
TaskFlow 的应用场景有很多，主要特征是 “流程长”、“调用复杂”、“有资源状态机” 等，Cinder create volume 的实现就是一次典型的应用。当然了，Octavia 也算一个。而且 Octavia 可以说是将 TaskFlow 的特性发挥到了极致，这个问题我们在后面的底层实现篇中再继续聊。
最后最后简单终结一下 Octavia 的架构设计，作为独立项目，Octavia 继承了 OpenStack 一贯优秀的开放性，在关键的 LB Provider、Certificates、Compute 和 Network 这些外部支撑节点都进行了高度抽象，使 Vendors 和 Users 有可能通过简单的开发接入现有的基础设施。这无疑是 Octavia 甚至 OpenStack 受到欢迎的原因之一。
下一篇《OpenStack Rocky Octavia 的实现与分析（一）创建 LoadBalancer 的流程》即将更新，敬请期待！
＞＞ 关于作者：九州云网络团队
＞ ＞ 关于『 Linux宝库 』：欢迎关注『Linux宝库』微信公众号，这里每天发布最新的开源人物和开源事件。谨以此号记录Linux和开源业界的点点滴滴，为开源爱好者和从业者点亮人生！
- END -
为开源爱好者和从业者点亮人生！
长按二维码关注我们
