【OpenStack】Grizzly中的LoadBalancer初步分析

转载：http://blog.csdn.net/lynn_kong/article/details/8528512

Grizzly中的LoadBalancer初步分析

本blog欢迎转发，但请保留原作者信息：
新浪微博：@孔令贤HW  
Blog地址：http://blog.csdn.net/lynn_kong
内容系本人学习、研究和总结，如有雷同，实属荣幸！  

在Grizzly版本中，Quantum组件引入了一个新的网络服务：LoadBalancer（LBaaS），服务的架构遵从Service Insertion框架（也是G版引入）。LoadBalancer为租户提供到一组虚拟机的流量的负载均衡，类似于Amazon的ELB。昨天（2013.1.20）Grizzly_2放出，实现10个BP，修复82个bug。大致过了下代码，目前我能识别到的更新如下：
1. 增加servicetype扩展（service insertion实现的前提条件），表示一种网络服务类型（LB，FW，VPN等），为了向后兼容，载入时会创建默认的servicetype
2. 安全组功能从Nova移植到了Quantum
3. 增加portbinding扩展，给port增加了三个属性：binding:vif_type，binding:host_id，binding:profile（这个属性是Cisco专用）
4. Ryu插件支持provider扩展
5. 增加loadbalancer扩展以实现负载均衡功能
6. 新增一个Quantum插件（Big Switch）

1.      基本流程

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

2.      概念

l  VIP
可以把一个VIP看做是具有一个虚拟IP地址和指定端口的负载均衡器，当然还有其他的属性，比如均衡算法，协议等。

l  Pool
一个pool代表一组逻辑设备（通常是同质设备），比如web服务器。负载均衡算法会选择pool中的某一member接收进入系统的流量或连接。目前一个VIP对应一个Pool。

l  Pool member
代表了后端的一个应用服务器。

l  Health monitor
一个health monitor用来检测pool内member的状态。一个pool可对应多个health monitor。有四种类型：
PING、TCP、HTTP、HTTPS。每种类型就是使用相应的协议对member进行检测。

l  Session Persistence
也就是一般我们听到的“Session粘滞”，是规定session相同的连接或请求转发的行为。目前支持三种类型：
SOURCE_IP：指从同一个IP发来的连接请求被某个member接收处理；
HTTP_COOKIE：该模式下，loadbalancer为客户端的第一次连接生成cookie，后续携带该cookie的请求会被某个member处理
APP_COOKIE：该模式下，依靠后端应用服务器生成的cookie决定被某个member处理

l  Connection Limits
这个特性主要用来抵御DoS攻击

对象关系模型：

 

3.      架构图

 截止到2013.1.22号，Grizzly_2版本仅实现了LBaaS Plugin部分，LBaaS Agent和Scheduler/Device Management正在开发。
如上图，可见LBaaS与QuantumPlugin的架构基本一致，将上层的逻辑概念与底层的实现分离。主要模块如下：
1. LBaaS Quantum Extension：处理REST API调用
2. LBaaS Quantum AdvSvc Plugin：核心Plugin之一。Quantum在Folsom版本仅支持一个Plugin，但在实现了Service Insertion之后可以运行多个服务的不同Plugin共存。
3. LBaaS Agent：同Quantum Agent一样，是部署在各个计算节点的独立进程
4. Driver：与实际的设备打交道，实现逻辑模型

4.      Scheduler/Device Management

Scheduler/Device Management是一个单独的Quantum组件，其功能主要有两个方面：
1. 实现服务的逻辑模型
2. 为了实现高级服务（Advanced Service），比如load balancers, firewalls, vpn gateways等而提供面向租户的扩展API

以创建Pool为例，流程图如下：

LBaaS Plugin收到创建pool的请求；
LBaaS Plugin在DB中新增记录，返回pool_id；
LBaaS Plugin调用Scheduler，传递service_type, pool_id, pool等参数；
Scheduler选择满足条件的device，保存device和pool的映射，将device_info返回；
Agent调用Driver，Driver将device接入租户网络，实现逻辑模型；
Agent向LBaaS通知，更新Pool在DB中的状态；