Octavia--Neutron中LBaaS的参考实现

2016-03-30

本博客所有文章采用的授权方式为 自由转载-非商用-非衍生-保持署名 ,转载请务必注明出处,谢谢。

声明:
本博客欢迎转发,但请保留原作者信息!
新浪微博:@Lingxian_kong;
博客地址:孔令贤的博客;
内容系本人学习、研究和总结,如有雷同,实属荣幸!

目标读者:OpenStack developer or operator
版本:Mitaka

Octavia简介

Octavia主要参与厂商:http://stackalytics.com/?project_type=openstack&metric=commits&module=octavia
Octavia的开发者文档:http://docs.octavia.io/review/master/

你需要了解的前置知识:

Neutron中loadbalance-as-a-server 2.0对外提供的API参考: http://developer.openstack.org/api-ref-networking-v2-ext.html#lbaas-v2.0

命令行使用流程

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

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

Octavia与Neutron的关系

作为Neutron中LBaaS的参考实现,与其说Octavia与Neutron的关系,还不如说Octavia与Neutron中LBaaS service plugin的关系。之前有人在网上问过同样的问题,一位Octavia core reviewer给出如下答案:

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.

总结一下就是,Neutron中有LBaaS service plugin,在LBaaS plugin中有很多provider或者叫driver(比如开源的haproxy driver或其他很多网络设备厂家实现的driver),其中一个叫octavia driver,该driver做的事情就是调用Octavia的API,与Octavia服务交互。

还有一点值得注意,使用Octavia时,在Neutron和Octavia中都会有database,会重复记录一些资源信息。Octavia只是作为LBaaS的service provider之一,所以,Neutron DB中同样会记录loadbalancer与provider的对应关系。因为octavia从一开始就朝着standalone设计,所以有自己的db是最基本的要求。因此,在生产环境下,建议自己实现一致性检查。

neutron与octavia通信时,使用admin token,但会把实际租户的project id设置到操作对象结构体中,octavia会把project id记录到DB。octavia的API处理目前是没有鉴权的,生产环境部署时,建议与neutron-server部署在一起,并通过本地地址访问。

通过neutron api使用lb资源时,get和list的操作都会使用neutron自己的db信息。

创建loadbalancer流程

目前支持single和active standby两种模式的loadbalancer,通过配置文件配置。测试环境可以是single,但生产环境使用时还是建议active standby。社区正在开发active active,目前(Mitaka)暂不支持。这里以active standby模式为例。

创建loadbalancer,Octavia会创建两个虚拟机。如果配置enable_anti_affinity,则会先在Nova创建ServerGroup(这个ServerGroup的ID会记录在DB中),两个虚拟机就会创建在不同的host上。虚拟机的flavor、image、network、keypair信息都是从配置文件中获取,其中network就是Octavia进程与虚拟机通信的管理平面。

Octavia每创建一个loadbalancer,都会在admin租户下创建包含同样policy的ServerGroup。虚拟机以及虚拟机上的port也属于admin租户。即:创建loadbalancer的租户只能看到这个loadbalancer的信息以及loadbalancer所占用的port(VIP的port)信息,背后的VM、VM的port、SecurityGroup、ServerGroup都是不可见的。同时,一个loadbalancer的创建会占用租户subnet内的IP资源和port配额。

有了虚拟机后,会根据入参的subnet创建port,port的IP作为VIP。同时在这个subnet下给两个虚拟机分别挂载网卡,将VIP作为address pair配置到网卡。对这几个port配置相应的安全组规则。

allowed_address_pairs特性,参见这里.

然后,向虚拟机发送REST API消息 (post vip plug):
POST https://<mgmt-ip>:9876/0.5/plug/vip/<ip address>
参数中有VIP所在subnet的CIDR,网关IP,vrrp port的mac地址,vrrp port的IP地址。amphora-agent的处理过程如下:

  • 如果vip所在的网卡已经在namespace中,则直接返回。
  • 根据vrrp port的mac地址找到vrrp网卡,也就是对外提供LB服务的网卡(比如eth1,一般eth0是mgmt-net上的网卡)
  • 设置网卡配置文件,将系统/etc/network下的文件(除去eth0和openssh相关文件)复制到/etc/netns/amphora-haproxy/network目录下。新建/etc/netns/amphora-haproxy/network/interfaces文件,其内容中source /etc/netns/amphora-haproxy/network/interfaces.d/*.cfg
  • 向/etc/netns/amphora-haproxy/network/interfaces.d/eth1.cfg中写入网卡配置,eth1是vrrp ip,eth1:0是vip ip
  • 更新/var/lib/octavia/plugged_interfaces,内容{mac_address} {interface},据注释说是为了重启时添加到namespace用的
  • 创建名为amphora-haproxy的namespace,将eth1添加到namespace下
  • 重新激活eth1和eth1:0 (ip netns exec amphora-haproxy ifdown/ifup eth1)

总结一下就是,把提供LB服务的网卡放在namespace下。

如果是active standby,向amphora发送消息:
GET https://<mgmt-ip>:9876/0.5/interface/<vrrp_ip_address>
找到vrrp网卡名称(通常是eth1)并更新到amphora表,在DB添加vrrp_group表记录,向amphora发送消息:
PUT https://<mgmt-ip>:9876/0.5/vrrp/upload
将keepalived配置文件推送到两个虚拟机中(配置文件是/var/lib/octavia/vrrp/octavia-keepalived.conf),注册keepalived服务,keepalived的vrrp check脚本是/var/lib/octavia/vrrp/check_script.sh,这个脚本会调用/var/lib/octavia/vrrp/check_script/目录下的listener-haproxy的check脚本。最后在命名空间中启动虚拟机中的keepalived服务:
PUT https://<mgmt-ip>:9876/0.5/vrrp/start

至此,一个loadbalancer就创建结束了。基本上,后面创建listener、pool、member、health monitor,都是围绕这两个虚拟机,对haproxy和keepalived进程进行配置。

创建listener流程

在Octavia中,一个listener就对应一个haproxy进程。

首先生成haproxy配置文件,向amp发送消息:
PUT https://<mgmt-ip>:9876/0.5/listeners/{amphora_id}/{listener_id}/haproxy
haproxy的配置文件在/var/lib/octavia/{listener-id}/haproxy.cfg,amphora-agent会先调用haproxy -c -L {peer} -f {config_file}校验配置文件,然后生成对应该listener的haproxy服务脚本。

再次向amp发送消息启动haproxy服务:
PUT https://<mgmt-ip>:9876/0.5/listeners/{listener_id}/start
amphora-agent的处理:

  • 先确定listener的配置目录(/var/lib/octavia/{listener-id}/)在不在
  • 如果是active standby,更新keepalived对各个haproxy的check脚本,/var/lib/octavia/vrrp/check_script/haproxy_check_script.sh
  • 启动haproxy服务,service haproxy-{listener_id} start

添加member流程

添加member,会在member所在的subnet中给amphora添加port,然后向amp发送消息:
POST https://<mgmt-ip>:9876/0.5/plug/network,参数是port的信息,处理流程与plug vip很类似,就是把通过nova api给amp挂载的网卡移到namespace下。

逻辑架构图

下图是通过octavia创建一个loadbalancer之后的逻辑图。
logical architecture of octavia loadbalancer

octavia中有个叫health-monitor的进程,其任务之一是监听来自amphorae虚拟机发送的运行状态数据,以此更新lb、listener、pool、member的状态,最重要的是更新amphora_health表。同时,更新listener_statistics表,这个表的数据可以作为计费依据。

health-monitor进程的任务之二,是根据amphora_health表,找到异常状态的amphorae虚拟机,对该虚拟机进行更换操作。即删除旧的虚拟机,创建并配置新的amphorae虚拟机。

需要注意的是,health-monitor进程的监听IP和端口,必须在lb-mgmt-net内,以便接收amphorae的消息。可以查看devstack安装脚本了解该步骤的初始化过程。

octavia还有个进程叫house-keeping,主要任务是确保空闲的amphorae池大小、定期清理db中已删除的amphorae记录、定期更新amphorae中的证书。

Failover流程和实验

health-monitor根据amphora_health表检测到有amphorae状态异常时,就会触发failover流程 (health-monitor每次运行时仅会failover一个amphora,如果是更换image等maintainance操作,需要考虑适当调整)。

  • 将amphorae db中的status设置为pending delete
  • 设置amphora-health db中的busy字段为True,这样该amp就不会被health monitor重复检测
  • 调用Nova接口删除amphorae虚拟机(按照Nova的设计,删除虚拟机,不会删除虚拟机以port形式挂载的网卡,但会删除使用network创建的port)
  • 等待Neutron将amphora vm上挂载的port的信息(比如device-id)重置(不考虑mgmt network上的port)
  • 删除amphora-health db中该amp的记录
  • 将amphorae db中的status设置为deleted
  • 创建新的amphorae虚拟机,此时虚拟机只挂载了mgmt network的网卡
  • 用旧的amphorae db的一些信息覆盖新的amphorae db记录,vrrp ip, ha ip, vrrp port id, ha port id等
  • 调用一次ListenersUpdate,没想明白是何意?
  • 给个虚拟机挂载vip port,vrrp port,以及与member互通的port,并到虚拟机里配置相应的网卡
  • 在amphora db中设置role,到虚拟机里处理keepalived相关的配置
  • 最后调用了一次ListenersStart

我的环境中已经创建如下资源:

vagrant@octavia:~/devstack$ source openrc demo demo
vagrant@octavia:~/devstack$ neutron lbaas-loadbalancer-list
+--------------------------------------+-------+-------------+---------------------+----------+
| id                                   | name  | vip_address | provisioning_status | provider |
+--------------------------------------+-------+-------------+---------------------+----------+
| 38307452-d6bd-488b-af29-3032fff65fe1 | my_lb | 10.0.0.11   | ACTIVE              | octavia  |
+--------------------------------------+-------+-------------+---------------------+----------+
vagrant@octavia:~/devstack$ source openrc admin admin
vagrant@octavia:~/devstack$ nova list
+--------------------------------------+----------------------------------------------+--------+------------+-------------+-----------------------------------------------------------------------------------+
| ID                                   | Name                                         | Status | Task State | Power State | Networks                                                                          |
+--------------------------------------+----------------------------------------------+--------+------------+-------------+-----------------------------------------------------------------------------------+
| e356a373-2fed-4228-a695-fec797a42a9e | amphora-b07c2493-32de-4af0-bf88-abe3c54355ce | ACTIVE | -          | Running     | lb-mgmt-net=192.168.0.10; private=fd36:53a8:d962:0:f816:3eff:feeb:ad76, 10.0.0.12 |
+--------------------------------------+----------------------------------------------+--------+------------+-------------+-----------------------------------------------------------------------------------+
vagrant@octavia:~/devstack$ neutron port-list -- --device-id e356a373-2fed-4228-a695-fec797a42a9e
+--------------------------------------+------+-------------------+-------------------------------------------------------------------------------------------------------------+
| id                                   | name | mac_address       | fixed_ips                                                                                                   |
+--------------------------------------+------+-------------------+-------------------------------------------------------------------------------------------------------------+
| 31289554-d738-4df3-b9be-85214ba7039b |      | fa:16:3e:67:fe:6e | {"subnet_id": "06e5e04f-a92c-43bb-ba2e-349016e4ff21", "ip_address": "192.168.0.10"}                         |
| fbdca2b6-03c6-4775-b72c-340d55be0aa3 |      | fa:16:3e:eb:ad:76 | {"subnet_id": "c43853c0-84a8-4a29-96f0-edbc387ae996", "ip_address": "10.0.0.12"}                            |
|                                      |      |                   | {"subnet_id": "a0a34d85-7327-4173-9ccc-865b9c06f54f", "ip_address": "fd36:53a8:d962:0:f816:3eff:feeb:ad76"} |
+--------------------------------------+------+-------------------+-------------------------------------------------------------------------------------------------------------+
vagrant@octavia:~/devstack$ neutron port-show 31289554-d738-4df3-b9be-85214ba7039b
+-----------------------+--------------------------------------------------------------------------------------------------------------+
| Field                 | Value                                                                                                        |
+-----------------------+--------------------------------------------------------------------------------------------------------------+
| admin_state_up        | True                                                                                                         |
| allowed_address_pairs |                                                                                                              |
| binding:host_id       | octavia                                                                                                      |
| binding:profile       | {}                                                                                                           |
| binding:vif_details   | {"port_filter": true, "ovs_hybrid_plug": true}                                                               |
| binding:vif_type      | ovs                                                                                                          |
| binding:vnic_type     | normal                                                                                                       |
| device_id             | e356a373-2fed-4228-a695-fec797a42a9e                                                                         |
| device_owner          | compute:None                                                                                                 |
| dns_assignment        | {"hostname": "host-192-168-0-10", "ip_address": "192.168.0.10", "fqdn": "host-192-168-0-10.openstacklocal."} |
| dns_name              |                                                                                                              |
| extra_dhcp_opts       |                                                                                                              |
| fixed_ips             | {"subnet_id": "06e5e04f-a92c-43bb-ba2e-349016e4ff21", "ip_address": "192.168.0.10"}                          |
| id                    | 31289554-d738-4df3-b9be-85214ba7039b                                                                         |
| mac_address           | fa:16:3e:67:fe:6e                                                                                            |
| name                  |                                                                                                              |
| network_id            | f280060d-d473-4ca1-8004-5ac880db7556                                                                         |
| port_security_enabled | True                                                                                                         |
| security_groups       | 74a0601b-29c9-4ea8-9eba-604fb35a090f                                                                         |
| status                | ACTIVE                                                                                                       |
| tenant_id             | 40621451e5b04ddcb96764022afb5a01                                                                             |
+-----------------------+--------------------------------------------------------------------------------------------------------------+
mysql> select * from amphora \G;
*************************** 1. row ***************************
              id: b07c2493-32de-4af0-bf88-abe3c54355ce
      compute_id: e356a373-2fed-4228-a695-fec797a42a9e
          status: ALLOCATED
load_balancer_id: 38307452-d6bd-488b-af29-3032fff65fe1
   lb_network_ip: 192.168.0.10
         vrrp_ip: 10.0.0.12
           ha_ip: 10.0.0.11
    vrrp_port_id: fbdca2b6-03c6-4775-b72c-340d55be0aa3
      ha_port_id: d2c26a5d-51b9-4487-bd16-5438218ad8ee
            role: STANDALONE
 cert_expiration: 2018-04-09 09:48:49
       cert_busy: 0
  vrrp_interface: NULL
         vrrp_id: 1
   vrrp_priority: NULL

为了启动failover流程,只需把amp虚拟机在lb-mgmt-net上的port状态down掉即可:

vagrant@octavia:~/devstack$ neutron port-update 31289554-d738-4df3-b9be-85214ba7039b --admin-state-up False

health-monitor进程会检测到该amp虚拟机异常,会替换该虚拟机,但会保留该虚拟机上所有非lb-mgmt-net上的port:

vagrant@octavia:~/devstack$ nova list
+--------------------------------------+----------------------------------------------+--------+------------+-------------+-----------------------------------------------------------------------------------+
| ID                                   | Name                                         | Status | Task State | Power State | Networks                                                                          |
+--------------------------------------+----------------------------------------------+--------+------------+-------------+-----------------------------------------------------------------------------------+
| 9396f601-ed7b-481e-a56b-a1b27ed3e609 | amphora-57865deb-b8b6-45bc-a2d2-d231c7e011ae | ACTIVE | -          | Running     | lb-mgmt-net=192.168.0.11; private=fd36:53a8:d962:0:f816:3eff:feeb:ad76, 10.0.0.12 |
+--------------------------------------+----------------------------------------------+--------+------------+-------------+-----------------------------------------------------------------------------------+
vagrant@octavia:~/devstack$ neutron port-list -- --device-id 9396f601-ed7b-481e-a56b-a1b27ed3e609
+--------------------------------------+------+-------------------+-------------------------------------------------------------------------------------------------------------+
| id                                   | name | mac_address       | fixed_ips                                                                                                   |
+--------------------------------------+------+-------------------+-------------------------------------------------------------------------------------------------------------+
| a4d27c16-b25e-44f2-a595-fd5fd066c2c4 |      | fa:16:3e:b5:3a:e4 | {"subnet_id": "06e5e04f-a92c-43bb-ba2e-349016e4ff21", "ip_address": "192.168.0.11"}                         |
| fbdca2b6-03c6-4775-b72c-340d55be0aa3 |      | fa:16:3e:eb:ad:76 | {"subnet_id": "c43853c0-84a8-4a29-96f0-edbc387ae996", "ip_address": "10.0.0.12"}                            |
|                                      |      |                   | {"subnet_id": "a0a34d85-7327-4173-9ccc-865b9c06f54f", "ip_address": "fd36:53a8:d962:0:f816:3eff:feeb:ad76"} |
+--------------------------------------+------+-------------------+-------------------------------------------------------------------------------------------------------------+
mysql> select * from amphora \G;
*************************** 1. row ***************************
              id: 57865deb-b8b6-45bc-a2d2-d231c7e011ae
      compute_id: 9396f601-ed7b-481e-a56b-a1b27ed3e609
          status: ALLOCATED
load_balancer_id: 38307452-d6bd-488b-af29-3032fff65fe1
   lb_network_ip: 192.168.0.11
         vrrp_ip: 10.0.0.12
           ha_ip: 10.0.0.11
    vrrp_port_id: fbdca2b6-03c6-4775-b72c-340d55be0aa3
      ha_port_id: d2c26a5d-51b9-4487-bd16-5438218ad8ee
            role: STANDALONE
 cert_expiration: 2018-04-09 10:04:58
       cert_busy: 0
  vrrp_interface: NULL
         vrrp_id: 1
   vrrp_priority: NULL

注意事项:使用spare pool可以加快failover的流程;但使用spare pool将不会遵从anti-affinity(如果配置的话)规则。

在failover流程中,amphorae虚拟机中的amphora-agent.log日志如下(我加了步骤名称),从日志中可以看到failover时,对新虚拟机的配置过程:

# ListenersUpdate
2016-04-13 23:36:35.265 416 INFO werkzeug [-] 192.168.0.3 - - [13/Apr/2016 23:36:35] "PUT /0.5/listeners/d5716c03-e269-4d13-9d03-8ddc21a0dcc4/816339a8-2e17-4b61-8825-c6856d7b7f2e/haproxy HTTP/1.1" 202 -
2016-04-13 23:36:35.500 416 INFO werkzeug [-] 192.168.0.3 - - [13/Apr/2016 23:36:35] "GET /0.5/listeners/816339a8-2e17-4b61-8825-c6856d7b7f2e HTTP/1.1" 200 -
2016-04-13 23:36:37.495 416 INFO werkzeug [-] 192.168.0.3 - - [13/Apr/2016 23:36:37] "PUT /0.5/listeners/816339a8-2e17-4b61-8825-c6856d7b7f2e/start HTTP/1.1" 202 -
# AmphoraPostVIPPlug
2016-04-13 23:40:44.096 416 INFO werkzeug [-] 192.168.0.3 - - [13/Apr/2016 23:40:44] "POST /0.5/plug/vip/10.0.0.6 HTTP/1.1" 202 -
# AmphoraPostNetworkPlug
2016-04-13 23:41:41.996 416 INFO werkzeug [-] 192.168.0.3 - - [13/Apr/2016 23:41:41] "POST /0.5/plug/network HTTP/1.1" 202 -
# AmphoraUpdateVRRPInterface
2016-04-13 23:41:46.481 416 INFO werkzeug [-] 192.168.0.3 - - [13/Apr/2016 23:41:46] "GET /0.5/interface/10.0.0.7 HTTP/1.1" 200 -
# AmphoraVRRPUpdate
2016-04-13 23:41:50.277 416 INFO werkzeug [-] 192.168.0.3 - - [13/Apr/2016 23:41:50] "PUT /0.5/vrrp/upload HTTP/1.1" 200 -
# AmphoraVRRPStart
2016-04-13 23:41:58.807 416 INFO werkzeug [-] 192.168.0.3 - - [13/Apr/2016 23:41:58] "PUT /0.5/vrrp/start HTTP/1.1" 202 -
# ListenersStart
2016-04-13 23:42:10.131 416 INFO werkzeug [-] 192.168.0.3 - - [13/Apr/2016 23:42:10] "PUT /0.5/listeners/816339a8-2e17-4b61-8825-c6856d7b7f2e/start HTTP/1.1" 202 -

Amphorae VM

在虚拟机里面,除了haproxy和keepalived进程,还有最重要的octavia agent进程。

octavia agent做两件事,第一,定时向health-monitor发送haproxy的运行时信息,该信息是通过向haproxy进程发送查询命令获取到,同时,从Queue中监听命令(reload/shutdown);第二,使用Flask库提供REST API,供octavia-controller-worker调用,控制haproxy和keepalived。

安装部署

Octavia要与Neutron配合,安装时neutron-lbaas软件包要与Neutron软件包安装在同一位置,在python路径中,neutron-lbaas目录与neutron目录同级。Octavia几个服务进程可以不与Neutron服务进程部署在同一host,因为neutron plugin与octavia是通过rest api通信。其实可以通过octavia中的devstack脚本了解其配置和安装过程。

当然,如果是生产环境要用,还要考虑其与周边安装工具的配合是否完备。比如是否有debian包、是否支持ansible安装、是否支持puppet安装?关于ansible的安装,社区正在做:

https://specs.openstack.org/openstack/openstack-ansible-specs/specs/mitaka/lbaasv2.html https://blueprints.launchpad.net/openstack-ansible/+spec/lbaasv2

上面的BP负责人回答:LBaaS v2 with agent (not octavia) is in Mitaka now, but the Liberty backport is still getting reviewed, octavia support is on hold until we can get something to make the LB mgmt network easier.

所以,截止Mitaka,如果要使用octavia,只有devstack是可用的。octavia社区正在完善installation文档。

在部署过程中,需要注意,octavia在设计之初仅考虑与neutron通信,目前缺少keystone认证机制,所以建议octavia api使用私有地址对neutron提供服务,并且建议octavia api进程与neutron server进程部署在一起。

AWS Elastic Loadbalancing

分析任何OpenStack中项目时,都会不由自主的看一看老大哥AWS的类似服务的文档,毕竟OpenStack很多project都是照着AWS实现的。对于LBaaS来讲也不例外,AWS中就有一个Elastic Loadbalancing服务,参考如下几个链接:

https://aws.amazon.com/elasticloadbalancing/ http://docs.aws.amazon.com/ElasticLoadBalancing/latest/APIReference/API_Welcome.html http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elastic-load-balancing.html

FAQ

添加member时,如果参数中member所在的subnet与loadbalancer的subnet不一致,会怎样?

Octavia允许member的IP地址范围与loadbalancer的subnet范围不同,内部实现时,会在member的IP地址范围内给amphora虚拟机添加网卡,以便与member通信。从另一种意义上来说,其实是对member所在subnet的IP地址空间的占用,而该subnet的租户是不感知的。

相似的问题,添加member时,如果member所在的subnet与lb-mgmt-net有地址重叠该怎么办?此时,amphorae会有多个网卡属于同一网段。

这个问题我也问过社区,目前有个patch正在解决这个问题。方法是在amphorae内使用namespace的方式对tenant network与lb-mgmt-net进行隔离。

创建member时,如果address不在subnet范围内,会怎么样?

我在阅读代码时发现了这个问题,并没有测试。按照代码逻辑,这个操作不会有什么异常。但loadbalancer肯定无法使用,因为amphora虚拟机根本访问不到member的IP地址。碰巧,我在review一个patch涉及此问题,我把问题抛给了patch的作者。patch链接:https://review.openstack.org/292614

如何升级amphora虚拟机的内核?

这个问题是团队内部考量是否部署octavia时,operator提出的一个很现实的问题。根据我对octavia的代码理解以及与octavia社区core的交流,我给出的答复如下:

There is a process called octavia-health-manager in octavia, it will check the amphora vm status and do failover. For example, we have amp1(master) and amp2(backup) for a loadbalancer in active-standby mode, when we want to patch the vm, we need to do following things:

  1. we need to make a new image included patches we need using diskimage-builder tool.
  2. update image data in Glance.
  3. Mark down the management port of any one of the two vms(amp2 is recommended).
  4. the octavia-health-manager process will know that, and it will replace the vm with a new one, using new image.
  5. repeat for the other vm.

其实一开始我的答案中第三步是删除虚拟机,但octavia社区目前仍有一个相关的bug待解决,所以octavia社区建议down掉虚拟机的lb管理面port即可。bug链接在这里

我的升级虚拟机内核的脚本在这里

高版本的octavia可否与低版本的neutron(lbaas v2)兼容?

经过测试,mitaka octavia完全兼容liberty neutron/neutron-lbaas,但在读代码时发现在mitaka中octavia driver会将project id传递给octavia服务,这在liberty版本的octavia driver中是没有的。需要进一步研究一下没有project id会产生什么影响。

但需要注意,liberty horizon与mitaka neutron-lbaas-v2(lbaas v2的第一个release)无法兼容,会出现如下错误:

on line 24 of dashboard/project/lbaasv2/lbaasv2.scss
Traceback:
  File "/home/lingxiankong/Envs/horizon/local/lib/python2.7/site-packages/scss/calculator.py", line 141, in evaluate_expression
    return ast.evaluate(self, divide=divide)
  File "/home/lingxiankong/Envs/horizon/local/lib/python2.7/site-packages/scss/ast.py", line 346, in evaluate
    raise SyntaxError("Undefined variable: '%s'." % self.name)
SyntaxError: Undefined variable: '$gray-light'.

octavia会依赖babican么?

在octavia的安装和使用中,我看到了octavia使用babican来做证书管理。但如果不使用octavia提供的TLS Termination的功能,就可以不使用babican。

有趣的是,neutron-lbaas和octavia中都使用了插件机制来提供证书管理,在实际使用过程中,需要两者的配置保持一致。虽然目前neutron-lbaas中支持barbican和local两种方式,但local的方式仅仅提供开发测试使用。

用户通过barbican创建或上传自己的证书,用barbican中的container id作为参数创建listener,octavia就会从barbican获取用户的证书和密钥文件,并上传到amphorae中配置haproxy ssl。

参考文档

http://blog.sina.com.cn/s/blog_704836f40101gm11.html https://serversforhackers.com/using-ssl-certificates-with-haproxy

文章评论

comments powered by Disqus


章节列表