https://www.161616.top/tags/ha/ Recent content in HA on Cylon's Collection Hugo -- 0.125.7 zh Wed, 01 Apr 2026 23:00:36 +0800 https://www.161616.top/haproxy-http-connection-mode/ Sat, 14 Feb 2026 00:00:00 +0000 https://www.161616.top/haproxy-http-connection-mode/ 问题描述 在使用 haproxy 驱动 Pod 代理时，在个别 k8s 集群中 haproxy 容器 (haproxytech/haproxy-debian:2.7) 在启动时出现 OOM 秒重启，即使配置了 16GB 的内存限制依然被杀掉。而同样的镜像和配置在其他 Rocky Linux 9 集群中运行正常。 关键症状 内存占用异常： 内存配置 症状 2GB OOM 8GB OOM 15GB OOM 就是配置多大的内存都会被吞掉。当时日志记录如下 text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 Feb 13 11:57:07 unit-z7p4-worker-02 kernel: memory: usage 8388608kB, limit 8388608kB, failcnt 110 Feb 13 11:57:07 unit-z7p4-worker-02 kernel: swap: usage 0kB, limit 0kB, failcnt 0 Feb 13 11:57:07 unit-z7p4-worker-02 kernel: Memory cgroup stats for /kubepods. https://www.161616.top/haproxy-http-connection-mode/ Tue, 31 Jan 2023 00:00:00 +0000 https://www.161616.top/haproxy-http-connection-mode/ haproxy作为一个『代理软件』如果当工作与 HTTP 模式下，所有经由haproxy的的连接的请求和响应都取决于 frondend 中配置的 『http_connection_mode』 即 haproxy 中 frontend 与 backend 的组合，而haproxy 支持 3 种连接模式： KAL keep alive: frontend 中配置为 http-keep-alive ; 这是默认模式，这也是http中的keepalive 表示所有请求和响应都得到处理，连接保持打开状态，但在响应和新请求之间处于空闲状态。 SCL server close : frontend 中配置为 http-server-close ; 接收到响应结束后，面向服务器的连接关闭，但面向客户端的连接保持打开状态 CLO close: frontend 中配置为 httpclose ；连接在响应结束后关闭，并在两个方向上附加 “Connection: close” 。 下列矩阵表示的是通过 frondend 与 backend 之间两端的代理模式，这个模式是对称的 text 1 2 3 4 5 6 7 | KAL | SCL | CLO ----+-----+-----+---- KAL | KAL | SCL | CLO ----+-----+-----+---- mode SCL | SCL | SCL | CLO ----+-----+-----+---- CLO | CLO | CLO | CLO 对于http选项的说明 选项 说明 forwardfor 这个选项同时存在于backend 与 frontend端，但backend中的优先级超过frontend 如果同时设置了这个参数，那么 backend段的子参数将优先与 frontend 一端 httpchk 启用http协议检查来检测server的健康状态，默认情况下状态检查是仅建立一个tcp连接 httpclose 这个选项代表了haproxy 对于http协议持久连接方便的配置 Reference：configuration. https://www.161616.top/haproxy2/ Wed, 14 Dec 2022 00:00:00 +0000 https://www.161616.top/haproxy2/ haproxy1 VS haproxy2 haproxy2由 2019-06-16 被发布，对于与haproxy1版本来说，haproxy 2.0 增加了对云原生的支持，这使得haproxy 2.0 更适用于云原生环境，对比于 haproxy1.0 在2001年发布来，到 1.9.16 在 2020/07/31 最后一次更新也代表haproxy1.0的结束维护 为什么选择haproxy2.0 haproxy2.0的核心功能就是集成了云原生架构的支持。包含L7重试, Prometheus metrics, 流量镜像 (traffic shadowing), 多语言可扩展性, gRPC 。haproxy2.0 还增加 基于haproxy2.0 的 Kubernetes Ingress Controller 和强大的 HAProxy Data Plane API，这提供了用于配置和管理 HAProxy 的 REST API 安装haproxy2.0 对于 Ubuntu/Debian 来说，社区版haproxy提供了更友好的安装方式，用户直接添加对应仓库可以直接安装最新版本的haproxy Debian/Ubuntu HAProxy packages 对于 CentOS/Fedora 来说，只有Fedora 仓库提供了较为新版的haproxy，通常来在这类平台的Linux都是通过编译安装haproxy 下载haproxy2.6源码 [ haproxy下载 ] 安装依赖包 bash 1 yum install gcc pcre-devel openssl-devel tar make -y 编译程序 bash 1 2 3 4 5 6 7 8 9 tar xf haproxy-2. https://www.161616.top/haproxy/ Thu, 16 Nov 2017 00:00:00 +0000 https://www.161616.top/haproxy/ haproxy 介绍 haproxy是一个开源的、高性能的基于TCP和HTTP应用代理的高可用的、负载均衡服务软件，它支持双机热备、高可用、负载均衡、虚拟主机、基于TCP和HTTP的应用代理、图形界面查看信息等功能。其配置简单、维护方便，而且拥有很好的对服务器节点的健康检查功能(相当于keepalived健康检查)，当其代理的后端服务器出现故障时，haproxy会自动的将该故障服务器摘除，当故障的服务器恢复后，haproxy还会自动将该服务器自动加入进来提供服务。 LVS/NGINX对比 haproxy 特别适用于那些高负载、访问量很大，但又需要会话保持及七层应用代理的业务应用。haproxy运行在今天的普通的服务器硬件上，几乎不需要进行任何的优化就可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单、轻松、安全的整合到各种己有的网站架构中，同时，haproxy的代理模式，可以使得所有应用服务器不会暴露到公共网络上，即后面的节点服务器不需要公网IP地址。 从1.3版本起，haproxy软件引入了frontend,backend的功能，frontend (ad规则匹配)可以让运维管理人员根据任意HTTP请求头内容做规则匹配，然后把请求定向到相关的backend(这个是事先定义好的多个server pools，等待前端把请求转过来的服务器组)。通过frontend和backend，我们可以很容易的买现haproxy的各种7层应用代理功能。 haproxy代理模式 haproxy支持两种主要代理模式： 1、基于4层的tcp应用代理(例如:可用于邮件服务、内部协议通信服务器、MySQL、HTTPS服务等)。 2、基于7层的http代理。在4层tcp代理模式下，haproxy仅在客户端和服务器之间进行流量转发。但是在7层http代理模式下，haproxy会分析应用层协议，并且能通过允许、拒绝、交换、增加、修改或者删除请求(request)或者回应(response)里指定内容来控制协议。 官方网站:www.haproxy.org haproxy 解决方案拓扑图 haproxy L4负载均衡应用架构拓扑 haproxy软件的四层tcp应用代理非常优秀，且配置非常简单、方便，比LVS和Nginx的配置要简单很多，首先，配置haproxy不需要在RS端做任何特殊配置 (只要对应服务开启就OK)就可以实现应用代理，其次，haproxy的配置语法和增加虚拟主机功能等也比lvs/nginx简单。并且和商业版的NS (Netscaler)、F5, A10等负载均衡硬件的使用方法和在架构中的位置一模一样。下面是haproxy的Layer4层应用代理的拓扑结构图: 说明:由于haproxy软件采用的是类NAT模式(本质不同)的应用代理，数据包来去都会经过haproxy，因此，在流量特别大的情况下(门户级别的流量)，其效率和性能不如LVS的DR模式负载均衡。 在一般的中小型公司，建议采用haproxy做负载均衡，而不要使用LVS或Nginx。为什么强调中小型公司呢?换句话说，千万PV级别以下直接使用haproxy做负载均衡，会让我们负责维护的运维管理人员配置简单、快速、维护方便，出问题好排查。 haproxy L7负载均衡应用架构拓扑 haproxy软件的最大优势在于其7层的根据URL请求头应用过滤的功能以及sesson会话功能，在门户网站的高并发生产架构中，haproxy软件一般用在4层LVS负载均衡软件的下一层，或者像haproxy官方推荐的也可以挂在硬件负载均衡althon, NS, F5, A10下使用，其表现非常好。从2009年起taobao，京东商城的业务也大面积使用了haproxy作为7层CACHE应用代理。 安装haproxy 模拟真实环境 搭建合适的模拟环境是一个人学习能力的重要体现。例如：人类第一次上太空也没有真正的环境，但是想去太空就是要自己动手去搭建逼真的模拟环境。实验多了就是经验，自然就有解除生产环境的机会了。 名称 接口 IP 用途 MASTER eth0 10.0.0.7 外网管理IP用于WAN数据转发 eth1 172.16.1.7 内网管理IP，用于LAN数据转发 eth2 10.0.10.7 用于服务器间心跳连接（直连） VIP 10.0.0.17 用于提供应用程序A挂载服务 BACKUP eth0 10.0.0.8 外网管理IP，用于WAN数据转发 eth1 172.16.1.8 内网管理IP，用于LAN数据转发 eth2 10.0.10.8 用于服务器间心跳连接（直连） VIP 10.0.0.8 用于提供应用程序B挂载服务 下载安装haproxy 下载地址：http://www.haproxy.org/download/ 文档地址：http://www.haproxy.org/download/1.7/doc/configuration.txt 编译haproxy bash 1 2 3 4 make TARGET=linux2628 ARCH=x86_64 # <==64位编译配置 make TARGET=linux2628 ARCH=i386 # <==32位编译配置 make PREFIX=/app/haproxy-1. https://www.161616.top/keepalived/ Wed, 15 Feb 2017 00:00:00 +0000 https://www.161616.top/keepalived/ Keepalived介绍 Keepalived软件起初是专为LVS负载均衡软件设计的，用来管理并监控LVS集群系统中各个服务节点的状态，后来又加入了可以实现高可用的VRRP功能。因此，Keepalived除了能够管理LVS软件外，还可以作为其他服务（例如：Nginx、Haproxy、MySQL等）的高可用解决方案软件。 Keepalived软件主要是通过VRRP协议实现高可用功能的。VRRP是Virtual Router Redundancy Protocol（虚拟路由器冗余协议）的缩写，VRRP出现的目的就是为了解决静态路由单点故障问题的，它能够保证当个别节点宕机时，整个网络可以不间断地运行。所以，Keepalived一方面具有配置管理LVS的功能，同时还具有对LVS下面节点进行健康检查的功能，另一方面也可实现系统网络服务的高可用功能。 Keepalived服务的三个重要功能 管理LVS负载均衡软件 早期的LVS软件，需要通过命令行或脚本实现管理，并且没有针对LVS节点的健康检查功能。为了解决LVS的这些使用不便的问题，Keepalived就诞生了，可以说，Keepalived软件起初是专为解决LVS的问题而诞生的。因此，Keepalived和LVS的感情很深，它们的关系如同夫妻一样，可以紧密地结合，愉快地工作。Keepalived可以通过读取自身的配置文件，实现通过更底层的接口直接管理LVS的配置以及控制服务的启动、停止等功能，这使得LVS的应用更加简单方便了。LVS和Keepalived的组合应用不是本章的内容范围。 实现对LVS集群节点健康检查功能（healthcheck） 前文已讲过，Keepalived可以通过在自身的keepalived.conf文件里配置LVS的节点IP和相关参数实现对LVS的直接管理；除此之外，当LVS集群中的某一个甚至是几个节点服务器同时发生故障无法提供服务时，Keepalived服务会自动将失效的节点服务器从LVS的正常转发队列中清除出去，并将请求调度到别的正常节点服务器上，从而保证最终用户的访问不受影响；当故障的节点服务器被修复以后，Keepalived服务又会自动地把它们加入到正常转发队列中，对客户提供服务。 作为系统网络服务的高可用功能（failover） Keepalived可以实现任意两台主机之间，例如Master和Backup主机之间的故障转移和自动切换，这个主机可以是普通的不能停机的业务服务器，也可以是LVS负载均衡、Nginx反向代理这样的服务器。 Keepalived高可用功能实现的简单原理为，两台主机同时安装好Keepalived软件并启动服务，开始正常工作时，由角色为Master的主机获得所有资源并对用户提供服务，角色为Backup的主机作为Master主机的热备；当角色为Master的主机失效或出现故障时，角色为Backup的主机将自动接管Master主机的所有工作，包括接管VIP资源及相应资源服务；而当角色为Master的主机故障修复后，又会自动接管回它原来处理的工作，角色为Backup的主机则同时释放Master主机失效时它接管的工作，此时，两台主机将恢复到最初启动时各自的原始角色及工作状态。 说明：Keepalived的高可用功能是本章的重点，后面除了讲解Keepalived高可用的功能外，还会讲解Keepalived配合Nginx反向代理负载均衡的高可用的实战案例。 Keepalived高可用故障切换转移原理 Keepalived高可用服务对之间的故障切换转移，是通过VRRP（Virtual Router Redundancy Protocol，虚拟路由器冗余协议）来实现的。 在Keepalived服务正常工作时，主Master节点会不断地向备节点发送（多播的方式）心跳消息，用以告诉备Backup节点自己还活着，当主Master节点发生故障时，就无法发送心跳消息，备节点也就因此无法继续检测到来自主Master节点的心跳了，于是调用自身的接管程序，接管主Master节点的IP资源及服务。而当主Master节点恢复时，备Backup节点又会释放主节点故障时自身接管的IP资源及服务，恢复到原来的备用角色。 什么是VRRP VRRP，全称Virtual Router Redundancy Protocol，中文名为虚拟路由冗余协议，VRRP的出现就是为了解决静态路由的单点故障问题，VRRP是通过一种竞选机制来将路由的任务交给某台VRRP路由器的。 VRRP早期是用来解决交换机、路由器等设备单点故障的，下面是交换、路由的Master和Backup切换原理描述，同样适用于Keepalived的工作原理。 在一组VRRP路由器集群中，有多台物理VRRP路由器，但是这多台物理的机器并不是同时工作的，而是由一台称为Master的机器负责路由工作，其他的机器都是Backup。Master角色并非一成不变的，VRRP会让每个VRRP路由参与竞选，最终获胜的就是Master。获胜的Master有一些特权，比如拥有虚拟路由器的IP地址等，拥有系统资源的Master负责转发发送给网关地址的包和响应ARP请求。 VRRP通过竞选机制来实现虚拟路由器的功能，所有的协议报文都是通过IP多播（Multicast）包（默认的多播地址224.0.0.18）形式发送的。虚拟路由器由VRID（范围0-255）和一组IP地址组成，对外表现为一个周知的MAC地址：00-00-5E-00-01-{VRID}。所以，在一个虚拟路由器中，不管谁是Master，对外都是相同的MAC和IP（称之为VIP）。客户端主机并不需要因Master的改变而修改自己的路由配置。对它们来说，这种切换是透明的。 在一组虚拟路由器中，只有作为Master的VRRP路由器会一直发送VRRP广播包（VRRP Advertisement messages），此时Backup不会抢占Master。当Master不可用时，Backup就收不到来自Master的广播包了，此时多台Backup中优先级最高的路由器会抢占为Master。这种抢占是非常快速的（可能只有1秒甚至更少），以保证服务的连续性。出于安全性考虑，VRRP数据包使用了加密协议进行了加密。 如果你在面试时，要你解答Keepalived的工作原理，建议用自己的话回答如下内容，以下为对面试官的表述： Keepalived高可用对之间是通过VRRP通信的： VRRP，全称Virtual Router Redundancy Protocol，中文名为虚拟路由冗余协议，VRRP的出现是为了解决静态路由的单点故障。 VRRP是通过一种竞选协议机制来将路由任务交给某台VRRP路由器的。 VRRP用IP多播的方式（默认多播地址（224.0.0.18））实现高可用对之间通信。 工作时主节点发包，备节点接包，当备节点接收不到主节点发的数据包的时候，就启动接管程序接管主节点的资源。备节点可以有多个，通过优先级竞选，但一般Keepalived系统运维工作中都是一对。 VRRP使用了加密协议加密数据，但Keepalived官方目前还是推荐用明文的方式配置认证类型和密码。 Keepalived服务的工作原理 介绍完了VRRP，接下来我再介绍一下Keepalived服务的工作原理： Keepalived高可用对之间是通过VRRP进行通信的，VRRP是通过竞选机制来确定主备的，主的优先级高于备，因此，工作时主会优先获得所有的资源，备节点处于等待状态，当主挂了的时候，备节点就会接管主节点的资源，然后顶替主节点对外提供服务。 在Keepalived服务对之间，只有作为主的服务器会一直发送VRRP广播包，告诉备它还活着，此时备不会抢占主，当主不可用时，即备监听不到主发送的广播包时，就会启动相关服务接管资源，保证业务的连续性。接管速度最快可以小于1秒。 Keepalived高可用服务搭建 安装Keepalived 通过官方地址获取Keepalived源码软件包编译安装 sh 1 2 3 4 ./configure \ --prefix=/app/keepalived-\ --mandir=/usr/local/share/man make && make install 复制命令到/usr/sbin下 sh 1 ln -s /app/keepalived-1.3.5/sbin/keepalived /usr/sbin/ keepalived默认会读取/etc/keepalived/keepalived.conf配置文件 https://www.161616.top/lvs-and-keepalived/ Sat, 07 Jan 2017 00:00:00 +0000 https://www.161616.top/lvs-and-keepalived/ LVS概述 负载均衡(Load Balance)集群提供了一种廉价、有效、透明的方法，来扩展网络设备和服务器的负载、带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。 搭建负载均衡服务的需求 把单台计算机无法承受的大规模的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间，提升用户体验. 单个重负载的运算分担到多台节点设备上做并发处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。 7*24小时服务保证，任意一个或多个有限后面节点设备宕机，要求不能影响业务。 在负载均衡集群中，所有计算机节点都应该提供相同的服务。集群负载均衡器所截获所有对该服务的入站请求。然后将这些请求尽可能的平均分配在所有集群节点上。 LVS (Linux Virtual Server)介绍 LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统，可在UNIX、Linux平台下实现负载均衡集群功能。该项目在1998年5月由章文嵩博士组织成立，是中国国内最早出现的自由软件项目之一 LVS项目介绍 http://www.linuxvirtualserver.org/zh/lvs1.html LVS集群的体系结构 http://www.linuxvirtualserver.org/zh/lvs2.html LVS集群中的IP负载均衡技术 http://www.linuxvirtualserver.org/zh/lvs3.html LVS集群的负载调度 http://www.linuxvirtualserver.org/zh/lvs4.html IPVS（LVS）发展史 早在2.2内核时，IPVS就已经以内核补丁的形式出现。 从2.4.23版本开始，IPVS软件就是合并到Linux内核的常用版本的内核补丁的集合。 从2.4.24以后IPVS已经成为Linux官方标准内核的一部分。 IPVS软件工作层次图 从上图可以看出，LVS负载均衡调度技术是在Linux内核中实现的，因此，被称之为Linux虚拟服务器（Linux virtual Server）。我们使用该软件配置LVS时候，不能直接配置内核中的ipvs，而需要使用ipvs的管理工具ipsadm进行管理. LVS技术点小结： 真正实现调度的工具是IPVS， 工作在Linux内核层面 LVS自导IPVS管理工具是ipvsadm keepalived实现管理IPVS及负载均衡器的高可用。 RedHat工具Piranha WEB管理实现调度的工具IPVS。 LVS体系结构与工作原理简单描述 LVS集群负载均衡器接受服务的所有入站客户端计算机请求，并根据调度算法决定那个集群几点应该处理回复请求。负载均衡器简称(LB)有时也被成为LVS Director简称Director LVS虚拟服务器的体系结构如下图所示，一组服务器通过告诉的局域网或者地理分布的广域网互相连接，在他们的前端有一个负载调度器（Load Balancer）。负载调度器能无缝地将网络请求调度到真实服务器上，从而使得服务器集群的结构对客户是透明的，客户访问集群系统提供的网络服务就像访问一台高性能、高可用的服务器一样。客户程序不收服务器集群的影响不需作任何修改。胸的伸缩性通过在服务集群中透明的加入和删除一各节点来达到，通过检测节点或服务进程故障和正确地重置系统达到高可用性。由于我们的负载调度技术是在Linux内核中实现的，我们称之为Linux虚拟服务器（Linux Virtual Server）。 LVS基本工作过程图 **LVS基本工作过程图1：带颜色的小方块代表不同的客户端请求 LVS基本工作过程图2： 不同的客户端请求小方块经过负载均衡器，通过指定的分配策略被分发到后面的机器上 LVS基本工作过程图3： LVS基本工作过程图4： LVS相关术语命名约定 名称 缩写 说明 虚拟IP地址(Virtual IP Address) VIP VIP为Direcort用于向客户端计算机提供IP地址.如www.baidu.com域名就要解析到VIP上提供服务 真实IP地址(Real Server IP Address) RIP 在集群下面节点上使用的IP地址，物理IP地址 Director的IP地址(Director IP Address) DIP Director用于连接内外网络的IP地址，物理网卡上的IP地址，是负载均衡器上的IP 客户端主机IP地址(Client IP Address) CIP 客户端用户计算机请求集群服务器的IP地址，该地址用作发送给集群的请求的源IP地址 LVS集群内部的节点称为真实服务器(Real Server)，也叫做集群节点。请求集群服务的计算机称为客户端计算机。 https://www.161616.top/heartbeat/ Fri, 25 Nov 2016 00:00:00 +0000 https://www.161616.top/heartbeat/ heartbeat介绍 Heartbeat一款开源提供高可用(Highly-Available)服务的软件，通过heartbeat，可以将资源（IP及程序服务等资源）从一台已经故障的计算机快速转移到另一台正常运转的机器上继续提供服务，一般称之为高可用服务。在实际生产应用场景中，heartbeat的功能和另一个高可用开源软件keepalived有很多相同之处，但在生产中，对应实际的业务应用也是有区别的，例如:keepalived主要是控制IP的漂移，配置、应用简单，而heartbeat则不但可以控制IP漂移，更搜长对资源服务的控制，配置、应用比较复杂 heartbeat工作原理 通过修改heartbeat软件的配置文件，可以指定哪一台Heartbeat服务器作为主服务器，则另一台将自动成为热备服务器.然后在热备服务器上配里Heartbeat守护程序来监听来自主服务器的心跳消息。如果热备服务器在指定时间内未监听到来自主服务器的心跳，就会启动故障转移程序，并取得主服务器上的相关资源服务的所有权，接替主服务器继续不间断的提供服务，从而达到资源及服务高可用性的目的。 以上描述的是heartbeat主备的模式，heartbeat还支持主主棋式，即两台服务器互为主备，这时它们之间会相互发送报文来告诉对方自己当前的状态，如果在指定的时间内未受到对方发送的心跳报文，那么，一方就会认为对方失效或者宕机了，这时每个运行正常的主机就会启动自身的资源接管模块来接管运行在对方主机上的资源或者服务，继续为用户提供服务。一般情况下，可以较好的实现一台主机故障后，企业业务仍能够不间断的持续运行。 注意：所谓的业务不间断，再故障转移期间也是需要切换时间的(例如:停止数据库及存储服务等)，heartbeat的主备高可用的切换时间一般是在5-20秒左右(服务器宕机的切换比人工切换要快)。 另外，和keepalived高可用软件一样，heartbeat高可用是操作系统级别的，不是服务(软件)级别的，可以通过简单的脚本控制.实现软件级别的高可用。 高可用服务器切换的常见条件场景： 主服务器物理宕机(硬件损坏，操作系统故障)。 Heartbeat服务软件本身故障。 两台主备服务器之间心跳连接故障。 服务故障不会导致切换.可以通过服务宕机把heartbeat服务停掉。 3 heartbeat心跳连接 经过前面的叙述，要部署heartbeat服务，至少需要两台主机来完成。那么，要实现高可用服务，这两台主机之间是如何做到互相通信和互相监侧的呢？ 下面是两台heartbeat主机之间通信的一些常用的可行方法： 利用串行电缆，即所谓的串口线连接两台服务器(可选)。 一根以太网电缆两网卡直连(可选)。 以太网电缆，通过交换机等网络设备连接(次选)。 如何为高可用服务器端选择心跳通信方案？ 串口线信号不会和以太网网络交集，也不需要单独配置丐地址等信息，因此传输稳定不容易出现问题，使用串口线的缺点是两个服务器对之间的距离距离不能太远，串口线对应服务端的设备为/dev/ttys0。串口线形状如下图所示： 使用以太网网线(无需特殊交叉线了)直连网卡的方式，配置也比较简单，只需对这两块直连网线的网卡配好独立的IP段地址能够互相通信即可，普通的网线就可以了（推荐） 使用联网以太网网线和网卡作为心跳线是次选的方案，因为这个链路里增加了交换机设备这样的故障点，且这个线路不是专用心跳线路，容易受以太网其他数据传输的影响，导致心跳报文发送延迟或者无法送达问题。 选择方案小结： 和数据相关的业务，要求较高，可以串口和网线直连的方式并用。 Web业务，可以网线直连的方式或局域网通信方式也可。 Heartbeat软件未来发展说明 有关heartbeat分3个分支的说明 自2.1.4版本后，Linux-HA将Heartbeat分包成三个不同的子项目，并且提供了一个cluster-glue的组件，专用于Local ResourceManager 的管理。即heartbeat + cluster-glue + resouce-agent 三部分。 Heartbeat hearbeat本身是整个集群的基础（cluster messaging layer），负责维护集群各节点的信息以及它们之前通信。 Cluster Glue 相当于一个中间层，负责调度，可以将heartbeat和crm（pacemaker）联系起来，包括两个摸块:本地资漂管理(Local Resource Manager)LRM和STONITH。 Resource Agents 资源代理层，各种的资源的ocf脚本，这些脚本将被LRM调用从而实现各种资源启动、停止、监控等等。 Pacfrmaker资料 pacemaker介绍：http://baike.baidu.com/view/8635511.htm 从头开始搭建其群在Fedora上面创建主/主和主/备集群 http://www.clusterlabs.org/doc/zh-CN/Pacemaker/1.1/html-single/Clusters_from_Scratch/index.html 参考文档：http://www.2cto.com/os/201511/448872.html 裂脑 什么是裂脑 由于某些原因，导致两台高可用服务器对之间在指定时间内，无法互相检侧到对方心跳而各自启动故障转移功能，取得了资源及服务的所有权，而此时的两台高可用服务器对都还活着并在正常运行，这样就会导致同一个IP或服务在两端同时启动而发生冲突的严重问题，最严重的是两台主机占用同一个VIP地址，当用户写入数据时可能会分别写入到两端，这样可能会导致服务器两端的数据不一致或造成数据丢失，这种情况就被称为裂脑，也有人称其为分区集群或大脑垂直分割，英文为split brain。 导致裂脑发生的多种原因 一般来说，裂脑的发生，有以下几个原因。 高可用服务器对之间心跳线链路故障。导致无法正常通信。 心跳线坏了(包括断了，老化)。 网卡及相关驱动坏了，IP配置及冲突问题(网卡直连)。 心跳线间连接的设备故障(网卡及交换机)。 仲裁的机器出问题(仲裁的方案)。 高可用服务器对上开启了如iptables防火墙阻挡了心跳的传输。 高可用服务器对上心跳网卡地址等信息配置不正确，导致发送心跳失败。 其它服务配置不当等原因，如心跳方式不同，心跳广播冲突、软件BUG等。 提示:另外的高可用软件keepalived配置里如果virtual router_id参数，两端配置不一致，也会导致裂脑问题发生。 防止裂脑发生的8种秘籍 发生裂脑时，对业务的影响是极其严重的，有时甚至是致命的。如:两台高可用服务器对之间发生裂脑，导致互相争用同一IP资源，就如同我们在局域网内常见的IP地址冲突一样，两个机器就会有一个或者两个都不正常，影响用户正常访问服务器。如果是应用在数据库或者存储服务这种极重要的高可用上，那就可能会导致用户发布的数据间断的写在两台不同服务器上，最终数据恢复极困难或难以恢复(当然，有NAS等公共存储的硬件也许会好一些）。