Grizzly中的LoadBalancer初步分析

  在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.