全是干货---Linux 高可用(HA)集群基本概念详解

http://www.linuxidc.com/Linux/2013-08/88522.htm

高可用集群的衡量标准 
  HA(High Available), 高可用性群集是通过系统的可靠性(reliability)和可维护性(maintainability)来度量的。工程上,通常用平均无故障时间(MTTF)来度量系统的可靠性,用平均维修时间(MTTR)来度量系统的可维护性。于是可用性被定义为:HA=MTTF/(MTTF+MTTR)*100%
  具体HA衡量标准:
99% 一年宕机时间不超过4天

99.9% 一年宕机时间不超过10小时

99.99% 一年宕机时间不超过1小时

99.999% 一年宕机时间不超过6分钟

~~~~~~~~~~~~~~~~

高可用集群可分为三个层次结构,分别由红色部分的Messaging与Membership层,蓝色部分的Cluster Resource Manager(CRM)层,绿色部分的Local Resource Manager(LRM)与Resource Agent(RA)组成,下面我们就来具体说明(如上图),
1.位于最底层的是信息和成员关系层(Messaging and Membership),Messaging主要用于节点之间传递心跳信息,也称为心跳层。节点之间传递心跳信息可以通过广播,组播,单播等方式。成员关系(Membership)层,这层最重要的作用是主节点(DC)通过Cluster Consensus Menbership Service(CCM或者CCS)这种服务由Messaging层提供的信息,来产生一个完整的成员关系。这层主要实现承上启下的作用,承上,将下层产生的信息生产成员关系图传递给上层以通知各个节点的工作状态;启下,将上层对于隔离某一设备予以具体实施。
2.集群资源管理层(Cluster Resource Manager),真正实现集群服务的层。在该层中每个节点都运行一个集群资源管理器(CRM,cluster Resource Manager),它能为实现高可用提供核心组件,包括资源定义,属性等。在每一个节点上CRM都维护有一个CIB(集群信息库 XML文档)和LRM(本地资源管理器)组件。对于CIB,只有工作在DC(主节点)上的文档是可以修改的,其他CIB都是复制DC上的那个文档而来的。对于LRM,是执行CRM传递过来的在本地执行某个资源的执行和停止的具体执行人。当某个节点发生故障之后,是由DC通过PE(策略引擎)和TE(实施引擎)来决定是否抢夺资源。
3.资源代理层(Resource Agents),集群资源代理(能够管理本节点上的属于集群资源的某一资源的启动,停止和状态信息的脚本),资源代理分为:LSB(/etc/init.d/*),OCF(比LSB更专业,更加通用),Legacy heartbeat(v1版本的资源管理)。

~~~~~~~~~~~

核心组件的具体说明(如上图):
1.ccm组件(Cluster Consensus Menbership Service):作用,承上启下,监听底层接受的心跳信息,当监听不到心跳信息的时候就重新计算整个集群的票数和收敛状态信息,并将结果转递给上层,让上层做出决定采取怎样的措施,ccm还能够生成一个各节点状态的拓扑结构概览图,以本节点做为视角,保证该节点在特殊情况下能够采取对应的动作。
2.crmd组件(Cluster Resource Manager,集群资源管理器,也就是pacemaker):实现资源的分配,资源分配的每个动作都要通过crm来实现,是核心组建,每个节点上的crm都维护一个cib用来定义资源特定的属性,哪些资源定义在同一个节点上。
3.cib组件(集群信息基库,Cluster Infonation Base):是XML格式的配置文件,在内存中的一个XML格式的集群资源的配置文件,主要保存在文件中,工作的时候常驻在内存中并且需要通知给其它节点,只有DC上的cib才能进行修改,其他节点上的cib都是拷贝DC上。配置cib文件的方法有,基于命令行配置和基于前台的图形界面配置。
4.lrmd组件(Local Resource Manager,本地资源管理器):用来获取本地某个资源的状态,并且实现本地资源的管理,如当检测到对方没有心跳信息时,来启动本地的服务进程等。
5.pengine组件:
PE(Policy Engine):策略引擎,来定义资源转移的一整套转移方式,但只是做策略者,并不亲自来参加资源转移的过程,而是让TE来执行自己的策略。

TE(Transition Engine): 就是来执行PE做出的策略的并且只有DC上才运行PE和TE。

6.stonithd组件
  STONITH(Shoot The Other Node in the Head,”爆头“), 这种方式直接操作电源开关,当一个节点发生故障时,另 一个节点如果能侦测到,就会通过网络发出命令,控制故障节点的电源开关,通过暂时断电,而又上电的方式使故障节点被重启动, 这种方式需要硬件支持。
  STONITH应用案例(主从服务器),主服务器在某一端时间由于服务繁忙,没时间响应心跳信息,如果这个时候备用服务器一下子把服务资源抢过去,但是这个时候主服务器还没有宕掉,这样就会导致资源抢占,就这样用户在主从服务器上都能访问,如果仅仅是读操作还没事,要是有写的操作,那就会导致文件系统崩溃,这样一切都玩了,所以在资源抢占的时候,可以采用一定的隔离方法来实现,就是备用服务器抢占资源的时候,直接把主服务器给STONITH,就是我们常说的”爆头 ”。

~~~~~~~~~~~~~~

高可用集群软件
Messaging and Membership Layer(信息与关系层):
heartbeat (v1,v2,v3),heartbeat v3 分拆  heartbeat pacemaker cluster-glue

corosync

cman

keepalived

ultramokey

Cluster Resource Manager Layer(资源管理层,简称:CRM):
haresource,crm (heartbeat v1/v2)

pacemaker (heartbeat v3/corosync)

rgmanager (cman)

常用组合:
heartbeat v2+haresource(或crm) (说明:一般常用于CentOS 5.X)

heartbeat v3+pacemaker (说明:一般常用于CentOS 6.X)

corosync+pacemaker (说明:现在最常用的组合)

cman + rgmanager (说明:红帽集群套件中的组件,还包括gfs2,clvm)

keepalived+lvs (说明:常用于lvs的高可用)

总结:我们经常在技术博客中看到,heartbeat+pacemaker实现mysql高可用,或corosync+pacemaker实现mysql高可用等,有的博友会问了,我们到底用什么好呢?经过上面的说明大家应该有所了解!

~~~~~~~~~~~~~~~~~

共享存储
  说到集群, 我们不得不说到,共享存储,因为不管理是Web高可用也,Mysql高可用也好,他们的数据都是共享的就一份,所有必须放在共享存储中,主节点能访问,从节点也能访问。下面我们就简单说一下共享存储。
1.DAS:(Direct attached storage)直接附加存储
说明:设备直接连接到主机总线上的,距离有限,而且还要重新挂载,之间有数据传输有延时
RAID 阵列

SCSI 阵列

2.NAS:(network attached storage)网络附加存储 
说明:文件级别的共享
NFS

FTP

CIFS

3.SAN:(storage area network)存储区域网络 
说明:块级别的,模拟的scsi协议
FC光网络(交换机的光接口超贵,一个差不多2万,如果使用这个,代价太高)

IPSAN(iscsi)存取快,块级别,廉价

~~~~~~~~~~~~~~~~

集群文件系统与集群LVM(集群逻辑卷管理cLVM)
集群文件系统:gfs2、ocfs2
集群LVM:cLVM
注:一般用于高可用双主模型中

~~~~~~~~~~~~~~

高可用集群的工作原理

说明:这里主要以主/从节点的高可用来说明工作原理。
  主服务器和从服务器建立双机热备,基本上都是共享一个存储,以mysql为例。通常情况下,数据库文件挂载在主数据库服务器上,用户连接到主服务器上进行数据库操作。当主服务器出现故障时,从服务器就会自动挂载数据库文件,并接替主服务器的工作。用户在未通知的情况下,通过从数据库连接到数据库文件进行操作。等主服务器的故障修复之后,又可以重新提供服务;
  那么,从服务器是如何知道主服务器挂掉了呢,这就要使用一定的检测机制,如心跳检测,也就是说每一个节点都会定期向其他节点通知自己的心跳信息,尤其是主服务器,如果从服务器在几个心跳周期内(可自行设置心跳周期)还没有检测到的话,就认为主服务器宕掉了,而这期间在通告心跳信息当然不能使用tcp传输的,如果使用tcp检测,还要经过三次握手,等手握完了,不定经过几个心跳周期了,所以在检测心跳信息的时候采用的是udp的端口694来进行传递信息的,如果主服务器在某一端时间由于服务繁忙,没时间响应心跳信息,这个时候从服务器要是把主服务资源抢过去(共享数据文件),但是这个时候主服务器还没有宕掉,这样就会导致资源抢占,就这样用户在主从上都能访问,如果仅仅是读操作还没事,要是有写的操作,那就会导致文件系统崩溃,这样一切都玩了,所以在资源抢占的时候,可以采用一定的隔离方法来实现,就是从服务器抢占资源的时候,直接把主服务器给“STONITH”,就是我们常说的“爆头”;
  那么,我们又用什么方式来检测心跳信息呢?就是通过心跳线来检测。运行在从服务器上的Heartbeat可以通过以太网连接检测主服务器的运行状态,一旦其无法检测到主服务器的“心跳”则自动接管主服务器的资源。通常情况下,主、从服务器间的心跳连接是一个独立的物理连接,这个连接可以是串行线缆、一个由“交叉线”实现的以太网连接。Heartbeat甚至可同时通过多个物理连接检测主服务器的工作状态,而其只要能通过其中一个连接收到主服务器处于活动状态的信息,就会认为主服务器处于正常状态。从实践经验的角度来说,建议为Heartbeat配置多条独立的物理连,以避免Heartbeat通信线路本身存在单点故障。
  上面的原理中我们提到了“隔离方法”,下面我们来说一说,隔离方法有两种,一种是节点隔离,另一种是资源隔离。节点隔离就是我们常说的STONITH(Shoot The Other Node In the Head ,俗称“爆头”),意思就是直接切断电源;常用的方法是所有节点都接在一个电源交换机上,如果有故障,就直接导致该节点的电压不稳定,或断电,让有故障的节点重启或关闭。(如下图),而资源隔离,就是 fencing 直接把某种资源截获过来。

 

  下面我们再来说一说“心路线”的类型,一种是串行电缆,另一种就是我们常看到的以太网线(交叉的双绞线),它们各有优缺点,串行电缆,被认为是比以太网连接安全性稍好些的连接方式,因为hacker无法通过串行连接运行诸如telnet、ssh或rsh类的程序,从而可以降低其通过已劫持的服务器再次侵入备份服务器的几率。但串行线缆受限于可用长度,因此主、备服务器的距离必须非常短。以太网线连接,使用此方式可以消除串行线缆的在长度方面限制,并且可以通过此连接在主从服务器之间同步文件系统,从而减少了对正常通信连接带宽的占用。(如下图)

时间: 2025-01-20 19:46:26

全是干货---Linux 高可用(HA)集群基本概念详解的相关文章

如何构建高可用ZooKeeper集群

ZooKeeper 是 Apache 的一个顶级项目,为分布式应用提供高效.高可用的分布式协调服务,提供了诸如数据发布/订阅.负载均衡.命名服务.分布式协调/通知和分布式锁等分布式基础服务.由于 ZooKeeper 便捷的使用方式.卓越的性能和良好的稳定性,被广泛地应用于诸如 Hadoop.HBase.Kafka 和 Dubbo 等大型分布式系统中. 本文的目标读者是对 ZooKeeper 有一定了解的技术人员,将从 ZooKeeper 运行模式.集群组成.容灾和水平扩容四方面逐步深入,最终构建

使用Docker Compose部署基于Sentinel的高可用Redis集群

大家一定非常熟悉如何利用Docker启动单个Redis容器用于开发环境,本文将介绍如何利用Docker Compose模板在本机和云端部署基于Sentinel的高可用Redis 3集群. Redis集群可以在一组redis节点之间实现高可用性和sharding.今天我们重点围绕master-slave的高可用模式来进行讨论,在集群中会有1个master和多个slave节点.当master节点失效时,应选举出一个slave节点作为新的master.然而Redis本身(包括它的很多客户端)没有实现自

Linux高可用(HA)之MySQL多主一从+Keepalived跨机房集群部署

添加host解析.时间同步和ssh互信(注:这里的做ssh互信的时候使用到一个脚本借助expect实现了面交互操作了) [root@DS-CentOS51 ~]# echo "172.16.0.51 mysql-master01 > 172.16.0.60 mysql-master02 > 172.16.0.63 mysql-slave01 > 172.16.0.69 mysql-slave02" >> /etc/hosts [root@DS-CentOS

Linux高可用(HA)之Heartbeat+Nginx+MySQL+NFS实现WEB+SQL服务高可用

环境说明: node1:ZhongH100.wxjr.com.cn 172.16.6.100 node2:ZhongH101.wxjr.com.cn 172.16.6.101 NFS存储:ZhongH102.wxjr.com.cn 172.16.6.102 VIP:172.16.7.200 node1和node2的主机名.SSH互通 操作系统:都是CentOS 6.6 x86_64 (自己配置好yum源.epel源.关闭SELinux.关闭防火墙) 注意:是[root@ZhongH100 ~]还

搭建高可用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 分片概念

配置高可用 mongodb 集群教程

在大数据的时代,传统的关系型数据库要能更高的服务必须要解决高并发读写.海量数据高效存储.高可扩展性和高可用性这些难题.不过就是因为这些问题Nosql诞生了. NOSQL有这些优势: 大数据量,可以通过廉价服务器存储大量的数据,轻松摆脱传统mysql单表存储量级限制. 高扩展性,Nosql去掉了关系数据库的关系型特性,很容易横向扩展,摆脱了以往老是纵向扩展的诟病. 高性能,Nosql通过简单的key-value方式获取数据,非常快速.还有NoSQL的Cache是记录级的,是一种细粒度的Cache,

CentOS7+MySQL/MariaDB+Galera+HAProxy+Keepalived构建高可用数据库集群

原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 .作者信息和本声明.否则将追究法律责任.http://dgd2010.blog.51cto.com/1539422/1603972 方案优势: Galera能够实现MySQL/MariaDB数据库的主主复制和多主复制等模式,这些复制模式都是同步进行的,同步时间非常短 每一个节点都可以同时写入和读取,当某一节点发生故障时,可自动从集群中自动剔除 HAProxy能提供负载均衡和故障判断等功能解决服务器系统存在的单点故障 Keepaliv

Docker化高可用redis集群

最近遇到部分系统因为redis服务挂掉,导致部分服务不可用.所以希望搭建一个redis集群镜像,把原先散落各处的redis服务器统一管理起来,并且保障高可用和故障自动迁移. 一:redis集群分类 大家都知道redis集群有两种,一种是redis sentinel,高可用集群,同时只有一个master,各实例数据保持一致:一种是redis cluster,分布式集群,同时有多个master,数据分片部署在各个master上.基于我们的需求和redis本身技术的成熟度,本次要搭建的是redis s

Redis开发运维实践高可用和集群架构与实践(四)

11.1.4 高可用和异常测试 11.1.4.1 测试环境介绍 sentinel的消息可以通过sentinel日志(/redis/log/sentinel.log)以及sentinel:hello订阅此频道进行查看. 11.1.4.2 手动切换测试 集群情况,2.128为主 发起主动切换: 查看sentinel日志: 在2.129上看,集群已经切换过来: 11.1.4.3 主实例宕测试 接上,此时master为2.129,找出redis实例的pid,然后kill: 此时查看sentinel日志: