openstack octavia的实现与分析（二）原理，架构与基本流程

【了解】

其实说白了，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。

基本流程如下：

【API 】

【数据结构】

以上是octavia主要数据表的拓扑图。

我们可以发现，load_balancer表几乎被关联到了所有的关键表，health_monitor是通过pool表去关联到listener和member的。

opertatingstatus和provisioning_status关联到了所有的关键表，主要作用是体现当前组件状态。

amphora_health主要体现amphora-agent的状态。

listener_statistics表，根据来自amphorae虚拟机发送的运行状态数据，实时维护对应 amphora_id与listener_id（主键） 的bytes_in，bytes_out，active_connections，total_connections字段，可以作为计费依据。

【主要流程】

·创建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 在命名空间中。

【参考】

https://docs.openstack.org/octavia/latest/

https://lingxiankong.github.io/2017-09-13-octavia.html

https://blog.csdn.net/Jmilk/article/details/84338419#Health_Manager_1343