在高可用集群管理中，资源约束直接决定了服务能否稳定对外提供能力。顺序位置与colocation是两类基础但极易混淆的约束：前者控制资源启动和停止的先后，后者控制资源是否必须或尽量运行在同一节点。只有把两者结合起来理解，才能搭建出符合业务依赖关系的集群。
什么是顺序位置与colocation约束
顺序位置约束（order constraint）规定了资源之间的先后动作关系。例如必须先启动存储资源，再启动数据库，最后启动前端应用。若颠倒顺序，应用可能因连不上库而报错退出。在Pacemaker中，这类约束通过pcs constraint order命令定义，可指定score为Mandatory或Optional。
colocation约束（colocation constraint）则描述资源的位置共处关系。比如要求Web服务与缓存服务始终在同一节点，或尽量不在同一节点以分散风险。它并不管启动顺序，只管落点。很多人误以为写了colocation就会自动按顺序拉起，其实二者职责完全不同，需要分别声明。
为何顺序与位置必须配合
假设有资源A（数据库）和资源B（应用），B强依赖A的数据接口。若只配colocation让AB同节点，但没配order，集群可能同时拉起AB，B先起就会连接失败。反之只配order不配colocation，B虽晚起但可能被分到其他节点，跨节点访问增加延迟和故障点。
实际生产中，正确做法是同时建立order A then B，以及colocation B with A。这样集群先在本节点起A，A健康后再起同节点B，既满足依赖又保持邻近。如下表格列出常见组合效果：
| 约束组合 | 启动表现 | 风险 |
|---|---|---|
| 仅order | 按序起但可能异节点 | 跨节点调用不稳定 |
| 仅colocation | 同节点但可能同时起 | 依赖未就绪报错 |
| order+colocation | 同节点且按序起 | 基本无 |
配置示例与参数要点
以Pacemaker为例，建立顺序约束可使用：pcs constraint order start A then start B。建立同址约束使用：pcs constraint colocation add B with A score=INFINITY。score为INFINITY表示必须同节点，若写100则表示倾向同节点但可被其他策略覆盖。
需要注意，colocation的with方向很关键。写B with A意味着B跟随A的位置，A在哪B去哪；若反过来写A with B，则调度以B为锚点。在多层依赖里，应让上层应用跟随底层服务，避免锚点漂移导致整体布局混乱。同时order也分then和then-stopped，停止时顺序通常反转，要显式声明。
常见误区与排查方法
一个典型误区是认为colocation会自动隐含顺序。某客户集群中，MySQL与Tomcat设了colocation，但Tomcat偶尔启动失败。查日志发现Tomcat早于MySQL监听端口。补充order约束后故障消失。这说明位置亲近不等于时间有序。
另一误区是滥用INFINITY score造成环路。如A colocation with B，B colocation with C，C又colocation with A，集群无法判定锚点会报约束冲突。排查时用pcs constraint list查看全量约束，用crm_simulate推演分配，能快速定位环路与矛盾设置。
总结建议
配置集群资源约束时，先画业务依赖图：底层资源有哪些，上层谁依赖谁。据此写出order链条，再补colocation让依赖方同址。每次改动后通过集群状态命令观察实际分配与起停顺序，逐步调score。
把顺序位置与colocation当作互补工具而非二选一，才能减少误判。当资源规模增长，还可引入resource group将相关约束打包，降低手动维护成本，但底层逻辑仍是本文所述的顺序与同址配合原则。
集群资源约束顺序位置colocation修改时间：2026-08-10 22:33:15