集群的分类
集群其实就是一堆计算机的集合，给用户提供同一个服务的一组计算机，就称之为集群，对于用户而言好像就是一台计算机提供的服务,集群主要分为三大类。
LB (load balance)负载均衡集群
负载均衡集群主要是提高服务的响应能力的，比如说某服务器的并发响应能力是100个，这个时候经常有人反映说连不上服务器，这个时候解决方案一般有两种，一是升级硬件，升级硬件显然不是很好的解决方案，假如说升级硬件之后过了一段时间由于业务量的加大，服务器又负载不起了怎么办呢？ 二是将现有空闲低配的设备组合起来做成一个具有高并发的负载均衡集群，多台计算机同时分摊负载用户的请求，这样一来服务器的压力也没有那么大了，那么这一类的集群具有很好的可伸缩性、可靠性、和成本低廉等好处。
HA (high availability)高可用性集群
高可用性集群主要是提供7*24小时不间断服务的(在线时间+故障处理时间)，不能说因为一台或几台服务器的down机而导致无法提供服务的，如果某台down机了，会自动的切换到其他计算机上面工作，从而达到高可用的效果。
HP (high performance)高性能集群
高性能集群主要是用于需要大量CPU运算的场景中，比如说天气预报，国外3D大片的特效制作，等等一系列需要做大量运算的应用。
LB/HA/HP各自的实现机制
LB负载均衡集群又分为硬件级与软件级的：硬件类的价格比较贵，常用的有：F5 BIGIP、A10、Citrix Netscaler。软件级的比较常见的有如下两种：四层LVS、七层Haproxy、Nginx。当然DNS轮询也可以算是负载均衡实现的一种方式。
HA高可用集群的解决方案常见的有以下几种：heartbeat、RHCS(corosync+openais)、ultramokey、keepalived。
HP高性能集群的解决方案常见的有以下：rocks cluster、hadoop、storm。
LVS介绍
LVS（Linux virtual server）是由国人章文嵩（现阿里开源负责人）开发的，基于Linux内核中实现了基于地址转换技术的负载均衡器，但在内核中的名字不叫LVS而是叫IPVS（IP virtual server）。LVS集群采用IP负载均衡技术和基于内容请求分发技术，调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。为此，在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性。
LVS工作在Linux内核TCP/IP协议栈上，借鉴了netfilter框架在INPUT链上做策略（当前端服务器接收到用户发来的报文时，到达本地INPUT链，匹配LVS规则，如果是访问集群主机就修改报文并转到OUTPUT，再转到POSTROUTING链）；具有很好的可伸缩性、可靠性、和可管理性；通过Linux系统和LVS可以实现一个高可用、高性能、低成本的服务器集群。
LVS分为两段式
ipvs：工作在内核空间，TCP/IP协议栈INPUT钩子函数上的框架（Linux2.5内核之后内置ipvs代码，LVS跟netfilter不能同时使用）。
ipvsadm：工作在用户空间，负责管理集群服务编写规则的命令行工具。
LVS采用三层结构
负载调度器（load balancer）：它是整个集群对外面的前端机，负责将客户的请求发送到一组服务器上执行，而客户认为服务是来自一个IP地址（我们可称之为虚拟IP地址）上的。
服务器池（server pool）：Realserver是一组真正执行客户请求的服务器，执行的服务有WEB、MAIL、FTP和DNS等。
共享存储（shared storage）：它为服务器池提供一个共享的存储区，这样很容易使得服务器池拥有相同的内容，提供相同的服务。
LVS的工作模型
LVS的包转发策略主要有三种模式：NAT（Detwork address translation）模式、IP隧道（IP tunneling）模式和直接路由（Direct Rrouting）模式，下面一一介绍。
LVS调用模式介绍
第一种：NAT模式介绍
NAT模型显然根据名字都可以看出来，是通过网络地址转换来实现的，他的工作方式是，首先用户请求到达前端的负载均衡器（即Director Server），然后负载均衡器根据事先定义好的调度算法将用户请求的目标地址修改为RIP（后端的应用服务器，即Real Server），源地址修改为DIP（后端服务器连接调度器的接口）。 应用程序服务器处理好请求之后将结果返回给用户，期间必须要经过负载均衡器，负载均衡器将报文的源地址改为用户请求的目标地址，再转发给用户，从而完成整个负载均衡的过程。
如下图所示：
NAT模式中且不需要在RealServer上做任何设置，其只要能提供一个tcp/ip的协议栈即可，甚至其无论基于什么OS都行。基于VS/NAT，所有的入站数据包均由Director进行目标地址转换后转发至内部的RealServer，RealServer响应的数据包再由Director转换源地址后发回客户端。VS/NAT模式不能与netfilter兼容，因此，不能将VS/NAT模式的Director运行在netfilter的保护范围之中。现在已经有补丁可以解决此问题，但尚未被整合进ip_vs code。
NAT模式的特点如下：
1）所有的节点必须在一个IP网络中。
2）Real Server的网关必须是DIP。
3）RIP通常是私有地址仅用于各集群节点间的通信。
4）调度器位于Client和RealServer之间并处理进出的所有通信，当负载过大的时候，负载均衡器将是整个集群的瓶颈。
5）支持端口映射。
6）Real Server可以使用任意操作系统。
7）最多支持8个节点。
第二种：DR模式介绍
DR模型是通过路由技术实现的负载均衡技术，而这种模型与NAT模型不同的地方是，负载均衡器接收到数据请求报文后通过改写用户请求报文中的MAC地址为所挑选的RealServer即可。并不修改报文的源地址(CIP)和目标地址(VIP)，并将请求报文发送到RealServer， 而RealServer（RS服务器必须额外配置VIP的地址，并关闭所有对VIP发送ARP广播的数据包响应，这样上端路由器发送ARP报文解析VIP地址时只有调度器才能响应并接收ARP数据包而所有的Realserver虽然也有VIP但是不会响应目标地址为VIP的ARP数据包）接收到报文后发现目标地址(VIP)就是自己后直接响应用户，这样就大大的减少负载均衡器的压力，在生产环境中DR模型也是用的最多的一种LVS调度模式，比NAT模型快10倍不止。
为了避免RealServer的VIP地址响应上端ARP报文请求在Linux内核中引入了一种机制，对于Linux系统而言IP地址是系统的而不是网卡的，所以可以最简单的实现方式也就是把RIP地址设置在对外提供服务的网卡上，如ETH0。VIP地址设置在loopback的别名上loopback:0上，然后通过调整Linux内核ARP栈在响应外部数据包请求的规则，如果接收的ARP报文目标地址不是Eth0上的RIP地址主机就不予相应。
需调整以下4个内核参数：
all_ignore
arp_ignore：定义接收到app请求时的响应级别，默认是0。
0：表示只要本地配置的有相应地址就给与响应。
1：表示仅在请求的目标地址配置请求到达的接口上的时候才给与相应。
all_announce
arp_announce：定义将自己地址向外通告时的通告级别，默认是0。
0：表示将本地任何接口的任何地址向外通告。
1：表示尽可能试图仅向目标网络通告与其网络匹配的地址。
2：表示仅向与本地接口上地址匹配的网络进行通告。
注意：Linux路由策略上默认有这样一种行为，响应报文的源地址一般会配置为报文流出接口的地址，这样一来客户端访问的目标地址是VIP经过调度器转发给RealServer后，如果响应的目标地址是Eth0接口的RIP，而客户端没有访问RIP所以拒绝接收相应数据包，所以还需要一种路由策略，必须保证访问数据包的目的地址如果是VIP，那么RealServer响应数据包的目标地址就必须是loopback上的VIP地址。这就需要额外配置一条独特的路由条目明确说明响应地址是VIP。
|
1 |
$ route add –host VIP dev lo:0 |
DR模型的特点如下：
1）所有的集群节点都必须同一个物理网络中。
2）RIP可以是公有IP也可以是私有IP。
3）负载均衡器只响应进站请求，RealServer自己响应出站请求，从而大大地减少调度器压力，因为进站请求数据包一般都很小而出站才是核心。
4）不支持端口映射。
第三种：TUN模式介绍
TUN模型是通过IP隧道技术实现的，TUN模型跟DR模型有点类似，不同的地方是负载均衡器(Director Server)跟应用服务器(RealServer)通信的机制是通过IP隧道技术将用户的请求转发到某个RealServer，而RealServer也是直接响应用户的，当客户端把数据报文发送到调度器之后，调度器会再次封装报文源地址是DIP，目标地址是RIP。Realserver接收到数据包之后拆封真正的数据包发现目标IP是VIP（Realserver还配置有VIP）是自己就会直接响应客户端。
TUN模型的特点：
1）所有的集群节点可以在任意地方。
2）RIP必须是公网IP。
3）负载均衡器只响应进站请求。
4）不支持端口映射。
5）只有支持隧道功能的OS才能用于RealServer。
LVS支持的调度算法
调度算法（Schedule method）也可以称为负载均衡的方法，上面说过前端的负载均衡器（Director Server）会将用户的请求分摊给后端的应用服务器（Real Server）。那么负载均衡器（Director Server）怎么会知道将用户请求分摊到哪台应用服务器（Real Server）呢? 就是根据调度算法来实现将用户请求具体分摊到哪台应用服务器（Real Server）的。在LVS中支持多达10种调度算法，下面来说说几个常用的调度算法。
1）轮询（RR:Round Robin）
轮询调度是将新的连接请求被轮流分配至各RealServer，算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。轮叫调度算法假设所有服务器处理性能均相同，不管服务器的当前连接数和响应速度。该算法相对简单，不适用于服务器组中处理性能不一的情况，而且当请求服务时间变化比较大时，轮叫调度算法容易导致服务器间的负载不平衡。
2）加权轮询（WRR:Weight Round Robin）
加权轮询可以为Real Server 设置不同的权值,对于性能好的Real Server可以较高的权值,而性能比较差的Real Server 的权值可以设置较低点,这样的话就充分利用了服务器的资源。
3）源地址hash算法（SH:Source Hashing）
根据每一个客户端地址可以把每个客户端地址做一次hash计算并在directory内部保持了一张hash表(地址对应服务器)；以后每一台客户端在来访问时就先计算一下客户端地址hash比照内部hash表只要有对应条目就会挑选相同的服务器响应客户端。
(作用：http是无状态协议同一个客户端发起两次请求服务器端并不能识别两次请求是同一个客户端从而影响用户登录；后来引入cookie机制,客户端访问服务器时服务器会发送一个身份标识到客户端的cookie中保存当客户端再次发起请求时就会添加cookie信息发送到服务器从而服务器就会在内存中找一块空间保存session会话从而识别客户端(对应电商网站来说session会话还保存着用户浏览记录和购物车信息)；那么在集群中客户端和服务器第一次建立好的连接当刷新再次请求时调度器挑选另外一台服务器响应客户端从而造成服务器无法识别客户端cookie信息)
4）目标地址hash算法（DH:Destination Hashing）
将同一个请求发送给同一个server服务器（主要用于缓存服务器，算法也是针对目标IP地址的负载均衡，但它是一种静态映射算法，通过一个散列（Hash）函数将一个目标IP地址映射到一台服务器。目标地址散列调度算法先根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器；否则返回空。对于缓存命中率提高但是对于调度不公平可能发生一个服务器连接很多一个服务器连接很少）。
5）最少连接（LC:Less Connection）
新的连接请求将被分配至当前连接数最少RealServer；最小连接调度是一种动态调度算法，它通过服务器当前所活跃的连接数来估计服务器的负载情况。调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1；当连接中止或超时，其连接数减一。
根据此算法活动连接*256+非活动连接数(active*256+inactive)比较谁连接数就少发送给哪台realserver服务器。
6）加权最少连接（WLC:Weight Less Connection）
加权最少连接可以将性能好的服务器的全值设置高点，性能差的服务器权值设置低一些根据此算法活动连接*256+非活动连接数然后除以权重((active*256+inactive)/weight)。
7）基于本地的最少连接（LBLC）
针对请求报文的目标IP地址的负载均衡调度，目前主要用于Cache集群系统，因为在Cache集群中客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求，算法的设计目标是在服务器的负载基本平衡情况下，将相同目标IP地址的请求调度到同一台服务器，来提高各台服务器的访问局部性和主存Cache命中率，从而整个集群系统的处理能力。LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于其一半的工作负载，则用“最少链接”的原则选出一个可用的服务器，将请求发送到该服务器(可能会破坏命中率从而提高负载均衡效果)。
8）基于本地带复制功能的最少连接（LBLCR）
也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射，而 LBLC算法维护从一个目标IP地址到一台服务器的映射。对于一个“热门”站点的服务请求，一台Cache 服务器可能会忙不过来处理这些请求。这时，LBLC调度算法会从所有的Cache服务器中按“最小连接”原则选出一台Cache服务器，映射该“热门”站点到这台Cache服务器，很快这台Cache服务器也会超载，就会重复上述过程选出新的Cache服务器。这样，可能会导致该“热门”站点的映像会出现在所有的Cache服务器上，降低了Cache服务器的使用效率。LBLCR调度算法将“热门”站点映射到一组Cache服务器（服务器集合），当该“热门”站点的请求负载增加时，会增加集合里的Cache服务器，来处理不断增长的负载；当该“热门”站点的请求负载降低时，会减少集合里的Cache服务器数目。这样，该“热门”站点的映像不太可能出现在所有的Cache服务器上，从而提供Cache集群系统的使用效率。LBLCR算法先根据请求的目标IP地址找出该目标IP地址对应的服务器组；按“最小连接”原则从该服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载；则按“最小连接”原则从整个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度(LBLCR比DH缓存命中率低但是比LBLC负载均衡要高)。
