Openstack Mitaka 负载均衡 LoadBalancerv2

​ 最近研究了一下Openstack负载均衡，yum源和源码级别的安装都尝试成功了。网上有不少文章都是LoadBalancerv1，这个已经被放弃了。因此写一下本身是如何使用LoadBalancerv2。固然在介绍以前仍是从负载均衡基础知识开始吧。（Mitaka版本的LoadBalancerv2）

负载均衡的概念和分类？

负载均衡（Load Balancing）是未来访的网络流量在运行相同应用的多个服务器之间进行分发的一种核心网络服务。它的功能由负载均衡器（load balancer）提供。负载均衡器能够是一个硬件设备，也能够由软件实现。它充当反向代理，在多个服务器之间分发网络或者应用流量。它经常使用来增长应用的访问容量（并发用户数）和可靠性，它也会经过下降服务器的负载来提升应用的整体性能。

负载均衡器的分类

负载均衡器通常能够分为两类：第4层负载均衡器和第7层负载均衡器。

第 4 层负载平衡器：基于网络和传输层协议（IP，TCP，FTP，UDP等）来均衡负载。

第7层的负载均衡器：基于应用层协议好比 HTTP, SMTP, SNMP, FTP, Telnet 等均衡负载。好比对 HTTP 来讲，第七层的负载均衡器能根据应用的特定数据好比 HTTP 头，cookies 或者应用消息中的数据来作进一步的请求分发。

负载分发算法

​ 两种类型的负载均衡器都能接收请求，而后根据特定的算法将请求分发到特定的服务器。一些行业标准的算法是：

​ 轮询 (Round robin)：轮流分发到各个（活动）服务器
​ 加权轮循 (Weighted round robin)：每一个服务器有必定的加权（weight），轮询时考虑加权。
​ 最少链接 (Least connections)：转发到有最少链接数的服务器
​ 最少响应时间 (Least response time)：转发到响应时间最短的服务器

 

可靠性和可用性

​ 负载均衡器经过监控应用的健康状态来确保可靠性和可用性，而且只转发请求到能及时作出响应的服务和应用。

Session persistence （会话保持）

​ 用户(浏览器)在和服务端交互的时候，一般会在本地保存一些信息，而整个过程叫作一个会话(Session)并用惟一的Session ID进行标识。会话的概念不只用于购物车这种常见状况，由于HTTP协议是无状态的，因此任何须要逻辑上下文的情形都必须使用会话机制，此外HTTP客户端也会额外缓存一些数据在本地，这样就能够减小请求提升性能了。若是负载均衡可能将这个会话的请求分配到不一样的后台服务端上，这确定是不合适的，必须经过多个backend共享这些数据，效率确定会很低下，最简单的状况是保证会话一致性——相同的会话每次请求都会被分配到同一个backend上去。

​ 会话保持表示在一个会话期间，转发一个用户的请求到同一个后端服务器。这对购物车或者付款类的请求很是重要。 经常使用的方法包括：

​ Source IP：相同来源的请求转发到同一个服务器
​ HTTP Cookie：该模式下，loadbalancer 为客户端的第一次链接生成 cookie，后续携带该 cookie 的请求会被某个 member 处理
​ APP Cookie：该模式下，依靠后端应用服务器生成的 cookie 决定被某个 member 处理

负载均衡的实现方式？

http重定向

​ 当http代理（好比浏览器）向web服务器请求某个URL后，web服务器能够经过http响应头信息中的Location标记来返回一个新的URL。这意味着HTTP代理须要继续请求这个新的URL，完成自动跳转。

缺陷：
一、吞吐率限制
​ 主站点服务器的吞吐率平均分配到了被转移的服务器。现假设使用RR（Round Robin）调度策略，子服务器的最大吞吐率为1000reqs/s，那么主服务器的吞吐率要达到3000reqs/s才能彻底发挥三台子服务器的做用，那么若是有100台子服务器，那么主服务器的吞吐率可想而知得有大？相反，若是主服务的最大吞吐率为6000reqs/s，那么平均分配到子服务器的吞吐率为2000reqs/s，而现子服务器的最大吞吐率为1000reqs/s，所以就得增长子服务器的数量，增长到6个才能知足。

二、重定向访问深度不一样
​ 有的重定向一个静态页面，有的重定向相比复杂的动态页面，那么实际服务器的负载差别是不可预料的，而主站服务器却一无所知。所以整站使用重定向方法作负载均衡不太好。

​ 咱们须要权衡转移请求的开销和处理实际请求的开销，前者相对于后者越小，那么重定向的意义就越大，例以下载。你能够去不少镜像下载网站试下，会发现基本下载都使用了Location作了重定向。

DNS负载均衡

​ DNS负责提供域名解析服务，当访问某个站点时，实际上首先须要经过该站点域名的DNS服务器来获取域名指向的IP地址，在这一过程当中，DNS服务器完成了域名到IP地址的映射，一样，这样映射也能够是一对多的，这时候，DNS服务器便充当了负载均衡调度器，它就像http重定向转换策略同样，将用户的请求分散到多台服务器上，可是它的实现机制彻底不一样。

​ 相比http重定向，基于DNS的负载均衡彻底节省了所谓的主站点，或者说DNS服务器已经充当了主站点的职能。但不一样的是，做为调度器，DNS服务器自己的性能几乎不用担忧。由于DNS记录能够被用户浏览器或者互联网接入服务商的各级DNS服务器缓存，只有当缓存过时后才会从新向域名的DNS服务器请求解析。也说是DNS不存在http的吞吐率限制，理论上能够无限增长实际服务器的数量。

缺陷：
一、没有用户能直接看到DNS解析到了哪一台实际服务器，加服务器运维人员的调试带来了不便。
二、策略的局限性。例如你没法将HTTP请求的上下文引入到调度策略中，而在前面介绍的基于HTTP重定向的负载均衡系统中，调度器工做在HTTP层面，它能够充分理解HTTP请求后根据站点的应用逻辑来设计调度策略，好比根据请求不一样的URL来进行合理的过滤和转移。
三、若是要根据实际服务器的实时负载差别来调整调度策略，这须要DNS服务器在每次解析操做时分析各服务器的健康状态，对于DNS服务器来讲，这种自定义开发存在较高的门槛，更况且大多数站点只是使用第三方DNS服务。
四、DNS记录缓存，各级节点的DNS服务器不一样程序的缓存会让你晕头转向。
五、基于以上几点，DNS服务器并不能很好地完成工做量均衡分配，最后，是否选择基于DNS的负载均衡方式彻底取决于你的须要。

 

反向代理负载均衡

​ 几乎全部主流的Web服务器都热衷于支持基于反向代理的负载均衡。它的核心工做就是转发HTTP请求。
相比前面的HTTP重定向和DNS解析，反向代理的调度器扮演的是用户和实际服务器中间人的角色：
一、任何对于实际服务器的HTTP请求都必须通过调度器
二、调度器必须等待实际服务器的HTTP响应，并将它反馈给用户（前两种方式不须要通过调度反馈，是实际服务器直接发送给用户）

特性：
一、调度策略丰富。例如能够为不一样的实际服务器设置不一样的权重，以达到能者多劳的效果。
二、对反向代理服务器的并发处理能力要求高，由于它工做在HTTP层面。
三、反向代理服务器进行转发操做自己是须要必定开销的，好比建立线程、与后端服务器创建TCP链接、接收后端服务器返回的处理结果、分析HTTP头部信息、用户空间和内核空间的频繁切换等，虽然这部分时间并不长，可是当后端服务器处理请求的时间很是短时，转发的开销就显得尤其突出。例如请求静态文件，更适合使用前面介绍的基于DNS的负载均衡方式。
四、反向代理服务器能够监控后端服务器，好比系统负载、响应时间、是否可用、TCP链接数、流量等，从而根据这些数据调整负载均衡的策略。
五、反射代理服务器可让用户在一次会话周期内的全部请求始终转发到一台特定的后端服务器上（粘滞会话），这样的好处一是保持session的本地访问，二是防止后端服务器的动态内存缓存的资源浪费。

IP层负载均衡LVS-NAT

​ 咱们须要在HTTP层面如下实现负载均衡，这些负载均衡调度器的工做必须由Linux内核来完成，由于咱们但愿网络数据包在从内核缓冲区进入进程用户地址空间以前，尽早地被转发到其余实际服务器上。并且正由于能够将调度器工做在应用层之下，这些负载均衡系统能够支持更多的网络服务协议，好比ftp，smtp，dns，以及流媒体和VoIP等应用。

​ DNAT： 反向NAT，将实际服务器放置在内部网络，而做为网关的NAT服务器未来自用户端的数据包转发给内部网络的实际服务器(须要修改的是数据包的目标地址和端口)。比较著名的例子是LVS。NAT调度器的吞吐率很高是由于其在内核中进行请求转发的较低开销。

可是NAT服务器的带宽却成为了瓶颈。幸运的是，LVS提供了另外一种负载均衡的方式，那就是直接路由。

直接路由LVS-DR

​ 不一样于NAT机制，直接路由的负载均衡调度器工做在数据链路层上，简单地说，它经过修改数据包的目标mac地址，将数据包转发到实际服务器上，而且重要的是，实际服务器的响应数据包将直接发送给客户端，不通过调度器。适用于视频网站（响应的数据包远远超过请求的数据包）。对于LVS-DR，一旦调度器失效，你能够立刻将LVS-DR切换到DNS-RR模式

常见的开源软件负载均衡器？

​ 负载均衡器 目前有2种，一种是经过硬件来进行进行，常见的硬件有比较昂贵的NetScaler、F五、Radware和Array等商用的负载均衡器，它的优势就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，因此对于规模较小的网络服务来讲暂时尚未须要使用；另一种就是相似于LVS/HAProxy、Nginx的基于Linux的开源免费的负载均衡软件策略,这些都是经过软件级别来实现，因此费用很是低廉。

Nginx、LVS及HAProxy是目前最经常使用的开源软件负载均衡器。

LVS

LVS：使用集群技术和Linux操做系统实现一个高性能、高可用的服务器，它具备很好的可伸缩性（Scalability)、可靠性（Reliability)和可管理性（Manageability)。

LVS的特色是：

一、抗负载能力强、是工做在网络4层之上仅做分发之用，没有流量的产生，这个特色也决定了它在负载均衡软件里的性能最强的；

二、配置性比较低，这是一个缺点也是一个优势，由于没有可太多配置的东西，因此并不须要太多接触，大大减小了人为出错的概率；

三、工做稳定，自身有完整的双机热备方案，如LVS+Keepalived和LVS+Heartbeat，不过咱们在项目实施中用得最多的仍是LVS/DR+Keepalived；

四、无流量，保证了均衡器IO的性能不会收到大流量的影响；

五、应用范围比较广，能够对全部应用作负载均衡；

六、软件自己不支持正则处理，不能作动静分离，这个就比较遗憾了；其实如今许多网站在这方面都有较强的需求，这个是Nginx/HAProxy+Keepalived的优点所在。

七、若是是网站应用比较庞大的话，实施LVS/DR+Keepalived起来就比较复杂了，特别后面有Windows Server应用的机器的话，若是实施及配置还有维护过程就比较复杂了，相对而言，Nginx/HAProxy+Keepalived就简单多了。

Nginx

Nginx的特色是：

一、工做在网络的7层之上，能够针对http应用作一些分流的策略，好比针对域名、目录结构，它的正则规则比HAProxy更为强大和灵活，这也是许多朋友喜欢它的缘由之一；

二、Nginx对网络的依赖很是小，理论上能ping通就就能进行负载功能，这个也是它的优点所在；

三、Nginx安装和配置比较简单，测试起来比较方便；

四、也能够承担高的负载压力且稳定，通常能支撑超过几万次的并发量；

五、Nginx能够经过端口检测到服务器内部的故障，好比根据服务器处理网页返回的状态码、超时等等，而且会把返回错误的请求从新提交到另外一个节点，不过其中缺点就是不支持url来检测；

六、Nginx仅能支持http和Email，这样就在适用范围上面小不少，这个它的弱势；

七、Nginx不只仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的Web应用服务器。LNMP如今也是很是流行的web架构，大有和之前最流行的LAMP架构分庭抗争之势，在高流量的环境中也有很好的效果。

八、Nginx如今做为Web反向加速缓存愈来愈成熟了，不少朋友都已在生产环境下投入生产了，并且反映效果不错，速度比传统的Squid服务器更快，有兴趣的朋友能够考虑用其做为反向代理加速器。

HAProxy

HAProxy的特色是：

一、HAProxy是支持虚拟主机的，之前有朋友说这个不支持虚拟主机，我这里特此更正一下。

二、可以补充Nginx的一些缺点好比Session的保持，Cookie的引导等工做

三、支持url检测后端的服务器出问题的检测会有很好的帮助。

四、它跟LVS同样，自己仅仅就只是一款负载均衡软件；单纯从效率上来说HAProxy更会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。

五、HAProxy能够对Mysql读进行负载均衡，对后端的MySQL节点进行检测和负载均衡，不过在后端的MySQL slaves数量超过10台时性能不如LVS，因此我向你们推荐LVS+Keepalived。

六、HAProxy的算法如今也愈来愈多了，具体有以下8种：

roundrobin，表示简单的轮询，这个很少说，这个是负载均衡基本都具有的；

static-rr，表示根据权重，建议关注；

leastconn，表示最少链接者先处理，建议关注；

source，表示根据请求源IP，这个跟Nginx的IP_hash机制相似，咱们用其做为解决session问题的一种方法，建议关注；

ri，表示根据请求的URI；

rl_param，表示根据请求的URl参数’balance url_param’ requires an URL parameter name；

hdr(name)，表示根据HTTP请求头来锁定每一次HTTP请求；

rdp-cookie(name)，表示根据据cookie(name)来锁定并哈希每一次TCP请求。

基本的负载均衡场景有3种：

Two-Arm (or sometimes called In-Line)（双臂）模式
One-Arm（单臂）模式
Direct Server Response模式

Two-Arm (or sometimes called In-Line)（双臂）模式

双臂模式有 switched mode（“bridge mode” or “transparent mode”） 和routed mode两种，routed mode要优于switched mode，实际生产环境也没有switched mode方式。

对于routed mode模式来讲，As you can agree, the Load-Balancer is also a router between the “Front End” and “Back End” networks. As such, he can simply do destination IP NAT in client request coming to the load-balanced virtual IP and forward the packet to one of the servers in server farm. During this proces, the destination physical server is chosen by the load-balancing algorithm.Return traffic is going back via the Load-Balancer and the source IP is again changed to the virtual load-balanced IP in the response to the Client.

One-Arm（单臂）模式

​ the Load-Balancer is using only one interface and this interface is on the same L2 network with all the servers.

​ The traffic that the client initializes will get to the Load-Balancer that has the virtual load-balanced IP. The load-sharing algorithm will pick a physical server to which the Load-Balancer will forward the traffic with destination IP NATed to the physical IP of the server and forward it out the same interface towards the physical server.BUT the Load-balancer also needs to do source IP nat so that the server reply will go back from the server to the Load-Balancer and not directly back to the Client, who is not expecting a reply directly from physical server IP. From the physical servers perspective, all the traffic is coming from Load-Balancer

 

Direct Server Response (or sometimes called Direct Server Return)

​ As we hopefully all know, switches learn about MAC addresses as they see frames coming on ports with source MACs. Also imagine that we have a router that has to know the MAC address of the Load-Balanced IP on the last L3 hop. With the picture below, you can already spot the “trick” this scenario tries to present here once you notice the disabled ARP on physical servers

Direct Server Response (or sometimes called Direct Server Return)

​ As we hopefully all know, switches learn about MAC addresses as they see frames coming on ports with source MACs. Also imagine that we have a router that has to know the MAC address of the Load-Balanced IP on the last L3 hop. With the picture below, you can already spot the “trick” this scenario tries to present here once you notice the disabled ARP on physical servers

In this scenario, Load-balancer only sees the incoming part of client-server traffic and all the returning traffic from physical servers is coming directly back to the client IP. The biggest advantages of this solution is that there is no NAT and the Load-Balancer throughput is only used in one way, so less performance impact for the Load-Balancer system. Disabling ARP on a physical server is not a difficult task.

​ Disadvantages however are that you have to manually configure the Load-Balancer with all the server MAC addresses and might be more difficult to troubleshoot with only one way traffic seen by the Load-Balancer on the whole L2 segment.

LoadBalancerv2初体验？

1.部署

咱们假设LoadBalancerv2服务在网络节点启动，以yum源的方式安装。源码是：

https://github.com/openstack/neutron-lbaas/tree/stable/mitaka

在控制节点(neutron-server)操做以下:

yum install openstack-neutron-lbaas
cd /etc/neutron/
#1.3编辑neutron.conf文件
service_plugins =router, neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2
#1.4 编辑lbaas_agent.ini 文件
[DEFAULT]
interface_driver =neutron.agent.linux.interface.OVSInterfaceDriver
ovs_use_veth = True
device_driver = neutron_lbaas.drivers.haproxy.namespace_driver.HaproxyNSDriver
[haproxy]
user_group =haproxy
#1.5 编辑neutron_lbaas.conf文件
service_provider =LOADBALANCERV2:Haproxy:neutron_lbaas.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default
#而后执行
neutron-db-manage --subproject neutron-lbaas upgrade head
systemctl restart neutron-server

　　

在网络节点操做以下：分布式的状况下能够用做计算节点好比L2模式下

yum install haproxy
yum install openstack-neutron-lbaas
cd /etc/neutron/
#1.4 编辑neutron.conf文件
service_plugins =router, neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2
#1.5 编辑lbaas_agent.ini 文件
[DEFAULT]
interface_driver =neutron.agent.linux.interface.OVSInterfaceDriver
ovs_use_veth = True
device_driver = neutron_lbaas.drivers.haproxy.namespace_driver.HaproxyNSDriver
[haproxy]
user_group =haproxy
#1.6 编辑neutron_lbaas.conf文件
service_provider =LOADBALANCERV2:Haproxy:neutron_lbaas.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default
#1.7启动服务
systemctl start neutron-lbaasv2-agent.service

　　

另外能够安装前端界面

1.8安装neutron-lbaas-dashboard
这个是在openstack_dashboard安装的节点，通常是controller节点

git clone https://git.openstack.org/openstack/neutron-lbaas-dashboard
cd neutron-lbaas-dashboard
python setup.py install
cp neutron_lbaas_dashboard/enabled/1480project_loadbalancersv2_panel.py /usr/share/openstack-dashboard/openstack_dashboard/local/enabled/
systemctl restart httpd.service memcached.service

　　

2.建立负载均衡

Load balancer
The load balancer occupies a neutron network port and has an IP address assigned from a subnet.
Listener
Load balancers can listen for requests on multiple ports. Each one of those ports is specified by a listener.
Pool
A pool holds a list of members that serve content through the load balancer.
Member
Members are servers that serve traffic behind a load balancer. Each member is specified by the IP address and port that it uses to serve traffic.
Health monitor
Members may go offline from time to time and health monitors divert traffic away from members that are not responding properly. Health monitors are associated with pools.
因为lbaas dashboard有些问题，因此在后台用命令行建立， dashboard可显示，但不能任何操做

[root@controller ~]# source admin-openrc.sh

[root@controller ~]# neutron subnet-list

建立loadbalancer
[root@controller ~]# neutron lbaas-loadbalancer-create –name lb1 96f0db98-45fb-48ef-afae-808425fbb2bc
添加lbaas-listener
[root@controller ~]# neutron lbaas-listener-create –loadbalancer lb1 –protocol HTTP –protocol-port 80 –name listener1
建立pool
[root@controller ~]# neutron lbaas-pool-create –lb-algorithm ROUND_ROBIN –listener listener1 –protocol HTTP –name pool1
添加member
[root@controller ~]# neutron lbaas-member-create –subnet 96f0db98-45fb-48ef-afae-808425fbb2bc –address 172.16.1.4 –protocol-port 80 pool1
[root@controller ~]# neutron lbaas-member-create –subnet 96f0db98-45fb-48ef-afae-808425fbb2bc –address 172.16.1.5 –protocol-port 80 pool1
[root@controller ~]# neutron lbaas-member-create –subnet 96f0db98-45fb-48ef-afae-808425fbb2bc –address 172.16.1.6 –protocol-port 80 pool1
添加监控
[root@controller ~]# neutron lbaas-healthmonitor-create –delay 3 –type HTTP –max-retries 3 –timeout 3 –pool pool1

[root@controller ~]# neutron lbaas-loadbalancer-show lb1

3.简单验证：

咱们对member成员进行模拟http服务，即172.16.1.4,172.16.1.5,172.16.1.6分别运行

172.16.1.4
while true; do echo -e ‘HTTP/1.0 200 OK\r\nContent-Length: 8\r\n\r\nserver1’ | sudo nc -l -p 80 ; done
172.16.1.5
while true; do echo -e ‘HTTP/1.0 200 OK\r\nContent-Length: 8\r\n\r\nserver2’ | sudo nc -l -p 80 ; done
172.16.1.6
while true; do echo -e ‘HTTP/1.0 200 OK\r\nContent-Length: 8\r\n\r\nserver3’ | sudo nc -l -p 80 ; done

而后建立一个客户端访问负载均衡的vip 172.16.1.9 ,屡次执行,以下图
wget -O - http:// 172.16.1.9 （第一次）
wget -O - http:// 172.16.1.9 （第二次）
wget -O - http:// 172.16.1.9 （第三次）
wget -O - http:// 172.16.1.9（第四次）

咱们发现第一次是server1响应

第二次是server2响应

第三次是server3响应

第四次是server1响应