集群或者说是群集：其目的是为了实现将多台计算机组合以来完成特定的任务，比如天气预报，大型网络游戏，这些都需要很大的运算量，单台计算机实现成本太高，而且不显示。那么就需要通过集群的方式，将废弃的或者正在使用的计算机联合起来，结合整体的力量来解决这些问题
集群类型：
1. 负载均衡集群 load blancing ,简称LB
2. 高可用性集群 high availibility,简称 HA
3. 高性能集群 high performance,简称 HP
作用：
1. 负载均衡集群目的是为了提高服务的并发能力
2. 高可用性集群目的是为了提供7*24小时服务的能力，提供冗余，防止服务中断。
3. 高性能集群目的是为了提高性能，应用大量复制的运算。
集群系统特点：
1. 可扩展性
集群提供了非常好的扩展/缩减性，可以方便的增加或者减少服务器，增大和减少规模。
2. 性能
***能扩展
3. 容量
负载均衡调度器类别的划分：
1.通过工作的协议层划分
(1) 传输层,tcp协议，根据请求报文中的目标地址及端口进行调度
(2) 应用层，根据请求的内容进行调度，而且此种调度为“代理”方式
2.软件类
(1) tcp: lvs(linux virtual server),haproxy,nginx
(2) http: nginx,haproxy,apache(proxymodule,balance module),ats(apache traffic server),squid,varnish
(3) mysql: mysql-proxy
3.硬件类
(1) F5 big ip 最有名的硬件负载均衡器
(2) Citrix的netscaler
(3) A10
(4) array
(5) redware
Linux Virtual Server详解
LVS的英文全称是Linux Virtual Server，即Linux虚拟服务器。它是我们国家的章文嵩博士的一个开源项目
基本架构：
lvs工作在网络四层交换，它通过内核框架模块ipvs及配置在该框架之上的一组规则来实现交换或路由。ipvsadm则是配置路由规则的工具。ipvs基于内核的netfilter框架模块，工作在其INPUT链上，将到达INPUT链的需要转发的包路由至Real Server。因此，ipvs功能会与netfilter的filter和nat表的功能有冲突。最好不要在部署了ipvs规则的主机上配置iptables的filter和nat规则。其在INPUT的工作原理图如下：
请求数据流从左边prerouting进入，到路由选择，发现访问的是VIP地址，送往本机，IPVS在INPUT链上虎视眈眈，发现有发往集群的IP和对应端口的数据，拦截！然后根据设置的工作类型和设置好的RS主机地址、调度方法，挑选一个RS主机，把请求数据直接投放到FORWARD链上，经POSTROUTING到达RS主机。
LVS有四种模型：
(1) lvs-nat:
masquerade
(2) lvs-dr:
directrouting
(3) lvs-tun:
tunneling
(4) lvs-fullnat:
fullnat
LVS-NAT模型:
它通过修改请求报文的目标地址为根据调度算法所挑选出的某RS的RIP来进行转发（只修改目标地址哦！）
工作原理如下图：
上图配置说明：Director为调度器，网卡接口上同时绑定了DIP和VIP，其余RS主机的RIP都绑定在各自网卡接口，网关指向DIP。
客户端发送请求（源地址CIP|目标地址VIP），达到服务端路由，经判断，发往Director,Director收到后，根据配置的调度算法挑选出一台RS1,修改请求报文的目标地址为选定RS1的RIP，然后ARP获得RS1的MAC地址，再发送过去。RS1获得请求，然后做出响应，返回源地址为本机RIP,目标地址为CIP的响应给Director,Director收到后再把源地址修改为VIP，目标地址修改为CIP，返回给客户端。
模型特征：
1. RS应该使用私有地址。
2. RS的网关必须指向Director的DIP。
3. RS的RIP和DIP必须在同一网段内。
4. 请求和响应的报文都经过Director，在高负载的场景中，Director可能成为
系统性能瓶颈。
5. 支持端口映射。
6. RS可以使用任意支持集群服务的操作系统。
7. Director需要2张网卡
模型缺点：
由于Director需要对请求进行2次处理，数据量大的话会成为瓶颈，而且RS和Director必须在同一网络
LVS-DR模型：
Director在实现转发时不修改请求的IP首部（源地址和目标地址都不修改），而是通过直接封装MAC首部完成转发；目标MAC是Director根据调度方法挑选出某RS的MAC地址；
工作原理如下图：
客户端请求过来（源地址：CIP 目标地址：VIP），到达目标网络的路由器，路由器ARP广播找VIP的MAC地址，由于DirectorVIP地址直接绑定在DIP接口上，所以可以直接相应路由器的广播返回MAC地址，为什么其他RS服务器也有VIP地址，却没法响应路由器的广播呢？使用了内核参数或arptables进行限制。Director响应了路由器得到客户端的请求后，挑选一台RS服务器给它发送客户端的请求，因为Director和RS服务器之间的通讯是通过MAC地址的，所以转发的客户端的请求源地址还是CIP，目标地址还是VIP。RS服务器收到客户端请求后，响应客户请求，是直接把请求返回给客户端而不用再经过Director，注意！RS返回客户端请求的时候，由于linux限制了哪个网络端口返回数据就绑定该端口IP地址，如果直接用RS上RIP端口返回，那么返回的源地址就会变成RIP私有地址，客户端就不能接收了。所以它会强制使用lo:0回环口响应（就可以绑定原来的VIP地址了），但回环口是不能对外通讯的，所以再经过一个forward转发到RIP口上，返回给客户端了。
注意：
1. director的VIP需绑定在DIP接口，其他RS的VIP需绑定在lo:0回环口
2. linux有个特性，配置的IP是属于内核的，不属于某个网卡接口，只要有请求
到来，而主机又有对应IP（例如不能对外通讯的lo:0回环口上配置的VIP，和
RIP），就必须要响应。所以红帽又增加了一个arptables，可以设置规则使得
lo:0不去响应，另外内核也有参数可以实现
DR模型的特征：
1. RS可以使用私有地址，也可以使用公网地址。
2. RS的网关一定不能指向DIP
3. RS和Director要在同一物理网络内（不能有路由器分割，且必须可以被arp广
播到）
4. 请求报文经过Director，但响应报文一定不经过Director
5. 不支持端口映射
6. RS可以使用大多数的操作系统
7. 保证前端路由器将目标地址为VIP的请求报文通过ARP地址解析后送往Director
解决方案：
1.静态绑定：在前端路由直接将VIP对应的目标MAC静态配置为Director的MAC
地址；
2.arptables：在各RS上，通过arptables规则拒绝其响应对VIP的ARP广播请求；
3.内核参数：在RS上修改内核参数，并结合地址的配置方式实现拒绝响应对VIP
的ARP广播请求；
模型缺点：
RS和Director必须在同一网络
LVS-TUN模型：
不修改请求报文IP首部，而是通过IP隧道机制在原有的IP报文之外再封装IP首部，经由互联网把请求报文交给选定的RS；(相当于在Dirctor和RS之间建立×××)
工作原理如下图：
客户端发送请求，Director收到后，挑选RS,然后和RS建立IP隧道，再在隧道之上发送客户端的请求给RS，RS响应处理后直接把结果返回客户端
TUN模型的特征：
1. RIP、DIP和VIP都必须是公网地址
2. RS的网关一定不能指向DIP
3. 请求报文经过Director，但响应报文一定不经过Director
4. 不支持端口映射
5. RS的操作系统必须支持IP隧道技术
LVS-FULLNAT模型
通过请求报文的源地址为DIP，目标为RIP来实现转发；对于响应报文而言，修改源地址为VIP，目标地址为CIP来实现转发；（目标地址和源地址都修改哦！）
工作原理如下图：
客户端发送请求，Director收到后，挑选RS,修改请求源地址和目标地址为DIP | RIP,发给RS,RS收到响应处理后，修改源地址和目标地址为RIP | DIP 返回给Director,Director收到后再次把源地址和目标地址修改为 VIP | DIP,最后返回给客户端
LVS-FULLNAT模型的特征：
(1) RIP,DIP可以使用私有地址；
(2) RIP和DIP可以不在同一个网络中，且RIP的网关未必需要指向DIP；
(3) 支持端口映射；
(4) RS的OS可以使用任意类型；
(5) 请求报文经过Director，响应报文经过Director；
(6) full nat跟nat 相比的优点是：保证RS回包一定能够回到LVS；
(7) full nat因为要更新source ip 所以性能正常比nat 模式下降 10%
调度策略lvs scheduler
静态方法：仅根据算法本身实现调度；
RR: round-robin
轮叫调度（Round Robin Scheduling）算法就是以轮叫的方式依次将请求调度不同的服务器，即每次调度执行i = (i + 1) mod n，并选出第i台服务器。算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。
WRR：weighted round-robin
加权轮叫调度（Weighted Round-Robin Scheduling）算法可以解决服务器间性能不一的情况，它用相应的权值表示服务器的处理性能，服务器的缺省权值为1。假设服务器A的权值为1，B的权值为2，则表示服务器B的处理性能是A的两倍。加权轮叫调度算法是按权值的高低和轮叫方式分配请求到各服务器。权值高的服务器先收到的连接，权值高的服务器比权值低的服务器处理更多的连接，相同权值的服务器处理相同数目的连接数。
SH：Source ip Hashing，源地址哈希；
把来自同一个地址请求，统统定向至此前选定的RS; 注意！此算法主要作用是会话保持，session保持，例如用于网站购物车保持。。时才会选用，不然其他时候是会损害负载均衡的效果的
DH：Destination ip Hashing, 目标地址哈希；
把访问同一个目标地址的请求，统统定向至此前选定的某RS；(例如在一个公司内部网络通过2台防火墙访问外网，那就需要一台Director对路由器的访问做负载均衡，这个时候内网用户的请求就会根据DH的算法分配到不同路由)
动态方法：根据算法及后端RS当前的负载状况实现调度；
LC: least connection
Overhead=Active*256+Inactive
最小连接调度（Least-Connection Scheduling）算法是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态调度算法，它通过服务器当前所活跃的连接数来估计服务器的负载情况。调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1；当连接中止或超时，其连接数减一。
当各个服务器有相同的处理性能时，最小连接调度算法能把负载变化大的请求分布平滑到各个服务器上，所有处理时间比较长的请求不可能被发送到同一台服务器上。但是，当各个服务器的处理能力不同时，该算法并不理想，因为TCP连接处理请求后会进入TIME_WAIT状态，TCP的TIME_WAIT一般为2分钟，此时连接还占用服务器的资源，所以会出现这样情形，性能高的服务器已处理所收到的连接，连接处于TIME_WAIT状态，而性能低的服务器已经忙于处理所收到的连接，还不断地收到新的连接请求。
WLC: weightedleast connection (lvs中默认的算法)
Overhead=(Active*256+Inactive)/weight
加权最小连接调度（Weighted Least-ConnectionScheduling）算法是最小连接调度的超集，各个服务器用相应的权值表示其处理性能。服务器的缺省权值为1，系统管理员可以动态地设置服务器的权值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。
SED：Shorted Expection Delay
最短的期望的延迟,简称SED，分配一个接踵而来的请求以最短的期望的延迟方式到服务器。计算当前realserver 的负载情况计算方法：
Overhead=(Active+1)*256/weight
SED是按照后面这样计算的：每个集群节点的总开销值是通过在活动连接数量值上加1得到的，然后通过你给每个集群节点指定的权重值来划分总开销值，最小SED值的节点将被选中。
关于SED调度方法有两个事情需要注意：
1.在判断每个集群节点的总开销值时不使用非活动连接数值。
2.在入站连接被分配后，它在活动连接数值基础上加1来预料总开销值
例如：假设你有两个节点，其中一个比另一个要×××倍（一个是1GHZ的处理器，另一个是3GHz的处理器[16]），因此，你决定将一个的权重值设为1，另一个设为3，假设集群已经启动并运行了一段时间，较慢的节点上有10个活动连接，较快的节点上有30个活动连接，当新的请求抵达时，Director必须决定请求分配给哪个节点，如果这个请求没有增加每个集群节点的活动连接数量，SED值应该按下面这样计算：
较慢的节点（1GHz处理器）10个活动连接/权重 1=10
较快的节点（3GHz处理器）30个活动连接/权重 3=10
因为SED值相同，Director会选择首先在集群节点的表中显示的节点，如果首先显示的是较慢的节点，新的请求也将分配给它，哪怕它很慢。
如果新的连接首先增加了活动连接的数量，计算方法应该这样：
较慢的节点（1GHz处理器）11个活动连接/权重 1=11
较快的节点（3GHz处理器）31个活动连接/权重 3=10.34
现在较快的节点SED值更小，因此它适合分配新的连接请求。
增加活动连接数值一方面是影响是集群节点可能处于空闲状态，即使多个请求被分配给另一个集群节点了，例如：让我们使用同样的两个集群节点，但是本次我们假设较慢的节点没有活动连接，较快的节点有1个活动连接，每个节点的SED计算方法如下（回想活动连接已经增加了1）：
较慢的节点（1GHz处理器） 1个活动连接/权重 1=1
较快的节点（3GHz处理器） 2个活动连接/权重 3=0.67
NQ：Never Queue最小队列调度，简称NQ
SED改进，永不排队，先扫描一次是否都没分配，那就每人一个先，第二轮再按SED的分配。
LBLC：Local-Based Least Connection，动态方式的DH算法；
基于局部性的最少链接调度（Locality-Based LeastConnections Scheduling，以下简称为LBLC）算法是针对请求报文的目标IP地址的负载均衡调度，目前主要用于Cache集群系统，因为在Cache集群中客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求，算法的设计目标是在服务器的负载基本平衡情况下，将相同目标IP地址的请求调度到同一台服务器，来提高各台服务器的访问局部性和主存Cache命中率，从而提高整个集群系统的处理能力。
LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于其一半的工作负载，则用“最少链接”的原则选出一个可用的服务器，将请求发送到该服务器。
LBLCR：Replicated LBLC
带复制的基于局部性最少链接调度（Locality-Based LeastConnections with Replication Scheduling，以下简称为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地址对应的服务器组；按“最小连接”原则从该服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载；则按“最小连接”原则从整个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。
Lvs 的Session 保持
1. Session Sticky (用session记录访问状态，就是上面SH方法的目的)
2. Session Replication Cluster (session 复制集群，RS之间会保存它们机器上
的session，每一台机器上都有其他RS完整的session信息，缺点：如果访问量
巨大，那么保持session消耗的资源也是巨大的，只适用3-5台规模的RS)
3. Session Server (使用一台专门的主机构建session服务器，所有RS都从那里读
取session信息)
