集群、高可用与负载均衡学习总结
近段时间一直在学习集群、高可用和复杂均衡方面的技术应用，现在基本上也算是学完了，写篇博客总结分享一下，但是掌握可能还是有些欠缺，所以本文内容只是出于我本人的理解，可能会有一些误点，如读者阅读过程发现失误请留言指正！
1. 首先上点概念
1.1集群（Cluster）
集群（Cluster）是用N台服务器构成的一个松耦合的多处理器系统(对用户来说，它们就像是一台服务器在提供服务)，在这个系统中服务器之间通过网络实现通信，相互协作，共同承载一个或者多个服务/应用的请求压力。
1.2 高可用
高可用(High Availbility，简称HA)是利用集群中系统的冗余，当主服务器出现故障时，备份服务器能够及时切换服务，自动接管主服务器的工作，以实现对用户的不间断服务。
1.3 负载均衡
详细内容可以参阅负载均衡原理与技术实现
负载均衡(Load Balance，简称LB)是一种服务器或网络设备的集群技术。负载均衡将特定的业务(网络服务、网络流量等)分担给多个服务器或网络设备，从而提高了业务处理能力，保证了业务的高可用性。负载均衡基本概念有：实服务、实服务组、虚服务、调度算法、持续性等，其常用应用场景主要是服务器负载均衡，链路负载均衡。能够实现负载均衡的组件有nginx、haproxy等
上张图理解一下一般结构
2. 认识一些组件
2.1、apache
apache是Apache软件基金会的一个开放源代码的跨平台的网页服务器，属于老牌的web服务器了，支持基于Ip或者域名的虚拟主机，支持代理服务器，支持安全Socket层(SSL)等等，目前互联网主要使用它做静态资源服务器，也可以做代理服务器转发请求(如：图片链等)，结合tomcat等servlet容器处理jsp。
2.2、ngnix
俄罗斯人开发的一个高性能的 HTTP加速和反向代理服务器。由于Nginx 超越 Apache 的高性能和稳定性，使得国内使用 Nginx 作为 Web 服务器的网站也越来越多，其中包括新浪博客、新浪播客、网易新闻、腾讯网、搜狐博客等门户网站频道等，在3w以上的高并发环境下，ngnix处理能力相当于apache的10倍。
2.3、lvs
Linux Virtual Server的简写，即Linux虚拟服务器，是一个虚拟的服务器集群系统。由毕业于国防科技大学的章文嵩博士于1998年5月创立，LVS 是一个实现负载均衡集群的开源软件项目，LVS架构从逻辑上可分为调度层、Server集群层和共享存储。
2.4、HAProxy
可参考 Haproxy负载均衡器
HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。HAProxy特别适用于那些负载特大的web站点， 这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中， 同时可以保护你的web服务器不被暴露到网络上.
2.5、keepalived
这里说的keepalived不是apache或者tomcat等某个组件上的属性字段，它也是一个组件，可以实现web服务器的高可用(HA high availably)。它可以检测web服务器的工作状态，如果该服务器出现故障被检测到，将其剔除服务器群中，直至正常工作后，keepalive会自动检测到并加入到服务器群里面。实现主备服务器发生故障时ip瞬时无缝交接。它是LVS集群节点健康检测的一个用户空间守护进程，也是LVS的引导故障转移模块（director failover）。Keepalived守护进程可以检查LVS池的状态。如果LVS服务器池当中的某一个服务器宕机了。keepalived会通过一 个setsockopt呼叫通知内核将这个节点从LVS拓扑图中移除。
2.6、Heartbeat
可参考 heartbeat与高可用
Heartbeat是Linux-HA项目中的一个组件，也是目前开源HA项目中最成功的一个例子，它提供了所有 HA 软件所需要的基本功能，比如心跳检测和资源接管、监测群集中的系统服务、在群集中的节点间转移共享 IP 地址的所有者等。
heartbeat （Linux-HA）的工作原理：heartbeat最核心的包括两个部分，心跳监测部分和资源接管部分，心跳监测可以通过网络链路和串口进行，而且支持冗 余链路，它们之间相互发送报文来告诉对方自己当前的状态，如果在指定的时间内未受到对方发送的报文，那么就认为对方失效，这时需启动资源接管模块来接管运 行在对方主机上的资源或者服务。
2.7、memcached
它是一个高性能分布式内存对象缓存系统。当初是Danga Interactive为了LiveJournal快速发展开发的系统，用于对业务查询数据缓存，减轻数据库的负载。其守护进程(daemon)是用C写的，但是客户端支持几乎所有语言(客户端基本上有3种版本[memcache client for java;spymemcached;xMecache])，服务端和客户端通过简单的协议通信；在memcached里面缓存的数据必须序列化。
3. 从RHCS组件说起
3.1. 什么是RHCS
RHCS是Red Hat Cluster Suite的缩写，也就是红帽子集群套件，RHCS是一个能够提供高可用性、高可靠性、负载均衡、存储共享且经济廉价的集群工具集合，它将集群系统中三大集群架构融合一体，可以给web应用、数据库应用等提供安全、稳定的运行环境。
更确切的说，RHCS是一个功能完备的集群应用解决方案，它从应用的前端访问到后端的数据存储都提供了一个行之有效的集群架构实现，通过RHCS提供的这种解决方案，不但能保证前端应用持久、稳定的提供服务，同时也保证了后端数据存储的安全。
RHCS提供了集群系统中三种集群构架，分别是高可用性集群、负载均衡集群、存储集群。
3.2. RHCS提供的三个核心功能
高可用集群是RHCS的核心功能。当应用程序出现故障，或者系统硬件、网络出现故障时，应用可以通过RHCS提供的高可用性服务管理组件自动、快速从一个节点切换到另一个节点，节点故障转移功能对客户端来说是透明的，从而保证应用持续、不间断的对外提供服务，这就是RHCS高可用集群实现的功能。
RHCS通过LVS（Linux Virtual Server）来提供负载均衡集群，而LVS是一个开源的、功能强大的基于IP的负载均衡技术，LVS由负载调度器和服务访问节点组成，通过LVS的负载调度功能，可以将客户端请求平均的分配到各个服务节点，同时，还可以定义多种负载分配策略，当一个请求进来时，集群系统根据调度算法来判断应该将请求分配到哪个服务节点，然后，由分配到的节点响应客户端请求，同时，LVS还提供了服务节点故障转移功能，也就是当某个服务节点不能提供服务时，LVS会自动屏蔽这个故障节点，接着将失败节点从集群中剔除，同时将新来此节点的请求平滑的转移到其它正常节点上来；而当此故障节点恢复正常后，LVS又会自动将此节点加入到集群中去。而这一系列切换动作，对用户来说，都是透明的，通过故障转移功能，保证了服务的不间断、稳定运行。
RHCS通过GFS文件系统来提供存储集群功能，GFS是Global File System的缩写，它允许多个服务同时去读写一个单一的共享文件系统，存储集群通过将共享数据放到一个共享文件系统中从而消除了在应用程序间同步数据的麻烦，GFS是一个分布式文件系统，它通过锁管理机制，来协调和管理多个服务节点对同一个文件系统的读写操作。
3.3 RHCS部署
server1 安装ricci（集群节点）
server2 安装ricci（集群节点） 和luci（集群管理界面）
部署及配置细节请参阅 RHCS高可用集群配置(luci+ricci+fence)
4. 走近LVS
LVS 是一个实现负载均衡集群的开源软件项目
4.1 LVS的组成
一般来说，LVS集群采用三层结构，三层主要组成部分为：
1 负载调度器（load balancer），它是整个集群对外面的前端机，负责将客户的请求发送到一组服务器上执行，而客户认为服务是来自一个IP地址（我们可称之为虚拟IP地址）上的。
2 服务器池（server pool），是一组真正执行客户请求的服务器，执行的服务有WEB、MAIL、FTP和DNS等。
3 共享存储（shared storage），它为服务器池提供一个共享的存储区，这样很容易使得服务器池拥有相同的内容，提供相同的服务。
4.2 lvs工作原理
1. 当用户向负载均衡调度器（Director Server）发起请求，调度器将请求发往至内核空间
2. PREROUTING链首先会接收到用户请求，判断目标IP确定是本机IP，将数据包发往INPUT链
3. IPVS是工作在INPUT链上的，当用户请求到达INPUT时，IPVS会将用户请求和自己已定义好的集群服务进行比对，如果用户请求的就是定义的集群服务，那么此时IPVS会强行修改数据包里的目标IP地址及端口，并将新的数据包发往POSTROUTING链
4. POSTROUTING链接收数据包后发现目标IP地址刚好是自己的后端服务器，那么此时通过选路，将数据包最终发送给后端的服务器
4.3 LVS实现负载调度的八种算法：
1 轮叫（Round Robin）
调度器通过"轮叫"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。
2 加权轮叫（Weighted Round Robin）
调度器通过"加权轮叫"调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
3 最少链接（Least Connections）
调度器通过"最少连接"调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用"最小连接"调度算法可以较好地均衡负载。
4 加权最少链接（Weighted Least Connections）
在集群系统中的服务器性能差异较大的情况下，调度器采用"加权最少链接"调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
5 基于局部性的最少链接（Locality-Based Least Connections）
"基于局部性的最少链接" 调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器 是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用"最少链接"的原则选出一个可用的服务 器，将请求发送到该服务器。
6 带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）
"带复制的基于局部性最少链接"调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个 目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务 器组，按"最小连接"原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器，若服务器超载；则按"最小连接"原则从这个集群中选出一 台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的 程度。
7目标地址散列（Destination Hashing）
"目标地址散列"调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
8 源地址散列（Source Hashing）
"源地址散列"调度算法根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
4.4 LVS的四种工作模式
LVS 的 NAT 模式
通过网络地址转换，调度器重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器；真实服务器的响应报文通过调度器时，报文的源地址被重写，再返回给客户，完成整个负载调度过程。LVS的DR模式
DR通过改写请求报文的MAC地址，将请求发送到真实服务器，而真实服务器将响应直接返回给客户。同VS/TUN技术一样，VS/DR技术可极大地 提高集群系统的伸缩性。这种方法没有IP隧道的开销，对集群中的真实服务器也没有必须支持IP隧道协议的要求，但是要求调度器与真实服务器都有一块网卡连 在同一物理网段上。LVS TUN
IP隧道(IP tunneling)是将一个IP报文封装在另一个IP报文的技术，这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。IP隧道技术亦称为IP封装技术(IP encapsulation)。IP隧道主要用于移动主机和虚拟私有网络(Virtual Private Network)，在其中隧道都是静态建立的，隧道一端有一个IP地址，另一端也有唯一的IP地址。它的连接调度和管理与VS/NAT中的一样，只是它的报文转发方法不同。调度器根据各个服务器的负载情况，动态地选择一台服务器，将请求报文封装在另一个IP报文中，再将封装后的IP报文转发给选出的服务器;服务器收到报文后，先将报文解封获得原来目标地址为 VIP 的报文，服务器发现VIP地址被配置在本地的IP隧道设备上，所以就处理这个请求，然后根据路由表将响应报文直接返回给客户。FullNAT模式
LVS当前应用主要采用DR和NAT模式，但这2种模式要求RS和DR在同一个vlan中，导致部署成本过高；TUN模式虽然可以跨vlan，但RS上需要部署ipip模块等，网络拓扑上需要连通外网，较复杂，不易运维。为了解决上述问题，我们在DR上添加了一种新的转发模式：FullNat，该模式和NAT模式的区别是：Packet IN时，除了做DNAT，还做SNAT（用户ip->内网ip），从而实现DR-RS间可以跨vlan通讯，RS只需要连接到内网，要想使用FULLNAT模式就需要为Linux内容打补丁，具体可以参阅我的博客http://blog.csdn.net/lockey23/article/details/78046696；
4.5 四种工作模式概要总结：
1、LVS NAT的特性：
1）RS应该使用私有地址；
2）RS的网关的必须指向DIP；
3）RIP和DIP必须在同一网段内；
4）请求和响应的报文都得经过Director；在高负载场景中，Director很可能成为系统性能瓶颈；
5）支持端口映射；
6）RS可以使用任意支持集群服务的OS；
2、LVS DR类型的特性：
1）RS可以使用私有地址；但也可以使用公网地址，此时可以直接通过互联网连入RS以实现配置、监控等；
2）RS的网关一定不能指向DIP；
3）RS跟DR要在同一物理网络内（不能由路由器分隔）；
4）请求报文经过DR，但响应报文一定不经过DR
5）不支持端口映射；
6）RS可以使用大多数的操作系统；
3、LVS TUN类型：IP隧道
1）RIP、DIP、VIP都得是公网地址；
2）RS的网关不会指向也不可能指向DIP；
3）请求报文经过DR，但响应报文一定不经过DR；
4）不支持端口映射；
5）RS的OS必须得支持隧道功能；
4、LVS FullNat：
1）DR,RS可以不在同一网络内，但它与TUN不同，所有IP报文头部信息变更都在DR上进行，所以性能方面比LVS_NAT更差一些；
2）需要注意配置路由，保证能正常通信；
5. LVS+OSPF
对于lvs+keepalived模式我们知道，是通过对web服务器做水平扩展，以此来提高系统的处理能力。但是我们会发现，两台Director间始终只有一台是处于工作状态，而另一台处于不工作的备份状态，即使访问的流量再大，同时也只能由一台Director 去应对，Director在这个架构里面没办法像web服务器那样做水平扩展，实现负载均衡。为了解决这种缺陷LVS+OSPF 架构应用而生。
在LVS+OSPF 架构中两台Director都是Master 状态，而不是Master-Backup，如此一来，两台Director 地位就平等了。剩下的问题，就是看如何在这两台Director 间实现负载均衡了。
LVS+OSPF架构图如下：
