Linux 集群技术

一、 集群概念

集群（Cluster）是由两台或多台节点机（服务器）构成的一种松散耦合的计算节点集合，为用户提供网络服务或应用程序(包括数据库、Web服务和文件服务等)的单一客户视图，同时提供接近容错机的故障恢复能力。集群系统一般通过两台或多台节点服务器系统通过相应的硬件及软件互连，每个群集节点都是运行其自己进程的独立服务器。这些进程可以彼此通信，对网络客户机来说就像是形成了一个单一系统，协同起来向用户提供应用程序、系统资源和数据。除了作为单一系统提供服务，集群系统还具有恢复服务器级故障的能力。集群系统还可通过在集群中继续增加服务器的方式，从内部增加服务器的处理能力，并通过系统级的冗余提供固有的可靠性和可用性。集群计算机按功能和结构可以分成以下几类:

1、 高可用性集群 High-availability (HA) clusters

一般是指当集群中有某个节点失效的情况下，其上的任务会自动转移到其他正常的节点上。还指可以将集群中的某节点进行离线维护再上线，该过程并不影响整个集群的运行。计思想就是要最大限度地减少服务中断时间。这类集群中比较著名的有Turbolinux TurboHA、Heartbeat、Kimberlite等。

2、负载均衡集群 Load balancing clusters

提供和节点个数成正比的负载能力，这种集群很适合提供大访问量的Web服务。负载均衡集群往往也具有一定的高可用性特点。Turbolinux Cluster Server、Linux Virtual Server都属于负载均衡集群。

主流架构Nginx+Keepalived（利于动静分离）、LVS+Keepalived。

3、高性能计算集群 High-performance (HPC) clusters

按照计算关联程度的不同，又可以分为两种。一种是任务片方式，要把计算任务分成任务片，再把任务片分配给各节点，在各节点上分别计算后再把结果汇总，生成最终计算结果。另一种是并行计算方式，节点之间在计算过程中大量地交换数据，可以进行具有强耦合关系的计算。这两种超级计算集群分别适用于不同类型的数据处理工作。有了超级计算集群软件，企业利用若干台PC机就可以完成通常只有超级计算机才能完成的计算任务。这类软件有Turbolinux EnFusion、SCore等。

高可用性集群与负载均衡集群的工作原理不同，适用于不同类型的服务。通常，负载均衡集群适用于提供静态数据的服务，如HTTP服务；而高可用性集群既适用于提供静态数据的服务，如HTTP服务，又适用于提供动态数据的服务，如数据库等。高可用性集群之所以能适用于提供动态数据的服务，是由于节点共享同一存储介质，如RAIDBox。也就是说，在高可用性集群内，每种服务的用户数据只有一份，存储在共用存储设备上，在任一时刻只有一个节点能读写这份数据。

二、 主流架构设计

1、高可用架构

集群管理器的高可用性：

为了屏蔽集群管理器的失效，需要为它建立一个备份机。主管理器和备份管理器上都运行着heartbeat程序，通过传送诸如"我活着"这样的信 息来监测对方的运行状况。当备份机不能在一定的时间内收到这样的信息时，它就激活fake程序，让备份管理器接管主管理器继续提供服务;当备份管理器又从 主管理器收到"我活着"这样的信息时，它就使fake程序无效，从而释放IP地址，这样主管理器就开始再次进行集群管理的工作了。

节点的高可用性：

节点的高可用性可以通过不断监视节点的状态以及节点上的应用程序的运行状态来实现，当发现节点已经失效时，可以重新配置系统并且将工作负载交给那些运行正常的节点来完成。通过这种方法，集群管理器可以自动屏蔽服务器和 其上运行的服务程序的失效，并且当实际服务器正常运转时能将它们重新加入到集群系统中。

2、 负载均衡架构

一个大型的网站或系统的话，可以存在多级代理，最前端可以用F5或LVS来作为网站或系统的入口，处理高并发流量，而Nginx由于其强大的正则处理能力，可以作为中层代理，一来可以作为F5/LVS的补充，节约大量成本，拓朴如下图：

LVS代替F5，拓朴图如下：

3、 软件级负载均衡器(LVS/HAProxy/Nginx)的特点和对比

1、抗负载能力强、是工作在网络4层之上仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的；

2、配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率；

3、工作稳定，自身有完整的双机热备方案，如LVS+Keepalived和LVS+Heartbeat，不过我们在项目实施中用得最多的还是LVS/DR+Keepalived；

4、无流量，保证了均衡器IO的性能不会收到大流量的影响；

5、应用范围比较广，可以对所有应用做负载均衡；

6、软件本身不支持正则处理，不能做动静分离，这个就比较遗憾了；其实现在许多网站在这方面都有较强的需求，这个是Nginx/HAProxy+Keepalived的优势所在。

7、如果是网站应用比较庞大的话，实施LVS/DR+Keepalived起来就比较复杂了，特别后面有Windows Server应用的机器的话，如果实施及配置还有维护过程就比较复杂了，相对而言，Nginx/HAProxy+Keepalived就简单多了。

1、工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构，它的正则规则比HAProxy更为强大和灵活，这也是许多朋友喜欢它的原因之一；

2、Nginx对网络的依赖非常小，理论上能ping通就就能进行负载功能，这个也是它的优势所在；

3、Nginx安装和配置比较简单，测试起来比较方便；

4、也可以承担高的负载压力且稳定，一般能支撑超过几万次的并发量；

5、Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测；

6、Nginx仅能支持http和Email，这样就在适用范围上面小很多，这个它的弱势；

7、Nginx不仅仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的Web应用服务器。LNMP现在也是非常流行的web架构，大有和以前最流行的LAMP架构分庭抗争之势，在高流量的环境中也有很好的效果。

8、Nginx现在作为Web反向加速缓存越来越成熟了，很多朋友都已在生产环境下投入生产了，而且反映效果不错，速度比传统的Squid服务器更快，有兴趣的朋友可以考虑用其作为反向代理加速器。

1、HAProxy是支持虚拟主机的，以前有朋友说这个不支持虚拟主机，我这里特此更正一下。

2、能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作

3、支持url检测后端的服务器出问题的检测会有很好的帮助。

4、它跟LVS一样，本身仅仅就只是一款负载均衡软件；单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。

5、HAProxy可以对Mysql读进行负载均衡，对后端的MySQL节点进行检测和负载均衡，不过在后端的MySQL slaves数量超过10台时性能不如LVS，所以我向大家推荐LVS+Keepalived。

6、HAProxy的算法现在也越来越多了，具体有如下8种：

①roundrobin，表示简单的轮询，这个不多说，这个是负载均衡基本都具备的；

②static-rr，表示根据权重，建议关注；

③leastconn，表示最少连接者先处理，建议关注；

④ource，表示根据请求源IP，这个跟Nginx的IP_hash机制类似，我们用其作为解决session问题的一种方法，建议关注；

⑤ri，表示根据请求的URI；

⑥rl_param，表示根据请求的URl参数'balance url_param' requires an URL parameter name；

⑦hdr(name)，表示根据HTTP请求头来锁定每一次HTTP请求；

⑧rdp-cookie(name)，表示根据据cookie(name)来锁定并哈希每一次TCP请求。

三、 Linux集群技术

1、 LVS虚拟服务器

利用LVS技术可以实现高性能，高可压缩的网路服务，例如WWW服务，FTP服务，MAIL服务等。LVS架设的服务器集群系统有三个部分组成：最前端的负载均衡层（Loader Balancer），中间的服务器群组层，用Server Array表示，最底层的数据共享存储层，用Shared Storage表示。在用户看来所有的应用都是透明的，用户只是在使用一个虚拟服务器提供的高性能服务。

LVS的体系架构如图：

Load Balancer层：

位于整个集群系统的最前端，有一台或者多台负载调度器（Director Server）组成，LVS模块就安装在Director Server上，而Director的主要作用类似于一个路由器，它含有完成LVS功能所设定的路由表，通过这些路由表把用户的请求分发给Server Array层的应用服务器（Real Server）上。同时，在Director Server上还要安装对Real Server服务的监控模块Ldirectord，此模块用于监测各个Real Server服务的健康状况。在Real Server不可用时把它从LVS路由表中剔除，恢复时重新加入。

Server Array层：

由一组实际运行应用服务的机器组成，Real Serverj可以是WEB服务器、MAIL服务器、FTP服务器、DNS服务器、视频服务器中的一个或者多个，每个Real Server之间通过高速的LAN或分布在各地的WAN相连接。在实际的应用中，Director Server也可以同时兼任Real Server的角色。

Shared Storage层：

是为所有Real Server提供共享存储空间和内容一致性的存储区域，在物理上，一般有磁盘阵列设备组成，为了提供内容的一致性，一般可以通过NFS网络文件系统共享数 据，但是NFS在繁忙的业务系统中，性能并不是很好，此时可以采用集群文件系统，例如Red hat的GFS文件系统，oracle提供的OCFS2文件系统等。

LVS 的IP负载均衡技术

通过IPVS模块来实现的，IPVS是LVS集群系统的核心软件，它的主要作用是：安装在Director Server上，同时在Director Server上虚拟出一个IP地址，用户必须通过这个虚拟的IP地址访问服务。这个虚拟IP一般称为LVS的VIP，即Virtual IP。访问的请求首先经过VIP到达负载调度器，然后由负载调度器从Real Server列表中选取一个服务节点响应用户的请求。

IPVS实现负载均衡机制

VS/NAT： 即（Virtual Server via Network Address Translation）：

由于IPv4中IP地址空间的日益紧张和安全方面的原因，很多网络使用保留IP地址（10.0.0.0/255.0.0.0、172.16.0.0/255.128.0.0和192.168.0.0/255.255.0.0）[64, 65, 66]。这些地址不在Internet上使用，而是专门为内部网络预留的。当内部网络中的主机要访问Internet或被Internet访问时，就需要采用网络地址转换（Network Address Translation, 以下简称NAT），将内部地址转化为Internets上可用的外部地址。NAT的工作原理是报文头（目标地址、源地址和端口等）被正确改写后，客户相信它们连接一个IP地址，而不同IP地址的服务器组也认为它们是与客户直接相连的。由此，可以用NAT方法将不同IP地址的并行网络服务变成在一个IP地址上的一个虚拟服务。

VS/NAT的体系结构如图3.1所示。在一组服务器前有一个调度器，它们是通过Switch/HUB相连接的。这些服务器提供相同的网络服务、相同的内容，即不管请求被发送到哪一台服务器，执行结果是一样的。服务的内容可以复制到每台服务器的本地硬盘上，可以通过网络文件系统（如NFS）共享，也可以通过一个分布式文件系统来提供。

图3.1：VS/NAT的体系结构

客户通过Virtual IP Address（虚拟服务的IP地址）访问网络服务时，请求报文到达调度器，调度器根据连接调度算法从一组真实服务器中选出一台服务器，将报文的目标地址Virtual IP Address改写成选定服务器的地址，报文的目标端口改写成选定服务器的相应端口，最后将修改后的报文发送给选出的服务器。同时，调度器在连接Hash表中记录这个连接，当这个连接的下一个报文到达时，从连接Hash表中可以得到原选定服务器的地址和端口，进行同样的改写操作，并将报文传给原选定的服务器。当来自真实服务器的响应报文经过调度器时，调度器将报文的源地址和源端口改为Virtual IP Address和相应的端口，再把报文发给用户。我们在连接上引入一个状态机，不同的报文会使得连接处于不同的状态，不同的状态有不同的超时值。在TCP连接中，根据标准的TCP有限状态机进行状态迁移；在UDP中，我们只设置一个UDP状态。不同状态的超时值是可以设置的，在缺省情况下，SYN状态的超时为1分钟，ESTABLISHED状态的超时为15分钟，FIN状态的超时为1分钟；UDP状态的超时为5分钟。当连接终止或超时，调度器将这个连接从连接Hash表中删除。这样，客户所看到的只是在Virtual IP Address上提供的服务，而服务器集群的结构对用户是透明的。对改写后的报文，应用增量调整Checksum的算法调整TCP Checksum的值，避免了扫描整个报文来计算Checksum的开销。

下面，举个例子来进一步说明VS/NAT，如图3.2所示：

图3.2：VS/NAT的例子

VS/NAT的配置如下表所示，所有到IP地址为202.103.106.5和端口为80的流量都被负载均衡地调度的真实服务器172.16.0.2:80和172.16.0.3:8000上。目标地址为202.103.106.5:21的报文被转移到172.16.0.3:21上。而到其他端口的报文将被拒绝。

从以下的例子中，我们可以更详细地了解报文改写的流程。

访问Web服务的报文可能有以下的源地址和目标地址：

调度器从调度列表中选出一台服务器，例如是172.16.0.3:8000。该报文会被改写为如下地址，并将它发送给选出的服务器。

从服务器返回到调度器的响应报文如下：

响应报文的源地址会被改写为虚拟服务的地址，再将报文发送给客户：

这样，客户认为是从202.103.106.5:80服务得到正确的响应，而不会知道该请求是服务器172.16.0.2还是服务器172.16.0.3处理的。

配置lvs/NAT
echo "1" > /proc/sys/net/ipv4/ip_forward
ipvsadm -C
ipvsadm -A -t 220.90.88.10:80 -s rr
ipvsadm -a -t 220.90.88.10:80 -r 192.168.0.10:80 -m -w 1
ipvsadm -a -t 220.90.88.10:80 -r 192.168.0.20:80 -m -w 1

在客户段访问http://220.90.88.10 以轮询的方式调用真实服务器的页面！出现交替返回两台服务器的页面，表示成功实现了LVS/NAT。

VS/TUN ：即（Virtual Server via IP Tunneling）

通过IP隧道实现虚拟服务器（VS/TUN）也就是IP隧道技术实现虚拟服务器。它的连接调度和管理与VS/NAT方式一样，只是它的报文转发方法不同，VS/TUN方式中，调度器采用IP隧道技术将用户请求转发到某个Real Server，而这个Real Server将直接响应用户的请求，不再经过前端调度器，此外，对Real Server的地域位置没有要求，可以和Director Server位于同一个网段，也可以是独立的一个网络。因此，在TUN方式中，调度器将只处理用户的报文请求，集群系统的吞吐量大大提高。

在VS/NAT的集群系统中，请求和响应的数据报文都需要通过负载调度器，当真实服务器的数目在10台和20台之间时，负载调度器将成为整个集群系统的新瓶颈。大多数Internet服务都有这样的特点：请求报文较短而响应报文往往包含大量的数据。如果能将请求和响应分开处理，即在负载调度器中只负责调度请求而响应直接返回给客户，将极大地提高整个集群系统的吞吐量。

IP隧道（IP tunneling）是将一个IP报文封装在另一个IP报文的技术，这可以使目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。IP隧道技术亦称为IP封装技术（IP encapsulation）。IP隧道主要用于移动主机和虚拟私有网络（Virtual Private Network），在其中隧道都是静态建立的，隧道一端有一个IP地址，另一端也有唯一的IP地址。

我们利用IP隧道技术将请求报文封装转发给后端服务器，响应报文能从后端服务器直接返回给客户。但在这里，后端服务器有一组而非一个，所以我们不可能静态地建立一一对应的隧道，而是动态地选择一台服务器，将请求报文封装和转发给选出的服务器。这样，我们可以利用IP隧道的原理将一组服务器上的网络服务组成在一个IP地址上的虚拟网络服务。VS/TUN的体系结构如图3.3所示，各个服务器将VIP地址配置在自己的IP隧道设备上。

图3.3：VS/TUN的体系结构

VS/TUN的工作流程如图3.4所示：它的连接调度和管理与VS/NAT中的一样，只是它的报文转发方法不同。调度器根据各个服务器的负载情况，动态地选择一台服务器，将请求报文封装在另一个IP报文中，再将封装后的IP报文转发给选出的服务器；服务器收到报文后，先将报文解封获得原来目标地址为VIP的报文，服务器发现VIP地址被配置在本地的IP隧道设备上，所以就处理这个请求，然后根据路由表将响应报文直接返回给客户。

VS/TUN的工作流程 在这里，请求报文的目标地址为VIP，响应报文的源地址也为VIP，所以响应报文不需要作任何修改，可以直接返回给客户，客户认为得到正常的服务，而不会知道是哪一台服务器处理的。

在VS/TUN中，响应报文根据服务器的路由表直接返回给客户，而不经过负载调度器，所以负载调度器只处于从客户到服务器的半连接中，VS/TUN的TCP状态迁移与VS/NAT的不同。我们给出半连接的TCP有限状态机，如图3.5所示，圈表示状态，箭头表示状态间的转换，箭头上的标识表示在当前状态上收到该标识的输入，迁移到下一个状态。VS/TUN的TCP状态迁移是按照半连接的TCP有限状态机进行的。

图3.5：半连接的TCP有限状态机

VS/DR： 即（Virtual Server via Direct Routing）

通过直接路由实现虚拟服务器（VS/DR）跟VS/TUN方法相同，VS/DR利用大多数Internet服务的非对称特点，负载调度器中只负责调度请求，而服务器直接将响应返回给客户，可以极大地提高整个集群系统的吞吐量。该方法与IBM的NetDispatcher产品中使用的方法类似，但IBM的NetDispatcher是非常昂贵的商品化产品，我们也不知道它内部所使用的机制，其中有些是IBM的专利。

(1) 直接路由
直接路由是指路由器各网络接口所直连的网络之间进行通信所使用的路由。直接路由是在配置完路由器网络接口的IP地址后自动生成的，因此，如果没有对这些接口进行特殊的限制，这些接口所直连的网络之间就可以直接通信。
(2) 间接路由

源主机和目的主机不在同一个物理网络上，其数据包的传送必须经过一个或多个路由器进行转送，由两个或多个路由器互连的网络之间的通信所使用的路由称为间接路由。间接路由通常是由人工配置的静态路由或通过运行动态路由协议而获得的动态路由。

调度器和服务器组都必须在物理上有一个网卡通过不分段的局域网相连，即通过交换机或者高速的HUB相连，中间没有隔有路由器。VIP地址为调度器和服务器组共享，调度器配置的VIP地址是对外可见的，用于接收虚拟服务的请求报文；所有的服务器把VIP地址配置在各自的Non-ARP网络设备上，它对外面是不可见的，只是用于处理目标地址为VIP的网络请求。（请看注释1）

也就是用直接路由技术实现虚拟服务器。它的连接调度和管理与VS/NAT和VS/TUN中的一样，但它的报文转发方法又有不同，VS/DR通过改写请求报文的MAC地址，将请求发送到Real Server，而Real Server将响应直接返回给客户，免去了VS/TUN中的IP隧道开销。这种方式是三种负载调度机制中性能最高最好的，但是必须要求Director Server与Real Server都有一块网卡连在同一物理网段上。

我们的LVS 服务器已经成功运行。但是在访问的过程中，集群系统是如何工作的呢？

VS/DR 的工作流程如图4-12 所示，在VS/DR中，请求报文的目标地址为VIP，响应报文的源地址也为VIP，所以响应报文不需要作任何修改，可以直接返回给客户，客户认为得到正常的服务，而不会知道是哪一台服务器处理的。 VS/DR负载调度器也只处于从客户到服务器的半连接中，按照半连接的TCP有限状态机进行状态迁移。调度器根据各个服务器的负载情况，动态地选择一台服务器，将数据帧的MAC 地址改为负载均衡服务器的MAC 地址，再将修改后的数据帧在与服务器组的局域网上发送（请看注释2）。因为数据帧的MAC 地址是负载均衡的服务器，所以服务器肯定可以收到这个数据帧，从中可以获得该IP 报文。当服务器发现报文的目标地址VIP 是在本地的网络设备上，服务器处理这个报文，然后根据路由表将响应报文直接返回给客户。

注释1：VIP地址为调度器和服务器（RealServer）把共享，那会不会引起IP冲突？

答案是：不会。正因为后面所说的，“调度器配置的VIP地址是对外可见的，用于接收虚拟服务的请求报文；所有的服务器把VIP地址配置在各自的Non-ARP网络设备上，它对外面是不可见的”。在调度器上，VIP与其局域网内IP对外都是可见的；在服务器上，对外可见的是其在局域网上的IP（调度器调度的时候使用的IP），而在服务器上，VIP的性质就像是平常我们所熟知的127.0.0.1的性质一样，它是一个loopback device，他只在网络层之上可见（包括网络层），这样的loopback device用来模拟网络适配器的行为。就算没有装网卡，127.0.0.1与VIP的这样IP都是可用的。
那为什么要在服务器上还放上一个VIP呢？
因为当只修改了MAC地址的链路层帧发到服务器的链路层时（详情请见注释2），要想再向上提交到应用层去让HTTP等服务器程序处理，必须再经过网络层、传输层等，而要通过这些层是要经过目标IP的检测的。
就像你要去参加一个婚礼，到门口，接待人员问你要参加谁的婚礼，人家这里明明举行的是李湘跟王老五的婚礼，你说你要参加谢霆锋跟张柏芝的婚礼，接待人员一定是不让你进去的。那我就是又要说我要参加谢霆锋跟张柏芝的婚礼，以要进入李湘跟王老五的婚礼现场，怎么办？那就在李湘跟王老五的婚礼现场里安排一个自己人，你到时候对他说：“我要参加谢霆锋跟张柏芝的婚礼”，他会意地笑一声，就会帮你在李湘跟王老五的婚礼现场安排座位，让你在里面享受各种服务。服务器里的VIP就有这个自己人的性质，他对外不可见，当请求包到达网络层以上的部分里，就可以看到VIP，从而一路上去，到达应用层，享用HTTP等服务。

注释2：在这里可能有人会产生疑问，修改MAC地址就能让请求包发往Real Server上吗，不用改目标IP地址？

答案是：是的。因为交换机是一个链路层的设备，链路层的传送单位是帧，他可不管网络层的包里放的是什么IP地址（网络层的ipv4包已经被封装在帧里）。当Direcotr把存有客户机的请求包的那帧的MAC地址改成某台Real Server的之后，就发出去，到交换机之后，交换机查找MAC地址与端口的对应表（端口MAC地址对应拥有些MAC地址的计算机），将这一帧发往与帧上MAC地址对应的端口，之后就发到计算机的链路层，如果MAC地址与网卡上的匹配，再向上层发送，直至应用层。

lvs公网环境配置

如果要做外部测试，请在路由器上设置路由，比如对外端口是80，映射地址是Virtual IP，而不是Master或者Backup的地址。安装CentOS时不要选择安装Xen或集群，会有问题。
应用案例：
1、使用一个vip(内网:192.168.1.12)负载2个nginx(内网:192.168.1.13和192.168.1.14)
然后配置一个域名，对应到公网IP:220.181.7.41. 然后做一个IP地址映射，把:220.181.7.41映射到vip(内网:192.168.1.12)上。这样配置就可以放到公网上测试。

2、在同一个lvs机器上再配置一个vip(内网:192.168.1.15)负载2个apache(内网：192.168.1.16和192.168.1.17)，同样配置另外一个域名，对应到公网IP220.181.7.42,做一个IP地址映射，把:220.181.7.42映射到vip(内网:192.168.1.15)上。这样就达到了1个lvs既负载nginx，又负载apache.（这样做的目的是节省机器）

3、就以上的逻辑图看分析：
①如果四台机器均置于IDC机房，前端无防火墙时，这种情况好处理，只需要向你的IDC申请5个公网IP即可，多余的一个公网ip用于VIP；
②如果是上述网络拓扑，后面四台机器均用内网；此时只需要前面的Juniper将内网VIP映射成公网IP即可；
③lvs就比较依赖于网络环境，可以用苛求来形容；要做好LVS管理员，确实得跟进学习很多有关网络通信方面的知识，就不再是一个HTTP那么简单了；相对而言，nginx对网络的依赖较小，理论上只要ping得通，网页访问正常，nginx就能连得通。
④ 本来我想将公司的web环境生级成LVS+Keepalived架构，却发现lvs怎么都不能转发；结果查了下机器的route情况，发现每台机器都有十几条静态路由，二个网关，而Network engineer也说明了网络环境不可能更改，只能由系统环境牵就网络环境；最后只能将LVS+Keepalvied更改为 Nginx+Keepalived架构，甚是遗憾。

DR模式下：

我现在仅有一个公网IP，我分给VIP使用，在防火墙上做MIP，将这个公网IP映射成一个私网IP（和web集群为一个网段），VS/DR 通过改写请求报文的MAC地址（改为选出服务器的MAC地址），再将修改后的数据帧发送给选出的web服务器。因为数据帧的MAC地址是选出的服务器，所以服务器肯定可以收到这个数据帧，从中可以获得该IP报文。当服务器发现报文的目标地址VIP是在本地的网络设备上（lo:0口），服务器处理这个报文，然后根据路由表将响应报文直接返回给客户。

应用服务器执行相应的操作后，将结果直接返回给客户。应用服务器执行相应操作后，通过lo:0口（也就是vip的地址），将结果返回给客户，这也就是为什么整个的架构中，仅需vip有公网IP，然后通过防火墙将公网IP做个mip到私网即可！实际测试：
vip：192.168.2.188
server1：192.168.2.158 （有a.com和b.com虚拟主机）
server2：192.168.2.189 （有a.com和b.com虚拟主机）
客户端–防火墙–vip （这里防火墙将一个公网IP NAT成vip的私网IP，客户端将a.com和b.com的解析指到公网IP）

4、LVS DR模式，前面是防火墙，realserver和lvs_dr都是内网ip,防火墙如何设置，是否要realserver都可以连接公网，还是只要vip连接公网就可以了。

①所有的real-server 和lvs 网关都指向防火墙Lan口 ，DNS填上正确的互联网上的DNS ，那么本身这几台服务器就都能对互联网访问了。
②Lvs前端服务器只是负责外界互联网用户对VIP 的80端口i的请求，后端的服务器直接把回应返回给互联网用户

③防火强唯一需要设置的就是： 把vip（私有地址）对应的互联网合法IP地址（这个地址是外界互联网访问的合法地址），进行静态一对一NAT映射即可

5、我想在内网用两台机器做director,转发请求到两台真是服务器。将一个外网地址映射到VIP上。请问真实服务器也需要外网地址吗。

不需要，只要设置好realserver上的虚拟ip，并配置好服务就可以了

2、 keepalived服务器状态监测

Keepalived的作用

keepalived是一个类似于layer3, 4 & 5交换机制的软件，也就是我们平时说的第3层、第4层和第5层交换。是检测web服务器的状态，如果有一台web服务器死机，或工作出现故障，Keepalived将检测到，并将有故障的web服务器从系统中剔除，当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的web服务器。

keepalived理论工作原理

keepalived也是模块化设计，不同模块复杂不同的功能，下面是keepalived的组件
core check vrrp libipfwc libipvs-2.4 libipvs-2.6
core：是keepalived的核心，复杂主进程的启动和维护，全局配置文件的加载解析等
check：负责healthchecker(健康检查)，包括了各种健康检查方式，以及对应的配置的解析包括LVS的配置解析
vrrp：VRRPD子进程，VRRPD子进程就是来实现VRRP协议的
libipfwc：iptables(ipchains)库，配置LVS会用到。
libipvs*：配置LVS会用到
注意，keepalived和LVS完全是两码事，只不过他们各负其责相互配合而已

2011-9-7 11:47:58 上传

keepalived启动后会有三个进程
父进程：内存管理，子进程管理等等
子进程：VRRP子进程
子进程：healthchecker子进程
有图可知，两个子进程都被系统WatchDog看管，两个子进程各自复杂自己的事，healthchecker子进程复杂检查各自服务器的健康程度，例如HTTP，LVS等等，如果healthchecker子进程检查到MASTER上服务不可用了，就会通知本机上的兄弟VRRP子进程，让他删除通告，并且去掉虚拟IP，转换为BACKUP状态

Keepalived使用的vrrp协议方式，虚拟路由冗余协议 (Virtual Router Redundancy Protocol，简称VRRP)；keepalived的目的是模拟路由器的双机.

Layer3：Keepalived使用Layer3的方式工作式时，Keepalived会定期向服务器群中的服务器发送一个ICMP的数据包（既我们平时用的Ping程序）,如果发现某台服务的IP地址没有激活，Keepalived便报告这台服务器失效，并将它从服务器群中剔除，这种情况的典型例子是某台服务器被非法关机。Layer3的方式是以服务器的IP地址是否有效作为服务器工作正常与否的标准。在本文中将采用这种方式。

Layer4:如果您理解了Layer3的方式，Layer4就容易了。Layer4主要以TCP端口的状态来决定服务器工作正常与否。如web server的服务端口一般是80，如果Keepalived检测到80端口没有启动，则Keepalived将把这台服务器从服务器群中剔除。

Layer5就是工作在具体的应用层了，比Layer3,Layer4要复杂一点，在网络上占用的带宽也要大一些。Keepalived将根据用户的设定检查服务器程序的运行是否正常，如果与用户的设定不相符，则Keepalived将把服务器从服务器群中剔除。

利用 LVS+Keepalived基于完整开源软件的架构可以为你提供一个负载均衡及高可用的服务器。

3、 heartbeat高可用集群

它实现了一个高可用集群系统。心跳服务和集群通信是高可用集群的两个关键组件，在 Heartbeat 项目里，由 heartbeat 模块实现了这两个功能。

高可用集群是指一组通过硬件和软件连接起来的独立计算机，它们在用户面前表现为一个单一系统，在这样的一组计算机系统内部的一个或者多个节点停止工作，服务会从故障节点切换到正常工作的节点上运行，不会引起服务中断。从这个定义可以看出，集群必须检测节点和服务何时失效，何时恢复为可用。这个任务通常由一组被称为“心跳”的代码完成。在Linux-HA里这个功能由一个叫做heartbeat的程序完成。

对于高可用集群系统，如果集群间的通信不可靠，那么很明显集群本身也不可靠。Heartbeat采用UDP协议和串口进行通信，它们本身是不可靠的，可靠性必须由上层应用来提供。那么怎样保证消息传递的可靠性呢？Heartbeat通过冗余通信通道和消息重传机制来保证通信的可靠性。Heartbeat检测主通信链路工作状态的同时也检测备用通信链路状态，并把这一状态报告给系统管理员，这样可以大大减少因为多重失效引起的集群故障不能恢复。

Heartbeat通过实现不同的通信子系统，从而避免了某一通信子系统失效而引起的通信失效。最典型的就是采用以太网和串口相结合的通信方式。这被认为是当前的最好实践，有几个理由可以使我们选择采用串口通信：

（1）IP通信子系统的失效不太可能影响到串口子系统。
（2）串口不需要复杂的外部设备和电源。
（3）串口设备简单，在实践中非常可靠。
（4）串口可以非常容易地专用于集群通信。
（5）串口的直连线因为偶然性掉线事件很少。

不管是采用串口还是以太网IP协议进行通信，heartbeat都实现了一套消息重传协议，保证消息包的可靠传递。实现消息包重传有两种协议，一种是发送者发起，另一种是接收者发起。

对于发送者发起协议，一般情况下接收者会发送一个消息包的确认。发送者维护一个计时器，并在计时器到时的时候重传那些还没有收到确认的消息包。这种方法容易引起发送者溢出，因为每一台机器的每一个消息包都需要确认，使得要发送的消息包成倍增长。这种现像被称为发送者（或者ACK）内爆（implosion）。

对于接收者发起协议，采用这种协议通信双方的接收者通过序列号负责进行错误检测。当检测到消息包丢失时，接收者请求发送者重传消息包。采用这种方法，如果消息包没有被送达任何一个接收者，那么发送者容易因NACK溢出，因为每个接收者都会向发送者发送一个重传请求，这会引起发送者的负载过高。这种现像被称为NACK内爆（implosion）。

Heartbeat实现的是接收者发起协议的一个变种，它采用计时器来限制过多的重传，在计时器时间内限制接收者请求重传消息包的次数，这样发送者重传消息包的次数也被相应的限制了，从而严格的限制了NACK内爆。

Heartbeat是基于主机或网络的服务的高可用方式；heartbeat的目的是用户service的双机。

lvs的高可用建议用keepavlived ,业务的高可用用heartbeat

原文链接：https://blog.csdn.net/weixin_34092455/article/details/92824308