简介

Octavia 是一款开放源码的运营商级负载平衡解决方案，旨在与 OpenStack 配合使用。
Octavia 之前由 Neutron LBaaS 项目承担，影响了Neutron LBaaS项目的转型，Neutron LBaaS 从版本1转为版本2。从OpenStack的Liberty发行版开始，Octavia 成为Neutron LBaaS第2版的参考实现。从 Pike 版本开始，Octavia 就可以作为独立的Keystone服务而不再是 Neutron 的一个 service plugin，同时，CLI 命令也作为 openstack 命令行的一部分，而不是通过 neutron 调用。
Octavia通过管理一组虚拟机，容器或裸机（通常称为amphora）来完成其负载均衡服务的交付。 这种按需、横向扩展特性将Octavia与其他负载平衡解决方案区分开来，从而使Octavia真正适合“云”。
说白了，就是将用户的API请求经过逻辑处理，转换成haproxy和keepalived的配置参数，下发到amphorae虚拟机中。

命令行使用流程

如下几个命令创建一个 loadbalancer，一个 listener 一个 pool，同时添加两个 member。

  • neutron CLI

    1
    2
    3
    4
    5
    neutron lbaas-loadbalancer-create --name lb1 private-subnet
    neutron lbaas-listener-create --loadbalancer lb1 --protocol HTTP --protocol-port 80 --name listener1
    neutron lbaas-pool-create --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP --name pool1
    neutron lbaas-member-create  --subnet private-subnet --address ${IP1} --protocol-port 80 pool1
    neutron lbaas-member-create  --subnet private-subnet --address ${IP2} --protocol-port 80 pool1

  • openstack CLI

    1
    2
    3
    4
    openstack loadbalancer create --name test_1 --vip-subnet-id f2492f6d-abe8-4600-9620-ea0b30e0f04c
    openstack loadbalancer listener create --name test_1 --protocol HTTP --protocol-port 80 a32dfcac-3f65-454d-acb1-fc038434b0ed
    openstack loadbalancer pool create --name test_pool_1 --protocol HTTP --listener 7a14d263-d19f-49c6-b7ac-35dc74f95e7e --lb-algorithm ROUND_ROBIN
    openstack loadbalancer member create --name member_1 --address 10.0.0.14 --subnet-id f2492f6d-abe8-4600-9620-ea0b30e0f04c --protocol-port 80 1922e4a8-3538-43ff-9489-7cb3b35e6bb0

涉及资源及概念

loadbalancer

octavia 的实现就是由 amphora 镜像起来的虚拟机实例，即创建 loadbalancer 就是创建 amphora 虚机。

目前支持 single 和 active-standby 两种模式，社区正在开发 active-active 模式，（Queens）暂不支持。active-standby 模式如果配置enable_anti_affinity，则会针对这个 lb 先在Nova创建ServerGroup（这个ServerGroup的ID会记录在DB中），两个虚拟机就会创建在不同的host上。

实现功能的 haproxy 和 keepalived 是在虚机的 amphora namespace 中。网络拓扑实现并没有使用 Linux bridge 或者 OVS 实现，而是由 namespace 独占一个网卡资源（一般是 eth1，用于 vrrp ，eth1:0 用于 vip），即 eth0 属于虚拟机主体，映射 neutron 中管理 lb 网络（lb-mgmt-net）的 port ，而 namespace 直接映射租户 vip 需求的 subnet。

listener

监听器即一个不断在端口上检查连接请求的进程，一旦发现客户端的连接请求，则会按照你设定的规则将连接请求转发给后端的服务器池。一个监听器关联一个端口，如：HTTP(80)、HTTPS（443），当使用HTTPS，则需要上传用于https 加密和解密的证书到监听器中。

即虚拟机里面的一个 haproxy 进程，frontend 配置。

*支持 L7 Policy

pool

服务器池即后端一组提供服务的实例，每个成员都是一个IP地址+4层的端口。
octavia 实现为 haproxy 配置中的一个 backend。

member

backend 配置中的一个 member，即真正承载内容的后端服务器。

health-monitor

健康检测的机制是指是负载均衡器通过定期的心跳信号检测服务器池中的服务器运行状态，从而排除掉后端故障的主机，保证服务整体正常。

支持的健康检测方式包括 ICMP、TCP、HTTP几种。

  • ICMP是最简单的，通过ping 和echo的方式，看根据服务器是否响应。只要服务器操作系统TCP/IP协议栈运行正常，网卡不出问题，服务器到负载均衡之间的网络正常，ICMP的方式都起到良好的作用，但以上情况都不能代表服务器上面运行的应用是正常的。
  • TCP是4层的检测方式，相比ICMP、TCP会请求主机的特定端口，看特定的端口能否正常响应。
  • HTTP的方式则更进一筹，会通过get特定的页面，根据HTTP的返回代码来判断应用是否正常。

健康监测的指标越精确，越能反映服务的实际响应情况，如果是web服务，最好是使用HTTP的方式，这样检测结果更可信。

health-manager

检查虚拟机状态，和虚拟机中的octavia agent通信，来更新各个组件的状态。
注意和 health-monitor 监控对象的不同。

amphora-agent

位于虚拟机内部，对下是接受指令操作下层的 haproxy 软件，对上是和 health-manager 通信汇报各种情况。

amphora 镜像制作

在 部署完 octavia 真正运行服务之前，最重要的一个工作就是准备镜像。这个镜像是用来创建 amphorae service 虚拟机。
octavia repo 中提供了创建 haproxy 镜像的脚本可以直接使用：

$ ./diskimage-create/diskimage-create.sh

目前直接使用 octavia 的代码来制作镜像会出现问题，另外因为在 centos 上以 ubuntu 为 base 制作镜像会出现包验证和权限的问题，所以将 base 改为 centos。
需要以下修改，涉及两方面的代码： dib octavia

dib

octv ia 需要使用 pypi（element）更换 pip 源，因此需要将 pypi 指的源变更为国内源

  • (方式一) export DIB_PYPI_MIRROR_URL (测试时未生效)
  • (方式二) pre-install.d/00-configure-pypi-mirror:46: indices.append(‘https://pypi.python.org/simple')

octavia

  • 首先需要引入 pypi，可以使用 export DIB_LOCAL_ELEMENTS
  • 接着将默认 base 改为 centos，或者使用 octvia 脚本中预留的 -i 参数
  • 最后修改一处代码：
1
2
3
4
5
6
7
8
@@ -12,9 +12,9 @@ AMP_VENV=/opt/amphora-agent-venv
# Create a virtual environment to contain the amphora agent
${DIB_PYTHON} -m virtualenv $AMP_VENV

+$AMP_VENV/bin/pip install --upgrade pbr

# Link the amphora-agent out to /usr/local/bin where the startup scripts look
ln -s $AMP_VENV/bin/amphora-agent /usr/local/bin/amphora-agent || true

Octavia与Neutron的关系

  • Before Pike

    lbaas v1: This is the original Neutron LBaaS, and what you see in Horizon or in the neutron CLI as “lb-*”. It has an haproxy backend, and a few vendors supporting it. Feature-wise, it’s basically a byte pump.

    lbaas v2: This is the “new” Neutron LBaaS, and is in the neutron CLI as “lbaas-*” (it’s not yet in Horizon.) It first shipped in Kilo. It re-organizes the objects, and adds TLS termination support, and has L7 plus other new goodies planned in Liberty. It similarly has an haproxy reference backend with a few vendors supporting it.

    octavia: Think of this as a service vm framework that is specific to lbaas, to implement lbaas via nova VMs instead of “lbaas agents”. It is expected to be the reference backend implementation for neutron lbaasv2 in liberty. It could also be used as its own front-end, and/or given drivers to be a load balancing framework completely outside neutron/nova, though that is not the present direction of development.

  • After Pike
    从 Pike 版本开始，octavia 可以作为一个独立服务部署而不依赖于 neutron，neutron 对于 octavia 开说只是下层的一个服务而已。所以，也就不会有两份数据库记录，不用担心数据不一致的问题。

逻辑架构图

逻辑架构图

参考连接

https://docs.openstack.org/octavia/latest/
https://lingxiankong.github.io/2017-09-13-octavia.html
https://www.cnblogs.com/pmyewei/p/7376921.html
http://www.cnblogs.com/sammyliu/p/4656176.html