负载均衡
一、四层负载均衡和七层负载均衡
1.四层负载均衡（目标地址和端口交换）
主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
以常见的TCP为例，负载均衡设备在接收到第一个来自客户端的SYN请求时，即通过上述方式选择一个最佳的服务器，并对报文中的目标IP地址进行修改（改为后端服务器IP）直接转发给该服务器。TCP的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡只是起到一个类似路由器的转发动作。在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。
实现四层负载均衡的软件有：
F5：硬件负载均衡器，功能好，但成本很高；
LVS：重量级的四层负载软件
Nginx：轻量级的四层负载软件，带缓存功能，正则表达式较灵活；
haproxy：模拟四层转发，较灵活；
2.七层负载均衡（内容交换）
所谓七层负载均衡，也称为“内容交换”，也就是主要通过报文中真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
七层应用负载的好处，是使得整个网络更加智能化。例如访问一个网站的用户流量，可以通过七层的方式，将对图片类的请求转发到特定的图片服务器并可以使用缓存技术；将对文字类的请求可以转发到特定的文字服务器并可以使用压缩技术。实现七层负载均衡的软件有：
haproxy：天生七层负载均衡技能，全面支持七层代理、会话支持、标记，路径转移；
Nginx：只在HTTP协议和mail协议上功能比较好，性能与haproxy差不多；
apache：功能较差；
MySQL proxy：功能尚可；
二、负载均衡算法/策略
1.轮循均衡（Round Robin）
每一次来自网络的请求轮流分配给内部服务器，从1到N，然后重新开始。此种均衡算法适用于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况；
2.权重轮循均衡（Weighted Round Robin）
根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。例如：服务器A的权值被设成1，B的权值是3，C的权值是6，则服务器A，B，C将分别接受10%，30%，60%的服务请求。此种均衡算法确保高性能的服务器得到更多的使用率，避免低性能的服务器负载过重。
3.随机均衡（Random）
把来自网络的请求随机分配给内部的多个服务器。
4.权重随即均衡（Weighted Random）
此种均衡算法类似于权重轮循算法，不过在处理请求分但时是个随机选择的过程。
5.响应速度均衡（Response Time 探测时间）
负载均衡设备对内部各服务器发出一个探测请求（例如ping），然后根据内部中各服务器对探测请求的最快响应时间来决定哪一台服务器来响应客户端的服务请求。此种均衡算法能较好地反映服务器的当前运行状态，但这最快响应时间仅仅指的是负载均衡设备与服务期间的最快响应时间，而不是客户端与服务器间的最快响应时间。
6.最少连接数均衡（Least Connection）
最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录，记录当前该服务器正在处理的连接数量，当有新的服务器请求时，将把当前请求分配给连接数最少的服务器，使均衡更加符合实际情况，负载更加均衡。此种均衡算法适合长时处理的请求服务，如FTP。
7.处理能力均衡（CPU、内存）
此种均衡算法将服务请求分配给内部中处理负荷（根据服务器CPU型号、CPU数量、内存大小及当前连接数等换算而成）最轻的服务器，由于考虑了内部服务器的处理能力及当前网络运行状况，所以此种均衡算法相对来说更加精确，尤其适合运用到第七层（应用层负载均衡的情况下）。
8.DNS响应均衡（Flash DNS）
在此均衡算法下，分处在不同地地理位置的负载均衡设备收到同一个客户端的域名解析请求，并在同一时间把此域名解析成各个相对应服务器的IP地址并返回给客户端，则客户端将以最先收到的域名解析IP地址来继续请求服务，而忽略其他的IP地址响应。此种均衡策略适用于在全局负载均衡的情况下，对本地负载均衡是没有意义的。
9.哈希算法
一致性哈希，相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其他提供者，不会引起剧烈变动。
10.IP地址散列（保证客户端服务器对应关系稳定）
通过管理发送方IP和目的地IP地址的散列，将来自同一发送方的分组（或发送至同一目的地的分组）统一转发到相同服务器的算法。当客户端有一系列业务需要处理而必须和一个服务器反复通信时，该算法能够以流（会话）为单位，保证来自相同客户端的通信能够一直在同一服务器中进行处理。
11.URL散列
通过管理客户端请求URL信息的散列，将发送至相同URL的请求转发至同一服务器的算法。
三、LVS
1.LVS原理
IPVS
LVS的IP负载均衡技术是通过IPVS模式来实现的，IPVS是LVS集群系统的核心软件，它的主要作用是：安装在Director Server上，同时在Director server上虚拟出一个IP地址，用户必须通过这个虚拟的IP地址访问服务器。这个虚拟IP一般称为LVS的VIP，即Virtual IP。访问的请求首先经过VIP到达负载调度器，然后由负载调度器从Real Server列表中选取一个服务节点响应用户的请求。在用户的请求到达负载调度器后，调度器如何将请求发送到提供服务的Real server节点，而real server节点如何返回数据给用户，是IPVS实现的重点技术。
ipvs：工作于内核空间，主要用于使用户定义的策略生效。
ipvsadm：工作于用户空间，主要用于用户定义和管理集群服务的工具。
ipvs工作于内核空间的INPUT链上，当收到用户请求某集群服务时，经过PREROUTING链，经检查本机路由表，送往INPUT链；在进入netfilter的INPUT链时，ipvs强行将请求报文通过ipvsadm定义的集群服务策略的路径改为FORWORD链，将报文转发至后端真实提供服务的主机。
2.LVS NAT模式
1）客户端将请求发往前端的负载均衡器，请求报文源地址是CIP（客户端IP），目标地址为VIP（负载均衡器前端地址）。
2）负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将客户端请求报文的目标地址改为了后端服务器的RIP地址并将报文根据算法发送出去。
3）报文送到Real Server后，由于报文的目标地址是自己，所以会响应该请求，并将响应报文返还给LVS。
4）然后LVS将此报文的源地址修改为本机并发送给客户端。
注意：在NAT模式中，Real Server的网关必须指向LVS，否则报文无法送达客户端。
特点：
1）NAT技术将请求的报文和响应的报文都需要通过LB进行地址改写，因此网站访问量比较大时LB负载均衡调度器有比较大的瓶颈，一般要求最多只能10-20台节点。
2）只需要在LB上配置一个公网IP地址就可以了。
3）每台内部的realserver服务器的网关地址必须是调度器LB的内网地址。
4）NAT模式支持对IP地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致。
优点：集群中的物理服务器可以使用任何支持TCP/IP操作系统，只有负载均衡器需要一个合法的IP地址。
缺点：扩展性有限。当服务器节点（普通PC服务器）增长过多时，负载均衡器将成为整个系统的瓶颈，因为所有请求包和应答包的流向都经过负载均衡器。当服务器节点过多时，大量的数据包都交汇在负载均衡器那，速度就会变慢！
3.LVS DR模式（局域网改写mac地址）
1）客户端将请求发往前端的负载均衡器，请求报文源地址是CIP，目标地址为VIP。
2）负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将客户端请求报文的源MAC地址改为自己DIP的MAC地址，目标MAC改为RIP的MAC地址，并将此包发送给RS。
3）RS发现请求报文中的目的MAC是自己，就会将此报文接收下来，处理完请求报文后，将响应报文通过io接口送给eth0网卡直接发送给客户端。
注意：需要设置io接口的VIP不能响应本地网络内的ARP请求。
总结：
1）通过在调度器LB上修改数据包的目的MAC地址实现转发。注意源地址仍然是CIP，目的地址仍然是VIP地址。
2）请求的报文经过调度器，而RS响应处理后的报文无需经过调度器LB，因此并发访问量大时使用效率高（和NAT模式相比）
3）因为DR模式是通过MAC地址改写机制实现转发，因此所有RS节点和调度器LB只能在一个局域网里面。
4）RS主机需要绑定VIP地址在LO接口（掩码32位）上，并且需要配置ARP抑制。
5）RS节点的默认网关不需要配置成LB，而是直接配置为上级路由的网关，能让RS直接出网就可以。
6）由于DR模式的调度器仅做MAC地址的改写，所以调度器LB就不能改写目标端口，那么RS服务器就得使用和VIP相同得端口提供服务。
7）直接对外的业务比如WEB等，RS得IP最好是使用公网IP。对外的服务，比如数据库等最好使用内网IP。
优点：和TUN（隧道模式）一样，负载均衡器也只是分发请求，应答包通过单独的路由方法返回给客户端。与VS-TUN相比，VS-DR这种实现方式不需要隧道结构，因此可以使用大多数操作系统作为物理服务器。DR模式的效率很高，但是配置稍微复杂一点，因此对于访问量不是特别大的公司可以用haproxy/nginx取代。
缺点：所有RS节点和调度器LB只能在一个局域网里面
4.LVS TUN（IP封装、跨网段）
1）客户端将请求发往前端的负载均衡器，请求报文源地址是CIP，目标地址为VIP。
2）负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将在客户端请求报文的首部再封装一层IP报文，将源地址改为DIP，目标地址改为RIP，并将此包发送给RS。
3）RS收到请求报文后，会首先拆开第一层封装，然后发现里面还有一层IP首部的目标地址是自己lo接口上的VIP，所以会处理此请求报文，并将响应报文通过lo接口送给eth0网卡直接发送给客户端。
注意：需要设置lo接口的VIP不能再公网上出现。
总结：
1）TUNNEL模式必须在所有的realserver机器上面绑定VIP的IP地址
2）TUNNEL模式的VIP----->realserver的包通信通过TUNNRL模式，不管是内网和外网都能通信，所以不需要lvs vip跟realserver在同一个网段内。
3）TUNNEL模式realserver会把packet直接发送给client不会给LVS了
4）TUNNEL模式走的隧道模式，所以运维起来比较难，所以一般不用。
优点：负载均衡器只负责将请求报分发给后端节点服务器，而RS将应答包直接发给用户。所以，减少了负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，就能处理很巨大的请求量。这种方式，一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。
缺点：隧道模式的RS节点需要合法IP，这种方式需要所有的服务器支持“IP Tunneling”（IP Encapsulation）协议，服务器可能只局限在部分Linux系统上。
5.LVS FULLNAT模式
无论是DR还是NAT模式，不可避免的都有一个问题：LVS和RS必须在同一个VLAN下，否则LVS无法作为RS的网关。这引发的两个问题是：
1）同一个VLAN的限制导致运维不方便，跨VLAN的RS无法接入。
2）LVS的水平扩展受到制约。当RS水平扩容时，总有一天其上的单点LVS会成为瓶颈。
Full-NAT由此而生，解决的是LVS和RS跨VLAN的问题，而跨VLAN的问题解决后，LVS和RS不再存在VLAN上的从属关系，可以做到多个LVS对应多个RS，解决水平扩容的问题。
Full-NAT相比NAT的主要改进是，在SNAT/DNAT的基础上，加上另一种转换，转换过程如下：
1）在包从LVS转到RS的过程中，源地址从客户端IP被替换成了LVS的内网IP。内网IP之间可以通过多个交换机跨VLAN通信。目标地址从VIP修改为RS IP。
2）当RS处理完接受到的包，处理完成后返回时，将目标地址修改为LVS IP，源地址修改为RS IP，最终将这个包返回给LVS的内网IP，这一步也不受限于VLAN。
3）LVS收到包后，在NAT模式修改源地址的基础上，再把RS发来的包中的目标地址从LVS内网IP改为客户端的IP，并将源地址修改为VIP。
Full-NAT主要的思想是把网关和其下机器的通信，改为了普通的网络通信，从而解决了跨VLAN的问题。采用这种方式，LVS和RS的部署在VLAN上将不再有任何限制，大大提高了运维部署的便利性。
总结：
1）FULL NAT模式不需要LBIP和realserver IP在同一个网段。
2）FULL NAT因为要更新sorce IP 所以性能正常比NAT模式下降10%。
四、KeepAlive
keepalive起初是为LVS设计的，专门用来监控LVS各个服务节点的状态，后来加入了VRRP的功能，因此除了LVS，也可以作为其他服务的高可用软件。VRRP是虚拟路由器冗余协议。VRRP的出现就是为了解决静态路由出现的单点故障，它能够保证网络可以不间断的稳定的运行。所以keepalive一方面具有LVS cluster node healthcheck 功能，另一方面也具有LVS director failover。
五、Nginx反向代理负载均衡
普通的负载均衡软件，如LVS，其实现的功能只是对请求数据包的转发、传递，从负载均衡下的节点服务器来看，接收到的请求还是来自访问负载均衡器的客户端的真实用户；而反向代理就不一样了，反向代理服务器在接受访问用户为请求后，会代理用户重新发起请求代理下的节点服务器，最后把数据返回给客户端用户。在节点服务器看来，访问的节点服务器的客户端用户就是反向代理服务器，而非真实的网站访问用户。
1.upstream_module和健康监测
ngx_http_upstream_module是负载均衡模块，可以实现网站的负载均衡功能，即节点的健康检查，upstream模块允许Nginx定义一组或多组节点服务器组，使用时可通过proxy_pass代理方式把网站的请求发送到事先定义好的对应upstream组的名字上。
2.proxy_pass请求转发
proxy_pass指令属于ngx_http_proxy_module模块，此模块可以将请求转发到另一台服务器，在实际的反向代理工作中，会通过location功能匹配指定的URI，然后把接收到服务匹配URI的请求通过proxy_pass抛给定义的upstream节点池。
location /download/{
proxy_pass http://download/video/;
}
#这是前端代理节点的设置
#交给后端upstream为download的节点
