1、简述四层和七层负载均衡的特点及Haproxy与LVS之间的对比
2、简述Haproxy常见的负载均衡调度算法及应用场景详解
3、通过Haproxy的ACL规划实现智能负载均衡，并简述tcp、http、health的配置示例
4、LNMT实现动静分离实战

1、简述四层和七层负载均衡的特点及Haproxy与LVS之间的对比

（1）简述四层和七层负载均衡的特点

四层负责均衡：主要是指通过判断报文的IP地址和端口并通过一定的负载均衡算法来决定转发到哪个指定目标，主要工作在OSI模型的第四层。四层负载均衡对数据包只是起一个数据转发的作用，并不会干预客户端与服务器之间应用层的通信（如：三次握手等）。所以能对数据所进行的操作也就很少，但相对于七层负载均衡来讲效率会高上很多

七层负载均衡：也被称为“内容交换”，指的是负载均衡设备通过报文中的应用层信息(URL、HTTP头部等信息)和负载均衡算法，选择到达目的的内部服务器。七层负载均衡可以“智能化”地筛选报文中应用层信息，然后根据不同的信息进行特定的负载均衡调度。这种方式提升了应用系统在网络层上的灵活性，另外也在一定程度上提升了后端系统的安全性。因为像网络常见的DoS攻击，这些攻击在七层负载均衡的环境下通常都在负载均衡设备上就截止了，不会影响到后台服务器的正常运行。

（2）HAproxy、nginx与Lvs的对比

前网络中常见的负载均衡主要分为硬件负载均衡和软件负载均衡。硬件负载均衡比较知名的产品有F5 Big-IP、Cirtix Netscaler等等。而软件负载均衡就有着众多的开源项目，常见的有Haproxy、nginx、lvs等。
Haproxy：

1、支持两种代理模式：TCP（四层）和HTTP（七层），支持虚拟主机；
2、能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作
3、支持url检测后端的服务器出问题的检测会有很好的帮助。
4、更多的负载均衡策略比如：动态加权轮循(Dynamic Round Robin)，加权源地址哈希(Weighted Source Hash)，加权URL哈希和加权参数哈希(Weighted Parameter Hash)。
5、单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。
6、HAProxy可以对Mysql进行负载均衡，对后端的DB节点进行检测和负载均衡。
9、支持负载均衡算法：Round-robin（轮循）、Weight-round-robin（带权轮循）、source（原地址保持）、RI（请求URL）、rdp-cookie（根据cookie）
10、不能做Web服务器即Cache。

lvs:

1、抗负载能力强、性能高，能达到F5硬件的60%；对内存和cpu资源消耗比较低
2、工作在网络4层，通过vrrp协议转发（仅作分发之用），具体的流量由linux内核处理，因此没有流量的产生。
2、稳定性、可靠性好，自身有完美的热备方案；（如：LVS+Keepalived）
3、应用范围比较广，可以对所有应用做负载均衡；
4、不支持正则处理，不能做动静分离。
5、支持负载均衡算法：rr（轮循）、wrr（带权轮循）、lc（最小连接）、wlc（权重最小连接）
6、配置复杂，对网络依赖比较大，稳定性很高。

nginx:

1、工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构；
2、Nginx对网络的依赖比较小，理论上能ping通就就能进行负载功能；
3、Nginx安装和配置比较简单，测试起来比较方便；
4、可以承担高的负载压力且稳定，一般能支撑超过1万次的并发；
5、对后端服务器的健康检查，只支持通过端口来检测，不支持通过url来检测。
6、Nginx对请求的异步处理可以帮助节点服务器减轻负载；
7、Nginx仅能支持http、https和Email协议，这样就在适用范围较小。
8、不支持Session的直接保持，但能通过ip_hash来解决。、对Big request header的支持不是很好，
9、支持负载均衡算法：Round-robin（轮循）、Weight-round-robin（带权轮循）、Ip-hash（Ip哈希）
10、Nginx还能做Web服务器即Cache功能

2、简述Haproxy常见的负载均衡调度算法及应用场景详解

roundrobin：基于权重进行轮询，此算法是动态的，其权重可以在运行时进行调整。
static-rr：基于权重进行轮询，与roundrobin类似，但是为静态方法，在运行时调整其服务器权重不会生效。
leastconn：新的连接请求被派发至具有最少连接数目的后端服务器，动态算法，适用于较长时间会话的场景。
source：将请求的源地址进行hash运算，并与后端服务器的总权重作取模运算后调度至某台服务器；同一IP地址的请求将始终被调度至某特定的服务器，静态算法，可以使用hash-type修改此特性；
uri：对URI的左半部分(“？”之前的部分)或整个URI进行hash运算，并与后端服务器的总权重作取模运算后调度至某台服务器；同一URI的请求将始终被调度至某特定的服务器，静态算法，可以使用hash-type修改此特性；
hdr(<name>)：根据用户请求报文中指定的http首部的值进行调度，常用于实现将对同一个虚拟主机的请求始终发往同个backend server。

3、通过Haproxy的ACL规划实现智能负载均衡，并简述tcp、http、health的配置示例

Haproxy可以做代理服务相对于nginx而言有很多相同之处，统一可以基于mode tcp进行四层代理也可以基于mode http进行七层代理，但不同的是其无法使用location和if等进行匹配判断。突出优势在于有会话绑定，web管理界面，状态统计非常详细。官方推荐只启用一个进程，相对于nginx多进程架构工作并不理想，更多的线程可能会受到系统内存的一些限制。
程序环境：
主程序：/usr/sbin/haproxy
主配置文件：/etc/haproxy/haproxy.cfg
Unit file：/usr/lib/systemd/system/haproxy.service

    配置段：
        global：全局配置段
            进程及安全配置相关的参数
            性能调整相关参数
            Debug参数
        proxies：代理配置段
            defaults：为frontend, listen, backend提供默认配置；
            frontend：前端，相当于nginx, server {}
            backend：后端，相当于nginx, upstream {}
            listen：同时拥前端和后端

查看配置文件

global
    log         127.0.0.1 local2
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon

    # turn on stats unix socket
    stats socket /var/lib/haproxy/stats

重要的几个参数，及性能调优，多数无需修改

    log：定义全局的syslog服务器；最多可以定义两个；
    log <address> [len <length>] <facility> [max level [min level]]
    nbproc <number>：要启动的haproxy的进程数量；
    ulimit-n <number>：每个haproxy进程可打开的最大文件数；
    maxconn <number>：设定每个haproxy进程所能接受的最大并发连接数；
         最大的并发连接数=nbproc * maxconn
    maxconnrate <number>：每个进程每秒种所能创建的最大连接数量；
    maxcomprate ：压缩创建的速率
    maxsessrate <number>：进程每秒能创建的会话数量
    maxsslconn <number>:每个进程所能接受的ssl连接数
    spread-checks <0..50, in percent>：散开监控状态检测

发现日志发送给本机rsyslog的local2的facility，而本机的rsyslog里并没有定义，需要我们自己去配置
所以vim /etc/rsyslog.conf添加一段将local2的所有信息记录在对应日志文件中

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514
local2.*              /var/log/haproxy.log

ACL规则

由于HAProxy可以工作在七层模型下，因此，要实现HAProxy的强大功能，一定要使用强大灵活的ACL规则，通过ACL规则可以实现基于HAProxy的智能负载均衡系统。HAProxy通过ACL规则完成两种主要的功能，分别是：
1）通过设置的ACL规则检查客户端请求是否合法。如果符合ACL规则要求，那么将放行；如果不符合规则，则直接中断请求。
2）符合ACL规则要求的请求将被提交到后端的backend服务器集群，进而实现基于ACL规则的负载均衡。HAProxy中的ACL规则经常使用在frontend段中，使用方法如下：
acl 自定义的acl 名称 acl 方法 -i [ 匹配的路径或文件] 其中：
·acl：是一个关键字，表示定义ACL规则的开始。后面需要跟上自定义的ACL名称。
·acl方法：这个字段用来定义实现ACL的方法，HAProxy定义了很多ACL方法，经常使用的方法有hdr_reg（host）、hdr_dom（host）、hdr_beg（host）、url_sub、url_dir、path_beg、path_end等。
·-i：表示不区分大小写，后面需要跟上匹配的路径或文件或正则表达式。与ACL规则一起使用的HAProxy参数还有use_backend，use_backend后面需要跟上一个backend实例名，表示在满足ACL规则后去请求哪个backend实例，与use_backend对应的还有default_backend参数，它表示在没有满足ACL条件的时候默认使用哪个后端

acl www_policy  hdr_reg(host)  -i  ^(www.z.cn|z.cn) 
acl bbs_policy  hdr_dom(host)  -i  bbs.z.cn
acl url_policy  url_sub       -i          buy_sid=
use_backend  server_www       if         www_policy 
use_backend  server_app     if        url_policy 
use_backend  server_bbs     if          bbs_policy 
default_backend  server_cache

这些例子定义了www_policy、bbs_policy、url_policy三个ACL规则，第一条规则表示如果客户端以www.z.cn或z.cn开头的域名发送请求时，则此规则返回true，同理第二条规则表示如果客户端通过bbs.z.cn域名发送请求时，则此规则返回true，而第三条规则表示如果客户端在请求的URL中包含“buy_sid=”字符串时，则此规则返回true。
第四、第五、第六条规则定义了当www_policy、bbs_policy、url_policy三个ACL规则返回true时要调度到哪个后端backend，例如，当用户的请求满足www_policy规则时，那么HAProxy会将用户的请求直接发往名为server_www的后端backend，其他以此类推。而当用户的请求不满足任何一个ACL规则时，HAProxy就会把请求发往由default_backend选项指定的server_cache这个后端backend。

acl host_www        hdr_beg(host) -i www 
acl host_static   hdr_beg(host) -i img. video. download. ftp. 
use_backend static    if host_static || host_www url_static 
use_backend www         if host_www 
default_backend            server_cache

与上面的例子类似，本例中也定义了url_static、host_www和host_static三个ACL规则，其中，第一条规则通过path_end参数定义了如果客户端在请求的URL中以.gif、.png、.jpg、.css或.js结尾时返回true，第二条规则通过hdr_beg（host）参数定义了如果客户端以www开头的域名发送请求时则返回true，同理，第三条规则也是通过hdr_beg（host）参数定义了如果客户端以img.、video.、download.或ftp.开头的域名发送请求时则返回true。
第四、第五条规则定义了当满足ACL规则后要调度到哪个后端backend，例如，当用户的请求同时满足host_static规则与url_static规则，或同时满足host_www和url_static规则时，那么会将用户请求直接发往名为static的后端backend，如果用户请求满足host_www规则，那么请求将被调度到名为www的后端backend，如果不满足所有规则，那么将用户请求默认调度到名为server_cache的这个后端backend。

global部分

log：全局的日志配置，local0是日志设备，info表示日志级别。其中日志级别有err、warning、info、debug4种可选。这个配置表示使用127.0.0.1上的rsyslog服务中的local0日志设备，记录日志等级为info。

maxconn：设定每个HAProxy进程可接受的最大并发连接数，此选项等同于Linux命令行选项“ulimit -n”。

user/group：设置运行HAProxy进程的用户和组，也可使用用户和组的uid和gid值来替代。

daemon：设置HAProxy进程进入后台运行。这是推荐的运行模式。

nbproc：设置HAProxy启动时可创建的进程数，此参数要求将HAProxy运行模式设置为daemon，默认只启动一个进程。该值的设置应该小于服务器的CPU核数。创建多个进程，能够减少每个进程的任务队列，但是过多的进程可能会导致进程崩溃。

pidfile：指定HAProxy进程的pid文件。启动进程的用户必须有访问此文件的权限。

defaults部分

mode：设置HAProxy实例默认的运行模式，有tcp、http、health三个可选值。

TCP模式：在此模式下，客户端和服务器端之间将建立一个全双工的连接，不会对七层报文做任何类型的检查，默认为tcp模式，经常用于SSL、SSH、SMTP等应用。
http模式：在此模式下，客户端请求在转发至后端服务器之前将会被深度分析，所有不与RFC格式兼容的请求都会被拒绝。
health模式：目前此模式基本已经废弃，不再多说。

retries：设置连接后端服务器的失败重试次数，如果连接失败的次数超过这里设置的值，HAProxy会将对应的后端服务器标记为不可用。此参数也可在后面部分进行设置。

timeout connect：设置成功连接到一台服务器的最长等待时间，默认单位是毫秒，但也可以使用其他的时间单位后缀。

timeout client：设置连接客户端发送数据时最长等待时间，默认单位是毫秒，也可以使用其他的时间单位后缀。

timeout server：设置服务器端回应客户端数据发送的最长等待时间，默认单位是毫秒，也可以使用其他的时间单位后缀。

timeout check：设置对后端服务器的检测超时时间，默认单位是毫秒，也可以使用其他的时间单位后缀。

frontend部分

bind：此选项只能在frontend和listen部分进行定义，用于定义一个或几个监听的套接字。bind的使用格式为： bind [<address>:<port_range>] interface <interface>其可以为主机名或IP地址，如果将其设置为“*”或“0.0.0.0”，将监听当前系统的所有IPv4地址。port_range可以是一个特定的TCP端口，也可是一个端口范围，小于1024的端口需要有特定权限的用户才能使用。interface为可选选项，用来指定网络接口的名称，只能在Linux系统上使用。

option httplog：在默认情况下，HAProxy日志是不记录HTTP请求的，这样很不方便HAProxy问题的排查与监控。通过此选项可以启用日志记录HTTP请求。

option forwardfor：如果后端服务器需要获得客户端的真实IP，就需要配置此参数。由于HAProxy工作于反向代理模式，因此发往后端真实服务器的请求中的客户端IP均为HAProxy主机的IP，而非真正访问客户端的地址，这就导致真实服务器端无法记录客户端真正请求来源的IP，而X-Forwarded-For则可用于解决此问题。通过使用forwardfor选项，HAProxy就可以向每个发往后端真实服务器的请求添加X-Forwarded-For记录，这样后端真实服务器日志可以通过“X-Forwarded-For”信息来记录客户端来源IP。

option httpclose：此选项表示在客户端和服务器端完成一次连接请求后，HAProxy将主动关闭此TCP连接。这是对性能非常有帮助的一个参数。

log global：表示使用全局的日志配置，这里的global表示引用在HAProxy配置文件global部分中定义的log选项配置格式。

default_backend：指定默认的后端服务器池，也就是指定一组后端真实服务器，而这些真实服务器组将在backend段进行定义。这里的htmpool就是一个后端服务器组。

backend部分

option redispatch：此参数用于cookie保持的环境中。在默认情况下，HAProxy会将其请求的后端服务器的serverID插入cookie中，以保证会话的session持久性。而如果后端的服务器出现故障，客户端的cookie是不会刷新的，这就会出现问题。此时，如果设置此参数，就会将客户的请求强制定向到另外一台健康的后端服务器上，以保证服务正常。

option abortonclose：如果设置了此参数，可以在服务器负载很高的情况下，自动结束当前队列中处理时间比较长的连接。
-balance：此关键字用来定义负载均衡算法。目前HAProxy支持多种负载均衡算法，常用的有如下几种：

roundrobin：是基于权重进行轮叫调度的算法，在服务器的性能分布比较均匀时，这是一种最公平、最合理的算法。此算法使用频繁。
static-rr：也是基于权重进行轮叫的调度算法，不过此算法为静态方法，在运行时调整其服务器权重不会生效。
source：是基于请求源IP的算法。此算法先对请求的源IP进行hash运算，然后将结果与后端服务器的权重总数相除后转发至某台匹配的后端服务器。这种方式可以使同一个客户端IP的请求始终被转发到某特定的后端服务器。
leastconn：此算法会将新的连接请求转发到具有最少连接数目的后端服务器。在会话时间较长的场景中推荐使用此算法，例如数据库负载均衡等。此算法不适合会话较短的环境中，例如基于HTTP的应用。
uri：此算法会对部分或整个URI进行hash运算，再经过与服务器的总权重相除，最后转发到某台匹配的后端服务器上。
uri_param：此算法会根据URL路径中的参数进行转发，这样可保证在后端真实服务器数量不变时，同一个用户的请求始终分发到同一台机器上。
hdr（<name>）：此算法根据http头进行转发，如果指定的http头名称不存在，则使用roundrobin算法进行策略转发。

cookie：表示允许向cookie插入SERVERID，每台服务器的SERVERID可在下面的server关键字中使用cookie关键字定义。

option httpchk：此选项表示启用HTTP的服务状态检测功能。HAProxy作为一个专业的负载均衡器，它支持对backend部分指定的后端服务节点的健康检查，以保证在后端backend中某个节点不能服务时，把从frotend端进来的客户端请求分配至backend中其他健康节点上，从而保证整体服务的可用性。
option httpchk的用法如下： option httpchk <method> <uri> <version> 其中，各个参数的含义如下：

method：表示HTTP请求的方式，常用的有OPTIONS、GET、HEAD几种方式。一般的健康检查可以采用HEAD方式进行，而不是采用GET方式，这是因为HEAD方式没有数据返回，仅检查Response的HEAD是不是状态码200。因此，相对于GET，HEAD方式更快、更简单。
uri：表示要检测的URL地址，通过执行此URL，可以获取后端服务器的运行状态。在正常情况下将返回状态码200，返回其他状态码均为异常状态。
version：指定心跳检测时的HTTP的版本号。
server：这个关键字用来定义多台后端真实服务器，不能用于defaults和frontend部分。使用格式为： server <name> <address>[:port] [param*] 其中，每个参数含义如下：
<name>：为后端真实服务器指定一个内部名称，随便定义一个即可。
<address>：后端真实服务器的IP地址或主机名。
<port>：指定连接请求发往真实服务器时的目标端口。在未设定时，将使用客户端请求时的同一端口。
[param*]：为后端服务器设定的一系列参数，可用参数非常多，这里仅介绍常用的一些参数：

check：表示启用对此后端服务器执行健康状态检查。

inter：设置健康状态检查的时间间隔，单位为毫秒。

rise：设置从故障状态转换至正常状态需要成功检查的次数，例如，“rise 2”表示2次检查正确就认为此服务器可用。

fall：设置后端服务器从正常状态转换为不可用状态需要检查的次数，例如，“fall 3”表示3次检查失败就认为此服务器不可用。

cookie：为指定的后端服务器设定cookie值，此处指定的值将在请求入站时被检查，第一次为此值挑选的后端服务器将在后续的请求中一直被选中，其目的在于实现持久连接的功能。上面的“cookie server1”表示web1的serverid为server1。同理，“cookie server2”表示web2的serverid为server2。

weight：设置后端真实服务器的权重，默认为1，最大值为256。设置为0表示不参与负载均衡。

backup：设置后端真实服务器的备份服务器，仅仅在后端所有真实服务器均不可用的情况下才启用。

通过ACL智能负载均衡动静分离

rontend web *:80
   compression algo gzip
   compression type text/html text/plain /application/xml application/javascript
   acl static path_end .jpg .jpeg.png .gif .txt .html .css .javascript .
js  #定义静态acl匹配规则，后缀匹配
   acl static path_beg /imgs /css /javascripts #定义静态acl匹配规则，前缀匹配
   use_backend staticsrvs if static  #使用静态acl匹配规则
   default_backend dynsrvs #未匹配到acl的，使用默认后端主机，动态内容

backend dynsrvs   #动态主机组
   cookie SRV insert indirect nocache #启用cookie绑定
   server dynsrv1 192.168.31.204:80 check cookie dynsrv1

backend staticsrvs  #静态主机组
   server staticsrv1 192.168.31.203:80 check               

listen stats
   bind *:9099
   stats enable
   stats uri /myproxy?admin #自定义信息页地址
   stats realm "HAProxy Stats Page" #认证提示
   stats auth admin:admin #认证时用的用户名和密码
   stats admin if TRUE  #启用信息页管理功能，总是为真

image.png

4、LNMT实现动静分离实战

用nginx反代后端的两台tomcat主机，做动静分离，如果是jsp结尾的就发往后端，否则就交给nginx处理。
在两台tomcat主机上创建应用

mkdir -pv /var/lib/tomcat/webapps/test/{WEB-INF,META-INF,calsses,lib}
然后创建应用程序jsp文件
在A主机上
 
            <%@ page language="java" %>
                    <html>
                        <head><title>TomcatA</title></head>
                        <body>
                            <h1><font color="red">TomcatA.magedu.com</font></h1>
                            <table align="centre" border="1">
                                <tr>
                                    <td>Session ID</td>
                                <% session.setAttribute("magedu.com","magedu.com"); %>
                                    <td><%= session.getId() %></td>
                                </tr>
                                <tr>
                                    <td>Created on</td>
                                    <td><%= session.getCreationTime() %></td>
                                </tr>
                            </table>
                        </body>
                    </html>
 
在B主机上
            <%@ page language="java" %>
                    <html>
                        <head><title>TomcatB</title></head>
                            <body>
                            <h1><font color="blue">TomcatB.magedu.com</font></h1>
                            <table align="centre" border="1">
                                <tr>
                                    <td>Session ID</td>
                                <% session.setAttribute("magedu.com","magedu.com"); %>
                                    <td><%= session.getId() %></td>
                                </tr>
                                <tr>
                                    <td>Created on</td>
                                    <td><%= session.getCreationTime() %></td>
                                </tr>
                            </table>
                            </body>
                    </html>

image.png

nginx配置

upstream tcservs {
        hash $request_uri consistent; #使用uri一致性哈希算法保持会话粘性
        #hash $cookie_name consistent 对cookie做哈希也可以
        server 192.168.31.203:8080;
        server 192.168.31.204:8080;
    }
vim /etc/nginx/conf.d/lvqin.conf
server {
        listen 80;
        server_name node1.lvqing.com;
 
          location ~* \.(jsp|do)$ {
                     proxy_pass http://tcservs;
         }
}

image.png

则动静分离就实现了，并且我们还基于uri实现了会话粘性

常见的负载均衡技术

1、简述四层和七层负载均衡的特点及Haproxy与LVS之间的对比

（1）简述四层和七层负载均衡的特点

（2）HAproxy、nginx与Lvs的对比

2、简述Haproxy常见的负载均衡调度算法及应用场景详解

3、通过Haproxy的ACL规划实现智能负载均衡，并简述tcp、http、health的配置示例

ACL规则

global部分

defaults部分

frontend部分

backend部分

通过ACL智能负载均衡动静分离

4、LNMT实现动静分离实战

通过HPA+CronHPA组合应对业务复杂弹性伸缩场景

搭建一個簡單的zabbix

Ansible的簡單配置

mysql的主從複製，讀寫分離

varnish的簡單配置

docker創建私人倉庫

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結