Openstack Neutron ： LBaaS v2

服务器池 Pool：服务器池内包含了多个服务器成员，同一个池内的服务器至少包含一种统一的对外服务。
服务器成员 Member：服务器成员，包含服务器的IP和端口。
监听器 Listener：监听器将持续监听指定的端口上的链接请求。一个负载均衡器中容许存在多个监听器，同时经过共享服务器池，多个监听器也能够关联到同一个服务器池。
健康监控 Health monitor：检查服务器池中成员的状态，以及服务器的加入、离开。

之因此称之为 lbaas v2，是由于Neutron的负载均衡的模型有过一次如上图的进化，在v2的版本中，neutron 对负载均衡的架构有了一次很是大的调整，v2版本变得更符合行业标准，且驱动和功能扩展变得更为简单，除此以外新版本还容许一个负载均衡器下添加多组 Listener 监听服务，以及加入了TLS。Lbaas v2没法和lbaas v1同时运行，开启lbaas v2须要中止lbaas v1。

改进后的LBaaS v2通过了更为全面的测试，而且加入了更多的HTTP层代理的特性。并开始支持Active-Standby部署模式，后续版本中将进一部支持Active-Active。新版能够说是负载均衡架构和功能的一次飞跃。

负载均衡概念

服务器池 Pool

服务器池即后端一组提供服务的实例，每一个成员都是一个IP地址+4层的端口。例如，常见的提供web服务的实例，在服务器池中表示为：192.168.1.1：80。提供的服务不一样则端口号也不相同。池内的服务器都统一对外提供某一种服务。例如：

服务器 1：192.168.1.1：80

服务器 2：192.168.1.3：80

服务器 3：192.168.1.4：80

负载均衡器经过 VIP 统一对前端提供服务，用户向虚拟IP发起链接请求，监听器监听到对应端口的请求后，经过负载均衡算法将请求转发到后端服务池中的一个成员上。而后成员对用户请求的资源进行响应，这样整个过程对于用户来讲是透明的。包括后端服务器的增长、减小以应对用户规模的增缩，都不会对已经创建的链接产生影响。

监听器 Listener

监听器即一个不断在端口上检查链接请求的进程，一旦发现客户端的链接请求，则会按照你设定的规则将链接请求转发给后端的服务器池。一个监听器关联一个端口，如：HTTP(80)、HTTPS（443），当使用HTTPS，则须要上传用于https 加密和解密的证书到监听器中。

L7 转发策略 l7 policy

l7策略转发流程

LBaaS v2 支持L7的转发策略，每一个监听器上均可以配置多条转发策略（L7 Policy）。策略由由规则（rule）和操做组成，相似 if…then…的条件语句，当有流量匹配了 rule 的条件时，就按照策略中的操做转发。不然就继续向下匹配。规则能够匹配HTTP请求中的特殊字段或URL，这给业务带来了极大的灵活性。

rule 支持的匹配项包括：

Hostname，L7 rule 支持匹配HTTP/1.1 请求中的host字段
path，HTTP URI 中路径的部分
file_type，请求的文件类型
header，HTTP 头中其余字段
cookie，cookie的值

须要注意的是，同一个policy下的rule是“与”的关系，即策略下的全部rule都匹配的状况下，才会按照策略的操做转发。其中任何一条不匹配都会跳过该策略向下匹配。

匹配的算法包括：

regex，正则表达式，非的意思
starts_with，字符串开头
ends_with，字符串结尾
contains，字符串中包含的值
equal_to，等于

L7 policy 的操做支持：

block，请求将直接被拒绝；
redirect_to_url，重定向用户的url；
redirect_to_pool，重定向到后端特定的主机池内。

例如：能够在监听器上添加两条rule，一条匹配HTTP请求中 file_type 包含：jgp、png、gif、zip、txt 的请求转发给 image pool。另外一条一条匹配URI中 path 以“*/login”开头的请求转发给APP pool。

这样就简单的实现了网站上静态内容（图片）与动态内容（用户登陆）的分流处理，这能在不改变应用架构的状况下，减轻web服务的负载。对于云原生应用来讲，这样的功能很是重要。

L7策略配置示例以下：

neutron --policy policy1 lbaas-create-l7policy --name "policy1" --description "My Description" --listener "listener1" --action redirect_to_pool --pool "pool1" --position 1 （建立L7策略，命名为“policy1”描述为“lb策略”，并关联 “listener 1”，策略的动做是将匹配的流量转发到“pool1”)
neutron lbaas-create-l7rule rule1 --rule-type path --compare-type starts_with --value "/api" --policy policy (在“policy 1”下添加一条规则，匹配全部URL中以 “/api”开头的请求)

可见到 LBaaS v2可根据业务需求制定出很是灵活的7层转发策略。

负载均衡算法 Algorithms

自己Neutron支持的负载均衡算法包括：轮询、最少链接、源IP。

轮询 Round robin，是最广泛的算法，每当有一个新的请求来临，负载均衡器都会按顺序选择服务器池中的一台设备来响应。有点相似音乐播放软件的列表循环。这种模式下服务器池中的每个服务器都能均匀地分配到相同的访问请求数，而不会管服务器繁忙程度、服务器配置的高低。比较适用于服务器池内的服务器配置相同、用户访问习惯相同的业务。加权轮询是改进的负载均衡算法，当后端服务器池中设备配置高低不一时，可根据服务器处理能力的高低分配服务器的权值，权值高的服务器会被分配更多的用户请求。
最少链接算法 Least connections，负载均衡器收到新的请求时，都会从当前服务器池中挑选一个当前并发链接数最少的服务器来负责。最少链接算法考虑的服务器的实时负载状况，尽可能保证了任务分配的平均，防止单个服务器超出负载，可是当后端服务器池中存在高处理能力的服务器时，这个处理能力高的设备始终没法得到更多的工做负载，存在性能的浪费。最少链接算法有优化后的加权最小链接算法
IP hash，负载均衡器在收到主机的链接请求后，会根据数据包的源IP地址字段的hash值，同时按照轮询的方式为客户端分配主机，当负载均衡器再次收到同一IP的请求时，则会按照以前的记录为客户端分配上次创建链接的主机。这样保证了当同一个IP的用户，屡次独立的访问都能由同一台服务器来处理，适用于服务器须要临时记录或保存客户信息的应用中。

健康监测 Monitor

健康检测的机制是指是负载均衡器经过按期的心跳信号检测服务器池中的服务器运行状态，从而排除掉后端故障的主机，保证服务总体正常。

Neutron支持的健康检测方式包括 ICMP、TCP、HTTP几种。

ICMP是最简单的，经过ping 和echo的方式，看根据服务器是否响应。只要服务器操做系统TCP/IP协议栈运行正常，网卡不出问题，服务器到负载均衡之间的网络正常，ICMP的方式都起到良好的做用，但以上状况都不能表明服务器上面运行的应用是正常的。
TCP是4层的检测方式，相比ICMP、TCP会请求主机的特定端口，看特定的端口可否正常响应。
HTTP的方式则更进一筹，会经过get特定的页面，根据HTTP的返回代码来判断应用是否正常。

健康监测的指标越精确，越能反映服务的实际响应状况，若是是web服务，最好是使用HTTP的方式，这样检测结果更可信。

会话保持 Session persistence

会话保持功能经常使用于有状态的服务中，好比服务器经过session来维护用户链接的状态，由于session保存在服务器本地，若是不断地经过网络来在服务器池中同步session的话，会消耗服务器的带宽和处理能力，因此这时会选择使用负载均衡器的会话保持功能。它能保证同一个用户的请求会被发送到同一台服务器。

Lbaas v2支持的会话保持的类型为：

源IP：源IP即IP hash 算法，根据IP地址来识别客户。负载均衡器在收到请求后会计算数据包头源IP地址的hash值，并按照轮询的方式给该客户端分配一个服务器，同时将二者的对应关系记录到表中，当再次收到同一源IP发来的请求时，则查找到以前的服务器进行转发。可是当客户端经过NAT、或代理的方式上网时，源IP的方式就可能致使多个客户端被分配到同一个主机。顺便一提，去年在公司用12306在高峰期抢车票时，刚打开网站就被提示“您的操做频率过快”，即颇有可能12306后端也是判断同一个IP提交的访问请求过多，从而误把新接入用户看成了已访问过的用户。
HTTP_cookie：该模式下会根据浏览器中缓存的cookie来识别用户，cookie里面通常都缓存了计算机信息和浏览器的信息以及用户认证的信息。Lbaas v2中负载均衡器会在服务器第一次返回给客户端的回应中插入“SRV”的cookie值，标识了回复的服务器。当再次收到客户端发起的HTTP请求时，lbaas v2会找出 cookie中的"SRV"字段，并剥离掉后转发给以前回复的服务器。HTTP_cookie 的问题在于，有可能一些用户会禁用掉浏览器上的cookies，这种状况下基于cookies的会话保持就将失效了。
App_cookie：该模式下须要在负载均衡器中预先定义各个后端中设置的cookie，并将对应关系存储到表中，当收到客户端的请求时，检查请求中是否有预先定义的cookie，若是有，则转发到对应的服务器。

虽然当今互联网应用中经过token来实现用户的识别和鉴权已经比较常见了，但负载均衡的会话保持可以很好弥补经过 seesion 识别用户的应用的不足。可是基于cookie的会话保持没法支持服务器直接返回的部署模式，即服务器返回给用户的流量不通过负载均衡器，而是直接上行转发出去。因此在某些大流量的应用中，负载均衡器可能成为性能的瓶颈。

非对称流量中，服务器直接返回到客户端，上行流量不通过负载均衡器，LBaaS v2 暂时还不支持这种部署模式。

实现

Neutron中 LBaaS v2有两种实现方式，

一是：使用HAproxy做为负载均衡器，在网络节点上运行LBaaS agent，agent会完成节点上的Haproxy 的建立和配置工做。这也是目前较为成熟的使用方式。

二是：使用Octavia 做为负载均衡器，Octavia是在LBaaS v2中加入到openstack中的，官方对它的定位不是要代替HAproxy在neutron中的地位，而是做为一个可选开源的LB服务提供者，相似LVS+F5等。Octavia的架构是全新设计的，并且在一开始就立志成为运营级的负载均衡解决方案。只是目前Octavia仍是远谈不上成熟，官方推荐只在Devstack中使用。

HAproxy + keepalive

比较经常使用的开源负载均衡器有LVS、Nginx、HAproxy，其中LVS只能作到四层的负载均衡，即只能依据IP+端口的方式进行转发，不支持L7的转发策略，Nginx不只能作Web服务器，同时也能做为负载均衡器使用；HAproxy 和Nginx都能基于L7策略进行转发。LVS也常常和HAproxy、Nginx混用，在大流量的集群中，先由LVS将流量分摊到不一样的Nginx/HAproxy集群，再由Nginx/HAproxy作L7转发。除此以外Neutron也支持Ctrix、F五、Radware等公司的插件，从而经过专用的负载均衡硬件来实现。

LBaaS v2的经典实现方式就是在网络节点上部署HAproxy+Keepalive 实现负载均衡服务。其中HAproxy提供L7的负载均衡，Keepalive用于实现高可用方案。

HAproxy

HAproxy可以为服务器池提供7层的负载均衡功能，即能根据HTTP请求头中的内容来执行负载均衡算法。并且做为开源软件，被普遍使用。

1.启用lbaas v2首先须要修改neutron的配置文件，加入插件： /etc/neutron/neutron.conf

service_plugins = [existing service plugins],neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2

 

2.在lbaas的配置文件中添加lbaas v2： /etc/neutron/neutron_lbaas.conf

service_provider = LOADBALANCERV2:Haproxy:neutron_lbaas.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default

 

3.选择2层设备的驱动： /etc/neutron/lbaas_agent.ini

[DEFAULT]
interface_driver = openvswitch

根据实际，选择 ovs 或者 linux bridge，须要与节点上的2层设备类型匹配。

 

4.开启数据库迁移

neutron-db-manage --subproject neutron-lbaas upgrade head

 

5.启动 lbaas v2 agent。

neutron-lbaasv2-agent \
--config-file /etc/neutron/neutron.conf \
--config-file /etc/neutron/lbaas_agent.ini

来自 <https://docs.openstack.org/ocata/networking-guide/config-lbaas.html#configuring-lbaas-v2-with-octavia>

随后便可以建立负载均衡器：

1.建立负载平衡器，指定负载平衡的名称和关联的子网名。需指定与虚拟机所在的子网。

neutron lbaas-loadbalancer-create --name my-lb  private-subnet


2.为新负载平衡器建立侦听器。

neutron lbaas-listener-create \    //添加监听器
--loadbalancer my-lb \   //关联以前建立的负载均衡器
--protocol HTTP  \     //选择监听器协议，TCP\HTTP\HTTPS
--protocol-port  80 \     //选择监听器对外监听的端口（即向用户开放的端口）
--name webservice-listener \    //设置监听器名称



3.建立 LBaaS 服务器池。

neutron lbaas-pool-create \
--lb-algorithm  ROUND_ROBIN \  //选择负载均衡算法,支持上文中提到的轮询、最少链接、IP hash等
--listener LISTENER_1_NAME \     //关联监听器
--protocol HTTP \     //服务器池使用的协议
--name LB_POOL_1      //服务器名称
 

4.将服务器实例添加到建立的 LBaaS 池中。

neutron lbaas-member-create  \
--subnet <subnet-id> --address <server 1 IP> \    //将后端服务器添加到地址池中
--protocol-port 80 <pool name>       //后端服务器上服务所使用的端口,能够与前端的端口不一致

neutron lbaas-member-create  \   
--subnet <subnet-id> --address <server 2 IP> \
--protocol-port 80 <pool name>


5.设置Health monitor指标。

neutron lbaas-healthmonitor-create \
--delay DELAY_IN_SECONDS     //设置心跳检测发送到服务器成员的周期，单位为秒。需避免过于频繁的心跳检测，以及检测不及时的状况出现，达到平衡。对可用性要求高能够设置为3～5秒，

--type [HTTP | TCP]       //选择心跳检测的协议，若是TCP则只检测服务器上端口是否开启,HTTP则支持检测web服务的状态。当选择HTTP时，能够指定http的方法，默认是 get 一个特定的页面。同时还能指定服务器正常响应对应的HTTP状态码，如返回200时，表明web服务正常，200之外的值，如40四、408等则表明异常。可经过 expected_codes  设置。url_path 则用来指定health monitor 请求的页面。

--max-retries NUMBER \      //设置在改变服务器可用状态以前，等待服务器的应答的次数。假设为n，若是是n次未响应，则切换为inactive，以后若是n次正常响应，则切换为active。推荐为 3
--timeout TIMEOUT_IN_SECONDS     //设置超时的时长，当超过该时长服务器都没有回应，则认为服务器这次心跳监测为故障。

--pool LBAAS_POOL       //将健康监测配置关联到服务器池。


一个服务器从出现故障，到负载均衡器发现并标记为不可用，再也不为其分配流量，这其中须要的时间为：Time = delay *(max-retries -1) + timeout   (*忽略从服务器发生故障到下一次健康监测中间的延时)，在这个时间段内，负载均衡器都会为服务器分配流量。


6.分配浮动IP，为负载均衡器分配浮动IP与为云主机分配浮动IP是同样的，都是在fip的命名空间中为指定一个公网地址到内网地址的映射。这样外部的用户就能够经过公网地址直接访问到服务器池内的主机。若是做为内部使用的负载均衡器，则不须要分配浮动ip。

neutron floatingip-associate FLOATINGIP_ID LOAD_BALANCER_PORT_ID

最后不要忘记设置防火墙和安全组，容许外部流量访问负载均衡器的VIP和开启的listener端口。

Keepalive

HAproxy的 Active/Standby 部署模式就是经过keepalive 来实现的。keepalive的核心是vrrp，openstack的HA中大量使用了vrrp协议来提供高可用，包括以前L3中提到的路由器的高可用。负载均衡器的vip将会配置在vrrp的 vip上，对外提供服务。同时vrrp会经过心跳检测负载均衡主备设备运行的状态，并实现vip的切换。

Octavia中还有一个假主备模式，即负载均衡在实际中为单节点部署，不过Octavia Controller内的Health manager会频繁检测负载均衡节点的运行状态，一旦发现负载均衡器故障，则从备用的负载均衡器中选一个代替故障的设备，并套用原来的配置。

Octavia

Octavia项目是在 Liberty 版本中随着LBaaS v2一同发布，其amphorea模块是实现负载均衡功能的模块，支持部署在虚拟机、容器、裸机上，为云上的租户提供负载均衡服务。

上图是Octavia的架构，neutron原生集成了Octavia的驱动，能够直接经过Neutron的接口来完成Octavia的管理。同时Octavia也支持独立工做，其拥有独立的数据库，租户的配置信息不只会保存在Neutron的数据库中，也会保存在Octavia的独立数据库中。（同时按照网上的部署经验，octavia和neutron的数据库同步是一个较大的问题）

Octavia 0.8版本中的amphorae 镜像是一台运行了HAproxy的ubuntu虚拟机，已经支持RH Linux、Centos、Fedora。将来还将支持以容器和裸金属的方式部署。

除此以外是Octavia的核心Controller，它包含4个组件：

API Controller：运行Octavia 的API，并接受外部的调用申请，而后经过消息总线传送给worker。
Controller Worker：负责执行API的各类操做，包括对nova、neutron接口的调用，以实现amphorae虚拟机的生命周期管理、建立端口、建立外部网络等资源，除此以外还有SSL证书、工做流等等功能管理。都由worker来一一实现。
Health manager：用于监控amphorae的运行状态，并执行amphorae的故障切换。
Housekeeping manager：用于删除无用的数据库记录，管理备用池和安全证书等。

用户在openstack环境中建立负载均衡服务时，建立amphorea虚拟机、端口、安全组等操做，这些都是由Octavia Controller自动完成，用户不可见，用户能见到的只有部署完成以后的Octavia的配置项和对应的网络端口。

service_provider = LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default

Octavia的建立和配置命令与建立HAproxy的命令是彻底同样的，配置好插件后 Octavia API Controller 将执行neutron指令，并完成amphorae的建立和配置等工做。

可见到Octavia项目目标是搭建一个完善的本地负载均衡管理平台，目前它是以虚拟机的方式提供服务，未来计划可以对云主机、容器、甚至裸机部署负载均衡服务，并支持Active、Active部署方式。

http://lingxiankong.github.io/blog/2016/03/30/octavia/

http://502245466.blog.51cto.com/7559397/1303506

Load Balancing as a Service : Liberty and Beyond

负载均衡自己的技术并不复杂，也发展得较为成熟，但现在负载均衡在各类云上扮演着很是重要的角色，各个云上与部署解决方案中都能看到它的身影。究其缘由是其给租户的应用带来的弹性和可用性。云的租户能够在前端用户彻底无感知的状况下，按负载增删后台服务器的数量，并实现服务的高可用，这很是符合云“按需使用”“分布式高可用服务”的理念。因此当服务的弹性伸缩和高可用性成为云计算的基本属性时，负载均衡器就开始在云上扮演不可替代的角色，能够说，不支持负载均衡的云不能称之为云。而传统的硬件负载均衡器不管是在可靠性、扩展性、可编程性、成本等方面都没法知足云供应商的需求。

Otavia的加入也能够说是openstack社区很清楚地看到了这一趋势，并立志将负载均衡单独拿出neutron做为一个重要项目来对待。从Octavia支持的部署模式就能看出这一项目的野心。或许它将来将成为一个跨虚拟机、容器、裸机的统一负载均衡服务。