高可用集群的实现原理

前言:

   该文章耗费作者大量时间,转载声明转http://anyisalin.blog.51cto.com/


介绍:

   该文章是我学习马哥的HA集群课程之后所写,基本凭自己的记忆编写,若有错误,麻烦回复指出,谢谢!



为什么要提供一个服务的高可用?

高可用(High Available)顾名思义是提高一个服务的可用性,在生产环境当中,如果对外提供服务的主机出现故障是致命的,可能会造成很大损失,我们需要提供一个解决方案,在服务器出现故障时能迅速将服务器上运行的服务转移到其他备用的节点,并让其继续运行对外提供服务.

服务高可用该如何实现?

   在实现服务高可用的时候有许许多多的问题需要,例如备用节点如何知道主节点出现故障?、备用节点如何接管资源?、如果主节点没故障,备用节点认为其故障而强制接管其资源怎么办?诸多问题需要解决.那么我们到底该怎么实现高可用集群呢?我们需要了解一些关于高可用集群的原理.

   

实现原理
    在高可用集群的各节点中定义了一个抽象层,信息传递层(Messaing Layer),用来传递集群之间的事务(Transaction)信息.事务信息中包含了节点的心跳信息(是否在线),节点的主机名、IP等一系列信息.当然光有Messaging Layer并不能实现一个集群的高可用.这里我们介绍一个概念

一个服务要是想实现高可用需要两个条件:

Messaging Layer

实现Messaging Layer的软件有很多,例如corosync,heartbeat...

ha-aware/CRM

ha-aware: 是指一个服务本身具备高可用能力,能够通过API调用Messaging Layer传递的信息来提供高可用

CRM: 全称Cluster Resource Manager,集群资源管理.能够通过Messaging Layer传递的信息,对集群中各节点的资源进行相应处理

CRM需要在集群各节点中选举出DC(Designated Coordinator)指定调解员对集群上的资源进行计算,计算出资源更适合运行在哪个节点中.

DC中又包含两个引擎来处理不同的事情

PE: Policy Engine  用来计算

TE: Transaction Engine 用来指挥资源的转移

TE通过指挥LRM(Local Resource Manager)来实现资源转移

FailOver: 故障转移,运行资源的节点出现故障时将资源转移到其他节点

FailBack: 转回,节点重新上线后将原来的资源转回




资源:

资源是运行在集群上的服务,IP等一系列可以被CRM所管理的,能够在节点出现故障时收到LRM的指令做出相应的动作

例如: 我们要提供一个httpd服务的高可用需要的资源:      VIP: 对外提供服务的IP地址

httpd: httpd服务

但是资源应该在那个节点中运行,是否能够运行在某个节点上都是通过Resource Constraint来定义的

Constraint: 资源约束分为三个类别

Location: 位置约束

使用分数来定义资源是否倾向于运行在此节点上

INF: 倾向于运行在此节点

-INF: 不倾向于运行在此节点

Colocation: 排列约束

使用分数来定义资源是否能够同时运行在一个节点上

INF: 能够同时运行在一个节点上

-INF: 不能同时运行在同一节点上

 Order: 顺序约束

定义资源启动|关闭的顺序

如果主节点出现故障,备用节点接管其资源来提供服务,一段时间后,主节点重新上线,那么集群资源是否会重新回到主节点,这里我们就要解释一下Resource Stickiness


Resource Stickiness: 资源粘性,定义一个资源是否倾向于留在此节点.

相信大家都了解,位置约束是定义资源是否倾向运行在此节点,那么当同时定义了资源粘性和资源约束的时候,资源到底应该运行在哪个节点上呢,我们来看一个案例

例子:

节点: node1.anyisalin.com,node2.anyisalin.com

节点资源: httpd

默认资源粘性为100,httpd对node1的位置约束的分数值为INF,对node2的位置约束的分数值为200

原本httpd服务运行在node1上,有一天node1突然出现了故障,资源理所应当转移到node2上,运行了一段时间之后,node1重新上线,我们来计算一下httpd服务到底应该运行在哪个节点

    node1: 对于httpd的位置约束分数值为INF,httpd对其资源粘性值为100
    node2: 对于httpd的位置约束分数值为200,httpd对其资源粘性值为100
    node1=100+INF  node1=INF
    node2=100+200  node2=300
    node1>node2
    故httpd服务应该转移回node1


RA: Resource Agent资源代理,其实就是定义成集群资源的脚本,能够LRM的发送的指令来实现对集群资源的管理

RG: Resource group资源组,若干个集群资源组成的组,同进同退

RA Classes:

    

LSB: Linux Standard Base

/etc/init.d/下的所有脚本就是LSB标准的,至少支持statr,status,restart,stop四个指令

OCF: Open CLuster Framework

一个支持更多指令的标准,更加的灵活


Resources Classes:

Primitive:

主资源类型,同一时刻集群中只能有一个节点运行主资源

Clone:

克隆,将主资源克隆,同一时刻必须运行在指定的节点上

Group:

组,将若干个主资源归类为组,当成一个单位同进同退

Master/Slave:

特殊的Clone资源,只能运行两份,一个节点为主节点,一个节点为备份节点




资源隔离:

什么时候需要资源隔离?

当集群节点无法有效获取其他节点信息,以至于抢占资源

严重后果: 抢占存储资源,导致分区崩溃

解决方案: 资源隔离

资源隔离:

节点级别:

STONITH: 使用STONITH设备强制关闭|重启节点

资源级别:

使用FC交换机,实现在存储资源级别隔离节点访问



我们可能还需要考虑一种情况,在节点发生故障时候,不能获取其他节点信息,节点是如何得知到底是自己出现故障,还是其他节点故障?

这里我们可以使用ping node,或者仲裁磁盘来解决了.

ping node: 当节点不能获取另一个节点信息时,ping提供的第三方节点,如果能ping通,fence另一个节点


仲裁磁盘: 集群中各节点在运行的时候,同时向同一共享存储中写入数据,当某节点不能获取另一个节点信息时,查看仲裁磁盘另一个节点是否还在写入数据,如果没有,fence另一个节点



在一些特定场景,我们在高可用集群中可能要使用多于2个的节点,那么我们需要考虑更多问题了

一个节点出现故障该如何判定自己应该自杀还是fence其他节点?

quorum: 法定票数

多节点集群中,每一个节点都具有相应的法定票数

node1 不能获取其他节点信息

node2 <--> node3 node2和node3能够获取对方信息

假定每个节点的票数都为1票

node2+node3 > 3/2 node1应该根据资源策略才做出相应动作

资源策略: Without_quorum_Policy 不具有法定票数

freeze: 不再接受新的请求,已连接的不便

stop: 停止集群服务

ignore: 忽略,继续运行集群服务

时间: 2024-10-09 20:32:55

高可用集群的实现原理的相关文章

HA 高可用集群概述及其原理解析

HA 高可用集群概述及其原理解析 1. 概述 1)所谓HA(High Available),即高可用(7*24小时不中断服务). 2)实现高可用最关键的策略是消除单点故障.HA严格来说应该分成各个组件的HA机制:HDFS 的HA和YARN的HA. 3)Hadoop2.0之前,在HDFS集群中NameNode存在单点故障(SPOF). 4)NameNode主要在以下两个方面影响HDFS集群: ? NameNode机器发生意外,如宕机,集群将无法使用,直到管理员重启 ? NameNode机器需要升级

Linux高可用集群方案之heartbeat基础原理及逻辑架构

 这篇文章我们主要学习heartbeat高可用集群的基础原理及逻辑架构,以及heartbeat的简单配置  ll  本文导航    · heartbeat之基本原理   · heartbeat之集群组件   · heartbeat之心跳连接   · heartbeat之脑裂(资源争用.资源隔离) · heartbeat之配置文件   · heartbeat至高可用集群配置  ll  要求  掌握heartbeat高可用集群的相关组件及简单配置   heartbeat之基本原理  heartbea

高可用集群原理

1.高可用集群概念 高可用集群就是当某一个节点或服务器发生故障时,另一个节点能够自动且立即向外提供服务,即将有故障节点上的资源转 移到另一个节点上去,这样另一个节点有了资源既可以向外提供服务.高可用集群是用于单个节点发生故障时,能够自动将资源.服务进行切换,这样可以保证服务 一直在线.在这个过程中,对于客户端来说是透明的. 2.高可用集群组件 1).Messaging Layer:集群服务信息层,主要的作用是传递当前节点的心跳信息,并告知给对方,这样对方就知道其他节点是否在线.如果不在线,则可以

高可用集群原理解析

HA(High Avaliablity,高可用)集群的出现是为了使集群的整体服务尽可能可用,从而减少由计算机硬件和软件易错性所带来的损 失.如果某个节点失效,它的备援节点将在几秒钟的时间内接管它的职责. 一.高可用原理简述 我们在要做高可用的节点上安装好实现高可用功能的程序,这些程序最核心的包括两个部分:心跳监测部分和资源管理部分:通过资源管理器的配置接口定义资源,并将配置文件同步到其它节点,节点之间在心跳监测层通过相互发送报文来告诉对方自己当前的状态,如果在指定的时间内未收到对方发送的报文,那

马哥学习笔记二十二——高可用集群原理

HA Resource:资源 FailOver:故障转移 FailBack:故障转回 资源粘性:资源是否倾向于留在当前节点 Messaging Layer:集群服务信息层,基于UDP互相传递心跳信息,集群事务信息等 heartbeat(v1,v2,v3) heartbeat v3:heartbeat,pacemaker,cluster-glue corosync cman keepalived ultramonkey CRM:(cluster resource manager)集群资源管理器,统

CentOS 6.5环境下heartbeat高可用集群的实现及工作原理详解

Linux HA Cluster高可用服务器集群,所谓的高可用不是主机的高可用,而是服务的高可用. 什么叫高可用:一个服务器down掉的可能性多种多样,任何一个可能坏了都有可能带来风险,而服务器离线通常带来的代价是很大的,尤其是web站点,所以当某一台提供服务的的服务器down掉不至于服务终止的就叫高可用. 什么叫心跳:就是将多台服务器用网络连接起来,而后每一台服务器都不停的将自己依然在线的信息很简短很小的通告给同一个网络中的备用服务器的主机,告诉其实主机自己依然在线,其它服务器收到这个心跳信息

linux高可用集群(HA)原理详解

高可用集群 一.什么是高可用集群 高可用集群就是当某一个节点或服务器发生故障时,另一个节点能够自动且立即向外提供服务,即将有故障节点上的资源转移到另一个节点上去,这样另一个节点有了资源既可以向外提供服务.高可用集群是用于单个节点发生故障时,能够自动将资源.服务进行切换,这样可以保证服务一直在线.在这个过程中,对于客户端来说是透明的. 二.高可用集群的衡量标准 高可用集群一般是通过系统的可靠性(reliability)和系统的可维护性(maintainability)来衡量的.通常用平均无故障时间

heartbeat2.0 原理解析与高可用集群案例实现

 这篇文章我们将学习heartbeat2.0的基本原理以及如何简单配置高可用集群  ll  本文导航    · 什么是高可用集群   · 高可用集群的解决方案   · heartbeat之基本原理   · heartbeat之逻辑架构   · heartbeat之心跳连接   · heartbeat之脑裂(资源争用.资源隔离) · heartbeat之配置文件   · heartbeat至高可用集群配置  ll  要求    什么是高可用集群  所谓高可用集群,即当前服务器出现故障时,可以将该服

linux高可用集群(HA)原理详解(转载)

一.什么是高可用集群 高可用集群就是当某一个节点或服务器发生故障时,另一个 节点能够自动且立即向外提供服务,即将有故障节点上的资源转移到另一个节点上去,这样另一个节点有了资源既可以向外提供服务.高可用集群是用于单个节点发 生故障时,能够自动将资源.服务进行切换,这样可以保证服务一直在线.在这个过程中,对于客户端来说是透明的. 二.高可用集群的衡量标准 高可用集群一般是通过系统的可靠性(reliability)和系统 的可维护性(maintainability)来衡量的.通常用平均无故障时间(MT