高可用集群原理概念详述

  1. 云栖社区>
  2. 博客>
  3. 正文

高可用集群原理概念详述

技术小胖子 2017-11-09 01:18:00 浏览919
展开阅读全文

一、高可用集群的定义

    高可用集群,英文原文为High Availability Cluster,简称HACluster,简单的说,集群(cluster)就是一组计算机,它们作为一个整体向用户提供一组网络资源。这些单个的计算机系统 就是集群的节点(node)。

    高可用集群的出现是为了使集群的整体服务尽可能可用,从而减少由计算机硬件和软件易错性所带来的损失。如果某个节点失效,它的备援节点将在几秒钟的时间内接管它的职责。因此,对于用户而言,集群永远不会停机。

    高可用集群软件的主要作用就是实现故障检查和业务切换的自动化。只有两个节点的高可用集群又称为双机热备,即使用两台服务器互相备份。当一台服务器出现故障时,可由另一台服务器承担服务任务,从而在不需要人工干预的 情况下,自动保证系统能持续对外提供服务。双机热备只是高可用集群的一种,高可用集群系统更可以支持两个以上的节点,提供比双机热备更多、更高级的功能,更能满足用户不断出现的需求变化。

二、高可用集群的特点

高可用服务

  • 通常使用集群方式实现,这也是集群的最大作用和体现。

  • 其终极目标是确保服务实时可用,不会因为任意的软硬件故障导致服务出现终止和不可用的情形。

度量标准

  • 系统的可靠性(reliability)和可维护性(maintainability)来度量。

  • 工程上,通常用平均无故障时间(MTTF)来度量系统的可靠性,用平均修复时间(MTTR)来度量系统的可维护性。

   计算公式,HA=MTTF/(MTTF+MTTR)*100%

   99%         全年停机时间不超过4天

   99.9%       全年停机时间不超过10小时

   99.99%      全年停机时间不超过1小时

   99.999%     全年停机时间不超过6分钟

集群节点

  • 集群软件必须包括一种机制来定义哪些系统的可用作集群节点(定义节点,2节点或以上)。

  • 所有位于集群中的主机都称为节点。

集群服务与资源

  • 哪些服务或应用程序可以在节点之间进行故障转移,并互连可以在节点间传送通信。

  • 服务通常包括多种资源,多种资源组成某种服务。

  • 如mysql高可用服务,则vip,mysqld,共享或镜像磁盘等则为该服务所需要的资源。

  • 对集群服务的管理,实际上是对资源的管理。

资源隔离与脑裂

  • 由于软硬件故障导致节点宕机发生资源争用,即出现故障节点或正常并存的情形。

  • 在故障的节点控制相同的集群资源的情况下,实施资源隔离,防止脑裂发生(Fence机制,STONITH等)。

集群状态监控

  • 通过集群管理和监控工具以及预定义的脚本来配置常见的服务或应用程序,监控,故障转移等。

  • 最为大家所熟知的如心跳,主要用于在集群环境中各节点之间相互感知对方的存在。

  • 可以基于串口、多播、广播和组播通信机制。一旦心跳失败,则会发生相应的资源转移,集群重构等动作。

三、高可用集群的层次结构

wKioL1ZlI-vhOgadAACnl7I62j8673.jpg

高可用集群可分为三个层次结构

  • Messaging and Membership:Messaging主要用于节点之间传递心跳信息,也称为心跳层。节点之间传递心跳信息可以通过广播,组播,单播等方式。成员关系(Membership)层,这层最重要的作用是主节点(DC)通过CCM或者CCS(Cluster Consensus Menbership Service)这种服务由Messaging层提供的信息,来产生一个完整的成员关系。这层主要实现承上启下的作用,承上,将下层产生的信息生产成员关系图传递给上层以通知各个节点的工作状态;启下,将上层对于隔离某一设备予以具体实施。

  • Cluster Resource Manager:集群资源管理层,真正实现集群服务的层。在该层中每个节点都运行一个集群资源管理器CRM(Cluster Resource Manager),它能为实现高可用提供核心组件,包括资源定义,属性等。在每一个节点上CRM都维护有一个CIB(集群信息库 XML文档)和LRM(本地资源管理器)组件。对于CIB,只有工作在DC(主节点)上的文档是可以修改的,其他CIB都是复制DC上的那个文档而来的。对于LRM,是执行CRM传递过来的在本地执行某个资源的执行和停止的具体执行人。当某个节点发生故障之后,是由DC通过PE(策略引擎)和TE(实施引擎)来决定是否抢夺资源。

  • Resource Agents:资源代理层,集群资源代理(能够管理本节点上的属于集群资源的某一资源的启动,停止和状态信息的脚本),资源代理分为:LSB(/etc/init.d/*)、OCF(比LSB更专业,更加通用)、Legacy heartbeat(v1版本的资源管理)。


四、高可用集群软件

wKioL1ZquXyBWibsAACbPOgq4BY058.png

Messaging and Membership Layer(信息与关系层):

  • heartbeat (v1,v2,v3),heartbeat v3 分拆为 heartbeat+pacemaker+cluster-glue

  • corosync (OpenAIS应用)

  • 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的高可用)

五、高可用集群基本概念

1、资源类型

  • primitive(native): 基本资源,同一时刻只能运行在一个节点,如服务的IP地址;

  • group: 资源组;

  • clone: 克隆资源(可同时运行在多个节点上),要先定义为primitive后才能进行clone;

  • master/slave: 只能运行2个节点,一主一从,比如drbd服务。

2、资源粘性stickiness

    表示资源是否倾向于留在当前节点

  • >0: 倾向于留在当前节点;

  • <0: 倾向于离开此节点;

  • =0: 由HA来决定去留;

  • INFINITY: 正无穷大;

  • -INFINITY: 负无穷大;

3、资源约束

    资源的启动是要有先后次序的,这时就需要对资源进行约束。
    资源约束用以指定在哪些群集节点上运行资源,以何种顺序装载资源,以及特定资源依赖于哪些其它资源。

  pacemaker提供了三种资源约束方法:

  • Location(位置约束): 定义资源可以/不可以/尽可能在哪些节点上运行; 

  • Collocation(排列约束):定义集群资源可以/不可以在某个节点上同时运行;

  • Order(顺序约束):定义集群资源在节点上启动的顺序;

4、法定票数quorum
    集群服务中的每个node都有自己的票数,票数是由DC负责统计,形成CIB(集群信息库),然后同步集群信息库到各个节点上,只有quorum大于总票数的二分之一,集群服务才可以继续运行,当quorum小于总票数的二分之一时,会有以下动作:

  • ignore(忽略): 当集群服务只有两个节点时,无论谁挂了,都需要切换node,所以要忽略法定票数;

  • freeze(冻结): 已经启动的资源继续运行,不允许新的资源启动;

  • stop(停止): 停止集群服务,这是默认值;

  • suicide(自杀): 将所有节点全部隔离;

5、隔离Fence
    多台node在共享存储写同一个文件时,文件系统就会崩溃,所以资源转移之前需要先完成其他节点的隔离,隔离有2个级别:

  • 资源隔离: 让被隔离主机不能再使用这个资源。如让隔离的主机不能访问共享存储;

  • 主机隔离: 直接让被隔离的主机关机。如通过STONITH让主机断电,强行关闭;

六、如何避免脑裂

    为了避免出现脑裂,可采用下面的预防措施:

  • 如前所述,在主、备节点间建立一个冗余的、可靠的物理连接来同时传送控制信息;

  • 一旦发生脑裂时,借助额外设备强制性地关闭其中一个节点;

    第二种方式即是俗称的"将其它节点'爆头'(shoot the other node in the head)",简称为STONITH。基于能够通过软件指令关闭某节点特殊的硬件设备,Heartbeat即可实现可配置的Stonith。但当主、备服务器是基于WAN进行通信时,则很难避免"脑裂"情景的出现。因此,当构建异地"容灾"的应用时,应尽量避免主、备节点共享物理资源。







     本文转自 wzlinux 51CTO博客,原文链接:http://blog.51cto.com/wzlinux/1720288,如需转载请自行联系原作者



网友评论

登录后评论
0/500
评论
技术小胖子
+ 关注