LBaaS v2

 

Neutron 包含负载均衡服务，即LBaaS。负载均衡器可以将用户的访问流量通过算法均摊到多台主机实例上，实现以 Scale-out的方式扩容应用的性能。Neutron LBaaS 包含以下核心的概念：

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

 

负载均衡概念

建立在现有的网络之上，提供了一种廉价、有效、透明的方法来扩大网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力，以及提高网络的灵活性和可用性。通过负载均衡器，可以实现N台廉价的Linux服务器并行处理，从面达到小型机或大型机的计算能力。单台负载均衡器位于网站的最前端，它起着分流客户请求的作用，相当于整个网站或系统的入口。由于IPv4中IP地址日益紧张以及出于安全方面的才虑，很多网络使用保留IP地址（如10.0.0.0/255.0.0.0、172.16.0.0/255.128.0.0、和192.168.0.0/255.255.0.0).这些不在Internet上使用，而是专门为内部网络预留的。当内部网络中的主机要访问Internet或被Internet访问时，就需要进行网络地址转换（Network Address Translation，NAT），NAT方法就是交不同IP地址的并行网络服务变成一个在同一IP地址上的虚拟服务。

 服务器池 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中使用。

三： 使用lvs作为负载均衡器

 

HAproxy + keepalive

比较常用的开源负载均衡器有LVS、Nginx、HAproxy，

LVS只能做到四层的负载均衡，即只能依据IP+端口的方式进行转发，不支持L7的转发策略，

Nginx不仅能做Web服务器，同时也能作为负载均衡器使用；

HAproxy 和Nginx都能基于L7策略进行转发。

LVS也经常和HAproxy、Nginx混用，在大流量的集群中，先由LVS将流量分摊到不同的Nginx/HAproxy集群，再由Nginx/HAproxy做L7转发。除此之外Neutron也支持Ctrix、F5、Radware等公司的插件，从而通过专用的负载均衡硬件来实现。

 

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

HAproxy

HAproxy能够为服务器池提供7层的负载均衡功能，即能根据HTTP请求头中的内容来执行负载均衡算法。而且作为开源软件，被广泛使用。

HAProxy的特点是：   

1. HAProxy也是支持虚拟主机的。 

2. HAProxy的优点能够补充Nginx的一些缺点，比如支持Session的保持，Cookie的引导；同时支持通过获取指定的url来检测后端服务器的状态。 

3. HAProxy跟LVS类似，本身就只是一款负载均衡软件；单纯从效率上来讲HAProxy会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。 

4. HAProxy支持TCP协议的负载均衡转发，可以对MySQL读进行负载均衡，对后端的MySQL节点进行检测和负载均衡，大家可以用LVS+Keepalived对MySQL主从做负载均衡。 

5. HAProxy负载均衡策略非常多，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请求。

1.启用lbaas v2首先需要修改neutron的配置文件，加入插件：/etc/neutron/neutron.confservice_plugins = [existing service plugins],neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2 2.在lbaas的配置文件中添加lbaas v2：/etc/neutron/neutron_lbaas.confservice_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

来自 <>

 

随后即可以创建负载均衡器：

1.创建负载平衡器，指定负载平衡的名称和关联的子网名。需指定与虚拟机所在的子网。neutron lbaas-loadbalancer-create --name my-lb  private-subnet2.为新负载平衡器创建侦听器。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 
       
         --address 
        
          \    //将后端服务器添加到地址池中--protocol-port 80 
         
                 //后端服务器上服务所使用的端口,可以与前端的端口不一致neutron lbaas-member-create  \   --subnet 
          
            --address 
           
             \--protocol-port 80 
            
             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以外的值，如404、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部署方式。

 

更多内容可以参考以下文章

 

Load Balancing as a Service : Liberty and Beyond

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

 

 

以LVS（Linux Virtual Server）作为负载均衡器：    

LVS：使用Linux内核集群实现一个高性能、高可用的负载均衡服务器，它具有很好的可伸缩性（Scalability)、可靠性（Reliability)和可管理性（Manageability)。

LVS的优点是：

1. 抗负载能力强、是工作在网络4层之上仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的，对内存和cpu资源消耗比较低。 

2. 配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率。 

3. 工作稳定，因为其本身抗负载能力很强，自身有完整的双机热备方案，如LVS+Keepalived，不过我们在项目实施中用得最多的还是LVS/DR+Keepalived。 

4. 无流量，LVS只分发请求，而流量并不从它本身出去，这点保证了均衡器IO的性能不会受到大流量的影响。 

5. 应用范围比较广，因为LVS工作在4层，所以它几乎可以对所有应用做负载均衡，包括http、数据库、在线聊天室等等。

LVS的缺点是：   

1. 软件本身不支持正则表达式处理，不能做动静分离；而现在许多网站在这方面都有较强的需求，这个是Nginx/HAProxy+Keepalived的优势所在。 

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

 

LVS的常见名词解释

CIP<-->VIP--DIP<-->RIP

Direct Routing：直接路由

负载均衡层(Loader Balancer)，它就是我们所说的的Director

RS real server ：真实提供服务的计算机

VIP：Virtual IP（VIP）address：Director用来向客户端提供服务的IP地址

RIP：Real IP （RIP） address：集群节点（后台真正提供服务的服务器）所使用的IP地址

DIP：Director's IP (DIP) address：Director用来和D/RIP 进行联系的地址

CIP：Client computer's IP (CIP) address：公网IP，客户端使用的IP

 

 

Session持久机制

1.Session绑定：始终将统一请求者的连接定向至统一RS（第一次请求时仍有调度选择）：没有容错能力，有损均衡效果

2.session复制：在RS之间同步session，因此，每个RS持集群中所有的session；对于大规模集群环境不适用

3.session服务器：利用单独部署的服务器来统一管理session

LVS的集群服务：

四层交换，四层路由

根据请求目标套接字（包括端口的协议类型tcp，udp）来实现转发

 LVS类型：

     NAT-->(DNAT)

     DR

     TUN

     FULLNAT（ipvsadm没有该模式）

 

 VS/NAT的体系结构比较简单：在一组服务器前有一个调度器，它们是通过Switch/HUB相连接的，这些服务器提供相同的网络服务、相同的服务内容，即不管请求被发送到哪一台服务器，执行结果都是一样的。服务的内容可以复制到每一台服务器的本地硬盘上，可能通过网络文件系统共享，也可以通过一个分布式文件系统来提供。

 LVS NAT的特性：

1、RS应该使用私有地址；

2、RS的网关的必须指向DIP；

3、RIP和DIP必须在同一网段内；

4、请求和响应的报文都得经过Director；在高负载场景中，Director很可能成为系统性能瓶颈；

5、支持端口映射；

6、RS可以使用任意支持集群服务的OS；

  

LVS DR类型的特性：

1、RS可以使用私有地址；但也可以使用公网地址，此时可以直接通过互联网连入RS以实现配置、监控等；

2、RS的网关一定不能指向DIP；

3、RS跟Dirctory要在同一物理网络内（不能由路由器分隔）；

4、请求报文经过Directory，但响应报文一定不经过Director

5、不支持端口映射；

6、RS可以使用大多数的操作系统；

 

LVS TUN类型：IP隧道

1、RIP、DIP、VIP都得是公网地址；

2、RS的网关不会指向也不可能指向DIP；

3、请求报文经过Directory，但响应报文一定不经过Director；

4、不支持端口映射；

5、RS的OS必须得支持隧道功能；

 

VS/DR或VS/TUN应用的一种模型中（所有机器都在同一个物理网络），所有机器（包括Director和RealServer）都使用了一个额外的IP地址，即VIP。当一个客户端向VIP发出一个连接请求时，此请求必须要连接至Director的VIP，而不能是RealServer的。因为，LVS的主要目标就是要Director负责调度这些连接请求至RealServer的。

因此，在Client发出至VIP的连接请求后，只能由Director将其MAC地址响应给客户端（也可能是直接与Director连接的路由设备），而Director则会相应的更新其ipvsadm table以追踪此连接，而后将其转发至后端的RealServer之一。

如果Client在请求建立至VIP的连接时由某RealServer响应了其请求，则Client会在其MAC table中建立起一个VIP至RealServer的对就关系，并以至进行后面的通信。此时，在Client看来只有一个RealServer而无法意识到其它服务器的存在。

为了解决此问题，可以通过在路由器上设置其转发规则来实现。当然，如果没有权限访问路由器并做出相应的设置，则只能通过传统的本地方式来解决此问题了。这些方法包括：

1、禁止RealServer响应对VIP的ARP请求；

2、在RealServer上隐藏VIP，以使得它们无法获知网络上的ARP请求；

3、基于“透明代理（Transparent Proxy）”或者“fwmark （firewall mark）”；

4、禁止ARP请求发往RealServers；

 

LVS Scheduling Method LVS的调度方法：

1.Fixed Scheduling Method  静态调服方法

(1).RR     轮询

(2).WRR    加权轮询

(3).DH     目标地址hash

(4).SH     源地址hash

2.Dynamic Scheduling Method 动态调服方法

(1).LC     最少连接

(2).WLC    加权最少连接

(3).SED    最少期望延迟

(4).NQ     从不排队调度方法

(5).LBLC   基于本地的最少连接

(6).LBLCR  带复制的基于本地的最少连接

 

ipvsadm组件定义规则的格式：

1.定义集群服务格式：

(1).添加集群服务：

ipvsadm -A|E -t|u|f service-address [-s scheduler]

              [-p [timeout]] [-M netmask]

-A：                  表示添加一个新的集群服务

-E：                  编辑一个集群服务

-t：                  表示tcp协议

-u：                  表示udp协议

-f：                  表示firewall-Mark,防火墙标记

service-address：     集群服务的IP地址，即VIP

-s                    指定调度算法

-p                    持久连接时长，如#ipvsadm -Lcn ，查看持久连接状态

-M                    定义掩码

 

ipvsadm -D -t|u|f service-address      删除一个集群服务

ipvsadm -C                             清空所有的规则

ipvsadm -R                             重新载入规则

ipvsadm -S [-n]                        保存规则

 

2.向集群服务添加RealServer规则：

(1).添加RealServer规则

ipvsadm -a|e -t|u|f service-address -r server-address

              [-g|i|m] [-w weight]

-a                 添加一个新的realserver规则

-e                 编辑realserver规则

-t                 tcp协议

-u                 udp协议

-f                 firewall-Mark，防火墙标记

service-address    realserver的IP地址

-g                 表示定义为LVS-DR模型

-i                 表示定义为LVS-TUN模型

-m                 表示定义为LVS-NAT模型

-w                 定义权重，后面跟具体的权值

ipvsadm -d -t|u|f service-address -r server-address          --删除一个realserver

ipvsadm -L|l [options]                                       --查看定义的规则

如：#ipvsadm -L -n  

ipvsadm -Z [-t|u|f service-address]                          --清空计数器

 

LVS-NAT 模型实例 

打开路由间转发功能

[root@mgm-net0 ~]# sysctl -a | grep net.ipv4.ip_forward

sysctl: reading key "net.ipv6.conf.all.stable_secret"

net.ipv4.ip_forward = 1

若为0，设置为1：

echo 1 > /proc/sys/net/ipv4/ip_forward

sysctl  -p      //立即生效

 

查看ipvs支持功能

[root@mgm-net0 ~]# grep -E -i "ipvs|IP_VS" /boot/config-3.10.0-862.11.6.el7.x86_64

CONFIG_NETFILTER_XT_MATCH_IPVS=m

CONFIG_IP_VS=m

CONFIG_IP_VS_IPV6=y

# CONFIG_IP_VS_DEBUG is not set

CONFIG_IP_VS_TAB_BITS=12

# IPVS transport protocol load balancing support

CONFIG_IP_VS_PROTO_TCP=y

CONFIG_IP_VS_PROTO_UDP=y

CONFIG_IP_VS_PROTO_AH_ESP=y

CONFIG_IP_VS_PROTO_ESP=y

CONFIG_IP_VS_PROTO_AH=y

CONFIG_IP_VS_PROTO_SCTP=y

# IPVS scheduler

CONFIG_IP_VS_RR=m

CONFIG_IP_VS_WRR=m

CONFIG_IP_VS_LC=m

CONFIG_IP_VS_WLC=m

CONFIG_IP_VS_LBLC=m

CONFIG_IP_VS_LBLCR=m

CONFIG_IP_VS_DH=m

CONFIG_IP_VS_SH=m

CONFIG_IP_VS_SED=m

CONFIG_IP_VS_NQ=m

# IPVS SH scheduler

CONFIG_IP_VS_SH_TAB_BITS=8

# IPVS application helper

CONFIG_IP_VS_FTP=m

CONFIG_IP_VS_NFCT=y

CONFIG_IP_VS_PE_SIP=m

查看速率信息

[root@lvs-server ~]# ipvsadm -Ln --rate
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port                 CPS    InPPS   OutPPS    InBPS   OutBPS
  -> RemoteAddress:Port
TCP  10.0.0.50:80                             1        5           5           449       550
  -> 192.168.1.51:80                       0         3           2           228       275
  -> 192.168.1.52:8080                   0         3           2           221       275
CPS：每秒的连接数
InPPS：每秒流入包个数
OutPPS：每秒流出包个数
InBPS：每秒进入流量（字节）
OutBPS：每秒流出流量（字节）

 

在配置完规则之后需要保存和重载，规则保存在/etc/sysconfig/ipvsadm文件中

#保存ipvsadm规则至/etc/sysconfig/ipvsadm文件中
[root@lvs-server ~]# ipvsadm -S >/etc/sysconfig/ipvsadm
[root@lvs-server ~]# cat /etc/sysconfig/ipvsadm

lbaas-lvs实现：namespace lvs-xxx下

底层代码实现：

class LvsDriver(agent_device_driver.AgentDeviceDriver):

[root@node0 ~]# ipvsadm -C

[root@node0 ~]# ipvsadm -ln --stats

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes

-> RemoteAddress:Port

[root@node0 ~]# ipvsadm -A -u 10.33.46.64:9999 -s sh -p 120

[root@node0 ~]# ipvsadm -ln --stats

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes

-> RemoteAddress:Port

UDP 10.33.46.64:9999 0 0 0 0 0

[root@node0 ~]# ipvsadm -a -u 10.33.46.64:9999 -r 10.33.46.68:9999 -m -w 1

[root@node0 ~]# ipvsadm -ln --stats

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes

-> RemoteAddress:Port

UDP 10.33.46.64:9999 0 0 0 0 0

-> 10.33.46.68:9999 0 0 0 0 0

[root@node0 ~]# arping -c 1 10.33.46.68

ARPING 10.33.46.68 from 10.33.46.64 tap85d707e7-35

Unicast reply from 10.33.46.68 [FA:16:3E:0D:A6:AB] 1.310ms

Sent 1 probes (1 broadcast(s))

Received 1 response(s)

[root@node0 ~]# netcat -uvz -w 1 10.33.46.68 9999

[root@node0 ~]# netcat -uvz -w 1 10.33.46.64 9999

Warning: Host 10.33.46.64 isn't authoritative! (direct lookup mismatch)

10.33.46.64 -> mgm-net0 BUT mgm-net0 -> 172.30.65.2

[root@node0 ~]# netcat -uvz -w 1 10.33.46.68 9990

[root@node0 ~]# ipvsadm -ln --stats

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes

-> RemoteAddress:Port

UDP 10.33.46.64:9999 2 2 0 64 0

-> 10.33.46.68:9999 2 2 0 64 0

[root@node0 ~]# ipvsadm -ln --stats

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes

-> RemoteAddress:Port

UDP 10.33.46.64:9999 2 3 0 111 0

-> 10.33.46.68:9999 2 3 0 111 0

[root@node0 ~]# ipvsadm -ln --stats

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes

-> RemoteAddress:Port

UDP 10.33.46.64:9999 2 4 0 142 0

-> 10.33.46.68:9999 2 4 0 142 0

测试：

负载均衡器的成员虚机上，server监听端口

[root@host-10-33-46-68 ~]# nc -ul  10.33.46.68 9999

[root@node0 ~]# ipvsadm -Z       ====清空统计数据

[root@node0 ~]# ipvsadm -ln --stats     ==查看统计

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes

-> RemoteAddress:Port

UDP 10.33.46.64:9999 0 0 0 0 0

-> 10.33.46.68:9999 0 0 0 0 0

client发包

[root@node2 ~]# echo "hello word"|nc -nuv 10.33.46.64 9999

Ncat: Version 7.50 ( https://nmap.org/ncat )

Ncat: Connected to 10.33.46.64:9999.

Ncat: 11 bytes sent, 0 bytes received in 0.02 seconds.

server端收到数据

[root@host-10-33-46-68 ~]# nc -ul 10.33.46.68 9999

hello word

[root@node0 ~]# ipvsadm -ln --stats

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes

-> RemoteAddress:Port

UDP 10.33.46.64:9999 1 1 0 39 0

-> 10.33.46.68:9999 1 1 0 39 0

 

 

部署LVS-DR集群

3.1 问题

使用LVS实现DR模式的集群调度服务器，为用户提供Web服务：

路由器对外公网IP地址为202.114.106.20

路由器内网IP地址为192.168.0.254

路由是需要设置SNAT及DNAT功能

LVS调度器真实IP地址为192.168.0.10

LVS调度器VIP地址设置为192.168.0.253

真实Web服务器地址分别为192.168.0.1、192.168.0.2

使用加权轮询调度算法，真实服务器权重与其IP地址末尾数一致

3.2 方案

使用4台虚拟机，1台作为Linux路由器、1台作为Director调度器、2台作为Real Server、物理机作为客户端，拓扑结构如图-2所示。

Nginx和LVS对比的总结：   

1. Nginx工作在网络的7层，所以它可以针对http应用本身来做分流策略，比如针对域名、目录结构等，相比之下LVS并不具备这样的功能，所以Nginx单凭这点可利用的场合就远多于LVS了；但Nginx有用的这些功能使其可调整度要高于LVS，所以经常要去触碰触碰，触碰多了，人为出问题的几率也就会大。    

2. Nginx对网络稳定性的依赖较小，理论上只要ping得通，网页访问正常，Nginx就能连得通，这是Nginx的一大优势！Nginx同时还能区分内外网，如果是同时拥有内外网的节点，就相当于单机拥有了备份线路；LVS就比较依赖于网络环境，目前来看服务器在同一网段内并且LVS使用direct方式分流，效果较能得到保证。另外注意，LVS需要向托管商至少申请多一个ip来做Visual IP，貌似是不能用本身的IP来做VIP的。要做好LVS管理员，确实得跟进学习很多有关网络通信方面的知识，就不再是一个HTTP那么简单了。

3. Nginx安装和配置比较简单，测试起来也很方便，因为它基本能把错误用日志打印出来。LVS的安装和配置、测试就要花比较长的时间了；LVS对网络依赖比较大，很多时候不能配置成功都是因为网络问题而不是配置问题，出了问题要解决也相应的会麻烦得多。 

4. Nginx也同样能承受很高负载且稳定，但负载度和稳定度差LVS还有几个等级：Nginx处理所有流量所以受限于机器IO和配置；本身的bug也还是难以避免的。 

5. Nginx可以检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。目前LVS中 ldirectd也能支持针对服务器内部的情况来监控，但LVS的原理使其不能重发请求。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而恼火。 

6. Nginx对请求的异步处理可以帮助节点服务器减轻负载，假如使用 apache直接对外服务，那么出现很多的窄带链接时apache服务器将会占用大 量内存而不能释放，使用多一个Nginx做apache代理的话，这些窄带链接会被Nginx挡住，apache上就不会堆积过多的请求，这样就减少了相当多的资源占用。这点使用squid也有相同的作用，即使squid本身配置为不缓存，对apache还是有很大帮助的。 

7. Nginx能支持http、https和email（email的功能比较少用），LVS所支持的应用在这点上会比Nginx更多。在使用上，一般最前端所采取的策略应是LVS，也就是DNS的指向应为LVS均衡器，LVS的优点令它非常适合做这个任务。重要的ip地址，最好交由LVS托管，比如数据库的 ip、webservice服务器的ip等等，这些ip地址随着时间推移，使用面会越来越大，如果更换ip则故障会接踵而至。所以将这些重要ip交给 LVS托管是最为稳妥的，这样做的唯一缺点是需要的VIP数量会比较多。Nginx可作为LVS节点机器使用，一是可以利用Nginx的功能，二是可以利用Nginx的性能。当然这一层面也可以直接使用squid，squid的功能方面就比Nginx弱不少了，性能上也有所逊色于Nginx。Nginx也可作为中层代理使用，这一层面Nginx基本上无对手，唯一可以撼动Nginx的就只有lighttpd了，不过lighttpd目前还没有能做到 Nginx完全的功能，配置也不那么清晰易读。另外，中层代理的IP也是重要的，所以中层代理也拥有一个VIP和LVS是最完美的方案了。具体的应用还得具体分析，如果是比较小的网站（日PV小于1000万），用Nginx就完全可以了，如果机器也不少，可以用DNS轮询，LVS所耗费的机器还是比较多的；大型网站或者重要的服务，机器不发愁的时候，要多多考虑利用LVS。

现在对网络负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术：

第一阶段：利用Nginx或HAProxy进行单点的负载均衡，这一阶段服务器规模刚脱离开单服务器、单数据库的模式，需要一定的负载均衡，但是仍然规模较小没有专业的维护团队来进行维护，也没有需要进行大规模的网站部署。这样利用Nginx或HAproxy就是第一选择，此时这些东西上手快， 配置容易，在七层之上利用HTTP协议就可以。这时是第一选择。

第二阶段：随着网络服务进一步扩大，这时单点的Nginx已经不能满足，这时使用LVS或者商用Array就是首要选择，Nginx此时就作为LVS或者Array的节点来使用，具体LVS或Array的是选择是根据公司规模和预算来选择，Array的应用交付功能非常强大，本人在某项目中使用过，性价比也远高于F5，商用首选，但是一般来说这阶段相关人才跟不上业务的提升，所以购买商业负载均衡已经成为了必经之路。

第三阶段：这时网络服务已经成为主流产品，此时随着公司知名度也进一步扩展，相关人才的能力以及数量也随之提升，这时无论从开发适合自身产品的定制，以及降低成本来讲开源的LVS，已经成为首选，这时LVS会成为主流。    

最终形成比较理想的基本架构为：Array/LVS — Nginx/Haproxy — Squid/Varnish — AppServer。