设为首页 收藏本站
查看: 2111|回复: 0

[经验分享] 全是干货---Linux 高可用(HA)集群基本概念详解

[复制链接]

尚未签到

发表于 2015-9-10 12:18:12 | 显示全部楼层 |阅读模式
  http://www.iyunv.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分钟
  ~~~~~~~~~~~~~~~~
DSC0000.jpg
  高可用集群可分为三个层次结构,分别由红色部分的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版本的资源管理)。
  ~~~~~~~~~~~
DSC0001.jpg
  核心组件的具体说明(如上图):
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
注:一般用于高可用双主模型中
DSC0002.jpg
  ~~~~~~~~~~~~~~
  高可用集群的工作原理
  
说明:这里主要以主/从节点的高可用来说明工作原理。
  主服务器和从服务器建立双机热备,基本上都是共享一个存储,以mysql为例。通常情况下,数据库文件挂载在主数据库服务器上,用户连接到主服务器上进行数据库操作。当主服务器出现故障时,从服务器就会自动挂载数据库文件,并接替主服务器的工作。用户在未通知的情况下,通过从数据库连接到数据库文件进行操作。等主服务器的故障修复之后,又可以重新提供服务;
  那么,从服务器是如何知道主服务器挂掉了呢,这就要使用一定的检测机制,如心跳检测,也就是说每一个节点都会定期向其他节点通知自己的心跳信息,尤其是主服务器,如果从服务器在几个心跳周期内(可自行设置心跳周期)还没有检测到的话,就认为主服务器宕掉了,而这期间在通告心跳信息当然不能使用tcp传输的,如果使用tcp检测,还要经过三次握手,等手握完了,不定经过几个心跳周期了,所以在检测心跳信息的时候采用的是udp的端口694来进行传递信息的,如果主服务器在某一端时间由于服务繁忙,没时间响应心跳信息,这个时候从服务器要是把主服务资源抢过去(共享数据文件),但是这个时候主服务器还没有宕掉,这样就会导致资源抢占,就这样用户在主从上都能访问,如果仅仅是读操作还没事,要是有写的操作,那就会导致文件系统崩溃,这样一切都玩了,所以在资源抢占的时候,可以采用一定的隔离方法来实现,就是从服务器抢占资源的时候,直接把主服务器给“STONITH”,就是我们常说的“爆头”;
  那么,我们又用什么方式来检测心跳信息呢?就是通过心跳线来检测。运行在从服务器上的Heartbeat可以通过以太网连接检测主服务器的运行状态,一旦其无法检测到主服务器的“心跳”则自动接管主服务器的资源。通常情况下,主、从服务器间的心跳连接是一个独立的物理连接,这个连接可以是串行线缆、一个由“交叉线”实现的以太网连接。Heartbeat甚至可同时通过多个物理连接检测主服务器的工作状态,而其只要能通过其中一个连接收到主服务器处于活动状态的信息,就会认为主服务器处于正常状态。从实践经验的角度来说,建议为Heartbeat配置多条独立的物理连,以避免Heartbeat通信线路本身存在单点故障。
  上面的原理中我们提到了“隔离方法”,下面我们来说一说,隔离方法有两种,一种是节点隔离,另一种是资源隔离。节点隔离就是我们常说的STONITH(Shoot The Other Node In the Head ,俗称“爆头”),意思就是直接切断电源;常用的方法是所有节点都接在一个电源交换机上,如果有故障,就直接导致该节点的电压不稳定,或断电,让有故障的节点重启或关闭。(如下图),而资源隔离,就是 fencing 直接把某种资源截获过来。
DSC0003.jpg
  下面我们再来说一说“心路线”的类型,一种是串行电缆,另一种就是我们常看到的以太网线(交叉的双绞线),它们各有优缺点,串行电缆,被认为是比以太网连接安全性稍好些的连接方式,因为hacker无法通过串行连接运行诸如telnet、ssh或rsh类的程序,从而可以降低其通过已劫持的服务器再次侵入备份服务器的几率。但串行线缆受限于可用长度,因此主、备服务器的距离必须非常短。以太网线连接,使用此方式可以消除串行线缆的在长度方面限制,并且可以通过此连接在主从服务器之间同步文件系统,从而减少了对正常通信连接带宽的占用。(如下图)

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-111935-1-1.html 上篇帖子: PostgreSQL Replication之第七章 理解Linux高可用(1) 下篇帖子: heartbeatv1 版讲解及实现nfs文件共享
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表