基于heartbeat v1+ldirectord实现LVS集群高可用

前言

高可用集群,High Availability Cluster,简称HA Cluster,是指以减少服务中断时间为目的的服务器集群技术。通过上文可以看出,LVS集群本身并不能实现高可用,比如Director Server不能检测Real Server的健康度,一旦其中一台或全部Real Server宕机,Director Server还会继续转发请求,导致站点无法访问,同样,如果Director Server宕机站点就更不可能正常运转了。本文将讲解如何基于heartbeat v1实现LVS集群高可用。

Heartbeat 

简介

Heartbeat是Linux-HA工程的一个组件,自1999年开始到现在,发布了众多版本,是目前开源Linux-HA项目最成功的一个例子,在行业内得到了广泛的应用。

工作原理

Heartbeat最核心的包括两个部分,心跳监测部分和资源接管部分,心跳监测可以通过网络链路和串口进行,而且支持冗余链路,它们之间相互发送报文来告诉对方自己当前的状态,如果在指定的时间内未收到对方发送的报文,那么就认为对方失效,这时需启动资源接管模块来接管运行在对方主机上的资源或者服务。

基于Heartbeat v1实现LVS集群高可用

实验拓扑

实验环境

node1:node1.scholar.com 172.16.10.123 CentOS6.6

node2:node2.scholar.com 172.16.10.124 CentOS6.6

Real Server1:192.168.1.10(VIP)172.16.10.125(RIP) CentOS6.6

Real Server2:192.168.1.10(VIP)172.16.10.126(RIP) CentOS6.6

注意事项

配置高可用集群的前提:(以两节点的heartbeat为例)

①时间必须保持同步

使用ntp服务器

②节点必须名称互相通信

解析节点名称

/etc/host

集群中使用的主机名为`uname -n`表示的主机名

③ping node

仅偶数节点才需要

④ssh密钥认证进行通信

配置过程

时间同步

请确保两个节点时间同步,这里不再详细讲述

解析名配置

[[email protected] ~]# vim /etc/hosts

172.16.10.123   node1.scholar.com node1
172.16.10.124   node2.scholar.com node2

[[email protected] ~]# vim /etc/sysconfig/network
HOSTNAME=node1.scholar.com

[[email protected] ~]# uname -n
node1.scholar.com

#两个节点都需如上操作

ssh密钥配置

[[email protected] ~]# ssh-keygen -t rsa -P ‘‘
[[email protected] ~]# ssh-copy-id -i .ssh/id_rsa.pub [email protected]
[[email protected] ~]# ssh-keygen -t rsa -P ‘‘
[[email protected] ~]# ssh-copy-id -i .ssh/id_rsa.pub [email protected]
[[email protected] ~]# date; ssh node2 ‘date‘  #测试
Sun Jun  7 17:46:03 CST 2015
Sun Jun  7 17:46:03 CST 2015

安装所需软件包

#解决依赖关系
[[email protected] ~]# yum install perl-TimeDate net-snmp-libs libnet PyXML -y #需epel源支持
[[email protected] ~]# cd heartbeat2
[[email protected] heartbeat2]# ls
heartbeat-2.1.4-12.el6.x86_64.rpm             heartbeat-pils-2.1.4-12.el6.x86_64.rpm
heartbeat-gui-2.1.4-12.el6.x86_64.rpm         heartbeat-stonith-2.1.4-12.el6.x86_64.rpm
heartbeat-ldirectord-2.1.4-12.el6.x86_64.rpm
[[email protected] heartbeat2]# rpm -ivh heartbeat-2.1.4-12.el6.x86_64.rpm heartbeat-pils-2.1.4-12.el6.x86_64.rpm heartbeat-stonith-2.1.4-12.el6.x86_64.rpm
[[email protected] heartbeat2]# yum install heartbeat-ldirectord-2.1.4-12.el6.x86_64.rpm -y

#两个节点都执行以上操作

配置heartbeat

准备配置文件

配置算法密钥

[[email protected] ~]# openssl rand -hex 8
4d8fd6cb49d2047b
[[email protected] ~]# vim /etc/ha.d/authkeys

auth 2
2 sha1 4d8fd6cb49d2047b

配置主配置文件

[[email protected] ~]# grep -v "#" /etc/ha.d/ha.cf |grep -v "^$"
logfile	/var/log/ha-log  #日志存放位置
keepalive 2              #指定心跳使用间隔时间
deadtime 30              #指定备用节点接管主节点服务资源超时时间
warntime 10              #指定心跳延迟的时间
initdead 120             #解决网络启动延时
udpport	694              #设置广播通信端口
mcast eth0 225.0.25.1 694 1 0 #定义广播地址
auto_failback on              #定义当主节点恢复后,是否将服务自动切回
node	node1.scholar.com     #主节点
node	node2.scholar.com     #备用节点
ping 172.16.0.1               #仲裁设备

配置资源管理器

[[email protected] ~]# vim /etc/ha.d/haresources 

node1.scholar.com 192.168.1.10/32/eth0/192.168.1.10 ldirectord::/etc/ha.d/ldirectord.cf

将配置文件传给备用节点

配置ldirectord

准备配置文件并配置

[[email protected] ~]# cp /usr/share/doc/heartbeat-ldirectord-2.1.4/ldirectord.cf /etc/ha.d/
[[email protected] ~]# grep -v ^#  /etc/ha.d/ldirectord.cf

checktimeout=3        #探测超时时间
checkinterval=1       #探测间隔时间
autoreload=yes        #修改配置文件,无需重启服务即可重载
quiescent=yes         #real server 宕机后从lvs列表中删除,恢复后自动添加进列表

virtual=192.168.1.10:80     #VIP
	real=172.16.10.125:80 gate    #real server
	real=172.16.10.126:80 gate    #real server
 	fallback=127.0.0.1:80 gate    #如果RS节点都宕机,则启用本地环回口地址
	service=http                  #基于http协议探测
	request=".health.html"        #探测文件
	receive="ok"                  #探测内容,判断RS是否存活
	scheduler=rr                  #调度算法
	#persistent=600
	#netmask=255.255.255.255

将配置文件传给备用节点,并禁止各节点ldirectord开启自启

准备fallback文件

RS设置

#两个RS各进行如下配置

配置内核参数

准备健康度探测文件和站点文件

测试页面

启动heartbeat

查看资源是否生效

高可用测试

刷新页面

将RS2模拟宕机

#service httpd stop

无论怎么刷新都是RS1的页面

接下来我们把RS1也停掉

切回fallback页面了

我们将node1停掉,看一下node2是否可以接管资源

[[email protected] ~]# service heartbeat stop

资源成功接管,以上访问也不受任何影响,当然如果在次启动node1资源会被再次抢过去,这里就不再演示

基于heartbeat v1 实现LVS高可用至此完成

The end

好了,基于heartbeat v1 实现LVS高可用就说到这里了,整个过程还是挺好玩的,配置过程中遇到问题可留言,下篇将会讲解基于heartbeat v2的高可用集群,有兴趣可以继续关注呦。以上仅为个人学习整理,如有错漏,大神勿喷~~~

时间: 2024-10-04 12:20:21

基于heartbeat v1+ldirectord实现LVS集群高可用的相关文章

基于heartbeat v1配置mysql和httpd的高可用双主模型

一.配置高可用集群的前提:(以两节点的heartbeat为例) ⑴时间必须保持同步 ⑵节点之间必须用名称互相通信 建议使用/etc/hosts,而不要用DNS 集群中使用的主机名为`uname -n`表示的主机名: ⑶ping node(仅偶数节点才需要) ⑷ssh密钥认证进行无障碍通信: 二.heartbeat v1的配置 程序主配置文件:ha.cf 认证密钥:authkeys, 其权限必须为组和其它无权访问: 资源配置文件:haresources /usr/share/doc/heartbe

CentOS6.5安装DRBD+MariaDB+Heartbeat实现数据库集群高可用

本实验使用两台服务器搭建: 系统                  CentOS6.5 tese02              IP:192.168.1.244 test03               IP:192.168.1.245 DRBD               版本:8.4.6 DRBD-UTIL       版本:8.9.2 MariaDB           版本:10.0.17 Heartbeat         版本:3.0.4 VIP                  

Rabbitmq集群高可用测试

Rabbitmq集群高可用 RabbitMQ是用erlang开发的,集群非常方便,因为erlang天生就是一门分布式语言,但其本身并不支持负载均衡. Rabbit模式大概分为以下三种:单一模式.普通模式.镜像模式 单一模式:最简单的情况,非集群模式. 没什么好说的. 普通模式:默认的集群模式. 对于Queue来说,消息实体只存在于其中一个节点,A.B两个节点仅有相同的元数据,即队列结构. 当消息进入A节点的Queue中后,consumer从B节点拉取时,RabbitMQ会临时在A.B间进行消息传

ActiveMQ + ZooKeeper 集群高可用配置

一. 准备条件: (1) 最好是有3台服务器[2台也行, 只是根据(replicas/2)+1 公式至少得2个ActiveMQ服务存在才能保证运行, 自己测试的时候麻烦点, 关掉其中一个, 再开启, 看会不会选举到另一个ActiveMQ服务, 多试几次可以看到效果] (2)  ActiveMQ安装参考: ActiveMQ (3)  ZooKeeper安装参考:ZooKeeper 二. 配置 : ActiveMQ根目录下的conf/activemq.xml, 原来默认如下: <persistenc

heartbeat v1(CRM)+DRBD实现数据库服务器高可用集群搭建

一. 方案简介 本方案采用Heartbeat双机热备软件来保证数据库的高稳定性和连续性,数据的一致性由DRBD这个工具来保证.默认情况下只有一台mysql在工作,当主mysql服务器出现问题后,系统将自动切换到备机上继续提供服务,当主数据库修复完毕,又将服务切回继续由主mysql提供服务. 二. 方案优缺点 优点:安全性高.稳定性高.可用性高,出现故障自动切换, 缺点:只有一台服务器提供服务,成本相对较高.不方便扩展.可能会发生脑裂. 三. 方案架构图 四.  方案适用场景 本方案适用于数据库访

基于腾讯云CLB实现K8S v1.10.1集群高可用+负载均衡

概述: 最近对K8S非常感兴趣,同时对容器的管理等方面非常出色,是一款非常开源,强大的容器管理方案,最后经过1个月的本地实验,最终决定在腾讯云平台搭建属于我们的K8S集群管理平台~ 采购之后已经在本地部署了不下百次模拟线上生成环境,尽可能还原本地搭建过程,于是修改了安装脚本以及镜像文件. 基础环境 主机 地址 Type k8s-host1 192.168.100.121 master node k8s-host2 192.168.100.122 master node k8s-host3 192

基于MMM搭建MySQL Replication集群高可用架构

MMM介绍 MMM是Multi-Master Replication Manager for MySQL的缩写,它是MySQL提供的一个多主复制管理器,其核心是使用perl语言编写的一组脚本.实际上MMM是比较早期甚至有点老的一种用于构建高可用MySQL架构的方式,但因其还有一定的应用场景,所以本文将会演示一下如何搭建一个MMM架构. MMM 由两个组件组成: monitor:监控集群内数据库的状态,在出现异常时发布切换命令,一般和数据库分开部署 agent:运行在每个 MySQL 服务器上的代

mfs3.0.85+heartbeat+drbd集群高可用实现

mfs集群部署文档 1.内容简介 MFS有元数据服务器(mfsmaster).元数据日志存储服务器(mfsmetalogger).数据存储服务器(mfschunkserver).客户端(clients)组成. 目前MFS元数据服务器存在单点问题,因此我们可以通过DRBD提供磁盘及时同步,通过HeartBeat提供Failover,来达到高可用.实现高可用后,不使用mfsmetalogger. 2.机器分配: 角色 软件版本 ip地址 操作系统 硬盘 网卡 mfsmaster moosefs3.0

Heartbeat实现集群高可用热备

公司最近需要针对服务器实现热可用热备,这几天也一直在琢磨这个方面的东西,今天做了一些Heartbeat方面的工作,在此记录下来,给需要的人以参考. Heartbeat 项目是 Linux-HA 工程的一个组成部分,它实现了一个高可用集群系统.通过Heartbeat我们可以实现双机热备,以实现服务的持续性. heartbeat (Linux-HA)的工作原理:heartbeat最核心的包括两个部分,心跳监测部分和资源接管部分,心跳监测可以通过网络链路和串口进行,而且支持冗 余链路,它们之间相互发送