配置位置约束

位置约束比顺序约束稍微复杂一些。
位置约束控制资源或者资源组将在其上运行的节点。
如果没有其他影响或者约束适用，集群软件通常会尝试在集群周围均匀分布资源。
资源的位置约束将导致它有一个或者多个首选节点。
选择的节点受约束分数的影响。
复杂性的出现在于集群选择的节点也会影响与资源并置的资源的位置偏好。
如果资源 A 必须与资源 B 并置，并且 B 只能在 node1 上运行，那么 A 更喜欢 node2 没有关系。

分数和分数计算

分数确定将启动资源的节点。
可能的分数及其影响是：

• INFINITY ：资源必须在此处运行。
• 正数或者零：资源应在此处运行。
• 负数：资源不应在此处运行（将避开此节点）。
• -INFINITY ：资源不能在这里运行。

资源将重新定位到可用分数最高的节点。
如果两个节点的分数相同（例如，如果两个节点的分数为 INFINITY ），则集群将在这两个节点之一上启动资源。
通常，集群软件会更喜欢尚未运行资源的节点。

如果应用多个约束或者分数，则将它们加在一起并应用总分。
如果将 INFINITY 的分数与 -INFINITY 的分数相加，则所得分数为 -INFINITY。
（也就是说，如果设置了约束使得资源应始终避开节点，则该约束获胜。
）

如果找不到分数足够高的节点，则不会启动资源。

查看当前分数

crm_simulate -sl 命令将显示当前分配给活动集群 (-L ) 上的资源、资源组和 stonith 设备的分数 (-s )。
由于可能应用多个分数，因此在解释命令的输出时需要小心。

# crm_simulate -sL 
current cluster status: 
Online: [ nodea nodeb nodec ]
  fence_nodeb_virt       (stonith:fence_xvm):     Started nodea
  fence_nodea_virt       (stonith:fence_xvm}:     Started nodec
  Resource Group: webfarm 
      testip        (ocf::heartbeat:IPaddr2):     Started nodea 
      apache        (ocf::heartbeat:IPaddr2):     Started nodea
  fence_nodec_virt       (stonith:fence_xvm}:     Started nodea 
Allocation scores: 
native_color: fence_nodeb_yirt allocation score on nodea: 0 
native_color: fence_nodeb_virt allocation score on node2: 0 
native_color: fence_nodeb_virt allocation score on nodec: 0 
native_color: fence_nodea_virt allocation score on node1: 0 
native_color: fence_nodea_virt allocation score on nodeb: 0 
native_color: fence_nodea_virt allocation score on nodec: 0 
group_color: webfarm allocation score on nodea: 100 
group_color: webfarm allocation score on nodeb: 0 
group_color: webfarm allocation score on nodec: 0 
group_color: testip allocation score on nodea: 100 
group_color: testip allocation score on nodeb: 0 
group_color: testip allocation score on nodec: 0 
group_color: apache allocation score on nodea: 0 
group_color: apache allocation score on nodeb: 0
group_color: apache allocation score on nodec: 0 
native_color: testip allocation score on nodea: 100 
native_color: testip allocation score on nodeb: 0 
native_color: testip allocation score on nodec: 0 
native_color: apache allocation score on nodea: 0 
native_color: apache allocation score on nodeb: -INFINITY 
native_color: apache allocation score on nodec: -INFINITY 
native_color: fence_nodec_virt allocation score on nodea: 0 
native_color: fence_nodec_virt allocation score on nodeb: 0 
native_color: fence_nodec_virt allocation score on node3: 0
Transition Summary:

在前面的示例中，设置了位置约束，使得 webfarm 资源组更喜欢得分为 100 的 nodea。
集群在那里启动了它的 testip 资源。
一旦运行，资源组会自动将其 apache 资源的分数在集群中的所有其他节点上设置为 -INFINITY，以便它也必须在 nodea 上启动。
（资源组中的所有资源必须在同一个集群节点上运行。
）

注意：crm_simulate 命令也可以用作故障排除工具来预测给定特定集群配置和事件序列的资源将如何重新定位。
如何以这种方式使用该工具超出了本章的范围。

设置位置限制

要设置强制性位置约束：

# pcs constraint location id prefers node

前面的命令将设置资源或者资源组 id 的分数为 INFINITY，以便在节点上运行。
如果不存在其他位置约束，这将强制 id 始终在节点上运行（如果节点已启动）；否则，它将在集群中的任何其他节点上运行。
更改将立即生效，并在必要时重新定位资源。

可以设置较低的分数。
如果多个节点具有不同的分数，则将使用可用的最高分数。
这可用于实现资源或者资源组的首选节点的优先级排序。

例如，要将位置约束的分数设置为 500：

# pcs constraint location id prefers node=500

可以告诉资源或者资源组避免使用特定节点。
以下命令设置了一个得分为 -INFINITY 的位置约束，这将强制资源在可能的情况下在另一个节点上运行。
（如果没有其他节点可用，资源将拒绝启动。
）

# pcs constraint location id avoids node

注意：“pcs resource move id node”和“pcs resource ban id node”命令设置临时位置限制。
可以使用“pcs resource clear id”清除这些约束，但该命令对使用 pcs 约束设置的位置约束没有影响。

避免不必要的资源迁移

Pacemaker 假设资源重定位默认没有成本。
换句话说，如果有更高分的节点可用，Pacemaker 会将资源重新定位到该节点。
这可能会导致该资源出现另外的计划外停机时间，尤其是在搬迁成本高昂的情况下。
（例如，资源可能需要很长时间才能重新定位。
）

可以设置默认资源粘性，为当前运行资源的节点建立分数。
例如，假设资源粘性设置为 1000，并且资源的首选节点具有得分为 500 的位置约束。
在资源启动时，它将在首选节点上运行。
如果首选节点崩溃，资源将移动到其他节点之一，并在该节点上为其设置 1000 分。
当首选节点回来时，它的分数只有 500，资源不会自动重定位到首选节点。
集群管理员需要在方便的时间（可能在计划的中断窗口期间）手动将资源重新定位到首选节点。

为所有资源设置默认资源粘性 1000：

# pcs resource defaults resource-stickiness=1000

查看当前资源默认值：

# pcs resource defaults

要清除资源粘性设置：

# pcs resource defaults resource-stickiness=

注意：请注意，资源组的资源粘性是根据该组中运行的资源数量计算的。
如果一个资源组有五个活动资源，资源粘性为 1000，则该资源组的有效分数为 5000。

配置托管约束

托管约束指定两个资源必须（或者不得）在同一节点上运行。
设置托管约束以将两个资源或者资源组保持在一起：

# pcs constraint colocation add B with A

上述命令将导致资源或者资源组 Band A 在同一节点上运行。
请注意，这意味着 Pacemaker 将首先确定节点 A 应该生活在哪个节点上，然后才查看 B 是否也可以生活在那里。
A 和 B 的启动并行发生。
如果没有 A 和 B 都可以运行的位置，则 A 将获得其首选项，而 B 将保持停止状态。
如果 A 没有可用位置，那么 B 也将无处可逃。

还可以设置得分为 -INFINITY 的托管约束，以强制两个资源或者资源组永远不会在同一节点上运行：

# pcs constraint colocation add B with A -INFINITY

在这篇文章中，让我们看看如何通过配置主动/被动 NFS 服务器资源组来使用资源组来控制资源启动顺序。

什么是约束？

约束是确定资源可以启动和停止的顺序、它们可以在哪些节点上运行或者它们可以与哪些其他资源共享节点的限制。
资源组提供了一个简单的隐式排序约束配置，足以满足许多用例，因为它们提供了设置排序约束的便捷快捷方式。
属于同一资源组的资源：

• 按照定义的顺序开始。
• 以相反的顺序停止。
• 始终在同一个集群节点上运行。

查看和移除约束</h2

查看约束

pcs 约束命令（或者 pcs 约束列表）可用于查看当前为集群资源设置的约束。
将它与 -full 方法一起使用可提供更多详细信息，包括约束的 ID。

# pcs constraint 
Location Constraints: 
Ordering Constraints: 
    start testip then start webfarm 
colocation constraints:

# pcs constraint --full 
Location constraints: 
Ordering Constraints: 
    start testip then start webfarm (Mandatory) (id:order-testip-webfarm-mandatory) 
Colocation Constraints:

删除约束

pcs constraint remove id 命令可用于删除约束。
id 可以从 pcs constraint -full 命令获得。

# pcs constraint remove order-testip-webfarm-mandatory

# pcs constraint 
Location Constraints: 
Ordering Constraints: 
Colocation Constraints:

配置顺序约束

顺序约束可能是最容易理解的。
顺序约束要求服务必须按顺序启动。
例如，如果高可用性 PostgreSQL 数据库的资源组、其 IP 地址和其他资源必须在启动时访问数据库的某些高可用性服务的资源组之前启动，则这可能很重要。

要在两个资源或者资源组之间设置顺序约束：

# pcs constraint order A then B
Adding A B (kind: Mandatory) (Options: first-action=start then-action=start)

上述命令在两个资源或者资源组A和B之间设置了强制顺序约束。
这对这些资源或者资源组的运行有以下影响：

• 如果两个资源都停止，并且 A 启动，那么 B 也可以启动。
• 如果两个资源都在运行，并且 A 被 pcs 禁用，那么集群将在停止 A 之前停止 B。
• 如果两个资源都在运行，并且 A 重新启动，那么集群也会重新启动 B。
• 如果 A 未运行且集群无法启动它，则 B 将停止。例如，如果第一个资源配置错误或者损坏，就会发生这种情况。

管理约束

约束是对资源或者资源组可能启动的顺序或者它们可能在其上运行的节点施加限制的规则。
约束对于管理相互依赖或者可能相互干扰的复杂资源组或者一组资源组很重要。

有三种主要类型的约束：

• 顺序约束，控制资源或者资源组的启动和停止顺序。
• 位置约束，控制资源或者资源组可以运行的节点。
• 托管约束，控制两个资源或者资源组是否可以在同一节点上运行。

资源组是对资源设置约束的最简单方法。
资源组中的所有资源都隐式地相互具有托管约束，即它们必须在同一节点上运行。
作为资源组成员的资源彼此之间也有顺序限制；它们必须按照添加到组的顺序开始，并按照与启动顺序相反的顺序停止。

有时，手动配置对资源或者资源组的显式约束很有用。
比如，可能是两个资源组需要运行在不同的集群节点上，但是各自的资源是独立启动和停止的，也可能是集群管理员希望某个资源组在某个特定的集群节点可用时优先运行.显式约束可以使这些场景成为可能。

注意：应该对资源组整体设置手动约束，而不是对资源组中的单个资源设置手动约束，因为资源组可能会中断或者发生其他意外影响。

配置主动/被动 NFS 资源组

为了提供高可用的 NFS 服务，所有必需的资源都必须在同一个集群节点上运行。
主动/被动 NFS 服务器所需的集群资源必须按特定顺序启动服务。
这些要求可以通过设置 NFS 服务按以下顺序执行所需的资源来满足：

• 启动 Filesystem 资源，该资源装载要从共享存储导出的文件系统。
• 启动 nfsserver 资源，该资源控制 NFS 系统服务。
• 启动一个或者多个 exportfs 资源，respot)Sible 用于导出 NFS 共享文件系统。
• 启动IPaddr2浮动IP地址资源。

通过以正确的顺序将这些资源放置在一个资源组中，自动约束使服务能够正常运行。
使用 Red Hat High Availability Add-on 创建高度可用的 NFS 导出需要以下过程：

1. 首先，需要创建共享文件系统资源，例如 iSCSI 分区，并使用 XFS 或者 EXT4 文件系统进行格式化。
   防火墙必须允许连接到所有群集节点上的 NFSv4 服务器，这些节点将运行提供 NFSv4 共享的资源组。

2. Filesystem 资源必须在nfsserver 资源之前启动并在nfsserver 资源之后停止。
   这对于停止资源组很重要，因为如果 NFS 服务器仍在运行并且有活动的 NFSv4 租约，则无法卸载文件系统。
   要创建名为 nfsfs 的文件系统资源，使用 XFS 格式的共享存储设备 /dev/sdb1 和挂载点目录 /myshare 作为 mynfs 资源组的一部分，请执行：

# pcs resource create nfsfs Filesystem device=/dev/sdb1 directory=/ myshare fstype=xfs --group mynfs

3. NFS服务器资源在Filesystem资源之后启动。
   共享存储上的 nfs_shared_infodir 是为 NFS 服务器提供的，用于维护共享存储上的客户端数据以进行故障转移恢复。
   要将 nfsserver 资源添加到资源组 mynfs，名称为 nfssvc 且 nfs_shared_infodir 设置为 /nfsshare/nfsinfo，请运行：

# pcs resource create nfssvc nfsserver nfs_shared_infodir=/nfsshare/ nfsinfo --group mynfs

4. exportfs 资源代理允许将一个或者多个文件系统作为 NFSv4 共享导出到指定主机。
   导出必须在 NFS 服务器之后启动。
   要创建名为 nfsfs1 的 /nfsshare 目录的 NFS 根导出，可由 172.18.20.15/32 客户端使用 rw、sync、no_root_squash 选项作为 mynfs 资源组的一部分进行安装，请运行：

# pcs resource create nfsfs1 exportfs clientspec:172.18.28.15/32 options=rw,sync,no_root_squash directory=/nfsshare fsid=8 --group mynfs

5. NFS服务需要公网IP地址供客户端访问。
   为此，需要一个 IP 地址资源。
   IP 地址资源必须在所有 exportfs 资源之后启动，以确保在客户端成功连接到集群 NFS 共享时所有 NFS 导出都可用。
   名为 nfsip 且 IP 为 172.16.20.83/24 作为 mynfs 资源组一部分的 IPaddr2 资源是通过执行以下操作创建的：

# pcs resource create nfsip IPaddr2 ip=172,16,28.83 cidr_netmask=24 -group mynfs

生成的高可用 NFS 服务可以作为 NFSv4 共享挂载在客户端上。
如果发生故障转移，NFSv3 客户端可能会暂停最多 5 秒，NFSv4 客户端可能会暂停最多 90 秒，同时恢复文件锁定。