8. Real-world example: annotated OpenStack controller CIB¶
This is a genuine cibadmin --query dump from a 3-node TripleO-style OpenStack
controller cluster (tripleo_cluster), included here because it's a good worked
example of most of the concepts above in one place.
Cluster identity & properties:
<nvpair name="cluster-infrastructure" value="corosync"/>
<nvpair name="cluster-name" value="tripleo_cluster"/>
<nvpair name="stonith-enabled" value="false"/>
Note stonith-enabled=false — fine for a lab/test TripleO deployment, not what
you'd want in production (see §5).
Resources present, and what they're for:
| Resource | Type | Purpose |
|---|---|---|
ip-172.17.4.18, ip-172.17.3.17, ip-192.168.24.12, ip-172.17.1.16, ip-10.0.0.101, ip-172.17.1.11 |
ocf:heartbeat:IPaddr2 |
One VIP per OpenStack network/endpoint (public, internal API, storage, tenant, management). |
haproxy-clone |
systemd:haproxy, cloned |
Runs HAProxy on all 3 controllers; the VIPs are colocated with it so whichever node holds the VIP is also running the proxy. |
galera-master |
ocf:heartbeat:galera, multistate (master-max=3) |
Galera synchronous MySQL cluster — all 3 nodes run as Galera masters simultaneously (this is Galera's own multi-master replication, distinct from Pacemaker's promote/demote semantics used for asymmetric master/slave resources). wsrep_cluster_address lists all 3 controllers. |
rabbitmq-clone |
ocf:heartbeat:rabbitmq-cluster, cloned, ordered=true |
RabbitMQ cluster with an ha-all policy mirroring all non-amq.* queues to every node. |
redis-master |
ocf:heartbeat:redis, multistate |
Redis in classic primary/replica mode — genuine promote/demote here, unlike Galera. |
openstack-cinder-volume |
systemd:openstack-cinder-volume |
Historically active/passive (only one instance should run) — this is the pattern referenced in the OpenStack/OpenShift guide as the reason Cinder-volume needed Pacemaker at all pre-container-native deployments. |
Constraints: every VIP has an INFINITY colocation with haproxy-clone (the
proxy must run wherever its VIP is) and an Optional-kind ordering constraint (VIP
starts, then HAProxy — but it's advisory, not blocking, hence kind="Optional"
rather than Mandatory).
rsc_defaults: resource-stickiness=INFINITY — once a resource is running
somewhere, Pacemaker will never move it purely for "balance"; it only moves on an
actual failure or an explicit pcs resource move. This is the right default for
anything where failover itself (not rebalancing) is the goal.
This maps directly onto the more general "Corosync manages OpenStack infrastructure" material — this file is a concrete instance of exactly that pattern.