heartbeat2.x-pacemaker Configuration Explained翻译笔记

本文作者：深夜的蚊子
本文链接：http://www.wenzizone.cn/?p=222
版权所有。转载时请以链接形式注明作者和原始出处及本声明，谢谢

 

Pacemaker配置手册讲解

上篇文章蚊子是从半截开始翻译的，这篇文章补充完整，这个是文章开头那部分介绍内容，没有更多的技术，只是对Pacemaker的整体介绍。还是那句话，蚊子英文水平太烂，真有翻译不对还望各位指正。

先读我

什么是Pacemaker

Pacemaker是集群资源管理。它利用你的集群基础组件（如OpenAIS或heartbeat）来停止，启动甚至监控你希望集群提供服务的健康状况。

它可以在任何大小规模的集群中工作，伴随使用可靠的模块，管理可以很准确的描述集群中资源的关系。

集群堆栈概述

在最顶层，集群由三部分组成

集群的核心基础提供消息和成员功能（红色描述）

非集群意识组件（蓝色描述）。在Pacemaker集群中，这一块不仅仅包含了知道如何启动，停止及监控资源的脚本，同时还有一个本地守护进程来掩饰脚本执行不同标准之间带来的差异。

大脑（绿色显示）用来响应和处理从集群（节点的脱离和加入），资源（监控健康），及管理员对于配置文件变更的事件。对于这些事件的响应，Pacemaker将会评估出集群的理想状态同时划分出一个路径用来打包。这可能会包括移动资源，停止节点，甚至是通过远程switches强迫他们离线。

Pacemaker架构

Pacemaker自己由4个关键组件组成（下面颜色的描述和之前那个概念上一样）

CIB（Cluster Information Base集群信息基础)

CRMd（Cluster Resource Management daemon集群资源管理守护进程)

PEngine（PE or Policy EnginePE或者策略引擎)

STONITHd

CIB使用XML替代了集群中的集群配置和所有资源的当前状态。CIB的内在自动在整个集群中保持同步同时被PEngine用来评估集群的理想状态和如何达到这个状态。

指令的列表传递给DC（指派的协调者）。Pacemaker通过选举一个CRMd线程作为主控的方式来收集集群中作出的决策。如果在选举的过程中或者选在一个几点上的时候，失败了，那一个新的就会被很快的建立起来。

DC通过必要的命令来实现PEngine的指示，通过集群消息架构（这个消息架构可以轮流把命令传递给他们的LRMd进程）把命令传递个LRMd（本地资源管理守护进程）或者其他节点上的CRMd。

同级节点奖他们的操作返回汇报给DC，同时基于真实的和期望的结果，将会需要等待前置任务完成再来执行任何响应，或者忽略进程告知PEngine根据意外的结果重新计算理想的集群状态。

在有些情况下关闭节点来保护共享数据或者完全恢复资源是很有必要的。为了这个Pacemaker出现了STONITHd。STONITH是Shoot-The-Other-Node-In-The-Head的缩写，通常用远程电源开关来充当。在Pacemaker中，STONITH设备是一个资源模块（配置在CIB中），使用它们可以很容易监控故障，然而STONITHd关心理解STONITH的拓扑结构这样在client请求把一个节点保护起来STONITHd就可以重启了。

运行在OpenAIS上的Pacemaker集群子系统

这个手册的作用域

本篇手册的目的更确切的讲是解释使用Pacemaker配置的概念。为了达到最好，更多的关注点放在了CIB配置文件中XML的语句规则上。

因为XML语法的敏感，Pacemaker随之出现了集群shell脚本，python脚本还有基于GUI的工具，然而这些命令并没有完全涵盖在此文档中，恰好因为他们隐藏了XML。

另外要说的就是这篇手册并不是一个手把手教你如何配置一个特定集群系统的文档。尽管可能这类文章将来会写出来，这篇文档的目的是提供建筑的地基，使用它可以构建任何类型的Pacemaker集群。

© 2009, 深夜的蚊子. 版权所有. 如转载，请注明：转载自 蚊子空间[http://www.wenzizone.cn]

 

苦于上次配置heartbeat2.x是遇到的两个问题还没有答案，又加上对于2.x的中文文章比较少，所以，蚊子决定自己来深入学习一下2.x的技术，因为heartbeat版本的更新，所以对于2.x中集群资源管理部分现在起名为pacemake了，我就按照自己的英文程度和理解，把pacemake configuration的英文文档翻译成中文，供大家参考。

强调一点，蚊子英文实在够烂，如有翻译不当的地方，还望高手指出，英文文档下载地址为：

http://clusterlabs.org/mediawiki/images/f/fb/Configuration_Explained.pdf

因为此文档前面部分都是一些简单的介绍，所以这里就先不做翻译了，蚊子先从Configuration Basics部分开始翻译起

基本配置

配置文件的布局

集群配置文件使用XML标记语言而且配置文件被分成了两部分：配置部分和状态监控部分。

状态部分包含了每一个资源在每个节点和建立在数据基础上的历史信息，集群配置可以构建当前完整的集群状态。状态监控部分最可靠的资源就是运行在每个节点上的本地资源管理（lrmd）进程，同时cluster偶尔会进入整个部分。就因为这个，所以这部分是不会写入磁盘的，同时也是坚决不允许管理员修改的。

配置部分包含的更多的是常规的信息，比如cluster选项，资源的列表，哪些资源运行在哪里。在当前文档中配置部分是主要关注的。

配置部分本身就被分成了4部分

Con?guration options (called crm_con?g)
Nodes
Resources
Resource relationships (called constraints)

<cib generated="true" admin_epoch="0" epoch="0" num_updates="0" have-quorum="false">
< configuration>
< crm_config/>
< nodes/>
< resources/>
< constraints/>
< /configuration>
< status/>
< /cib>

一个空的配置

当前集群的状态

在开始配置一个集群之前呢，还是值得解释一下怎么来查看一个完成配置的。为了这个目的，我们创建了一个crm_mon的工具，这个工具可以显示当前激活集群的状态。这个命令可以显示集群的状态按照节点或者资源，同时既可以用在single-shot模式也可以用在dynamically-updating模式。还有另外一种模式用来显示操作执行（按节点和资源分组）后失败信息的列表。

使用这个工具，你可以检查集群状态是否有误同时还可以看到当你引起或者模拟故障的时候的响应信息。

要想获得这个工具提供的更详细的信息可以执行crm_mon --help命令查看。

============
Last updated: Fri Nov 23 15:26:13 2007
Current DC: sles-3 (2298606a-6a8c-499a-9d25-76242f7006ec)
3 Nodes configured.
5 Resources configured.
============
Node: sles-1 (1186dc9a-324d-425a-966e-d757e693dc86): online
Node: sles-2 (02fb99a8-e30e-482f-b3ad-0fb3ce27d088): standby
Node: sles-3 (2298606a-6a8c-499a-9d25-76242f7006ec): online
Resource Group: group-1
192.168.100.181  (heartbeat::ocf:IPaddr):  Started sles-1
192.168.100.182  (heartbeat:IPaddr):    Started sles-1
192.168.100.183  (heartbeat::ocf:IPaddr):  Started sles-1
rsc_sles-1 (heartbeat::ocf:IPaddr):   Started sles-1
rsc_sles-2 (heartbeat::ocf:IPaddr):   Started sles-3
rsc_sles-3 (heartbeat::ocf:IPaddr):   Started sles-3
Clone Set: DoFencing
child_DoFencing:0  (stonith:external/vmware):  Started sles-3
child_DoFencing:1  (stonith:external/vmware):  Stopped
child_DoFencing:2  (stonith:external/vmware):  Started sles-1

crm_mon的输出示例

============
Last updated: Fri Nov 23 15:26:14 2007
Current DC: sles-3 (2298606a-6a8c-499a-9d25-76242f7006ec)
3 Nodes configured.
5 Resources configured.
============
Node: sles-1 (1186dc9a-324d-425a-966e-d757e693dc86): online
192.168.100.181  (heartbeat::ocf:IPaddr):  Started sles-1
192.168.100.182  (heartbeat:IPaddr):    Started sles-1
192.168.100.183  (heartbeat::ocf:IPaddr):  Started sles-1
rsc_sles-1  (heartbeat::ocf:IPaddr):  Started sles-1
child_DoFencing:2  (stonith:external/vmware):  Started sles-1
Node: sles-2 (02fb99a8-e30e-482f-b3ad-0fb3ce27d088): standby
Node: sles-3 (2298606a-6a8c-499a-9d25-76242f7006ec): online
rsc_sles-2  (heartbeat::ocf:IPaddr):  Started sles-3
rsc_sles-3  (heartbeat::ocf:IPaddr):  Started sles-3
child_DoFencing:0  (stonith:external/vmware):  Started sles-3

crm_mon -n的输出示例

DC（指派控制器）节点负责做出决定，而且当当前的DC挂了的时候，一个新的DC就会从其他剩余节点中被推举出来。DC的选择对管理员来讲并不关心，相对于这个来说，更会在意一下生成的日志。

配置文件如何被更新

更新集群配置文件有三个基本的规则

规则1-坚决不要手动编辑cib.xml文件
规则2-再把第一条规则读一遍
规则3-如果你忽略第一和二条规则，集群会提醒你并且拒绝使用配置文件

现在清楚了怎么能不更新配置文件，我们来解释一下你应该怎么做。

最有用的用来调整配置文件的工具就是cibadmin，它可以直接和运行中的集群系统进行通信。使用cibadmin，用户可以对配置文件的任何部分进行查询，添加，删除，更新或者替换，同时所有改变将立刻生效，并不需要执行什么类似reload的操作。

对于我们来讲，最简单的方法就是使用cibadmin工具将当前的配置文件存到一个临时文件中，然后使用任意一个我们熟悉的xml编辑工具对其进行编辑然后上传成修订后的配置文件。

cibadmin --query > tmp.xml
vi tmp.xml
cibadmin --replace --xml-file tmp.xml

一些好的xml编辑器会利用Relax NG schema来帮助用户检查改动是否有效。通常情况下可以在大部分系统的/usr/lib/heartbeat/pacemaker.rng里找到配置文件的schema描述。

如果你需要修改resources部分，你可以这样做

cibadmin --query --obj_type resources > tmp.xml
vi tmp.xml
cibadmin --replace --obj_type resources --xml-file tmp.xml

这样可以避免修改配置文件的其他任何部分。

 

快速删除部分配置文件

找出你希望删除的目标，例如：

 

sles-1:~ # cibadmin -Q | grep stonith
< nvpair id="cib-bootstrap-options-stonith-action" name="stonith-action" value="reboot"/>
< nvpair id="cib-bootstrap-options-stonith-enabled" name="stonith-enabled" value="1"/>
< primitive id="child_DoFencing" class="stonith" type="external/vmware">
< lrm_resource id="child_DoFencing:0" type="external/vmware" class="stonith">
< lrm_resource id="child_DoFencing:0" type="external/vmware" class="stonith">
< lrm_resource id="child_DoFencing:1" type="external/vmware" class="stonith">
< lrm_resource id="child_DoFencing:0" type="external/vmware" class="stonith">
< lrm_resource id="child_DoFencing:2" type="external/vmware" class="stonith">
< lrm_resource id="child_DoFencing:0" type="external/vmware" class="stonith">
< lrm_resource id="child_DoFencing:3" type="external/vmware" class="stonith">

 

接下来找出资源标签和id（在这个例子中是primitve和child_DoFencing）。然后可以简单的执行

cibadmin --delete --crm_xml ‘<primitive id=”child_DoFencing”/>’

不使用XML文件更新配置文件

有些普通的任务可以通过使用高层次的工具来完成，从而避免了读取和编辑xml文件。

拿激活stonith来举例，可以执行

crm_attribute --attr-name stonith-enabled --attr-value true

或者想看看是否哪个节点可以允许运行资源，可以执行

crm_standby --get-value --node-uname somenode

又或者想找出my-test-rsc的当前位置，可以执行

crm_resource --locate --resource my-test-rsc

在沙箱中更改配置文件

经常是被描述为在自动更新配置文件之前预览一遍一系列改变带来的效果。为了这个目的我们创建了crm_shadow命令，这个命令可以创建配置文件的一份“影子”拷贝，同时为所有命令行工具使用做了准备。

在开始，简单引用crm_shadow命令并给一个要创建的配置文件名，接着跟随屏幕上的提示操作。如果不这样做，就会导致你必须更新当前在用的配置文件。

 

c001n01:~ # crm_shadow --create test
Setting up shadow instance
Type Ctrl-D to exit the crm_shadow shell
shadow[test]:

 

创建一个新的沙箱

 

shadow[test] # crm_shadow --which
test

 

查看哪个影子拷贝是激活的

从现在这点开始，所有集群上执行的命令都自动作用在影子拷贝上了，而不会再去修改真实使用的配置。

 

shadow[test] # crm_failcount -G -r rsc_c001n01
name=fail-count-rsc_c001n01 value=0
shadow[test] # crm_standby -v on -n c001n02
shadow[test] # crm_standby -G -n c001n02
name=c001n02 scope=nodes value=on
shadow[test] # cibadmin --erase --force
shadow[test] # cibadmin --query
< cib cib_feature_revision="1" validate-with="pacemaker-1.0" admin_epoch="0" crm_feature_set="3.0" have-
quorum="1" epoch="112" dc-uuid="c001n01" num_updates="1" cib-last-written="Fri Jun 27 12:17:10 2008">
< configuration>
< crm_config/>
< nodes/>
< resources/>
< constraints/>
< /configuration>
< status/>
< /cib>

 

对影子配置进行修改

一旦你完成了实验，你就可以提交你的更高，或者是在影子状态下废除变更。此外请仔细跟随屏幕指示进行操作。

 

shadow[test] # crm_shadow --delete test --force
Now type Ctrl-D to exit the crm_shadow shell
shadow[test] # exit
c001n01:~ # crm_shadow --which
No shadow instance provided
c001n01:~ # cibadmin -Q
< cib cib_feature_revision="1" validate-with="pacemaker-1.0" admin_epoch="0" crm_feature_set="3.0" have-
quorum="1" epoch="110" dc-uuid="c001n01" num_updates="551">
< configuration>
< crm_config>
< cluster_property_set id="cib-bootstrap-options">
< nvpair id="cib-bootstrap-1" name="stonith-enabled" value="1"/>
< nvpair id="cib-bootstrap-2" name="pe-input-series-max" value="30000"/>

 

废除改变同时确认真实配置文件未受损

想要获得crm_shadow的全部选项列表，请不加任何参数执行这个命令。

测试你配置文件的更改

我们前面也看到了如何对配置文件的影子拷贝进行一系列的更改。在把这些变动加载到集群之前（例如：crm_shadow –commit mytest –force），通常来讲使用ptest命令来模拟改变效果是明智的。

ptest --live-check -VVVVV --save-graph tmp.graph --save-dotfile tmp.dot

这个工具使用和真实集群一样的库文件，来显示当活动输入的时候都完成了什么。除了输出外还会有大量重要的日志记录，存储在tmp.graph和tmp.dot这两个文件中，两个都是同一件事情的响应—你的集群系统对于你变更操作的响应。在graph文件中存储着完整的流程，包含了所有功能的列表，还有他们的参数和首要事。正因为流程graph并不是非常容易阅读，所以这工具也生成了一个图形化的dot文件来描述相同的信息。

用图表形式描绘流程graph的一个例子

解释Graphviz输出

箭头指示出命令的依赖关系

虚线箭头表示没有在流程图中出现的依存关系

任意颜色的虚线框的行为没组成流程图的部分

绿色框的行为组成了流程图的部分

红色框的行为是集群中的其中一员可能会执行但还没有被执行的

蓝色框的行为是集群中的其中一员认为没必须要执行的

橘黄色字体的是假的或者假装的行为集群用来简化图表的

黑色字体的行为是发送给LRM的

资源行为由{rsc}_{action}_{interval} {node}文字组成

任何一个依赖于红框里的行为的行为都将不被执行

环形了就太糟糕了，这时请将这种情况报告给开发小组

在上面的例子中，出现了一个新的节点，node2，当node2变成在线状态时，集群检查并确认rsc1，rsc2和rsc3没有在他上执行（*_monitor_0条目表示）。一旦开始执行并假定资源并没有在上面激活，接下来可能会在node1上停止rsc1和rsc2并把它们移到node2上。然后这样会出现一些问题，而且集群可能或者不被允许执行stop操作这就意味着同样不能执行start操作。因为种种原因集群可能不会再任何地方启动rsc3.

想获得ptest能支持的更多参数，请使用ptest –help查看。

另外一个，稍微复杂点的流程图，并不期望着你能读懂

我用不用在所有的集群节点上更新配置文件

回答是否定的，任何的变更都会立刻同步到所有活跃的集群节点上。

为了减少带宽，集群仅仅广播你你更改后的结果的那部分增量更新，同时使用md5值来确保每一份拷贝都是一致的。

未完，下期继续………………

注：蚊子这部分看的有点晕，有些名词把握可能不到位，随着后面学习的深入，可能对理解上会有所帮助，之后review的时候再做调整了。