- What we know
- What we've created
- Hints and Kinks
- Checking Corosync cluster membership
- Configuring radosgw to behave like Amazon S3
- Downgrading to DRBD 8.3
- Fencing in Libvirt/KVM virtualized cluster nodes
- Fencing in VMware virtualized Pacemaker nodes
- GFS2 in Pacemaker (Debian/Ubuntu)
- Interleaving in Pacemaker clones
- Maintenance in active Pacemaker clusters
- Managing cron jobs with Pacemaker
- Mandatory and advisory ordering in Pacemaker
- Migrating virtual machines from block-based storage to RADOS/Ceph
- Network connectivity check in Pacemaker
- OCFS2 in Pacemaker (Debian/Ubuntu)
- Solid-state drives and Ceph OSD journals
- Solve a DRBD split-brain in 4 steps
- Testing Pacemaker clusters
- Totem "Retransmit List" in Corosync
- Turning Ceph RBD Images into SAN Storage Devices
- Which OSD stores a specific RADOS object?
- Presentations
- Ceph Tutorial (LCA 2013)
- Ceph: The Storage Stack for OpenStack (OpenStack Israel 2013)
- Die eigene Cloud mit OpenStack Essex (German, LinuxTag 2012)
- Fencing (LCE 2011)
- GlusterFS in HA Clusters (LCEU 2012)
- GlusterFS und Ceph (German, CeBIT 2012)
- Hands-On With Ceph (LCEU 2012)
- High Availability Update (OpenStack Summit Fall 2012)
- High Availability in OpenStack (CloudOpen 2012)
- High Availability in OpenStack (OpenStack Conference Spring 2012)
- Highly Available Cloud: Pacemaker integration with OpenStack (OSCON 2012)
- Mit OpenStack zur eigenen Cloud (German, CLT 2012)
- Mit OpenStack zur eigenen Cloud (German, OSDC 2012)
- More Reliable, More Resilient, More Redundant (OpenStack Summit April 2013)
- MySQL HA Deep Dive (MySQL Conference 2012)
- MySQL High Availability Deep Dive (PLUK 2012)
- MySQL High Availability Sprint (PLUK 2011)
- OpenStack Essex im Praxistest (German, Linuxwochen Wien 2012)
- OpenStack High Availability Update (Grizzly and Havana)
- Roll Your Own Cloud (LCA 2011)
- Storage Replication in HPHA (LCA 2012)
- Zen of Pacemaker (LCA 2012)
- hastexo in 100 Seconds
- Technical documentation
- News releases
- Hints and Kinks
- What we charge
- What others say

Interleaving in Pacemaker clones
Ever wonder what meta interleave really means in a Pacemaker clone definition? We'll explain.
The interleave meta attribute is only valid on Pacemaker clone definitions – and their extended version of sorts, master/slave sets. It's not available on primitives and groups. Clones are often used in configurations involving cluster filesystems, such as GFS2 (here's an example).
Consider the following example (primitive definitions omitted to keep this short):
clone cl_foo p_foo meta interleave=false clone cl_bar p_bar meta interleave=false order o_foo_before_bar inf: cl_foo cl_bar
What this means is for the order constraint to be fulfilled, all instances of cl_foo must start before any instance of cl_bar can. Often, that's not what you want.
In contrast, consider this:
clone cl_foo p_foo meta interleave=true clone cl_bar p_bar meta interleave=true order o_foo_before_bar inf: cl_foo cl_bar
Here, for each node, as soon as the local instance of cl_foo has started, the corresponding local instance of cl_bar can, too. This is what's usually desired – when in doubt, allow interleaving.
One thing that often throws people is that interleaving only works when Pacemaker is configured to run the same number of instances of two clones on the same node. Thus,
clone cl_foo p_foo\
meta interleave=true \
globally-unique=true clone-node-max=2
clone cl_bar p_bar meta interleave=false
order o_foo_before_bar inf: cl_foo cl_bar... won't work, as Pacemaker is allowed to run 2 instances of cl_foo on the same node, but only one of cl_bar (the default for clone-node-max is 1).
Also, globally-unique=true is a requirement for any clone-node-max>1 – which means that interleaving between a globally-unique and a not globally-unique clone is also not supported.
- Anmelden oder Registrieren um Kommentare zu schreiben
