在OpenStack Grizzly版本中，Quantum组件引入了一个新的网络服务：LoadBalancer（LBaaS），服务的架构遵从Service Insertion框架。LoadBalancer为租户提供到一组虚拟机的流量的负载均衡，其基本实现为：在neutron-lbaas-agent中生成Haproxy的配置文件然后启动Haproxy。

Neutron LBaaS Service Architecture

 

LBaaS主要由以下几个模块构成，如下图所示

• Loadbalancer 处理Restful API
• LoadBalancerPlugin，This class manages the workflow of LBaaS request/response. Most DB related works are implemented in class loadbalancer_db.LoadBalancerPluginDb
• Scheduler: loadbalancer_pool_scheduler_driver = neutron.services.loadbalancer.agent_scheduler.ChanceScheduler 负责为vip分配相应的agent
• lbaas-agent 接收plugin消息，并将请求转发给device_driver(HaproxyNSDriver)执行
• HaproxyNSDriver 实现负载均衡的device driver，生成Haproxy的配置文件然后启动Haproxy

 

LBaaS数据模型

如上图所示，数据模型主要由Pool,VIP,Member,HealthMonitor等四个对象组成。

• 处在核心位置的是Pool（我倾向于把它命名成loadballancer）, 它代表一个负载均衡器。
• 一个负载均衡器拥有一个VIP，也就是虚拟IP。虚拟IP中的虚拟其实是相对后面的Member而言，也就是说这个VIP不固定在任何一个Member上。用户访问这个VIP，有时由这个成员提供服务，有时由那个成员提供服务。
• Member是后台提供服务的服务器。
• HealthMonitor用来监控和检查后台服务器的联通情况。当检查到某个服务器不能使用时，负载均衡器就不会用它来向用户提供服务。一个pool可对应多个health monitor。有四种类型：PING、TCP、HTTP、HTTPS。每种类型就是使用相应的协议对member进行检测。

除了以上四个对象，Session Persistence和Connection Limits这两个特性也比较重要：

• Session Persistence规定session相同的连接或请求转发的行为。目前支持三种类型：

 

• • SOURCE_IP：指从同一个IP发来的连接请求被某个member接收处理；
  • HTTP_COOKIE：该模式下，loadbalancer为客户端的第一次连接生成cookie，后续携带该cookie的请求会被某个member处理
  • APP_COOKIE：该模式下，依靠后端应用服务器生成的cookie决定被某个member处理

 

• Connection Limits 这个特性主要用来抵御DDoS攻击

 

LBaaS部署方法

1. DevStack中，增加 ENABLED_SERVICES+=,q-lbaas 选项即可；

2. RDO部署： packstack --allinone --neutron-lbaas-hosts=192.168.1.10 （具体步骤参考：http://openstack.redhat.com/LBaaS）

3. 也可以使用Openstack Heat来部署LBaaS，具体见http://blog.csdn.net/lin_victor/article/details/23060467

 

LBaaS使用方法

基本的使用步骤为：

 

• 租户创建一个pool，初始时的member个数为0；
• 租户在该pool内创建一个或多个member
• 租户创建一个或多个health monitor
• 租户将health monitors与pool关联
• 租户使用pool创建vip

 

在OpenStack Grizzly版本中，Quantum组件引入了一个新的网络服务：LoadBalancer（LBaaS），服务的架构遵从Service Insertion框架。LoadBalancer为租户提供到一组虚拟机的流量的负载均衡，其基本实现为：在neutron-lbaas-agent中生成Haproxy的配置文件然后启动Haproxy。

Neutron LBaaS Service Architecture

 

LBaaS主要由以下几个模块构成，如下图所示

• Loadbalancer 处理Restful API
• LoadBalancerPlugin，This class manages the workflow of LBaaS request/response. Most DB related works are implemented in class loadbalancer_db.LoadBalancerPluginDb
• Scheduler: loadbalancer_pool_scheduler_driver = neutron.services.loadbalancer.agent_scheduler.ChanceScheduler 负责为vip分配相应的agent
• lbaas-agent 接收plugin消息，并将请求转发给device_driver(HaproxyNSDriver)执行
• HaproxyNSDriver 实现负载均衡的device driver，生成Haproxy的配置文件然后启动Haproxy

 

LBaaS数据模型

如上图所示，数据模型主要由Pool,VIP,Member,HealthMonitor等四个对象组成。

• 处在核心位置的是Pool（我倾向于把它命名成loadballancer）, 它代表一个负载均衡器。
• 一个负载均衡器拥有一个VIP，也就是虚拟IP。虚拟IP中的虚拟其实是相对后面的Member而言，也就是说这个VIP不固定在任何一个Member上。用户访问这个VIP，有时由这个成员提供服务，有时由那个成员提供服务。
• Member是后台提供服务的服务器。
• HealthMonitor用来监控和检查后台服务器的联通情况。当检查到某个服务器不能使用时，负载均衡器就不会用它来向用户提供服务。一个pool可对应多个health monitor。有四种类型：PING、TCP、HTTP、HTTPS。每种类型就是使用相应的协议对member进行检测。

除了以上四个对象，Session Persistence和Connection Limits这两个特性也比较重要：

• Session Persistence规定session相同的连接或请求转发的行为。目前支持三种类型：

 

• • SOURCE_IP：指从同一个IP发来的连接请求被某个member接收处理；
  • HTTP_COOKIE：该模式下，loadbalancer为客户端的第一次连接生成cookie，后续携带该cookie的请求会被某个member处理
  • APP_COOKIE：该模式下，依靠后端应用服务器生成的cookie决定被某个member处理

 

• Connection Limits 这个特性主要用来抵御DDoS攻击

 

LBaaS部署方法

1. DevStack中，增加 ENABLED_SERVICES+=,q-lbaas 选项即可；

2. RDO部署： packstack --allinone --neutron-lbaas-hosts=192.168.1.10 （具体步骤参考：http://openstack.redhat.com/LBaaS）

3. 也可以使用Openstack Heat来部署LBaaS，具体见http://blog.csdn.net/lin_victor/article/details/23060467

 

LBaaS使用方法

基本的使用步骤为：

 

• 租户创建一个pool，初始时的member个数为0；
• 租户在该pool内创建一个或多个member
• 租户创建一个或多个health monitor
• 租户将health monitors与pool关联
• 租户使用pool创建vip

 

本文转自feisky博客园博客，原文链接：http://www.cnblogs.com/feisky/p/3853734.html，如需转载请自行联系原作者