集群概念

消息交换和基础结构层

Messaging and Infrastructure Layer：这一层也被称为心跳层，这一层主要包含了如发送心跳信息和集群中各种事务信息

Membership Layer：也叫CCM层，用来计算整个集群中的节点状态信息的大图景，以及同步这个信息给集群中的所有节点，如集群中有几个节点，可以投几票等信息。还有组织集群拓朴的组件，所以它可以拥有整个集群的全局视图。

资源分配层

• CRM：资源分配层所采取的每个动作都是通过CRM来实现的，所以它是基础核心层，在每个节点上，CRM负责生成一个CIB，使每个节点都能了解整个集群的所有配置状态等。CRM会在集群中选举出一个节点当作DC，DC负责维持主CIB文档，所有对CIB的修改都应该通过DC来实现，而后由DC同步给其他节点，对CIB的读写都应该通过主CIB，也就是DC上的CIB，不能修改非DC的CIB，因为非DC的CIB是不会同步的。在一个集群中DC是唯一的，而且能做集群范围的修改操作及其他所有操作都是由DC来做出的。CIB是一个位于内存中的（也会同步到磁盘中），XML格式的，保存了集群每个条目的相关信息，包括集群状态，节点成员关系，定义的资源，及资源的关系等，如果要修改CIB的话可以使用各种客户端工具，如cibadmin这样的命令行工具或heartbeat GUI这样的图形化工具。DC还拥有PE和TE两个组件，一旦DC要做一个集群全局范围的修改，Policy Engine将用于实现计算集群的下一个状态，如当某一个节点离去了，此时位于这个节点上的所有资源应该被转移，之后运行在哪个节点就要由DC来决策，决策后还要修改CIB文档，PE还要将状态变化保存到CIB中，DC所做出的决策，如约束，是否爆头等都是由PE计算得出的，之后由TE负责执行。由TE将PE的决策发放给每个CRM，各CRM收到信息后，将指令发送给LRM，LRM将指令发给RA去执行。RA是脚本，可以执行基本的三个操作，start/stop/monitor

群集资源管理器 (CRM)

在资源分配层中执行的每个操作都要经过群集资源管理器。如果资源分配层的其他组件（或更高层中的组件）需要通讯，则它们通过本地 CRM 进行。在每个节点上，CRM 都会维护群集信息库 (CIB)

群集信息库 (CIB)

群集信息库是整个群集配置和当前状态在内存中的 XML 表示。它包含所有群集选项、节点、资源、约束及其之间的关系的定义。CIB 还将更新同步到所有群集节点。群集中有一个主 CIB，由指定协调器 (DC)进行维护。所有其他节点都包含 CIB 复本。

指定协调器 (DC)

群集中的一个 CRM 会被选为 DC。DC 是群集中唯一可以决定需要在整个群集执行更改（例如节点屏蔽或资源移动）的实体。DC 同时也是用于保存 CIB 主副本的节点。所有其他节点都从当前 DC 获取他们的配置和资源分配信息。DC 是在成员资格更改后从群集的所有节点中选出的。

策略引擎 (PE)

只要指定协调程序需要进行群集范围的更改（对新 CIB 作出反应），策略引擎就会根据群集的当前状态和配置计算其下一个状态。PE 还生成一个转换图，包含用于达到下一个群集状态的（资源）操作和依赖性的列表。PE 始终在 DC 上运行。

本地资源管理器 (LRM)

LRM一般由CRM提供，代表 CRM 调用本地资源代理。因此它可以执行启动/停止/监视操作并将结果报告给 CRM。LRM 是其本地节点上所有资源相关信息的权威来源。

资源层

最高层是资源层。资源层包括一个或多个资源代理 (RA)。资源代理是已写入的用来启动、停止和监视某种服务（资源）的程序（通常是shell脚本）。资源代理仅由 LRM 调用。第三方可将他们自己的代理放在文件系统中定义的位置，这样就为各自的软件提供了现成群集集成。

Resource Layer：这里是一堆脚本ocf格式或lsb格式，建议使用ocf格式

概念

群集最多可包含 32 个 Linux 服务器。如果群集内的一台服务器发生故障，则群集内的任何其他服务器均可重启动此服务器上的资源（应用程序、服务、IP 地址和文件系统）。

集群中应该有奇数个节点，如果是偶数，应该引入仲裁设备，集群中的节点通过心跳信息通告自己的健康状态，而不是探测其他主机，这意味着每个节点上都要运行一个应用程序，这些应用程序在固定的IP地址和端口上工作，通常因为是一对多的通信关系，因此是通过多播的方式向多播域内发送心跳信息和集群事务信息，其他主机看到这个信息就知道这个主机是在线的，这种功能的实现的层次称为message layer，message layer不但能传送心跳，还能传送集群事务信息，比如：如果集群发生分裂的话，失去联系并不具备法定票数的主机会被杀死。这就是集群事务内的决策信息。任何应用要想实现高可用，就要调用message layer提供的多播模式传递心跳信息和集群事务信息完成集群内部资源运行的决策，但不是所有应用都有这种能力，这就需要由CRM集群资源管理器实现，它向上可以为不具备高可用能力的服务提供高可用性，让其可以利用message layer完成高可用。向下，它利用message layer传递过来的各节点的心跳和集群事务信息，形成一个大的决策图景，从而决策都由CRM决定。因为各种资源的启动方式各有不同，为了避免这种麻烦，在CRM之上又加入了一个层次，叫LRM本地资源管理器。本地资源管理器一般都是由集群资源管理器提供的，本地资源不能做出一个资源应该如何启动与关闭，而要借助资源代理RA来实现，这是第四个层次。在每个节点上都有众多的RA，它是帮助启动关闭监控资源的脚本 。

资源类型

• Primitive：主资源，只能运行于集群内的某单个节点；只能启动一份，也称作native
• Group：组资源，这是一个容器类资源，它可以包含一个或多个资源，这些资源可通过“组”这个资源统一进行调度
• Clone：克隆资源，可以在同一个集群内的多个节点运行多份克隆；
• Master/slave：主从资源，在同一集群内部于两个节点运行两份资源，其中一个为主一个为从

资源的约束的关系

• location：位置约束，定义资源对节点的倾向性；用数值表示，从负无穷到正无穷
• colocation：排列约束，定义资源彼此间“在一起”的倾向性；从负无穷到正无穷
• 分组：也能实现将多个资源绑定在一起；但不能让资源不在一起
• Order：顺序约束，定义资源在同一个节点上启动时的先后顺序；

运行在哪个节点，是在资源管理器的接口上进行配置，配置有三：1.这个资源更倾向运行在哪个节点上；2.这个资源更倾向与哪个资源运行在一起，注意：一个资源不能称之为服务，比如构建一个高可用的web集群，需要IP地址，进程，页面文件等，所以高可用服务与高可用资源是两回事。高可用服务可能包括多个高可用资源。一个高可用集群中的高可用资源可能有多个，而且要分类在一起才能构建成一个服务，比如，要启动三个资源，IP在第一个节点上，进程在第二个节点上，页面文件在第三个节点上，这是没用的，因为它们要同进退的。所以哪些资源要运行在一起，不能分开。这叫资源的排列约束。这主要是定义资源在一起的倾向性的。3. 如果多个资源必须运行在同一个节点上，并提供同一个服务工作，那是否有先后次序关系呢？是否要先启动一个再启动一个。比如：是先挂载页面文件还是先启动web进程。这就是次序约束。

参考：

SUSE Linux Enterprise High Availability Extension 11 SP4 高可用性指南