OpenStack octavia 详解

一、Octavia架构分析

具体架构图请参考：

https://docs.openstack.org/octavia/latest/reference/introduction.html

组件分析：

Octavia API：提供 Restful API，包括，负载均衡的几个对象的CURD操作，操作结果写入数据库，做持久，同时，通过消息总线通知controller。

Controller:是整个Octavia的核心，主要包括：四个部分，一个部分是API Consumer，第二个部分是 Controller worker，第三个部分是health manager，第四个部分是housekeeping manager.

API Consumer:通过消息总线接收来自于API的请求，并且实例化 Controller worker来处理API  请求。

Controller worker:接收API  命令，做相应的动作完成对应的请求，controller woker支持插件框架，包括：网络驱动，计算驱动，证书驱动，负载均衡实现驱动（参考实现是基于虚拟机形式的haproxy）。

Health Manager:监控负载均衡实现体（ amphora），确保他是健康的，如果发现它发现异常，则处理这种异常。

Housekeeping Manager：清理DB里的已经删除的纪录，维护一个空闲的负载均衡实现体（amphora）池，及维护证书的循环使用。



 

二、Octavia流程分析

1、创建loadbalancer流程

    创建一个loadbalancer涉及上面的描述的几个组件，API-->API Consumer--> Controller worker.

这里主要分析 controller worker组件里的动作，controller worker为了完成创建一个负载均衡实例，需要做多个动作，它采用了taskflow这个flow编程引擎来把所有的动作串联起来。

 1、通过loadbalancer id从数据库中读取loadbalancer的配置信息。

2、起一个创建loadbalanber的线性flow

  2.1创建一个loadbalancer id失败的复原的task，主要把该loadbalancer id在数据库的provision_status设置为error

  2.2根据topology的类型为active和standby，topology目前是一个管理员的配置行为，后续建议放开给租户通过flavor来配置，这里以active-standy topology为例来说明loadbalancer创建过程。

       2.2.1 起一个创建Server Group的task，为该loadbalancer 创建一个server group

       2.2.2 起一个数据库更新task，更新 该loadbalancer id对应的server group id

       2.2.3

 

架构利弊分析

1、octavia采用虚拟机来做为负载均衡的执行体，可以实现灵活的弹性伸缩。