neutron之负载均衡LBaas

作者：【吴业亮】云计算开发工程师
博客：http://blog.csdn.net/wylfengyujiancheng

一、LBaaS 逻辑架构

1、VIP

VIP(Virturl IP address)就是负载均衡对外提供服务的地址。VIP 有自己的 IP 地址，而且一般都能通过公网进行访问。在 Neutron 中，VIP 对应着二层虚拟设备 br-int 上的一个 port。当负载均衡 Pool 里面至少有一个 member 时，VIP 才有存在的意义，因为这时至少有一个实际的 OpenStack 实例在处理网络请求。VIP 负责将网络流量分发到各个 member，Neutron LBaaS 中支持以下三种网络流量的分发方式。

● Round robin：在多个实例之间均匀地分发请求。

● Least connections：分配到实例的请求，以最后活跃的连接数为准。

有的 member 连接数一样，则遵循 Round robin 的方式。
Neutron 中，VIP 还支持设置最大连接数(connection-limit)，这样在网络流量大时，可以保护负载均衡池。最大连接数可以设置成-1，这时不限制连接数。

2、Pool
Pool 是 LBaaS V1 中的 root resource。所有的其他资源都是基于 pool 来创建的。Neutron LBaaS 默认以 HAProxy 为 Driver 实现。在默认情况下，一个 pool 对应着一个独立的 HAProxy 进程，一个独立的 namespace。目前一个 pool 只能有一个 VIP，在 LBaaS V2 里面，可以允许一个 pool 对应多个 VIP。

3、Member
Member 对应的是 pool 里面处理网络请求的 OpenStack 实例。在 OpenStack Neutron 中，member 是一个逻辑关系，表示着实例与 pool 的对应关系。这也就是说，一个 OpenStack 实例，可以对应不同的 pool，在 Neutron 的 LBaaS 里面创建多个 member。在创建 member 时所选择的实例，必须与 pool 处于同一个 subnet，否则将不能工作。

4、Health monitor（健康监控）
Health monitor 只有在关联 pool 时才有意义。它用来监测 pool 里面 member 的状态。它会以轮询的方式，去查询各个 member，如果 member 未作出响应，它会更新 member 的状态至 INACTIVE，这样在 VIP 分发网络请求时，就不会考虑这个 member 了。如果 member 恢复了响应，它会更新 member 的状态至 ACTIVE。这时，member 会重新出现在 VIP 的分发列表中。

与其他的概念不同，Health monitor 在 Neutron 的负载均衡中不是必须的。也就是说，没有 Health monitor，也能组成一个负载均衡池。但是，如果没有 Health monitor，pool 会一直认为所有的 member 都是 ACTIVE 状态，这样所有的 member 会一直出现在 VIP 的分发列表中，哪怕 member 对应的实例不能响应网络请求。这在实际应用中会造成负载均衡的响应异常。

二、Neutron Load Balance 的实现

Neutron LBaaS 是基于 Neutron 实现的，pythone-neutronclient 中包含了 LBaaS 相关的命令，LBaaS 的数据也是存储在 Neutron 的数据库中。LBaaS 的程序架构也遵循着 Neutron 对 service plugin 的要求。

从图中可以看出，代码主要由三部分组成：
● Extension：负责处理 REST API 请求，并将 REST API 请求转发到 Plugin。
● Plugin：处理核心逻辑，管理 DB 的读写。
● Agent：处理并响应由 Plugin 发来的请求，管理 Driver。前面说过，OpenStack Neutron 默认采用 HAProxy 作为 driver。

三、安装部署
1、安装软件：

# yum install centos-release-openstack-mitaka
# yum install *neutron-lbaas-agent haproxy -y

2、在 /etc/neutron/neutron.conf文件中使用service_provider 属性，来启用HAProxy 插件：

 service_provider = LOADBALANCER:Haproxy:neutron_lbaas.services.loadbalancer.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default

注意：
在基于红帽的系统下，service_provider属性在/usr/share/neutron/neutron-dist.conf文件中已经定义好了。不要再在neutron.conf中定义了，否则网络服务会重启失败，
红帽系列配置方法，在/etc/neutron/neutron_lbaas.conf文件[service_providers]中加入

service_provider = LOADBALANCER:Haproxy:neutron_lbaas.services.loadbalancer.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default

3、在/etc/neutron/neutron.conf文件DEFAULT中通过使用 service_plugins属性来启用负载均衡插件：

service_plugins = lbaas

如果此属性已经定义过了，将lbaas添加到列表，使用逗号分隔。例如：

service_plugins = router,lbaas

4、在/etc/neutron/lbaas_agent.ini文件DEFAULT中启用HAProxy负载均衡器：

device_driver = neutron_lbaas.services.loadbalancer.drivers.haproxy.namespace_driver.HaproxyNSDriver

5、在文件/etc/neutron/lbaas_agent.ini中[DEFAULT]选择所需要的驱动：
激活Open vSwitch 负载均衡即服务驱动:

interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver

或者，激活Linux网桥负载均衡即服务驱动:

interface_driver = neutron.agent.linux.interface.BridgeInterfaceDriver

配置haproxy

[haproxy]
user_group = haproxy

6、在数据库中创建所要求的表：

# neutron-db-manage --service lbaas upgrade head

7、重启neutron-server 和 neutron-lbaas-agent服务以使设置生效。

# systemctl restart  neutron-serve   neutron-lbaas-agent
# systemctl enable neutron-serve   neutron-lbaas-agent

8、在面板的项目 选项卡下启用负载均衡。
在local_settings文件中修改enable_lb 的属性为True (
Fedora, RHEL,和 CentOS: /etc/openstack-dashboard/local_settings,
Ubuntu 和 Debian: /etc/openstack-dashboard/local_settings.py,
openSUSE 和 SLES: /srv/www/openstack-dashboard/openstack_dashboard/local/local_settings.py):

OPENSTACK_NEUTRON_NETWORK = {
    'enable_lb': True,
    ...
}

重启web服务器以使设置生效。此时可以在图形面板中的项目中看到负载均衡器的管理项了。

四、实践
1、创建另个虚拟机，由于本次在虚拟机上操作，资源有限，只通过ssh验证

2、创建资源池

3、将俩虚拟机加入成员中

4、添加监控

成功后：

5、分别添加vip和关联监控

成功后：

测试：
第一次ssh浮动IP

第二次ssh浮动IP

登录后台发现，neutron将配置文件写在 /var/lib/neutron/lbaas/
haproxy配置文件

进程ID

参考：
http://www.ibm.com/developerworks/cn/cloud/library/1506_xiaohh_openstacklb/

http://docs.ocselected.org/openstack-manuals/kilo/admin-guide-cloud/content/install_neutron-lbaas-agent.html

https://access.redhat.com/documentation/en/red-hat-openstack-platform/

http://www.haproxy.com/doc/aloha/7.0/haproxy