负载均衡集群

1、集群是什么？

① 集群（cluster）技术是一种较新的技术，通过集群技术，可以在付出较低成本的情况下获得在性能、可靠性、灵活性方面的相对较高的收益，其任务调度则是集群系统中的核心技术。

② 集群是一组相互独立的、通过高速网络互联的计算机，它们构成了一个组，并以单一系统的模式加以管理。一个客户与集群相互作用时，集群像是一个独立的服务器。

③ 集群组成后，可以利用多个计算机和组合进行海量请求处理（ 负载均衡 ），从而获得很高的处理效率，也可以用多个计算机做备份（高可用），使得任何一个机器坏了整个系统还是能正常运行。集群在目前互联网公司是必备的技术，极大提高互联网业务的可用性和可缩放性。

2、负载均衡集群技术

① 负载均衡（Load Balance）：负载均衡集群为企业需求提供了可解决容量问题的有效方案。负载均衡集群使负载可以在计算机集群中尽可能平均地分摊处理。

② 负载通常包括应用程序处理负载和网络流量负载。这样的系统非常适合向使用同一组应用程序的大量用户提供服务。每个节点都可以承担一定的处理负载，并且可以实现处理负载在节点之间的动态分配，以实现负载均衡。对于网络流量负载,当网络服务程序接受了高入网流量，以致无法迅速处理，这时，网络流量就会发送给在其它节点上运行的网络服务程序。也可根据服务器的承载能力，进行服务请求的分发，从而使用户的请求得到更快速的处理。

3、负载均衡集群技术的实现

负载均衡（Load Balance）

负载均衡技术类型：基于 4 层负载均衡技术和基于 7 层负载均衡技术

负载均衡实现方式：硬件负载均衡设备或者软件负载均衡

硬件负载均衡产品： F5 BIG-IP 、Citrix Netscaler  、深信服 、Array 、Radware

软件负载均衡产品： LVS （Linux Virtual Server）、 Haproxy、Nginx、Ats（apache traffic server）

4、实现效果如图

5、负载均衡分类

负载均衡根据所采用的设备对象（ 软/硬件负载均衡 ），应用的OSI网络层次（ 网络层次上的负载均衡 ），及应用的地理结构（ 本地/全局负载均衡 ）等来分类。本文着重介绍的是根据应用的 OSI 网络层次来分类的两个负载均衡类型。

我们先来看一张图，相信很多同学对这张图都不陌生，这是一张网络模型图，包含了 OSI 模型及 TCP/IP 模型，两个模型虽然有一点点区别，但主要的目的是一样的，模型图描述了通信是怎么进行的。它解决了实现有效通信所需要的所有过程，并将这些过程划分为逻辑上的层。层可以简单地理解成数据通信需要的步骤。

根据负载均衡所作用在 OSI 模型的位置不同，负载均衡可以大概分为以下几类：

二层负载均衡（mac）

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

三层负载均衡（ip）

一般采用虚拟IP地址方式，外部对虚拟的ip地址请求，负载均衡接收后分配后端实际的IP地址响应。

四层负载均衡（tcp）

在三层负载均衡的基础上，用ip+port接收请求，再转发到对应的机器。

七层负载均衡（http）

根据虚拟的url或IP，主机名接收请求，再转向相应的处理服务器。

在实际应用中，比较常见的就是四层负载及七层负载。这里也重点说下这两种负载。

6、四层负载均衡（基于IP+端口的负载均衡）

所谓四层负载均衡，也就是主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

layer4

1在三层负载均衡的基础上，通过发布三层的IP地址（VIP），然后加四层的端口号，来决定哪些流量需要做负载均衡，对需要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。

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

3对应的负载均衡器称为四层交换机（L4 switch），主要分析IP层及TCP/UDP层，实现四层负载均衡。此种负载均衡器不理解应用协议（如HTTP/FTP/MySQL等等）要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。

4实现四层负载均衡的软件有：

F5：硬件负载均衡器，功能很好，但是成本很高。

lvs：重量级的四层负载软件

nginx：轻量级的四层负载软件，带缓存功能，正则表达式较灵活

haproxy：模拟四层转发，较灵活

7、七层的负载均衡（基于虚拟的URL或主机IP的负载均衡)

所谓七层负载均衡，也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

layer7

1在四层负载均衡的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，比如同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否需要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子，如果你的Web服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。

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

3对应的负载均衡器称为七层交换机（L7 switch），除了支持四层负载均衡以外，还有分析应用层的信息，如HTTP协议URI或Cookie信息，实现七层负载均衡。此种负载均衡器能理解应用协议。

4实现七层负载均衡的软件有：

haproxy：天生负载均衡技能，全面支持七层代理，会话保持，标记，路径转移；

nginx：只在http协议和mail协议上功能比较好，性能与haproxy差不多；

apache：功能较差

Mysql proxy：功能尚可。

8、四层负载与七层负载的区别

举个例子形象的说明：四层负载均衡就像银行的自助排号机，每一个达到银行的客户根据排号机的顺序，选择对应的窗口接受服务；而七层负载均衡像银行大堂经理，先确认客户需要办理的业务，再安排排号。这样办理理财、存取款等业务的客户，会根据银行内部资源得到统一协调处理，加快客户业务办理流程。

总结：从上面的对比看来四层负载与七层负载最大的区别就是效率与功能的区别。四层负载架构设计比较简单，无需解析具体的消息内容，在网络吞吐量及处理能力上会相对比较高，而七层负载均衡的优势则体现在功能多，控制灵活强大。在具体业务架构设计时，使用七层负载或者四层负载还得根据具体的情况综合考虑。

2、Haproxy 实现四层负载

关于负载均衡，经常听到四层负载均衡和七层负载均衡的说法，他们之间有什么关系和区别呢，今天就简单总结概括下。

也就是说，四层负载均衡是 基于IP+端口 的负载均衡，七层负载均衡是 基于URL 等应用层信息的负载均衡。

同理，还有基于MAC地址的二层负载均衡和基于IP地址的三层负载均衡。

在实际应用中,比较常见的就是四层负载及七层负载。这里也重点说下这两种负载。

  所谓的四到七层负载均衡，就是在对后台的服务器进行负载均衡时， 依据四层的信息或七层的信息来决定怎么样转发流量 。 比如四层的负载均衡，就是通过发布三层的IP地址（VIP），然后加四层的端口号，来决定哪些流量需要做负载均衡，对需要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。七层的负载均衡，就是在四层的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，比如同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否需要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子，如果你的Web服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。

负载均衡器通常称为 四层交换机 或 七层交换机 。那么四层和七层两者到底区别在哪里？

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

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

  七层因为可以代理任意修改和处理用户的请求，所以可以使整个应用更加智能化和安全，代价就是设计和配置会更复杂。所以是否有必要使用七层负载均衡是一个需要权衡的问题。

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

Linux集群原理

Linux集群系统包括集群节点和集群管理器两部分。集群节点有时简称为节点、服务器或服务器节点，是提供处理资源的系统，它进行集群的实际工作。一般来讲，它必须进行配置才能成为集群的一部分，也必须运行集群的应用软件。应用软件可以是专用于集群的软件，也可以是设计用于分布式系统的标准软件。Linux集群管理器则是将节点捆绑在一起，以构成单一系统外观的逻辑结构，它用于将任务分解到所有的节点。

集群因多种不同的原因而有着不同的类型，建立Linux集群的最直接原因是共享CPU资源，在多个机器之间平衡负载，获得更多的系统可靠性，或在主机失败时提供后备系统(切换)。

通过对相关软件的分析，实现集群负载的功能是通过流量管理实现的，具体有以下几种实现方法：直接路由(Direct Forwarding)、网络地址转换(NAT)和隧道技术(Tunneling)。

直接路由(Direct Forwarding)是当参与集群的计算机和作为控制管理的计算机在同一个网段时可以使用此法。控制管理的计算机接收到请求包时，直接送到参与集群的节点。它的优点是返回给客户的流量不经过控制主机，速度快、开销少。

可能大家比较熟悉网络地址转换(NAT)这种方法。地址转换器有能被外界访问到的合法IP地址，它修改来自专有网络的流出包的地址，外界看起来包是来自地址转换器本身。当外界包送到转换器时，它能判断出应该将包送到内部网的哪个节点。它的优点是节省IP地址，能对内部进行伪装;缺点是效率低，因为返回给请求方的流量要经过转换器。

隧道技术(Tunneling)这种方式是Linux集群的节点不在同一个网段时采用的转发机制，是将IP包封装在其它网络流量中。从安全角度考虑，应该使用隧道技术中的***,也可使用租用专线。

Linux集群所能提供的服务是基于TCP/IP的Web服务、Mail服务、News服务、DNS服务和Proxy服务器等。下面我就以一个具体的产品TurboLinux Cluster Server 来实现一个负载均衡Linux集群系统，用于提供Web和FTP服务。

Linux集群规划

1提供的服务：Web、FTP

2做一个较完善的负载均衡系统，以便能用到其中较多的功能。

3使用4台服务器，其中3台安装TurboLinux Cluster Server,1台安装Windows 2000 Sever

Linux集群安装

1在3台服务器上安装Turbo Linux,还需要安装Apache和wu-ftpd,因为Linux集群要提供这种服务。安装完成后重启机器，挂接光驱在目录/mnt/cdrom下，执行。/TLCS-install,然后按提示完全安装。

2在1台服务器上安装Windows 2000 Server,还要安装Internet Information Server 50

配置Linux集群管理器

1设置各台服务器的IP地址、子网掩码、路由等，调通网络，并将1台TurboLinux服务器设置成DNS服务器，使其能够正向解析和反向解析。此例服务器名为pc1,域为testcom

2配置Cluster Server执行TurboLinuxclusteradmin,设置情况如下(连字符连接的是选单选项或其下级选单，冒号后为设置情况)：

(1)ClusterServer Configuration-Cluster Services-Application Stability Agents:

http为默认的服务，不用设置。

ftp:/usr/lib/ftpAgent

(2)ClusterServer Configuration--Cluster Services--Service Settings:

http,80:TCP,sticky

ftp,21:TCP,ftp

(3)ClusterServer Configuration--Servers Configuration:

pc1 (pc1testcom)，direct,ping

pc2 (pc2testcom)，direct,ping

pc3 (pc3testcom)，direct,ping

pc4 (pc4testcom)，direct,ping

(4)ClusterServer Configuration--Advance Traffic Managers:

Advance Traffic Manager System:pc1testcom

Advance Traffic Manager Setting: 默认值

(5)ClusterServer ConfigurationàVirtual Severs:

主机为：pc1testcom

sendmail:master@pc1 testcom

Server pool name: Server Group1

(6)ClusterServer ConfigurationàGloble Settings:

网络设置：netmask 2552552550

配置集群各节点

1配置Windows 2000 Server节点

因为TurboLinux Cluster Server 本身能被工具自动同步，所以只要配置Windows 2000 Server即可。

(1)开始→设置→控制面板→添加新硬件→下一步→添加/排除设备故障→添加新设备→否，再从列表选择硬件→其它设备→Microsoft:Microsoft Loopback Adapter→完成。

(2)在桌面上单击鼠标右键选择网上邻居→属性→TCP/IP,设置IP地址、缺省网关、子网掩码(先设成 2552552550)。

(3)开始→运行→regedit→找到注册表中与Microsoft Loopback Adapter相关的项，将子网掩码改成 255255255255

(4)配置系统运行合适的服务，并配置适合集群管理器管理的配置，以便可在控制管理器中使用。

2配置Turbo Linux Cluster Server节点

(1)在管理菜单中选tlcs_content _sync执行内容同步，输入将要配置的节点机密码，将复制集群管理器中的服务内容到节点。

(2)在管理菜单中选择tlcs_ config _sync执行设置同步，输入将要配置的节点机密码，复制集群管理器中的设置内容到节点。

到此，我们已经可以在集群管理器PC1上看到运行状态，可将客户端连在接服务器的交换机上，客户端可以请求Web和FTP服务。

你可以直接买一台负载均衡交换机啊，何必要浪费1台服务器呢。

2 应该是每台都会有一个IP地址 外网 访问连接到的那个IP地址 是你的负载均衡交换机的IP地址 他随机把你的访问请求分配到你的3台服务器上

3 无主从关系，负载均衡交换机它会没2秒左右向你的服务器发送一个健康检查，如果发现你的服务器出现问题，它会自动屏蔽你这台服务器

4 你问的重复问题。

它们是按SMP、NUMA、MPP、集群、分布处理从最紧密到最松散的排列。　　SMP(多处理系统):这种系统是在一台计算机里有多个CPU,CPU之间的地位是平等的，它们共享内存空间和I/O设备。其工作方法是由操作系统负责将任务分解成多个并发进程，然后让其在不同的CPU上运行。　　NUMA(非统一内存存取):这种系统可以让多处理计算机的CPU比SMP更高效地共享本地内存，CPU可以更快速地存取单一的内存区域，不过如需要也可以用间接方式存取其他区域的内存，这种方法是让某些CPU在给定范围的物理内存中有更大的优先使用权。　　MPP(巨型并行处理):这种系统的节点都有自己的CPU，并有自己的专有资源。此种结构相对独立，但各个节点一般没有完全存取I/O的能力。　　集群:集群系统是由独立的计算机组成，但有控制管理工具统一管理。　　分布处理:它是比我们要构筑的集群系统更松散的连接，一般是任务在不同的地方完成，没有可以作为整体管理的单一实体。　　以上的聚合方式有紧有疏，它们都有自己的适用范围，这里就不多说了，有兴趣可自己找些资料看，这里只是想让大家了解它所处的位置。　　实现负载均衡的方法　　集群的目的是共享和高效地利用资源，提供大型运算，提供负载均衡分配请求压力以及出现故障时能够进行切换实现高可用性。　　限于篇幅，本文只对负载均衡的实现做些介绍(针对TurboLinux Cluster Server)。通过对相关软件的分析，实现集群负载的功能是通过流量管理实现的，具体有这样几种实现方法:直接路由(Direct forwarding)、网络地址转换(NAT)、隧道技术(Tunneling)。　　直接路由(Direct forwarding)　　当参与集群的计算机和作为控制管理的计算机在同一个网段时可以用此法，控制管理的计算机接收到请求包时直接送到参与集群的节点。优点是返回给客户的流量不经过控制主机，速度快开销少。　　网络地址转换(NAT)　　这种方法可能大家较熟悉，地址转换器有能被外界访问到的合法IP地址，它修改来自专有网络的流出包的地址，外界看起来包是来自地址转换器本身，当外界包送到转换器时，它能判断出应该将包送到内部网的哪个节点。优点是节省IP地址，能对内部进行伪装;缺点是效率低，因为返回给请求方的流量经过转换器。　　隧道技术(Tunneling)　　这种方式是在集群的节点不在同一个网段时可用的转发机制，是将IP包封装在其他网络流量中的方法，为了安全的考虑，应该使用隧道技术中的***,也可使用租用专线。　　集群所能提供的服务是基于TCP/IP的Web服务、Mail服务、News服务、DNS服务、Proxy服务器等等，下面我们将就具体的产品TurboLinux Cluster Server 来实现一个进行负载均衡集群系统，用于提供Web和FTP的服务。　　四台服务器的负载均衡实例　　所提供的服务:Web、FTP。　　系统的实现目的:做一个较完善负载均衡的系统，以便能用到其中的较多的功能。　　采用设备状况:使用四台服务器，其中3台装TurboLinux Cluster Server,1台安装Windows 2000 Sever。　　系统安装　　1在两台服务器上安装TurboLinux， apache和wu-ftpd也要安装，因为集群要提供这种服务,安装完后重启，挂接光驱在目录/mnt/cdrom下，执 行/TLCS-install,然后按提示完全安装。

章文嵩：研发，原就职alibaba公司，目前就职滴滴；

lvs：2部分组成

ipvsadm：用户空间的命令行工具；用于管理集群服务及集群服务上的RS；

ipvs：是内核中的框架；工作于内核上的netfilter的INPUT钩子上的程序，可根据用户定义的集群实现请求转发；

注意：在lvs主机上，不允许在INPUT链上添加规则，一般不建议与ipvs一同使用filter规则；更不能使用nat规则，任何链接追踪功能都不能开启，链接会话表就限制了会话能力，否则，并发响应能力将大大受到限制；

支持基于TCP UDP SCTP AH EST AH_EST等协议及端口进行调度；

以下部分内容摘自于： https://wwwjianshucom/p/5184c6564ee2

多目标的DNAT；通过将请求报文中的目标地址和目标端口修改为挑选出的某RS的RIP和PORT实现转发；

ipvs工作在INPUT链上，所以只有在INPUT链上才能判断出集群服务，然后才能向后转发，转发时，基于某种调度算法，ipvs自动从后端主机中挑选出一个来响应用户请求，挑选出的主机IP会成为报文目标IP的修改对象；

定义负载均衡集群服务时，要定义集群服务，集群服务的真实主机；

上图为lvs-nat的常见的使用场景，其工作流程如下：

1、客户端的请求发往Director 的VIP。

2、Director发到客户端请求报文后，将报文中的目标Ip修改为集群中的选定的RIP，目标端口80也修改成8080，然后将请求报文发往RS。

3、当RS收到请求报文后，在检查报文的目标IP为自己的RIP后，会接受报文并进行处理响应。响应的源Ip为RIP，目标IP为CIP，端口不变。

4、Director收到RS的响应报文，修改响应报文的源IP为VIP，端口为80，然后转发给客户端。

5、客户端接受响应报文，其源IP为VIP，端口为80，整个过程对于客户端来说是透明无感知的。

通过修改请求报文的MAC地址，重新封装一个MAC首部进行转发；源MAC是DIP所在接口的MAC地址，目标MAC是挑选出的某RS的RIP所在接口的MAC地址；IP首部不会发生变化（依然是CIP<-->VIP）

lvs服务主机与后端服务器主机接在同一交换机上，且每个后端主机都配有vip，为了避免地址冲突，把各后端主机配置的vip进行隔离；

隔离的方法有3种

（1）确保前端路由器将目标IP为VIP的请求报文转发往Director；

（2）RS的RIP可以使用私有地址，也可以使用公网地址；

（3）RS跟Director必须在同一物理网络（基于MAC地址转发）；RS的网关必须不能指向DIP；

（4）请求报文必须由Directory调度，但响应报文必须不能经由Director；

（5）不支持端口映射；

（6）RS可以使用大多数的OS；一般都为Linux系统；

上图为lvs-dr的常见的使用场景,其工作流程如下：

1、客户端的请求会发往Director，此时，客户端请求报文的源Ip为CIP，目标Ip为Director的VIP。

2、当Director接受到客户端的请求报文后，Director会在请求报文外封装一个MAC首部，其源MAC为Director接口的MAC地址，目标MAC为选定RS的MAC地址；

3、当RS收到Director转发过来的请求报文后，检查发现请求报文的目标Ip为本地环回接口上配置的VIP，因此会接受报文进行响应处理。另外由于对ARP响应规则做了修改，因此RS不会把响应报文响应给director ，而是响应给GW；

4、客户端接收响应报文，完成通信。

请求报文源IP为cip，目标IP为vip，到达lvs服务进入INPUT链上，在整个ip报文外又加了一层ip首部，即IP报文传输IP报文所以叫IP隧道，此时外层源IP为dip，目标IP为某一个被挑选出来远端的rip，远端的服务主机收到报文经过不断拆包后，将响应报文发给客户端，构建响应报文的源IP为rip，目标IP为cip；

（1）RIP，DIP，VIP全得是公网地址；

（2）RS网关不能指向也不可能指向DIP；

（3）请求报文经由Director转发，但响应报文将直接发往CIP；

（4）不支持端口映射；

（5）RS的OS必须支持隧道功能；

（1）VIP是公网地址，RIP和DIP一般是私网地址，且通常不再同一网络中，但需要经由路由器互通；

（2）RS收到的请求报文源IP为DIP，因此响应报文将直接响应给DIP；

（3）请求和响应报文都经由Director；

（4）支持端口映射；

（5）RS可以使用大多数的OS；

负载均衡集群中会话保持的方式

（1）原地址哈希；

（2）会话集群；

（3）会话服务器；

如上图所示：

1客户端的请求会发往Director，此时，客户端请求报文的源IP为CIP，目标IP为Director的VIP

2当Director收到客户端的请求报文时，会将源IP修改为本机的DIP，同时将请求报文中的目标IP修改为后端某个RS的RIP，具体为哪个RS的RIP，取决于LVS使用的具体算法

3当RS收到对应的请求报文时，会发现报文的目标IP就是自己的RIP，于是就会接收报文并处理后进行响应。响应报文的源IP则为RIP，目标IP则为DIP

4当Director收到对应的响应报文时，Director会将响应报文的源IP修改为VIP，目标IP修改为CIP，于是响应报文被发往客户端。

5客户端则会收到响应报文，源IP为VIP，端口为80，而LVS相对于客户端而言，转换过程是透明的。

根据其调度时是否考虑后端主机的当前负载，可分为 静态方法 和 动态方法 两类

基于客户端瘦cookie+服务器端的session机制，在负载均衡时，同一用户被调度不同后端服务器时，为了保持会话连接功能不丢失；当第一次用户请求时，通过调度机制给该用户分配了一个负责响应后端服务器，以后来自该用户的请求就由这个服务器负责响应了，而不再调度，这就叫 源地址哈希 ；

在调度器上有会话追踪表，在这个会话追踪模板中，把用户的IP地址和挑选的后端服务器对应的记录下来，而且定义一个超时时长，在定义的时间内该条目不会删除；所以，用户请求到来时，先检查这个表，把原IP当做k查找，因为哈希就是k/v数据，对应的v就是后端的真实服务器；如果检查有用户的IP对应的记录，则直接将请求报文发给记录中对应的后端真实服务器，而不通过调度；

缺陷 ：当记录的真实服务器挂了时，就没有会话保持记录了；当内网用户同过同一IP地址访问外网时，可能会把内网用户的所有请求都发往会话记录表上的真实服务器，这样负载均衡能力是受到损害的；

解决办法

内网用户请求的目标地址，在调度器上把目标地址绑定到一个代理缓存服务器上，以后，任何用户访问的是该目标地址就发往绑定的代理服务器，代理服务器收到请求后，再发往后端服务器主机，从而实现正向代理负载均衡的作用；

ipvs功能特别强大，一般网站用到的可能性比较小，但面试必会问到；

如果负载不是特别大，使用配置比较麻烦，维护成本较大；

ipvs/ipvsadm的关系相当于netfilter/iptables的关系；

真正提供lvs服务的是ipvs；

因为是根据请求的目标ip地址和目标端口（能识别协议）进行转发；一个ipvs（Director）主机就可同时为多个集群提供服务进行调度；这就是四层交换的原因；只不过一个Director很有可能成为负载均衡的瓶颈；

注意：单个Director可同时为多个集群提供调度服务；

在centos 7系统上：

判断内核是否支持ipvs：

判断ipvsadm程序包是否安装

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

-A：增，添加

-E：修改

ipvsadm -D -t|u|f service-address

-D：删除集群服务；

service-address：定义集群服务的地址

-t：tcp，把tcp端口定义成集群服务，vip:tcp_port；

-u：udp，把udp端口定义成集群服务，vip:udp_port；

-f：Firewalls mark防火墙标记，是一个数字；

-s scheduler：定义集群服务的调度方法，默认为wlc加权最少连接；

ipvsadm -a|e -t|u|f service-address -r server-address [-g|i|m] [-w weight]

-a：增，添加RS；

-e：改，修改RS；

ipvsadm -d -t|u|f service-address

-d：删除

-r server-address：向已存在的service-address（集群服务）添加RS的地址；

rip[:port] 端口省略时，表示不做端口映射，与请求服务的端口为同一端口；有些集群服务不支持端口映射，如lvs-dr，lvs-tun，只要响应报文不经过Director都不支持；

查看： ipvsadm -L|l [options]

-L，--list：列出集群服务；

-n, --numeric：数字格式显示，不反解主机名到ip地址，服务到端口号；

--exact：精确显示数值，不进行单位换算；

-c, --connection：显示当前ipvs连接；可查看后端服务器是否连接；

--stats：统计数据；

--rate：速率；

清空 ：clear

ipvsadm -C

保存和重载

保存：输出重定向

ipvsadm -S > /PATH/TO/SOME_RULE_FILE

ipvsadm-save > /PATH/TO/SOME_RULE_FILE

重载：输入重定向

ipvsadm -R < /PATH/TO/SOME_RULE_FILE

ipvsadm-restore < /PATH/TO/SOME_RULE_FILE

清空计数器：

ipvsadm -Z [-t|u|f service-address]

例如：

例如：

添加集群服务，vip为1721811111提供web服务，指明调度方法为rr；不指明为默认wlc；

在集群服务中添加RS地址为1921682552，类型为lvs-nat，权重为1此值无意义，因为前面已经指明使用rr调度算法

再次添加一个RS

再次添加一个集群服务

在另一个集群服务上添加2个RS

修改集群服务的调度方法为wrr

注意：修改只能改属性，不能改IP地址；只有删除集群服务才能从新改IP地址；

修改RS的权重值为10

保存集群服务规则至指定路径

查看保存的内容：

清空集群服务

重载集群服务配置文件

下次开机时会自动载入集群服务规则：

所以，可把规则保存在/etc/sysconfig/ipvsadm文件中；

[root@VM_0_2_centos ~]# ipvsadm-save > /etc/sysconfig/ipvsadm

一般手动保存后（确保保存无误），下次开机时，会自动重载此文件；

需要开机自动有效：

[root@VM_0_2_centos ~]# systemctl enable ipvsadmservice

lvs-nat设计要点：

（1）DIP与RIP要在同一IP网络，RIP的网关要指向DIP；

（2）支持端口映射；

（3）是否用到共享存储，取决于业务需要；

1、配置RS1

2、配置RS2

3、配置Director

打开网卡核心转发功能；永久有效：

查看内核参数是否打开核心转发功能

此时，在Director测试，访问RS1、RS2；

添加ipvs集群：

在另一台虚拟机上测试，调度是否起作用：

测试主机为：1721811111

修改Director上的调度方式为wrr

再到测试主机为：1721811111，测试wrr的调度效果

经过多次请求测试后，有明显wrr调度效果；

其RS服务器响应权重比是1:2，即RS1响应1次后RS响应2次；

数据同步：rsync+inotify

响应报文不用经过Director，每个RS必须配置VIP，为了避免地址冲突，有3种方式：

在各主机（Director，RS）均需要配置VIP，因此，要解决地址的冲突的问题，目标是让各RS上的VIP不可见，仅用接收目标地址为VIP的报文，同时可作为响应报文的源地址；

（1）在前端的网关接口上静态绑定（vip+mac）；

缺陷：一旦Director挂了，基于高可用转移另外节点上无法实现；而且，要在网关上有权限操作；

（2）在各RS上使用arptables；添加规则，拒绝自己的VIP地址向外通告及响应arp解析地址的请求；

（3）在各RS上修改内核参数，来限制arp响应和通告；

注意：要将VIP配置在lo的别名上，不能配置在网卡的别名上；

在各RS上设置arp通告级别即修改两个内核参数arp_ignore、arp_announce，因为地址是属于内核的，所以在Linux主机默认的通告方式是所有本机的可用IP地址通告给每个接口；

arp_announce要限制通告级别，每一个网卡仅在把自己的网络地址向所在物理网络中通告，即各网卡间地址绝不交叉通告；arp_announce设置为2；

arp_ignore是限制响应别人arp请求的级别；默认响应请求是无论从哪个接口接收到arp请求，只要本机有这个地址都会响应；限制arp响应级别后可实现，从哪个网卡接收的arp请求，

必须与该接口属于同一网络时才响应；arp_ignore`设置为1

lvs-dr设计要点：

（1）各主机一个接口即可，但需要在同一物理网络中；

（2）RIP的网关不能指向DIP，RIP和DIP通常应在同一网络，但此二者未必会与VIP在同一网络；

（3）各RS需要先设置内核参数，再设置VIP和路由；

搭建网络环境

1、配置Director

2、配置RS1

3、配置RS2

4、访问测试

在RS2主机运行

在报文进入时，进行打标记，例如目标IP是VIP端口80，把这类报文分拣出来打标，标记一般为十六进制整数，例如标记1；在input链上定义集群服务时，就可判定如果防火墙标记为1，则为集群服务；把本来在input链上完成识别、定义集群服务分成了两步，识别在prerouting做，定义在ipvs（inputing）上实现；

在mangle表上的prerouting链上，目标ip（VIP）为17218117，目标端口为80，打标记为1；

mark标记里包含了IP地址和端口；定义集群服务时使用mark即可；

打标记的方法：

iptables -t mangle -A PREROUTING -d $vip -p $protocol --dport $clusterserverport -j MARK --set-mark #

#：代表十六进制整数；

打标作用 ：提供辅助持久连接功能；在多个端口定义服务时，可把相关作为一个集群来调度；

配置RS1：

配置RS2：

在Director创建CA：

在RS1主机：

在CA服务上签证并传回给RS1：

在各RS主机重启web服务并查看443端口是否监听：

手动测试直接访问RS的IP：

测试请求，OK可以响应页面；-k表示可接受不受信任的页面响应；

单机测试ok，下面绑定80和443服务，打标记：

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

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

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

Haproxy：

lvs:

nginx:

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

程序环境：

主程序：/usr/sbin/haproxy

主配置文件：/etc/haproxy/haproxycfg

Unit file：/usr/lib/systemd/system/haproxyservice

查看配置文件

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

发现日志发送给本机rsyslog的local2的facility，而本机的rsyslog里并没有定义，需要我们自己去配置

所以vim /etc/rsyslogconf添加一段将local2的所有信息记录在对应日志文件中

由于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条件的时候默认使用哪个后端

这些例子定义了www_policy、bbs_policy、url_policy三个ACL规则，第一条规则表示如果客户端以 wwwzcn 或 zcn 开头的域名发送请求时，则此规则返回true，同理第二条规则表示如果客户端通过 bbszcn 域名发送请求时，则此规则返回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。

与上面的例子类似，本例中也定义了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。

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

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

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

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

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

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

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

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

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

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

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

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

bind：此选项只能在frontend和listen部分进行定义，用于定义一个或几个监听的套接字。bind的使用格式为： bind [<address>:<port_range>] interface <interface>其可以为主机名或IP地址，如果将其设置为“”或“0000”，将监听当前系统的所有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就是一个后端服务器组。

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

option abortonclose：如果设置了此参数，可以在服务器负载很高的情况下，自动结束当前队列中处理时间比较长的连接。

-balance：此关键字用来定义负载均衡算法。目前HAProxy支持多种负载均衡算法，常用的有如下几种：

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

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

option httpchk的用法如下： option httpchk <method> <uri> <version> 其中，各个参数的含义如下：

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：设置后端真实服务器的备份服务器，仅仅在后端所有真实服务器均不可用的情况下才启用。

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

在两台tomcat主机上创建应用

nginx配置

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