高可用集群 （HA）
可用性(availability)是通过系统的可靠性(reliability)和可维护性(maintainability)来度量的。工程上通常用平均无故障时间(MTTF)来度量系统的可靠性，用平均维修时间（MTTR）来度量系统的可维护性 #衡量标准 （1）平均无故障时间/（平均无故障时间+平均修复时间) #业界根据可用性的衡量标准将服务器进行了分类，即5个9参数
（2）高可用集群HA的功能 #服务可用性：高可用、数据高可用、代码发布高可用等
高可用集群基础概念详解
ha_aware #应用程序自己能够利用底层心跳信息层的功能完成集群事务决策的程序；也就是说该程序自己具有HA的能力,则该程序就是ha_ware 非ha_aware #ha_awre反之则为非ha_aware
自身不具备HA的程序，需要借助其他程序组件来实现高可用集群的功能
DC （Designated Coordinator）
# 资源管理器层的领导者
CRM （Cluster Resource Manager）
# 集群资源管理器
LRM （Local Resource Manager）
# 本地资源管理器
RA （Resource Agent）
# 资源代理类型 (帮助管理资源)
# {start|stop|restart|status} ------管理资源的动作
# status : ------资源的状态（2个）
# running 运行
# stopped 停止
# failover:失效转移，故障转移
# fileback:失效转回，故障转回
Messagine Layer
# 心跳信息层--底层
CRM、 RA 、MessagesLayer
##高可用集群中，任何资源都不应该自行启动，而是由CRM管理器启动与否；
CRM 类别
#（1） hearbeat v1 : haresources ( 配置接口haresources文件)
#（2） hearbeat v2 : crm （配置接口：客户端crm(shell)，heartbeat-GUI图形界面客户端工具；各节点均运行进程crmd，）
#（3） hearbeat v3 : heartbeat + pacemaker(心脏起搏器) + cluster-glue（集群的粘合器）
# pacemaker
# 配置接口 ：
# CLI : crm（SuSE）, pcs
# GUI : hawk（网页版的GUI）, LCMC(窗口GUI),pacemaker-mgmt
#（4） cman + rgmanager:
# rgmanager : 资源组管理器 -------Failover Domain 故障转移域
# 配置接口：
# RHCS： RedHat Cluster Suite 红帽自带集群套件
# 配置接口：Conga (完全生命周期的配置接口)
RA 类别 #（1） heartbeat legacy : ---heartbeat的传统类型 #（2） LSB: /etc/rc.d/init.d/* ----所有服务脚本 #（3） O: Open Cluster Framework ----开源的集群框架 # provider:pacemaker、 linbit ----框架提供者 #（4） STONITH:Shot ON It's Head ------------爆头，专门用于隔离资源的资源代理类型
Messages Layer # 实现心跳信息传递的工具 # heartbeat v1,v2,v3 ---------heartbeat的三个版本 # (OpenAIS) corosync ---------属于OpenAIS中的corosync
RHEL OR CentOS高可用集群解决方案
版本5
# 自带：RHCS(cman+rgmanager)
# 选用第三方：corosync+pacemaker,heartbeat(v1或v2)；keepalived
心跳层+资源管理层
版本6
# 自带：RHCS（cman+rgmanager）
# corosync+rgmanager
# cman+pacemaker
# heartbeat v3 + pacemaker
# keepalived
心跳层+资源管理层
#其中keepalived与上述集群模式不同，它利用路由交换的冗余协议，使用IP实现前段负载均衡的高可用。
应用方式（2种）
# （1）做前段负载均衡器的高可用：keepalived
# （2）做大规模的高可用集群 ：corosync(cman) + pacemaker
资源隔离
资源隔离：--------集群可能分裂（split brain），为了防止非集群节点和集群节点争抢资源 # 从两个级别上实现资源隔离 # 节点级别：（STONITH ）---某节点宕机，直接将其切断电源，或者stop # 依赖于电源交换机、服务器上的控制芯片（高级服务器都带有比如IBM-RSAII、HP-iLO） # 资源级别：（Fense 栅栏）---某资源停止，直接将资源stop # 依赖于存储交换机(SAN交换机) 资源仲裁：--------防止集群分裂 # 仲裁设备： # ping node/ping group # 另一种仲裁设备： # qdisk
HA集群的工作模型
A/P #两个节点，工作在主、备节点 ------使用ping node 来实现仲裁，一般而言2个节点不常见。 N-M #N>M N为节点，M为 --N-M个节点会空闲出来，空闲节点为前边的工作节点提供 HA高可用 N-N #N个节点，N个服务； A/A #双主模型；---两个节点运行不同的服务器；也可以运行不同的服务（使用ping node提供仲裁）VIP1 httpd服务、VIP2 NFS服务
资源转移方式
rgmanager(红帽中的组件) ：failover domain（故障转移域）, priority(级别)
pacemaker :（heartbeat v3版本后将pacemaker分隔出来为一个单独的资源管理器）
资源粘性 :
资源约束 ：（3种类型）
# 位置约束：资源更倾向于哪个节点上； --------------Location
# inf : 无穷大
# n : 100
# -n : -100
# -inf : 负无穷 ----但凡有一个节点存在，都不会用这个节点
#排列约束：定义资源运行在同一节点的倾向性； ----------Relocation
# inf : 无论如何都要在一起的节点
# -inf : 相忘于江湖；
#
#顺序约束 ：定义资源的启动次序及关闭次序；先启动的后关闭 ----------Order
注意： pacemaker集群分为对称和非对称集群，根据位置约束：对称的可以转移到任意节点上，非对称为不可以转移到任何的节点上去
思考篇
如果节点不再是集群节点成员时，如何处理运行于当前节点的资源？ # stopped 关闭---关闭非集群节点的服务 # ignore 忽略---不管是不是集群节点，都会运行该服务； # freeze 冻结---已经连接进来的用户请求可以处理，新的请求不再处理 # suicide 自杀 ----当节点不再是集群成员时，自己将服务kill掉；
一个资源刚配置完成时，是否启动？ # 通过target-role ？（目标决策） 来定义是否启动！ # 默认情况下是指定特定资源启动的；
如何让服务（web service） 中的三个资源：VIP、httpd 、以及filesystem运行于同一节点上？ #方案1 ： 排列约束（colocation）； #方案2 ： 资源组（resource group）；
资源类型
#(1)primitive/native: 本地资源，主资源，只能运行于一个节点；
#(2)group: 组资源；将多个资源定义为一个组，以一个组为单位来调度资源；
#(3)clone：克隆资源；-----允许某一种资源在多个节点上运行。定义clone资源方法：先将资源定义为主资源，然后再定义为clone类型
# 一般需要定义的参数：①每个节点可运行的总克隆数② 每个节点最多可运行的克隆数；
# 其中允许在多个节点上运行的资源：stonith,cluster file system
# 其中分布式文件系统：通过分布式锁实现，将分布式锁作为资源
#
#（4）master/slave:主从类型资源，--也是克隆资源，不过只有两份---类似于mysql的主从同步模型
HA原理图详解
上图分析
主从两个节点
#最底层：Messaging/Infrastructure 心跳信息信息层/基础架构层
传递心跳信息
能够实现该功能的为Corosync 或者heartbeat
#资源分配层/资源管理器层（Resource Allocaton）
核心组件 CRM（集群资源管理器）--集群资源管理器上必须有一个被选为CRM领导者Designated Coordinator* （DC）
DC：运行两个额外进程：PE & TE PE---董事长--做决策 TE--CEO---
TE： (tralation engine)事务引擎
PE：(plicy engine)策略引擎，通过Messaging层收集的整个集群中所有节点的信息 ，在本地形成一个Big Picture，来决策那些资源运 行在那个节点上，并通知其他节点上的资源管理器来实现资源的关闭启动等操作的；
#1、PE知道节点上有哪些资源；通过资源约束来判断哪些资源启动在哪些几点上启动--关闭还是启动
# 通过配置接口来配置--资源约束 （任何节点上都提供配置节点）
# 配置接口配置以后，通过messeges layer ，自动广播或是组播给每一个节点，从而保证了每一个节点配置信息相同；
#2、各个节点之间如何与其他节点传递数据的？
# 通过拓展结构语言来实现数据的格式传递（半结构化数据），半结构化数据时基于xml文件保存的； 因此每一个节点上的信息保存都是根据xml文件保存的（能够实现自动配置）--不同于heartbeat v1 的配置文件haresource文件 需要手动的传递文本信息过于简陋；
# 3、能够完成xml格式的配置信息：接受用户配置，并理解配置 需要一个工具实现即CIB
# CIB（cluster information Base） ：集群信息库
# 真正配置集群的时只要能够连接到任何一个几点上的CRM都能配置（不论是不是DC），首先将信息保存在DC上的CRM的CIB中，然后由DC同步给各个节点上的CRM 信息库CIB
# 这个xml配置文件就叫做CIB
# PE 根据CIB 获取资源配置信息， 并通过mees la 的活动信息而做出决策，然后启动资源---通过本地CRM借助于mees 通知给位于其他节点上的资源信息库--然后让CRM去启动或者 关闭资源。CRM并不工作，调用本地资源管理器LRM， LRM借助于RA 完成资源管理
HA工作流程总结：CRM收集信息，推举为DC的CRM由PE运行，PE负责整个集群系统中的所有资源，并确保资源能够在合适的节点上启动起来，PE一旦做出决策之后，会通知给对应节点上的CRM，CRM调用LRM ，LRM借助于 RA 完成操作；
以上为高可用集群（HA）的相关概念、工作原理与工作流程的总结！
PS：水平有限，总结的有不妥之处，或欠缺之处请指出！！
转载于:https://blog.51cto.com/jungege/1398799
3007
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
