linux负载均衡总结性说明;四层负载和七层负载有什么区别

负载均衡分类

1&＃xff09;二层负载均衡&＃xff08;mac&＃xff09;
根据OSI模型分的二层负载&＃xff0c;一般是用虚拟mac地址方式&＃xff0c;外部对虚拟MAC地址请求&＃xff0c;负载均衡接收后分配后端实际的MAC地址响应&＃xff09;

2&＃xff09;三层负载均衡&＃xff08;ip&＃xff09;
一般采用虚拟IP地址方式&＃xff0c;外部对虚拟的ip地址请求&＃xff0c;负载均衡接收后分配后端实际的IP地址响应&＃xff09;

3&＃xff09;四层负载均衡&＃xff08;tcp&＃xff09;
在三次负载均衡的基础上&＃xff0c;用ip&＃43;port接收请求&＃xff0c;再转发到对应的机器。

4&＃xff09;七层负载均衡&＃xff08;http&＃xff09;
根据虚拟的url或IP&＃xff0c;主机名接收请求&＃xff0c;再转向相应的处理服务器&＃xff09;。

在运维中最常见的四层和七层负载均衡&＃xff0c;这里重点说下这两种负载均衡。

1&＃xff09;四层的负载均衡就是基于IP&＃43;端口的负载均衡&＃xff1a;在三层负载均衡的基础上&＃xff0c;通过发布三层的IP地址&＃xff08;VIP&＃xff09;&＃xff0c;然后加四层的端口号&＃xff0c;来决定哪些流量需要做负载均衡&＃xff0c;对需要处理的流量进行NAT处理&＃xff0c;转发至后台服务器&＃xff0c;并记录下这个TCP或者UDP的流量是由哪台服务器处理的&＃xff0c;后续这个连接的所有流量都同样转发到同一台服务器处理。
对应的负载均衡器称为四层交换机&＃xff08;L4 switch&＃xff09;&＃xff0c;主要分析IP层及TCP/UDP层&＃xff0c;实现四层负载均衡。此种负载均衡器不理解应用协议&＃xff08;如HTTP/FTP/MySQL等等&＃xff09;。
实现四层负载均衡的软件有&＃xff1a;
F5&＃xff1a;硬件负载均衡器&＃xff0c;功能很好&＃xff0c;但是成本很高。
lvs&＃xff1a;重量级的四层负载软件
nginx&＃xff1a;轻量级的四层负载软件&＃xff0c;带缓存功能&＃xff0c;正则表达式较灵活
haproxy&＃xff1a;模拟四层转发&＃xff0c;较灵活

2&＃xff09;七层的负载均衡就是基于虚拟的URL或主机IP的负载均衡&＃xff1a;在四层负载均衡的基础上&＃xff08;没有四层是绝对不可能有七层的&＃xff09;&＃xff0c;再考虑应用层的特征&＃xff0c;比如同一个Web服务器的负载均衡&＃xff0c;除了根据VIP加80端口辨别是否需要处理的流量&＃xff0c;还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子&＃xff0c;如果你的Web服务器分成两组&＃xff0c;一组是中文语言的&＃xff0c;一组是英文语言的&＃xff0c;那么七层负载均衡就可以当用户来访问你的域名时&＃xff0c;自动辨别用户语言&＃xff0c;然后选择对应的语言服务器组进行负载均衡处理。
对应的负载均衡器称为七层交换机&＃xff08;L7 switch&＃xff09;&＃xff0c;除了支持四层负载均衡以外&＃xff0c;还有分析应用层的信息&＃xff0c;如HTTP协议URI或COOKIE信息&＃xff0c;实现七层负载均衡。此种负载均衡器能理解应用协议。
实现七层负载均衡的软件有&＃xff1a;
haproxy&＃xff1a;天生负载均衡技能&＃xff0c;全面支持七层代理&＃xff0c;会话保持&＃xff0c;标记&＃xff0c;路径转移&＃xff1b;
nginx&＃xff1a;只在http协议和mail协议上功能比较好&＃xff0c;性能与haproxy差不多&＃xff1b;
apache&＃xff1a;功能较差
Mysql proxy&＃xff1a;功能尚可。

总的来说&＃xff0c;一般是lvs做4层负载&＃xff1b;nginx做7层负载&＃xff1b;haproxy比较灵活&＃xff0c;4层和7层负载均衡都能做。

两者之间的区别&＃xff1a;

1&＃xff09;从技术原理上分析

      所谓四层负载均衡&＃xff0c;也就是主要通过报文中的目标地址和端口&＃xff0c;再加上负载均衡设备设置的服务器选择方式&＃xff0c;决定最终选择的内部服务器。
      以常见的TCP为例&＃xff0c;负载均衡设备在接收到第一个来自客户端的SYN 请求时&＃xff0c;即通过上述方式选择一个最佳的服务器&＃xff0c;并对报文中目标IP地址进行修改(改为后端服务器IP&＃xff09;&＃xff0c;直接转发给该服务器。TCP的连接建立&＃xff0c;即三次握手是客户端和服务器直接建立的&＃xff0c;负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下&＃xff0c;为保证服务器回包可以正确返回给负载均衡设备&＃xff0c;在转发报文的同时可能还会对报文原来的源地址进行修改。

  所谓七层负载均衡&＃xff0c;也称为“内容交换”&＃xff0c;也就是主要通过报文中的真正有意义的应用层内容&＃xff0c;再加上负载均衡设备设置的服务器选择方式&＃xff0c;决定最终选择的内部服务器。
      以常见的TCP为例&＃xff0c;负载均衡设备如果要根据真正的应用层内容再选择服务器&＃xff0c;只能先代理最终的服务器和客户端建立连接(三次握手)后&＃xff0c;才可能接受到客户端发送的真正应用层内容的报文&＃xff0c;然后再根据该报文中的特定字段&＃xff0c;再加上负载均衡设备设置的服务器选择方式&＃xff0c;决定最终选择的内部服务器。负载均衡设备在这种情况下&＃xff0c;更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。所以从这个技术原理上来看&＃xff0c;七层负载均衡明显的对负载均衡设备的要求更高&＃xff0c;处理七层的能力也必然会低于四层模式的部署方式。

2&＃xff09;从应用场景的需求上分析

     七层应用负载的好处&＃xff0c;是使得整个网络更"智能化"。可以参考这篇&＃xff1a;http应用优化和加速说明-负载均衡&＃xff0c;就可以基本上了解这种方式的优势所在。例如访问一个网站的用户流量&＃xff0c;可以通过七层的方式&＃xff0c;将对图片类的请求转发到特定的图片服务器并可以使用缓存技术&＃xff1b;将对文字类的请求可以转发到特定的文字服务器并可以使用压缩技术。当然这只是七层应用的一个小案例&＃xff0c;从技术原理上&＃xff0c;这种方式可以对客户端的请求和服务器的响应进行任意意义上的修改&＃xff0c;极大的提升了应用系统在网络层的灵活性。很多在后台&＃xff0c;例如Nginx或者Apache上部署的功能可以前移到负载均衡设备上&＃xff0c;例如客户请求中的Header重写&＃xff0c;服务器响应中的关键字过滤或者内容插入等功能。

     另外一个常常被提到功能就是安全性。网络中最常见的SYN Flood攻击&＃xff0c;即黑客控制众多源客户端&＃xff0c;使用虚假IP地址对同一目标发送SYN攻击&＃xff0c;通常这种攻击会大量发送SYN报文&＃xff0c;耗尽服务器上的相关资源&＃xff0c;以达到Denial of Service(DoS)的目的。从技术原理上也可以看出&＃xff0c;四层模式下这些SYN攻击都会被转发到后端的服务器上&＃xff1b;而七层模式下这些SYN攻击自然在负载均衡设备上就截止&＃xff0c;不会影响后台服务器的正常运营。另外负载均衡设备可以在七层层面设定多种策略&＃xff0c;过滤特定报文&＃xff0c;例如SQL Injection等应用层面的特定攻击手段&＃xff0c;从应用层面进一步提高系统整体安全。

     现在的7层负载均衡&＃xff0c;主要还是着重于应用HTTP协议&＃xff0c;所以其应用范围主要是众多的网站或者内部信息平台等基于B/S开发的系统。 4层负载均衡则对应其他TCP应用&＃xff0c;例如基于C/S开发的ERP等系统。

3&＃xff09;七层应用需要考虑的问题

1.是否真的必要。七层应用的确可以提高流量智能化&＃xff0c;同时必不可免的带来设备配置复杂&＃xff0c;负载均衡压力增高以及故障排查上的复杂性等问题。在设计系统时需要考虑四层七层同时应用的混杂情况。

2.是否真的可以提高安全性。例如SYN Flood攻击&＃xff0c;七层模式的确将这些流量从服务器屏蔽&＃xff0c;但负载均衡设备本身要有强大的抗DDoS能力&＃xff0c;否则即使服务器正常而作为中枢调度的负载均衡设备故障也会导致整个应用的崩溃。

3.是否有足够的灵活度。七层应用的优势是可以让整个应用的流量智能化&＃xff0c;但是负载均衡设备需要提供完善的七层功能&＃xff0c;满足客户根据不同情况的基于应用的调度。最简单的一个考核就是能否取代后台Nginx或者Apache等服务器上的调度功能。能够提供一个七层应用开发接口的负载均衡设备&＃xff0c;可以让客户根据需求任意设定功能&＃xff0c;才真正有可能提供强大的灵活性和智能性。

4&＃xff09;总体对比

1.智能性

七层负载均衡由于具备OIS七层的所有功能&＃xff0c;所以在处理用户需求上能更加灵活&＃xff0c;从理论上讲&＃xff0c;七层模型能对用户的所有跟服务端的请求进行修改。例如对文件header添加信息&＃xff0c;根据不同的文件类型进行分类转发。四层模型仅支持基于网络层的需求转发&＃xff0c;不能修改用户请求的内容。

2.安全性

七层负载均衡由于具有OSI模型的全部功能&＃xff0c;能更容易抵御来自网络的攻击&＃xff1b;四层模型从原理上讲&＃xff0c;会直接将用户的请求转发给后端节点&＃xff0c;无法直接抵御网络攻击。

3.复杂度

四层模型一般比较简单的架构&＃xff0c;容易管理&＃xff0c;容易定位问题&＃xff1b;七层模型架构比较复杂&＃xff0c;通常也需要考虑结合四层模型的混用情况&＃xff0c;出现问题定位比较复杂。

4.效率比

四层模型基于更底层的设置&＃xff0c;通常效率更高&＃xff0c;但应用范围有限&＃xff1b;七层模型需要更多的资源损耗&＃xff0c;在理论上讲比四层模型有更强的功能&＃xff0c;现在的实现更多是基于http应用。

五、负载均衡策略

在实际应用中&＃xff0c;我们可能不想仅仅是把客户端的服务请求平均地分配给内部服务器&＃xff0c;而不管服务器是否宕机。而是想使Pentium III服务器比Pentium II能接受更多的服务请求&＃xff0c;一台处理服务请求较少的服务器能分配到更多的服务请求&＃xff0c;出现故障的服务器将不再接受服务请求直至故障恢复等等。选择合适的负载均衡策略&＃xff0c;使多个设备能很好的共同完成任务&＃xff0c;消除或避免现有网络负载分布不均、数据流量拥挤反应时间长的瓶颈。在各负载均衡方式中&＃xff0c;针对不同的应用需求&＃xff0c;在OSI参考模型的第二、三、四、七层的负载均衡都有相应的负载均衡策略。
负载均衡策略的优劣及其实现的难易程度有两个关键因素&＃xff1a;负载均衡算法&＃xff1b;对网络系统状况的检测方式和能力。

1、负载均衡算法

1&＃xff09;轮循均衡&＃xff08;Round Robin&＃xff09;&＃xff1a;每一次来自网络的请求轮流分配给内部中的服务器&＃xff0c;从1至N然后重新开始。此种均衡算法适合于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。
2&＃xff09;权重轮循均衡&＃xff08;Weighted Round Robin&＃xff09;&＃xff1a;根据服务器的不同处理能力&＃xff0c;给每个服务器分配不同的权值&＃xff0c;使其能够接受相应权值数的服务请求。例如&＃xff1a;服务器A的权值被设计成1&＃xff0c;B的权值是 3&＃xff0c;C的权值是6&＃xff0c;则服务器A、B、C将分别接受到10%、30&＃xff05;、60&＃xff05;的服务请求。此种均衡算法能确保高性能的服务器得到更多的使用率&＃xff0c;避免低性能的服务器负载过重。
3&＃xff09;随机均衡&＃xff08;Random&＃xff09;&＃xff1a;把来自网络的请求随机分配给内部中的多个服务器。
4&＃xff09;权重随机均衡&＃xff08;Weighted Random&＃xff09;&＃xff1a;此种均衡算法类似于权重轮循算法&＃xff0c;不过在处理请求分担时是个随机选择的过程。
5&＃xff09;响应速度均衡&＃xff08;Response Time&＃xff09;&＃xff1a;负载均衡设备对内部各服务器发出一个探测请求&＃xff08;例如Ping&＃xff09;&＃xff0c;然后根据内部中各服务器对探测请求的最快响应时间来决定哪一台服务器来响应客户端的服务请求。此种均衡算法能较好的反映服务器的当前运行状态&＃xff0c;但这最快响应时间仅仅指的是负载均衡设备与服务器间的最快响应时间&＃xff0c;而不是客户端与服务器间的最快响应时间。
6&＃xff09;最少连接数均衡&＃xff08;Least Connection&＃xff09;&＃xff1a;客户端的每一次请求服务在服务器停留的时间可能会有较大的差异&＃xff0c;随着工作时间加长&＃xff0c;如果采用简单的轮循或随机均衡算法&＃xff0c;每一台服务器上的连接进程可能会产生极大的不同&＃xff0c;并没有达到真正的负载均衡。最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录&＃xff0c;记录当前该服务器正在处理的连接数量&＃xff0c;当有新的服务连接请求时&＃xff0c;将把当前请求分配给连接数最少的服务器&＃xff0c;使均衡更加符合实际情况&＃xff0c;负载更加均衡。此种均衡算法适合长时处理的请求服务&＃xff0c;如FTP。 
7&＃xff09;处理能力均衡&＃xff1a;此种均衡算法将把服务请求分配给内部中处理负荷&＃xff08;根据服务器CPU型号、CPU数量、内存大小及当前连接数等换算而成&＃xff09;最轻的服务器&＃xff0c;由于考虑到了内部服务器的处理能力及当前网络运行状况&＃xff0c;所以此种均衡算法相对来说更加精确&＃xff0c;尤其适合运用到第七层&＃xff08;应用层&＃xff09;负载均衡的情况下。
8&＃xff09;DNS响应均衡&＃xff08;Flash DNS&＃xff09;&＃xff1a;在Internet上&＃xff0c;无论是HTTP、FTP或是其它的服务请求&＃xff0c;客户端一般都是通过域名解析来找到服务器确切的IP地址的。在此均衡算法下&＃xff0c;分处在不同地理位置的负载均衡设备收到同一个客户端的域名解析请求&＃xff0c;并在同一时间内把此域名解析成各自相对应服务器的IP地址&＃xff08;即与此负载均衡设备在同一位地理位置的服务器的IP地址&＃xff09;并返回给客户端&＃xff0c;则客户端将以最先收到的域名解析IP地址来继续请求服务&＃xff0c;而忽略其它的IP地址响应。在种均衡策略适合应用在全局负载均衡的情况下&＃xff0c;对本地负载均衡是没有意义的

2、网络系统状况的检测方式

尽管有多种的负载均衡算法可以较好的把数据流量分配给服务器去负载&＃xff0c;但如果负载均衡策略没有对网络系统状况的检测方式和能力&＃xff0c;一旦在某台服务器或某段负载均衡设备与服务器网络间出现故障的情况下&＃xff0c;负载均衡设备依然把一部分数据流量引向那台服务器&＃xff0c;这势必造成大量的服务请求被丢失&＃xff0c;达不到不间断可用性的要求。所以良好的负载均衡策略应有对网络故障、服务器系统故障、应用服务故障的检测方式和能力&＃xff1a;
1&＃xff09;Ping侦测&＃xff1a;通过ping的方式检测服务器及网络系统状况&＃xff0c;此种方式简单快速&＃xff0c;但只能大致检测出网络及服务器上的操作系统是否正常&＃xff0c;对服务器上的应用服务检测就无能为力了。
2&＃xff09;TCP Open侦测&＃xff1a;每个服务都会开放某个通过TCP连接&＃xff0c;检测服务器上某个TCP端口&＃xff08;如Telnet的23口&＃xff0c;HTTP的80口等&＃xff09;是否开放来判断服务是否正常。
3&＃xff09;HTTP URL侦测&＃xff1a;比如向HTTP服务器发出一个对main.html文件的访问请求&＃xff0c;如果收到错误信息&＃xff0c;则认为服务器出现故障。