|
|
7.1 集群资源代理
在Pacemaker高可用集群中，资源就是集群所维护的高可用服务对象。最为简单的资源是原始资源（ Primitive Resource），此外还有相对高级和复杂的资源组（Resource Group )和克隆资源（ Clone Resource )等集群资源概念。在Pacemaker集群中，每一个原始资源都有一个资源代理（ Resource Agent, RA),RA是一个与资源相关的外部脚本程序，该程序抽象了资源本身所提供的服务并向集群呈现一致的视图以供集群对该资源进行操作控制。通过RA，几乎任何应用程序都可以成为Pacemaker集群的资源从而被集群资源管理器和控制。集群资源管理器无需知道资源具体的工作逻辑和原理( RA已将其封装)，资源管理器只需向RA发出Start、Stop、Monitor等命令，RA便会执行相应的操作。从资源管理器对资源的控制过程来看，集群对资源的管理完全依赖于该资源所提供的RA，即资源的RA脚本功能直接决定了资源管理器可以对该资源进行何种控制，因此一个功能完善的RA 在发行之前必须经过充分的功能测试。在多数情况下，资源RA以shell 脚本的形式提供。
在Pacemaker集群中，资源管理器支持不同种类的资源代理，这些受支持的资源代理包括OCF, LSB、Upstart 、Systemd、Service、Fencing、Nagios Plugins 。而在Linux系统中，最为常见的有OCF(Open Cluster Framework)资源代理LSB(Linux Standard Base)资源代理、Systemd和Service资源代理。
(1)OCF
OCF（open Cluster Framework）是开放式集群框架的简称，从本质上来看，OCF标准其实是对LSB标准约定中init 脚本的一种延伸和扩展。在OCF脚本发行使用之前一定要经过充分的功能测试，否则有问题的OCF脚本将会扰乱整个集群的资源管理。在Pacemaker集群中，OCF作为一种可以自我描述和高度灵活的行业标准，其已经成为使用最多的资源类别。
(2)LSB
LSB是最为传统的Linux资源标准之一，例如在Redhat 的RHEL6 及其以下版本中（或者对应的CentOS版本中），经常在/etc/init.d目录下看到的资源启动脚本便是LSB标准的资源控制脚本。通常， LSB类型的脚本是由操作系统的发行版本提供的。
(3)Systemd
在很多Linux 的最新发行版本中， Systemd被用以替换传统“ SysV ”风格的系统启动初始化进程和脚本，如在Redhat的阳EL7 和对应的Cent0S7 操作系统中， Systemd 已经完全替代了Sysvinit 启动系统，同时Systemd 提供了与Sysvinit以及LSB风格脚本兼容的特性，因此老旧系统中已经存在的服务和进程元需修改便可使用Systemd。在Systemd中，服务不再是/etc/init.d 目录下的shell 脚本，而是一个单元文件(unit-file) , Systemd通过单元文件来启停和控制服务，Pacemaker提供了管理Systemd 类型的应用服务的功能。
(4)Service
由于系统中存在各种类型的服务（如LSB、System 和OCF), Pacemaker使用服务别名的方式自动识别在指定的集群节点上应该使用哪一种类型的服务。当一个集群中混合有Systemd, LSB 和OCF 类型资源的时候， Sevice类型的资源代理别名就变得非常有用，例如在存在多种资源类别的情况下，Pacemaker将会自动按照LSB、Systemd、Upstart的顺序来查找启动资源的脚本。
在Pacemaker中，每个资源都具有属性，资源属性决定了该资源RA 脚本的位置， 以及该资源隶属于哪种资源标准。例如，在某些情况下，用户可能会在同一系统中安装不同版本或者不同来源的同一服务（如相同的RabbitMQ Cluster安装程序可能来自RabbitMQ官方社区也可能来自Redhat 提供的RabbitMQ安装包），在这个时候，就会存在同一服务对应多个版本资源的情况，为了区分不同来源的资源，就需要在定义集群资源的时候通过资源属性来指定具体使用哪个资源。在Pacemaker 集群中，资源属性由以下几个部分构成。
- Resource id:用:户定义的资源名称。
- Standard:脚本遵循的标准，允许值为OCF, Service、Upstart、Systemd 、LSB、Stonith
- Type:资源代理的名称，如常见的IPaddr 便是资源的Type 。
- Provider :OCF 规范允许多个供应商提供同一资源代理， Provide 即是指资源脚本的提供者，大多数OCF 规范提供的资源代理均使用Heartbeat 作为Provider 。
例如要在集群中创建一个名称为neutron-ovs-cleanup 的资源（resource_ id 属性），并指定资源的RA符合OCF 规范（standard 属性)，该RA由OpenStack的Neutron 组件提供（Provider 属性）， RA 的名称为OVS_Cleanup (Type属性），通过PCS 命令行工具的Resource 命令来创建资源，则最终的资源定义语句如下：
pcs resource create neutron-ovs-cleanup ocf :neutron:OVSCleanup --clone\ interleave=true
通过上述语句定义资源后，集群资源管理器将根据Standard、Provider以及Type属性信息对neutron-ovs-cleanup资源、对应的RA脚本位置进行定位，在RHEL或者Centos系统中，软件安装完成后，符合OCF规范的RA脚本均位于/usr/lib/ocf/resource.d 目录中。例如，在成功安装OpenStack的Neutron组件后，便可以到该目录下找到Type 为OVS Cleanup的RA 脚本。
该目录下存放了全部的Providers，每个Provider 目录下会有多个Types。在该示例中，/usr/lib/ocf/resource.d目录有5 个子目录，每个子目录均是一个Provider，其中有名为
neutron的Provider，该Provider中有如下的Type:
可以看到，/usr/lib/ocf/resource.d/neutron目录下有3个可执行文件，每一个就是一个Type（即RA 脚本的名称），在此，除了OVSCleanup外， neutron这个Provider 还提供了NeutronScale h和NetnsCleanup两个Type 。在创建neutron-ovs-cleanup资源的过程中，定义资源属性的语句段是ocf:neutron:OVSCleanup ( standard:provider:type ）通过该信息，集群资源管理器便可定位资源RA脚本的最终位置，并使用该脚本来控制资源。资源属性的查看可以通过pcs 命令行工具实现，最常使用的资源属性查看方式有以下几种：
pcs resource list ：查看集群中所有可用资源列表。
pcs resource standards ：查看支持的资源代理标准。
pcs resource providers ：查看集群中可用资源代理提供程序列表。
pcs resource list string ：查看根据指定字符串过滤的可用资源列表，可使用这个命令根据名称、提供程序或类型过滤资源。
pcs resource describe standard:provider:type ：查看standard:provider:type指定的资源代理的详细信息。
如下示例演示了集群资源属性的查看方式及结果，示例环境为CentOS7系统，系统中已经安装有OpenStack 相关的软件包和Pacemaker集群软件：
从示例输出中可以看到，当前集群支持的规范包括OCF, LSB 、Service 、Systemd和Stonith ，而集群中的Provides 包括Heartbeat、Neutron、Openstack、Pacemaker、RabbitMQ等，符合OCF规范的Heartbeat资源代理供应程序提供了包括MySQL、RabbitMQ-Cluster、1Paddr2和Filesystem等资源代理。其中，OpenStack这个Provider提供了符合OCF和Systemd两种规范的资源代理，这些资源代理是OpenStack高可用集群部署的基础，Pacemaker 集群将通过这些资源代理对OpenStack 服务进行控制。在众多资源代理中，用户可能想要了解某个资源代理的具体信息和使用方法，例如要了解NovaCompute资源代理的介绍和使用参数等信息，则可以通过如下命令实现：pcs resource describe ocf:openstack:novaCompute
由于不同的规范和Provider可以提供相同名称的资掠代理，因此在一个集群系统中可能包含有多个同名的资源代理，如下：
在Pacemaker集群中，要获取同名资源代理的绝对路径，可以通过如下方式实现
此外，多数OCF规范的资源代理都有资源选项(Resource Options) 和(元数据选项 Meta) ，资源选项即是可以传递给该资源代理的参数，Resource Options和Meta可以在创建资源时指定，也可以在资源创建完成后进行修改，创建带有Resource Options 和Meta 选项资源的语法如下：
pcs resource create resource_id standard:provider: type I type [resource options] [meta meta_options ... ]
如下命令在集群中创建一个名为vip-qpid 的资源， 并在资源选项中设定了该资源的IP地址和子网掩码，同时指定元数据Resource-Stickiness 的值为50:
pcs resource create vip-qpid ocf: heartbeat: IPaddr2 ip= 192 .168. 0 .12 0 cidr-netmask=
24 meta resource-stickiness=50
元数据Resource-Stickiness表示资源的粘性，即资源倾向于当前状态的程度。如果资源已经创建完成，因为系统参数调整而要修改资源参数，例如集群中已经存在资源vipqpid，现要修改资源的IP 地址和Resource-Stickiness 的值，则可以通过如下命令实现：
在Pacemaker集群中，另一个常见的与资源管理相关的操作，就是重置资源状态并清除资源失败计数器，资源状态重置后，将会触发集群重新启动资源，这对于重新启动因处于失败状态而失去资源管理器控制的资源很有用，重置资源状态的语法如下：
pcs resource cleanup resource_id
如果在命令中没有指定Resource id ，则这个命令会对集群中全部的资源进行状态重置和失败计数器清零，并且按照资源的启动依赖关系重新启动集群的全部资源，在集群资源管理中，在需要重启全部集群资源时，经常使用该方法。
7.2 集群资源约束
Pacemaker 集群中的资源约束可以分为以下几类:
- 位置约束(Location)：位置约束限定了资源应该在哪个集群节点上启动运行。
- 顺序约束(Order)：顺序约束限定了资源之间的启动顺序。
- 资源捆绑约束(Colocation)：捆绑约束将不同的资源捆绑在一起作为一个逻辑整体，即资源A位于C节点，则资源B 也必须位于C节点，并且资源A 、B将会同时进行故障切换到相同的节点上。
在Openstack高可用集群配置中，我们希望Nova-Compute资源仅运行在计算节点上，而Nova-api和Neutron-sever等资源仅运行在控制节点上，这时便可通过资源的Location约束来实现。例如，我们先给每一个节点设置不同的osprole 属性（属性名称可自定义），计算节点中该值设为compute ，控制节点中该值设为controller ，如下：
pcs property set --node compute1 osprole=compute
pcs property set --node co mpute2 osprole=compute
pcs property set --node controller1-vm osprole=controller
pcs property set --node controller2-vm osprole=controller
pcs property set --node controller3-vm osprole=controller
然后， 通过为资源设置Location 约束，便可将Nova-Compute资源仅限制在计算节点上运行,Location 约束的设置命令如下：
pcs constraint location nova-compute-clone rule\ resource-discovery=exclusive score=0 osprole eq compute
即资源Nova-Compute-Clone仅会在osprole 等于compute的节点上运行，也即计算节点上运行。
Pacemaker集群中解决资源启动依赖的方案便是Order约束。例如，在OpenStack的网络服Neutron配置中，与Neutron相关的资源启动顺序应该如下： Keystone-->Neutron-server-->Neutron-ovs-cleanup-->Neutron-netns-cleanup-->Neutron-openvswitch-agent->Neutron-dhcp-agent -->Nutron-l3-agent ,上述依赖关系可以通过如下Order 约束实现：
pcs constraint order start keystone-clone then neutron-server-api-clone
pcs constraint order start neutron-server-api-clone then neutron-ovs-cleanup clone
pcs constraint order start neutron-ovs-cleanup -clone then neutron-netns cleanup-clone
pcs constraint order start neutron-netns-cleanup-clone then neutron-openvswitch-agent-clone
pcs constraint order start neutron-openvswitch agent-clone then neutron-dhcp-agent-clone
pcs constraint order start neutron-dhcp-agent-clone then neutron-13-agent-clone
pcs constraint order start neutron-13-agent-clone then neutron-metadata-agent-clone
Colocation约束主要用于根据资源A的节点位置来决定资源B 的位置， 即在启动资源B的时候，会依赖资源A的节点位置。在OpenStack高可用集群配置中，通常需要将Libvirtd-compute与Neutron-openvswitch-agent进行资源捆绑， 要将Nova-compute与Libvirtd-compute进行资源捆绑，则Colocation 约束的配置如下：
pcs constraint colocation add nova-compute-clone with libvirtd-compute-clone
pcs constraint colocation add libvirtd-compute-clone with neutron-openvswitchagent-clone
7.3 集群资源类型
集群资源类型包括：资源组、资源克隆、资源多态。
(1)资源组
在Pacemaker集群中，经常需要将多个资源作为一个资源组进行统一操作，例如将多个相关资源全部位于某个节点或者同时切换到另外的节点，并且要求这些资源按照一定的先后顺序启动，然后以相反的顺序停止，为了简化同时对多个资源进行配置， Pacemaker提供了高级资源类型一一资源组。
资源组的常用命令：
在Pacemaker集群中，资源组所包含的资源数目是不受限的，资源组中的资源具有如下的基本特性：
- 资源按照其指定的先后顺序启动，如在前面示例的MyGroup资源组中，首先启动IPaddr ，然后启HAproxy 。
- 资源按照其指定顺序的相反顺序停止，如首先停止HA proxy ，然后停止IPaddr。
- 如果资源组中的某个资源无法在任何节点启动运行，那么在该资源后指定的任何资源都将无法运行，如IPaddr不能启动，则HAproxy也不能启动。
- 资源组中后指定资源不影响前指定资源的运行，如HA proxy不能运行，但IPaddr却可以正常运行。
以下是资源属性中比较重要的几个属性及其默认值。
- Priority ：资源优先级，其默认值是0 ，如果集群无法保证所有资源都处于运行状态，则低优先权资源会被停止，以便让高优先权资源保持运行状态。
- Target-role ：资源目标角色，其默认值是Started，表示集群应该让这个资源处于何种状态，允许值为：
- Stopped ：表示强制资源停止；
- Started ：表示允许资源启动，但是在多状态资源的情况下不能将其提升为Master资源；
- Master ：允许资源启动，并在适当时将其提升为Master 。
- is-managed ：其默认值是true，表示是否允许集群启动和停止该资源， false表示不允许。
- Resource-stickiness ：默认值是0，表示该资源保留在原有位置节点的倾向程度值。
- Requires ：默认值为fencing，表示资源在什么条件下允许启动。
(2)资源克隆
只有已经规划为可以运行在Active/Active高可用模式的资源才能在集群中配置为克隆资源。
(3)资源多态
7.4 集群资源规则
资源规则（ Rule ）使得Pacemaker集群资源具备了更强的动态调节能力，资源规则最常见的使用方式就是在集群资源运行时设置一个合理的粘性值（ Resource-stickness ），以防止资源、回切到资源创建之初指定的高优先级节点上，即动态改变资源粘性值以防止资源意外回切。资源规则的另一重要作用就是通过设置节点属性，将多个具有某一相同属性值的物理节点聚合到一个逻辑组中，然后通过资源的Location约束，利用节点组的这个共有节点属性值，将资源限制在该节点组上运行（openstack主要使用的这一条规则）。如下配置命令将计算节点和控制节点分别设置为不同的节点属性：
pcs property set --node compute osprole=compute
pcs property set --node compute2 osprole=compute
pcs property set --node controller1-vm osprole=controller
pcs property set --node controller2-vm osprole=controller
pcs property set --node controller3-vm osprole=controller
此处通过为节点分别设置不同的osprole属性值，将节点划分为两个集合，即计算节点组和控制节点组，将节点compute1和compte2 归纳到compute节点组，节点controller1-vm、controller2-vm 以及controller3-vm归纳到controller 节点组，然后通过资源的Location约束将资源限制到不同的节点组中运行，配置命令如下：
pcs constraint location nova-compute-clone rule resource-discovery=exclusive score=0.osprole eq compute
pcs constraint location nova-api-clone rule resource discovery=exclusive score=0 osprole eq controller
在上述命令中，当Rule表达式“ osprole=compute ”或者“ osprole=controller ”成立，即Rule为True ，则执行对应资源的Location约束。此处，通过资源Location 约束的“ resource-discovery= exclusive ”配置，资源、nova-compute-clone只能运行在compute节点组中， 而compute组中只有compute1和compute2节点，因此nova-compute-clone只能在compute1和compute2上运行，绝不会在controller1-vm 、controller2-vm及controller3-vm 上运行。同样，nova-api-clone资源只会在controller组中的三个节点上运行。绝不会在compute1和compute2 节点上运行。
资源Rule的表达式主要分为节点属性表达式和时间/日期表达式，节点属性表达式由以下几个部分组成。
- Value ：用户提供的用于同节点属性值进行比较的值。
- Attribute ：节点属性变量名，其值即是Value要匹配的节点属性值。
- Type ：确定使用哪种类型的值匹配，允许的值包括字符串、整数、版本号（ Version ） 。
- Operation ：操作符，确定用户提供的Valu巳与节点Attribute 的值如何匹配，主要包括以下几种操作符。
- It ：如果Value小于Attribute的值，表达式为正True;
- gt ：如果Value大于Attribute的值，表达式为正True;
- lte ：如果Value小于等于Attribute的值，表达式为正True;
- gte ：如果Value大于等于Attribute的值， 表达式为正True;
- eq ：如果Value等于Attribute 的值，表达式为正True;
- ne ：如果Value不等于Attribute 的值，表达式为正True; .
- defined ：如果表达式中的Attribute在节点中有定义，则表达式为True;
- not defined ：如果节点中没有定义表达式中的Attribute ，则表达式为True。
要通过Rule 的节点属性表达式来确定资源的Location，则通常的命令语法如下：
pcs resource constraint location resource_id rule [rule_id] [role=master|Islave] [score=score expression]
此处的表达式可以是以下几种形式：
- Ddefined|not_ defined attribute
- attribute lt|gt|lte|gte|eq|ne value
- date [start=start] [end=end] operation=gt!Itlin-range
- date-spec date_ spec_ options
在OpenStack 高可用集群配置中，使用最多的是第二种形式的表达式，例如要限制Nova-compute服务仅运行在计算节点上，则可以通过如下Rule 和Location 配置实现：
pcs constraint location nova-compute-clone rule resource-discovery=exclusive score=0 osprole eq compute
上述命令中，“ osprole eq compute”即是Rule的表达式，其中osprole是节点的Attribute, Compute 是用户指定的节点属性值（value），该表达式的操作符是等于符号（eq ）。该命令语句中的规则表达式的意思就是，当节点的osprole 值等于用户指定值（ compute ）的时候，则Rule表达式为True （计算节点属性中已经预先设置了osprole 属性值为compute）。
|
|
|
QQ群⑧：
窥视卡
雷达卡
发表于 2018-2-6 17:32:34
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡