分享

HA 集群基本概念详解

 bull000 2022-11-12 发布于江苏

HA 集群基本概念详解

⼀、⾼可⽤集群的定义

⼆、⾼可⽤集群的衡量标准

三、⾼可⽤集群的层次结构

四、⾼可⽤集群的分类

五、⾼可⽤集群常⽤软件

六、共享存储

七、集群⽂件系统与集群LVM

⼋、⾼可⽤集群的⼯作原理

⼀、⾼可⽤集群的定义

⾼可⽤集群,英⽂原⽂为High Availability Cluster,简称HACluster,简单的说,集群(cluster)就是⼀组计算机,它们作为⼀个整体向⽤

户提供⼀组⽹络资源。这些单个的计算机系统 就是集群的节点(node)。

⾼可⽤集群的出现是为了使集群的整体服务尽可能可⽤,从⽽减少由计算机硬件和软件易错性所带来的损失。如果某个节点失效,它的备

援节点将在⼏秒钟的时间内接管它的职责。因此,对于⽤户⽽⾔,集群永远不会停机。

⾼可⽤集群软件的主要作⽤就是实现故障检查和业务切换的⾃动化。只有两个节点的⾼可⽤集群⼜称为双机热备,即使⽤两台服务器互相

备份。当⼀台服务器出现故障时,可由另⼀台服务器承担服务任务,从⽽在不需要⼈⼯⼲预的 情况下,⾃动保证系统能持续对外提供服务。

双机热备只是⾼可⽤集群的⼀种,⾼可⽤集群系统更可以⽀持两个以上的节点,提供⽐双机热备更多、更⾼级的功能,更能满⾜⽤户不断出

现的需求变化。

⼆、⾼可⽤集群的衡量标准

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,就是我们常说的”爆头 ”

四、⾼可⽤集群的分类

1.双机热备(Active/Passive)

官⽅说明:Two-node Active/Passive clusters using Pacemaker and DRBD are a cost-effective solution for many High Availability

situations.

2.多节点热备(N+1)

官⽅说明:By supporting many nodes, Pacemaker can dramatically reduce hardware costs by allowing several active/passive clusters to

be combined and share a common backup node.

3.多节点共享存储(N-TO-N)

官⽅说明:When shared storage is available, every node can potentially be used for failover. Pacemaker can even run multiple copies of

services to spread out the workload.

4.共享存储热备 (Split Site)

官⽅说明:Pacemaker 1.2 will include enhancements to simplify the creation of split-site clusters

五、⾼可⽤集群软件

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的⾼可⽤)

六、共享存储

说到集群, 我们不得不说到,共享存储,因为不管理是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类的程序,从⽽可以降低其

通过已劫持的服务器再次侵⼊备份服务器的⼏率。但串⾏线缆受限于可⽤长度,因此主、备服务器的距离必须⾮常短。以太⽹线连接,使⽤

此⽅式可以消除串⾏线缆的在长度⽅⾯限制,并且可以通过此连接在主从服务器之间同步⽂件系统,从⽽减少了对正常通信连接带宽的占

⽤。(如下图)

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多