Linux HA Cluster高可用服务器集群,所谓的高可用不是主机的高可用,而是服务的高可用。

什么叫高可用:一个服务器down掉的可能性多种多样,任何一个可能坏了都有可能带来风险,而服务器离线通常带来的代价是很大的,尤其是web站点,所以当某一台提供服务的的服务器down掉不至于服务终止的就叫高可用。

什么叫心跳:就是将多台服务器用网络连接起来,而后每一台服务器都不停的将自己依然在线的信息很简短很小的通告给同一个网络中的备用服务器的主机,告诉其实主机自己依然在线,其它服务器收到这个心跳信息就认为本机是在线的,尤其是主服务器。

心跳信息怎么发送,由谁来收,其实就是进程中的通信两台主机是没法通信的,只能利用网络功能,通过进程监听在某一套接字上,实现数据发送,数据请求,所以多台服务器就得运行同等的进程,这两个进程不停的进行通信,主节点(主服务器)不停的向对方同等的节点发送自己的心跳信息,那这个软件就叫高可用的集群的基准层次,也叫心跳信息传递层以及事物信息的传递层,这是运行在集群中的各节点上的进程,这个进程是个服务软件,关机后需要将其启动起来,主机间才可以传递信息的,一般是主节点传给备节点。

所谓的资源:以web为例,vip是资源,web服务也是资源,还有网页面也是资源,一个服务包括多个资源,而像web的共享存储也是资源等等,不同的服务所需要的资源也是不同的,而共享存储是高可用集群中最难解决的问题。

如是主节点挂了,多个备节点怎么样来选择一个备节点来做为提供服务的一个节点呢,而这种应该选择哪个备用节点来做为提供服务的机制就叫做集群事物决策的过程

ha_aware:如果一个应用程序自己能够利用底层心跳信息传递层的功能完成集群事物决策的过程的软件就叫ha_aware。

DC:Designated Coordinator选定的协调员,当DC所在的主机挂了就会先选出一个DC,再由DC做出事物的决策。注意:在高可用集群中最核心的、最底层的管理的单位叫资源,把资源组合在一起来组合成一个服务。

高可用集群中任何资源都不应该自行启动,而是由CRM管理启动启动的;
   CRM:Cluster Resources Manager集群资源管理,真正做出决策的是CRM。

heartbeat v1版时就有了资源管理的概念,而v1版的资源就是heartbeat自带的,叫haresources,这个文件是个配置文件;而这个配置文件接口就叫haresources;
   当heartbeat v2第二版的时候,heartbeat被做了很大的改进,自己可以做为一个独立进程来运行,并而可以通过它接收用户请求,它就叫crm,在运行时它需要在各节点上运行一个叫crmd的进程,这个进程通常要监听在一个套接字上,端口就是5560,所以服务器端叫crmd,而客户端叫crm(可以称为crm shell),是个命令行接口,通过这个命令行接口就可以跟服务器端的crm通信了,heartbeat也有它的图形化界面工具,就叫heartbeat-GUI工具,通过这个界面就可以配置进行。
   第三版heartbeat v3,被独立成三个项目heartbeat、pacemaker(心脏起博器)、cluster-glue(集群的贴合器),架构分离开来了,可以结合其它的组件工作了。

RA:resource agent资源代理,其实就是能够接收CRM的调度用于实现在节点上对某一个资源完成管理的工具,这个管理的工具通常是脚本,所以我们通常称为资源代理。任何资源代理都要使用同一种风格,接收四个参数:{start|stop|restart|status},包括配置IP地址的也是。每个种资源的代理都要完成这四个参数据的输出。
   当某一个节点出现故障时,其上面的资源被自动转移到其它正常的备用节点上并启动的这个过程叫故障转移,也称为失效转移(failover)
   如果出现故障的节点又回来的,那我们就要把这个节点添加回来,那这个添加回来的过程我们就叫失效转回,也称故障转回(failback)

资源争用、资源隔离:
   万一集群发生分裂时,为了避免不再成为集群上的节点继续使用资源而发生资源争用情况,导致有挂载文件系统的系统文件发生崩溃,成为新的集群的就会给不再成为集群的节点补一枪,让不是集群节点的服务死透,不再接收请求,这就叫stonith(shoot the other node in the head),而这种功能就叫资源隔离。争用共享存储的后果是非常严重的,轻则共享存储崩溃,重则整个文件系统都崩溃,数据全部丢失。

资源隔离有两种级别:
   节点级别:这种就叫STONITH,这种就是不管怎么样直接把对方的电源给切断,一般这种主机都是连接到电源交换机上的。
   资源级别:这种需要依赖一些硬件设备来完成,比如连接到共享存储的光纤交换机,把需要踢除出去的节点的光纤接口屏蔽了,这种就叫资源级别的隔离。
   对于服务器左右分隔的这种情况通常称为脑裂(brain-split),左右不协调了,在高可以用集群中避免资源争用完成资源隔离是我们在设计高可用集群中必须要考滤的问题。

两个节点的模式下,一旦发生集群分隔以后,其中一个节点发生故障,在我们无法判定哪个节点不正常的时候,而正常的节点一定是可以连到互联网上去的,这样的话就说明正常的节点是可以跟前端路由通信的,所以我们就把前端路由当成第三个节点,这里我们称为ping节点,当每个节点联系到对方之后先去ping前端的节点,如果可以ping通,那就说明自己是正常的,就说明该节点是有多票法定票数的节点,而前端的ping节点就叫仲裁设备,帮助节点判断哪个节点是优胜一方的,偶数节点数时就会借助于仲裁设备。
   RHCS不是使用ping节点来判断的,他是使用了一个共享存储的设备,偶数个节点处于活动的节点不断的往磁盘中写数据,按照心跳信息频率每隔一个信息频率就往磁盘里写一个数据位,只要这个设备每隔一个心跳时间间隔就更新一次数据位,就说明这个设备处于活动状态的,如果发现节点多次没有写数据位了就认为节点挂了,这种也叫仲裁设备(qdisk)。仲裁设备又有两种:分别为ping node和qdisk;

那心跳是怎么传递的呢,在多台主机之机又是怎么互相工作良好呢,如图:高可用主从的两个节点;

信息层(Messaging Layer):主从两个节点的心跳信息都要基于信息层来实现,也叫底层基础架构层,用于传递心跳信息的,而能够实现这种功能的有Corosync和heartbeat,corosync是openAIS的一个组件,
   资源分配层(Resource Allocation):也叫资源管理器层,这层的核心组件叫CRM(Cluster Resourcce Manager集群资源管理器),CRM上必须有一个资源被推举成为管理者的,叫Leader,它的工作是决策集群中的所有事物的,这里称为DC(Designated Coordinator指定协调员),任何DC上会额外运行两个进程,一个叫PE(Policy Engine策略引擎),所谓策略引擎就是将底层信息层收集整个集群中所有节点上的信息在本地生成一个大图big pic来策略节点运行在哪个节点上,并通知其实节点上的资源管理器来实现资源的启动和关闭等操作;一个叫TE(Transition Engine 传输引擎),它主要是把PE做出的决策通告给对应节点的CRM;
   集群资源管理器必须借助于Messageing Layer通告给每一个节点,自动的广播或组播给每一个节点,这样就保证了每一个节点上的信息都是一样的,而这些数据在计算机中又怎么样来交互数据的呢,这里就要基于扩展标记语言来实现数据的格式传递的,这种叫半结构化数据基于XML的,所以在各节点之间实现配置信息保存都是通过XML文件保存的,而要能够理解这个XML文件保存的信息使用到一个工具叫CIB(Cluster Information Base集群信息库);只要能连接到CRM上都可以去配置这个XML文件,首先它会先保存到DC的XML中,然后再由DC同步支每个节点上的XML文件中去的;
   Resources层:而PE(策略引擎)就是根据XML这个库来获取资源的配置信息的,并通过Messaging Layer不获取当前节点的活动信息,而后做出决策,一旦做得决策就要启动资源了;所以PE借助于本地的Messaging Layer通知给其实节点的集群信息库来实现对某些资源信息的传递,比如说通告其它CRM要启动某一资源了,收到信息后CRM并不负责启动,转由LRM(Local Resource Manager本地资源管理)启动,每个节点上都运行在这个LRM,而并发资源又借助于RA(Resource Agent资源代理)实现资源管理,这就是它的工作原理;CRM负责收集信息,推举为DC的由PE运行,PE负责整合整个集群中的所有资源,并确保某些资源在合适的节点上运行起来,一旦做出决策就会通告给其它节点上的CRM,对应节点上的CRM收到通告以后会调用自己的LRM,由LRM指挥RA完成相关的操作;

那下面我们来实现heartbeat v1版本的工作过程:
安装配置高可用集群:实现heartbeat v1版的过程
   1、节点名称很关键,集群每个节的名称都得能互相解析;
   用hosts文件,/etc/hosts:hosts中主机名的正反解析结果必须跟”uname -n”的结果保持一致;
   2、时间必须得同步,使用网络时间服务器同步时间;
   3、各节点间能基于ssh密钥互相认证通信;

1)配置主机名、
   第一台节点的主机名为node1.tanxw.com,第二台节点的主机名为node2.tanxw.com

# vim /etc/hosts  改主机名,注意,两个节点都要添加,我几个节点就加几条解析

172.16.249.61 node1.tanxw.com

172.16.249.62 node2.tanxw.com

# uname -n

# hostname node1.tanxw.com

# hostname node2.tanxw.com

# cat /etc/sysconfig/network 如果这个与node1或2不一致就改一下,这个改配置文件保证下次系统重启时主机名依然有效,

# 如果改好了没有生效就ctrl+d注销一下再登录就OK了。

2)两台主机或多台主机基于ssh无密钥通信

# ssh-keygen -t rsa -P ‘’   这个生成一个密码为空的公钥和一个密钥,把公钥复制到对方节点上即可

# ssh-copy-id -i .ssh/id_rsa.pub [email protected] 对方主机名用登录用户名

两台主机都要互相可以通信,所以两台主机都得互相生成密钥和复制公钥,相互的节点上的hosts文件是都要解析对方的主机名,172.16.249.61 node1.tanxw.com

172.16.249.62 node2.tanxw.com

# ssh node2.tanxw.com ‘date’;date  测试一下是否已经互信

3)安装heartbeat v1版本的程序,两个节点都要安装上heartbeat的相关程序包

# 安装这几个包,但是存在依赖关系,需要解决:

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

# 解决依赖关系:

# yum -y install perl-TimeDate net-snmp-libs libnet PyXML

# rpm -ivh heartbeat-pils-2.1.4-12.el6.x86_64.rpm heartbeat-stonith-2.1.4-12.el6.x86_64.rpm  heartbeat-2.1.4-12.el6.x86_64.rpm

一个高可用集群得依赖:1、信息层; 2、资源管理器;3、资源代理
   我们配置的过程就按这种层次去配置就可以了;
   这里要注意的是:如何在网络中我们期望的节点集群成为我们所需要的节点,在集群中信息不能随便传递,而心跳节点是基于组播地址传递的,如果别人也装了heartbeat也连接到这个组播地址上来,这都不安全,基于这种情况,我们各节点这间信息传递是需要认证的,这种认证基于HMAC(消息认证码),消息认证码是使用单向加密算动法来实现的,而单向加密一般有三类:crc(循环冗余校验码)、md5(信息摘要算法)、sha1。heartbeat基于udp协议,监听在694端口上;

4)配置heartbeat,它的配置文件在/etc/ha.d/的目录下,但是安装完程序之后这个目录下没有这个配置文件,只有/usr/share/doc/heartbeat-2.1.4/目录下有ha.cf的主配置文件样本,复制到/etc下修改配置文件即可使用;还有一个authkeys的认证文件,这个文件就是我们各节点认证时所保存的认证密码和认证机制,所以这个文件的权限至关重要,必须是600,否则启动不了服务;第三个haresources,定义资源时需要资源管理器来读取这个文件,所以这个也得有;

# cp /usr/share/doc/heartbeat-2.1.4/{ha.cf,authkeys,haresources} /etc/ha.d/

# cd /etc/ha.d/

# openssl rand -hex 8   生成16位随机数

ee869d3d86e1556f

# vim /etc/ha.d/authkeys

auth 2   这里的2与下面选项的数只要一致就可以了,没有什么限定

2 sha1 ee869d3d86e1556f

# chmod 600 authkeys

# vim /etc/ha.d/ha.cf    启用以下参数及功能

logfile /var/log/ha-log  #日志文件,正常日志信息记录到哪去的

keepalive 1000ms   #每隔多长时间发送一次心跳信息的,单位是秒,毫秒用ms

deadtime 8    #隔多长时间探测到对方不在线就kill掉的时间间隔

warntime 10   #警告时间

udpport 694

mcast eth0 225.0.0.1 694 1 0   #定义组播地址

auto_failback on    #开启故障转回功能

node    node2.tanxw.com   #定义两个节点

node    node1.tanxw.com

crm on      #启用crm功能

ping 172.16.0.1   #ping节点

compression     bz2    #压缩格式

compression_threshold 2    #表示小于2K时不压缩传输

   定义资源:在资源管理器的配置文件中定义;/etc/ha.d/haresources,在/etc/ha.d/resource.d下有各种资源类型,当在资源配置文件中定义时就会调用这里的资源类型来运行相应的程序;

# vim /etc/ha.d/haresources

node1.tanxw.com 172.16.249.66 httpd   # 172.16.249.66这个是浮动地址

注:node1.tanxw.com:说明哪台主机是主节点,更倾向于谁上面

[node1.tanxw.com 172.16.249.61/16/eth0/172.16.255.255 httpd 也可以这样定义

node2.tanxw.com 172.16.249.62 httpd  httpd是怎么被调用的呢:首先会找/etc/ha.d/resource.d目录下,如果没有就去/etc/init.d/目录下找httpd,找到就start。]

# scp -p authkeys haresources ha.cf node1.tanxw.com:/etc/ha.d/

# service heartbeat start

结束:

当一个节点挂掉了,另一个节点就会顶上去,成为主节点,使用服务依然可以提供服务,而不会使用服务终止,这里我们应该准备两个节点不同的web页面的内容加以区别,测试时我们把其中的别一个web服务终止,就可以看得出效果来了,heaetbeat会自动切换到别一个正常运行的节点上去断续提供服务。

时间: 2024-10-19 14:11:50

Linux HA Cluster高可用服务器集群,所谓的高可用不是主机的高可用,而是服务的高可用。的相关文章

keepalived+LVS 实现双机热备、负载均衡、失效转移 高性能 高可用 高伸缩性 服务器集群

本章笔者亲自动手,使用LVS技术实现实现一个可以支持庞大访问量.高可用性.高伸缩性的服务器集群 在读本章之前,可能有不少读者尚未使用该技术,或者部分读者使用Nginx实现应用层的负载均衡.这里大家都可以阅读本章,即使部分读者使用Nginx负载均衡,但是在大流量下性能相对于工作在链路层的LVS真是不能同日而语,并且LVS不仅可以实现WEB方面的负载均衡,其他诸如数据库.FTP.Mail等都可以实现. 通常对于小型网站,很多都使用单台服务器,顶多在弄个缓存服务器.数据库服务器.但是一旦流量上来,单台

Linux HA Cluster高可用集群之HeartBeat2

一.阐述Linux HA Cluster的使用背景: 1.1 高可用集群定义: 高可用集群全称:High Availability Cluster,简单的说,集群就是一组高可扩展.高可用性.高性价比的计算机.它们作为一个整体向用户提供一组网络资源.其中单个的计算机系统就是一个集群的节点.高可用集群软件的主要作用就是实现故障检查和业务切换的自动化,以提供不中断的服务. 1.2 集群系统的主要优点: (1)高可扩展性:  (2)高可用性HA:集群中的一个节点失效,它的任务可传递给其他节点.可以有效防

Redis Cluster搭建高可用Redis服务器集群

原文:Redis Cluster搭建高可用Redis服务器集群 一.Redis Cluster集群简介 Redis Cluster是Redis官方提供的分布式解决方案,在3.0版本后推出的,有效地解决了Redis分布式的需求,当一个节点挂了可以快速的切换到另一个节点,当遇到单机内存.并发等瓶颈时,可以采用分布式方案要解决问题. 二.集群原理 Redis Cluster架构图 Redis Cluster集群采用了P2P的模式,完全去中心化,Redis把所有的Key分成了16384个slot,每个R

CentOS Linux 负载均衡高可用WEB集群之LVS+Keepalived配置

CentOS Linux 负载均衡高可用WEB集群之LVS+Keepalived配置 LB集群是locd balance集群的简称.翻译成中文是:负载均衡集群的意思:集群是一组相互独立的.通过高速网络互联的计算机相互之间构成一个组合,并以单一的系统的模式加以管理.LVS是Linux Virtual Server的简写,翻译中文是Linux虚拟服务器,是一个虚拟的服务器集群系统. 负载均衡集群:是为了企业提供更为实用,性价比更高的系统机构解决方案.负载均衡集群把用户的请求尽可能的平均分发到集群的各

keepalived结合nginx状态检测脚本实现对web服务器集群的高可用

实验环境 两台CentOS-7.5虚拟机web1:10.0.11.203web2:10.0.11.204VIP :10.0.11.210web类型:nginx客户端:自用笔记本(win10)nginx状态检测脚本:ck_nginx.sh 实验一.使用keepalived简单实现web集群的高可用功能 1.准备两台web服务器 1)web1网卡情况[[email protected] ~]# [[email protected] ~]# ip a 2)web2网卡情况[[email protect

直接路由的高可用LVS集群配置

 直接路由的高可用LVS集群配置: 调度服务器IP:(106.3.43.240)192.168.11.100,节点服务器分别为:192.168.11.101,192.168.11.102 一.安装ipvsadmin: 1.yum -y install ipvsadmin(推荐用第一种方法) 2.下载http://www.linuxvirtualserver.org/software/,找到相应的版本: 注意对应自己的内核版本 ipvsadm-1.24.tar.gz tar zxvf ipvs

34补1-4 实现高可用mysql集群

HA Cluster基础及heartbeat实现HA 配置环境 node1:192.168.1.121 CentOS6.7 node2:192.168.1.122 CentOS6.7 node3:192.168.1.123 CentOS6.7 vip 192.168.1.88 配置前准备    # cat /etc/hosts 127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1  

linux在服务器集群的应用

引言 随着服务器需求量的不断增长,关于操作系统的研究也在近几年进行的异常火热.虽然Unix在服务器领域盘踞多年,因此作为类Unix系统的Linux,近几年在人们视野的曝光率也越来越高.著名的科技杂志<网络世界>从2010年1 月份开始,发起了一项关于"Linux 企业应用现状"的调查报告.通过各种不同的渠道搜集了来自金融产业.电信产业.能源产业.科研教育产业.医疗产业.制造业等许多不同类型的行业,以及众多政府机构的多位IT部门负责人的反馈,渴望通过真实的Linux在产业的真

搭建高可用mongodb集群(分片)

MongoDB基础请参考:http://blog.51cto.com/kaliarch/2044423 MongoDB(replica set)请参考:http://blog.51cto.com/kaliarch/2044618 一.概述 1.1 背景 为解决mongodb在replica set每个从节点上面的数据库均是对数据库的全量拷贝,从节点压力在高并发大数据量的场景下存在很大挑战,同时考虑到后期mongodb集群的在数据压力巨大时的扩展性,应对海量数据引出了分片机制. 1.2 分片概念