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 】

Balancers

GET

/v2/lbaas/loadbalancers

List Load Balancers

  

POST

/v2/lbaas/loadbalancers/{loadbalancer_id}

Create a Load Balancer

  

GET

/v2/lbaas/loadbalancers/{loadbalancer_id}

Show Load Balancer details

  

PUT

/v2/lbaas/loadbalancers/{loadbalancer_id}

Update a Load Balancer

  

DELETE

/v2/lbaas/loadbalancers/{loadbalancer_id}

Remove a Load Balancer

  

GET

/v2/lbaas/loadbalancers/{loadbalancer_id}/stats

Get Load Balancer statistics

  

GET

/v2/lbaas/loadbalancers/{loadbalancer_id}/status

Get the Load Balancer status tree

  

PUT

/v2/lbaas/loadbalancers/{loadbalancer_id}/failover

Failover a load balancer

Listeners

GET

/v2/lbaas/listeners

List Listeners

  

POST

/v2/lbaas/listeners

Create Listener

  

GET

/v2/lbaas/listeners/{listener_id}

Show Listener details

  

PUT

/v2/lbaas/listeners/{listener_id}

Update a Listener

  

DELETE

/v2/lbaas/listeners/{listener_id}

Remove a Listener

  

GET

/v2/lbaas/listeners/{listener_id}/stats

Get Listener statistics

Pools

  

  

  

  

GET

/v2/lbaas/pools

List Pools

  

POST

/v2/lbaas/pools

Create Pool

  

GET

/v2/lbaas/pools/{pool_id}

Show Pool details

  

PUT

/v2/lbaas/pools/{pool_id}

Update a Pool

  

DELETE

/v2/lbaas/pools/{pool_id}

Remove a Pool

Members

  

  

  

  

GET

/v2/lbaas/pools/{pool_id}/members

List Members

  

POST

/v2/lbaas/pools/{pool_id}/members

Create Member

  

GET

/v2/lbaas/pools/{pool_id}/members/{member-id}

Show Member details

  

PUT

/v2/lbaas/pools/{pool_id}/members/{member_id}

Update a Member

  

PUT

/v2/lbaas/pools/{pool_id}/members

Batch Update Members

  

DELETE

/v2/lbaas/pools/{pool_id}/members/{member_id}

Remove a Member

Health Monitor

  

  

  

  

GET

/v2/lbaas/healthmonitors

List Health Monitors

  

POST

/v2/lbaas/healthmonitors

Create Health Monitor

  

GET

/v2/lbaas/healthmonitors/{healthmonitor_id}

Show Health Monitor details

  

PUT

/v2/lbaas/healthmonitors/{healthmonitor_id}

Update a Health Monitor

  

DELETE

/v2/lbaas/healthmonitors/{healthmonitor_id}

Remove a Health Monitor

L7 Policies

  

  

  

  

GET

/v2/lbaas/l7policies

List L7 Policies

  

POST

/v2/lbaas/l7policies

Create an L7 Policy

  

GET

/v2/lbaas/l7policies/{l7policy_id}

Show L7 Policy details

  

PUT

/v2/lbaas/l7policies/{l7policy_id}

Update a L7 Policy

  

DELETE

/v2/lbaas/l7policies/{l7policy_id}

Remove a L7 Policy

L7 Rules

  

  

  

  

GET

/v2/lbaas/l7policies/{l7policy_id}/rules

List L7 Rules

  

POST

/v2/lbaas/l7policies/{l7policy_id}/rules

Create an L7 Rule

  

GET

/v2/lbaas/l7policies/{l7policy_id}/rules/{l7rule_id}

Show L7 Rule details

  

PUT

/v2/lbaas/l7policies/{l7policy_id}/rules/{l7rule_id}

Update a L7 Rule

  

DELETE

/v2/lbaas/l7policies/{l7policy_id}/rules/{l7rule_id}

Remove a L7 Rule

Quotas

  

  

  

  

GET

/v2/lbaas/quotas

List Quota

  

GET

/v2/lbaas/quotas/defaults

Show Quota Defaults

  

GET

/v2/lbaas/quotas/{project_id}

Show Project Quota

  

PUT

/v2/lbaas/quotas/{project_id}

Update a Quota

  

DELETE

/v2/lbaas/quotas/{project_id}

Reset a Quota

Providers

  

  

  

  

GET

/v2/lbaas/providers

List Providers

  

GET

/v2/lbaas/providers/{provider}/flavor_capabilities

Show Provider Flavor Capabilities

Flavors

  

  

  

  

GET

/v2.0/lbaas/flavors

List Flavors

  

POST

/v2.0/lbaas/flavors

Create Flavor

  

GET

/v2.0/lbaas/flavors/{flavor_id}

Show Flavor Details

  

PUT

/v2.0/lbaas/flavors/{flavor_id}

Update a Flavor

  

DELETE

/v2.0/lbaas/flavors/{flavor_id}

Remove a Flavor

Flavor Profiles

  

  

  

  

GET

/v2.0/lbaas/flavorprofiles

List Flavor Profiles

  

POST

/v2.0/lbaas/flavorprofiles

Create Flavor Profile

  

GET

/v2.0/lbaas/flavorprofiles/{flavorprofile_id}

Show Flavor Profile Details

  

PUT

/v2.0/lbaas/flavorprofiles/{flavorprofile_id}

Update a Flavor Profile

  

DELETE

/v2.0/lbaas/flavorprofiles/{flavorprofile_id}

Remove a Flavor Profile

Amphorae

  

  

  

  

GET

/v2/octavia/amphorae

List Amphora

  

GET

/v2/octavia/amphorae/{amphora_id}

Show Amphora details

  

GET

/v2/octavia/amphorae/{amphora_id}/stats

Show Amphora Statistics

  

PUT

/v2/octavia/amphorae/{amphora_id}/config

Configure Amphora

  

PUT

/v2/octavia/amphorae/{amphora_id}/failover

Failover Amphora

   

【数据结构】

 

以上是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

现支持singleactive 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

posted @ 2019-07-18 21:09 imcate 阅读(...) 评论(...) 编辑 收藏