集群
一、集群分类：
1、负载均衡类集群LBC（Load balancing clusters）
1.1 软件负载均衡
常见的负载均衡软件LVS（Linux Virtual Server）
1.2 硬件负载均衡
性能好，价格昂贵
2、高可用集群HAC（High Available clusters）
3、高可用科学计算集群HPC（High Performance Computing）
4、高可用集群计算集群HPC与负载均衡集群LBC区别：
① 负载均衡集群的单节点所做的任务是一样的，而高可用计算集群每个节点所做任务是不同的。
② 负载均衡集群提升的是工作效率，而高可用计算机集群所做的是减少单个任务消耗的时间。
二、负载均衡集群重点分析
1、LVS介绍
LVS（Linux Virtual Server）即Linux虚拟服务器，是由章文嵩博士主导的开源负载均衡项目，目前LVS已经被集成到Linux内核模块中。该项目在Linux内核中实现了基于IP的数据请求负载均衡调度方案，其体系结构如图所示，终端互联网用户从外部访问公司的外部负载均衡服务器，终端用户的Web请求会发送给LVS调度器，调度器根据自己预设的算法决定将该请求发送给后端的某台Web服务器，比如，轮询算法可以将外部的请求平均分发给后端的所有服务器，终端用户访问LVS调度器虽然会被转发到后端真实的服务器，但如果真实服务器连接的是相同的存储，提供的服务也是相同的服务，最终用户不管是访问哪台真实服务器，得到的服务内容都是一样的，整个集群对用户而言都是透明的。
LVS的专有名词汇总：
Director：负责调度集群的主机；也简称负载调度器、分发器
LB：Load Balance 也就是是负载调度器D
RS：RealServer 真正向外提供服务的服务器
VIP：Virtual IP 向外提供服务的IP，通常此IP绑定域名
RIP：RealServer IP 内部真正提供服务的主机IP
DIP：与内部主机RIP通信的IP，在Director主机上
CIP：客户端IP
2、LVS原理
客户端访问web需经由LVS负载调度器，LVS负载调度器根据特定算法（规则库）将数据包请求转发给真实的web服务器，web服务器的回应数据包到达LVS负载调度器时，LVS负载调度器为了减小自己的压力，并不涉及到流量产生，也不真正接收数据包，而仅仅将数据包做一个地址信息转换（所以这就在性能方面有一点优势）.
LVS负载调度器如果宕机了，集群就GG了,所以为了防止这种情况的发生，需要为其配置高可用！
3、nginx七层负载
4、LVS四层负载与nginx七层负载的区别
① LVS四层负载的负载调度器为了减少自己的压力，仅仅只对数据包做地址信息转换，从客户端到真正的web服务器只有一条完整的TCP连接；而Nginx七层负载，当数据包到达nginx负载调度器时，负载调度器会重新建立一条到真实web服务器的tcp连接，也就是说从客户端到web服务器相当于总共有两条完整的TCP连接。所以在负载均衡上LVS性能是远远优于nginx。
② LVS能识别 协议、主机名、端口、IP等等，既能做B/S架构的负载均衡，又能做例如数据库集群的C/S架构的负载均衡；而nginx只能识别TCP的应用层协议，所以nginx只能做B/S架构的负载均衡
③ LVS不能精确的找到目标，nginx可以通过域名等使命中率更高
举例：
LVS---你去某栋楼找张三，一楼保安告诉你张三在某层楼，你还要自己跑到三层楼一个房间一个房间的找张三；单个TCP连接Nginx---同样你去某栋楼找张三，一楼的保安会跑到某一层楼某一房间把张三叫到你面前；两个完整的TCP连接
两个例子分别代表LVS负载均衡，nginx负载均衡，这两种负载均衡方式不同，保安即代表负载调度器的）
LVS的优点和缺点:
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就简单多了
5、LVS的三种工作模式
LVS可以划分为两个部分，一部分是内核空间的ipvs，ipvs是LVS的核心组件，已经被集成到Linux内核中，用户只需考虑其是否启动了即可。
另一部分是工作在用户空间的ipvsadm，ipvsadm是lvs的命令行管理工具。
5.1 NAT模式
Network Address Translation 网络地址转换
5.1.1 NAT模式原理
当用户想访问web服务器的时候，将会发送一个源地址是12.13.14.15:XXXX（用户端口是随机产生的），目的地址是负载调度器的公网地址14.15.16.17:80的数据包。
当数据包到达LVS负载调度器时，负载调度器将会对数据包做DNAT（D即目的地址）操作，即由特定的算法选择其中一个真实web服务器，并将数据包的目的地址修改为真实web服务器的私有地址192.168.52.11:80（假设选中web服务器1了）。
web服务器1为回应用户的请求将会发送一个源地址是其自身私有地址192.168.52.11：80，目的地址是用户公网地址12.13.14.15:XXXX的数据包，当数据包到达负载调度器时，负载调度器将会对数据包做SNAT操作，将数据包源地址由web服务器1的私有地址转换为负载均衡服务器对外开放的公网IP地址14.15.16.14:80
5.1.2 NAT模式总结
① 集群节点都必须在同一个网络下且真实服务器的网关必须是负载调度器，原因是如果负载调度器不是网关，不经过负载调度器，数据包就无法做DNAT映射，数据包到客户端之后就无法被接受
② RIP（真实服务器的IP）通常是私有IP，仅用于集群节点间通信，如果是公网IP,那么它的网关一般情况下就不是负载调度器，就会出现上述情形
③ LVS支持端口映射；假设客户端访问的是负载调度器的80端口，但是真实的web服务器的端口并不是80，只要在负载调度器中定义好了相应的端口映射关系，那么初始用户数据包到达负载调度器时，DNAT不仅会修改目的IP地址，也会修改目的端口为web服务器的相应端口（选择某一个web服务器是通过特定的算法实现的），数据包的返程也是同样的道理！
④ 负载调度器必须是Linux操作系统，web服务器则无要求
5.2 DR （Direct Routing直接路由）模式
DR模式就是RS服务器与负载调度器都连接在同一个交换机上，属于同一个广播域，即同一个网段。
不管是Director Server还是Real Server上都需要配置VIP，而且RS的VIP是配置在lo接口上的！ 也就是说DR模式中，RS既有VIP，又有RIP
5.2.1 DR模式原理
① 当客户端请求域名访问web服务时，客户端请求的域名经DNS解析到IP后，这个IP是集群对外公开的VIP，当用户请求到达集群网络的前端路由器的时候,请求数据包的源地址为CIP，目标地址为VIP,此时前面的路由器会发广播问谁是VIP,集群中所有的节点都配置有VIP,默认情况下谁先响应路由器，路由器就会将用户请求发给谁,那么这样一来LVS集群系统就没有意义了！所以我们需要一种方法使用户请求的数据包都会发送到DS（负载均衡调度器）
a、在路由器上设置静态路由到DS，弊端是网络出口路由器如果是运营商的路由器，将无权进行MAC地址绑定等操作
b、arptables：
基于MAC地址做访问控制，我们只需要在每台RS上定义arptables规则，如果用户的arp广播请求的目标地址是本机的VIP则不给予响应或者响应的报文发不出去。
那么这个情况所有的RS都不响应arp广播请求，只有Director响应，则报文就必然被发送给Director。
c、kernel paramter:
arp_ignore
arp_announce作用：限定Linux主机对arp广播请求的响应级别，以及向外通告自已ip地址的通告级别。
② 客户端请求数据包到达负载均衡调度器D。到达负载调度器D的数据包：源IP是客户端的IP地址（CIP），目的IP是集群对外公开的IP地址（VIP）,源MAC地址是与负载调度器相连接的路由器的MAC地址（便于理解记为CMAC），目的MAC地址是负载调度器D的MAC地址。
③ 此时负载均衡调度器D首先拆掉报文上的帧首部，帧首部的目的MAC就是负载均衡调度器DS自身，拆掉帧首部以后，查看IP首部和TCP首部，它根据目的IP 和 端口 来确认请求的报文访问的是否为LVS定义过的服务（例如监听在80端口的web集群服务）。如果是定义过的LVS服务，LVS将会根据特定的算法来选中一个RS，并根据ipvs规则来修改报文，并且只会在原有的IP首部之上( 切记源IP、目标IP、源端口、目标端口等等都没有动 )，仅仅是在原有的报文外面又重新封装了一个MAC地址帧首部。此时报文中目的MAC地址为被选中的RS服务器的MAC地址（RMAC）,源MAC地址为负载均衡调度器D的MAC地址。然后数据包通过交换机转发给选中的那个RS。
④ 请求数据包到达对应的RS服务器之后，其链路层检查到目的MAC是自身，到了网络层，发现源IP地址是客户端IP（CIP），目的IP地址是VIP，以此便能判断是本地主机的数据包，于是数据包被转发给用户的应用进程（nginx、apache等），应用程序响应请求，并产生相应数据包，以VIP为源IP地址，确定下一跳和发送网卡设备信息，将数据包发送出去。此时响应数据包的源IP地址是VIP，目的IP地址是客户端IP（CIP），源MAC地址是这台RS的MAC地址，目的MAC地址是下一跳的MAC地址，随后数据包经相连的路由器发送到客户端！
注意数据包返回的时候并没有经过调度器D，而是由RS服务器直接发送给客户端，这样就减轻了调度器D的负担
5.2.2 DR工作模式总结
DR模式总结一句话就是：资源调度服务器D仅拆掉客户端请求数据包的帧首部（更换目的MAC地址），经特定算法决定转发给某一个RS，并将请求数据包的目的MAC地址修改为对应RS的MAC地址，然后由RS自身直接回送数据回应包给客户端。DR模式在三种模式中是性能最好的！因为少了一些拆解、封装数据包的过程。
DR模式中，如果RS上没有配置VIP，那么RS是不会接收请求数据报文的，所以在这里可以看出来集群的每一个RS都要设置VIP！问：那么RS服务器上的VIP应该怎么配置呢？
答: VIP要配置在RS服务器的lo接口上。因为为了让RS能够处理目标地址为VIP的IP数据包，首先必须要让RS能接收到这个包，不可以将VIP设置在RS的出口网卡上，否则当开始广播请求数据包的时候，RS会响应arp请求并造成网关的arp表混乱，以至于整个集群都不能正常工作！
5.3 TUN模式
5.3.1 TUN模式原理
TUN模式适用于异地集群（LVS集群的DS与RS、RS与RS位于不同的地理位置）。其工作机制与DR模式一样，只是在转发的时候需要在原始报文外部封装一层IP报文。
原理为：
客户发送请求数据包根据目标地址VIP发送到DS负载调度器上。DS接收到客户请求包之后，进行IP Tunnel封装。即在原有的包头加上IP Tunnel的首部（这个IP首部的源地址是DIP,目标地址是特定算法选中RS的RIP），然后发送出去。
RS节点服务器根据IP Tunnel包头信息（就是一种逻辑上的隐形隧道，只有DS和RS之间懂）收到请求包，然后解开IP Tunnel包头信息，得到客户的请求包并进行响应处理。
响应处理完毕之后，RS服务器使用自己的出公网线路，将这个响应数据包发送给客户端。源IP地址还是VIP地址（RS节点服务器需要在本地回环接口lo配置VIP，所以TUN模式的RS既有RIP又有VIP，这点与DR模式一样）
5.3.2 TUN模式优缺点（总结）
① 集群所有节点都必须直接/间接拥有公网地址
② 真实服务器RS的网关不是DS负载调度器
③ TUN模式不支持端口映射
④ DS与RS必须开启隧道功能
⑤ 数据包入站由DS完成，出站由RS完成
5.4 DR、NAT、TUN三种模式简单对比
采用NAT模式时，由于请求和响应的报文必须通过调度器地址重写，当客户请求越来越多时，调度器处理能力将成为瓶颈。为了解决这个问题，调度器把请求的报文通过IP隧道转发到真实的服务器。真实的服务器将响应处理后的数据直接返回给客户端。这样调度器就只处理请求入站报文，由于一般网络服务应答数据比请求报文大很多。所以相比NAT模式，采用TUN模式后，集群系统的最大吞吐量可以提高很多。
但是由于其封装、拆封数据包过程也较多，所以相比DR模式压力也是较大的。
参考资料：
https://blog.csdn.net/xmh_sxh_1314/article/details/104828986
https://blog.csdn.net/weixin_34174105/article/details/89776427
https://blog.51cto.com/467754239/1549699
https://www.cnblogs.com/yaboya/p/9109462.html
