一、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采用虚拟机来做为负载均衡的执行体，可以实现灵活的弹性伸缩。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
