LPIC-3 High Availability and Storage Clusters common mistakes
LPIC-3 High Availability and Storage Clusters · Understand the traps and how to avoid them.
Building a Pacemaker resource stack and immediately testing failover without ever defining a fencing device - either leaving stonith-enabled at its default while no stonith resource exists, or quietly setting stonith-enabled=false to make resources start.
In a two-VM lab, fencing looks like an optional extra, and candidates panic when the cluster refuses to start resources and 'fix' it by disabling stonith instead of understanding why the cluster insists on it. They then design answers around a cluster that can never safely recover from a split brain.
What to do instead
Create a real fence device (fence_ipmilan, fence_redfish, fence_mpath, fence_virtd for labs) and keep stonith-enabled=true. Verify with 'pcs stonith status' and 'pcs stonith config', then prove the path end to end with 'stonith_admin --reboot ' outside production hours. If you must disable stonith for a lab, document that no-quorum-policy must not be left at 'ignore' at the same time.
Leaving a two-node cluster at default quorum behaviour, then expecting resources to start on the surviving node after the peer is powered off.
Votequorum needs a majority; with two nodes the survivor holds 50% of votes, quorum is lost, and the default no-quorum-policy stops resources. Candidates misread this as a resource-agent bug or a DRBD problem and start changing unrelated configuration.
What to do instead
For an intentional two-node design, run 'pcs quorum update wait_for_all=1' and 'pcs property set no-quorum-policy=ignore' only together with working fencing, or add a qdevice/third vote. Confirm the expected state before testing: 'corosync-quorumtool -s' should show Quorum: 1 or explicit wait_for_all behaviour, and 'pcs quorum config' should match the design.
Reading colocation and ordering constraints as if both used 'start first, then second': issuing 'pcs constraint colocation add db with web' when the intent was for the web server to follow the database.
The CLI is left-to-right and the words 'with' and 'then' feel symmetric, so the dependent resource is silently reversed. The cluster is perfectly happy - it just schedules the wrong resource, and the error surfaces only during failover tests.
What to do instead
Anchor the semantics: in 'colocation add with ' the first resource must run where the second runs; in 'order then ' the first starts first. After writing constraints, dump 'pcs constraint --full' and simulate placement and ordering with 'crm_simulate -sL' before touching live nodes.
Promoting the DRBD device by hand with 'drbdadm primary r0' on a node while Pacemaker is supposed to own it via a promotable clone, or creating the DRBD resource as a plain clone instead of '--promotable clone'.
Candidates learn DRBD 8/9 manual operation first, and manual promotion appears to 'fix' a resource that has not been promoted because the clone lacks the promotable flag or the monitor operations use the wrong role naming (Master/Slave versus Promoted/Unpromoted).
What to do instead
Never run drbdadm primary/setup while the resource is under cluster control; use 'drbdadm secondary', then 'drbdadm down', and clear the fail count. Define the agent as 'ocf:linbit:drbd drbd_resource=' with 'op monitor interval=15s role=Promoted' and 'op monitor interval=30s role=Unpromoted', then add '--promotable clone'. Check 'drbdadm role' and 'drbdsetup status' agree with 'pcs status'.
Creating an LVM volume group directly on a shared SAN/iSCSI device and activating it on both cluster nodes at once, assuming LVM handles concurrency.
Plain LVM metadata is not cluster-aware; concurrent activation corrupts the VG. Candidates see identical pvscan output on both nodes and conclude the storage is shared and therefore safe, instead of treating LVM as single-writer.
What to do instead
Choose one supported model and label it explicitly: HA-LVM (volume_list filtering plus tagging and 'lvmetad'/'lvmlocal' restriction) so only the active node activates it; or shared LVM with lvmlockd using sanlock or dlm, creating VGs with 'vgcreate --shared'. Verify with 'lvm lvs -o+lv_active' on both nodes and ensure the locking daemon is running before activation.
Configuring fence_mpath for multipathed storage without setting reservation_key in the multipath defaults, or setting it differently in multipath.conf and in the stonith device.
Fencing a multipath LUN depends on SCSI-3 persistent reservations, and the key must match what mpathpersist registers and what the fence agent issues. Candidates assume 'multipathd is up' is enough, and the fence action times out or fences the wrong node.
What to do instead
Put 'reservation_key ' in the defaults section (and 'reservation_key' per device if needed) of /etc/multipath.conf, reload with 'systemctl reload multipathd' / 'multipath -r', then register keys via a device 'reserve' action and confirm with 'mpathpersist --showkeys -k'. Point the stonith device at the correct WWID ('pcs stonith create ... fence_mpath pcmk_host_map=:').
Mapping a Ceph RBD image on two cluster nodes and mounting a normal filesystem such as ext4 on it, treating an RBD image as a shared disk.
RBD looks like a block device and reads as 'distributed storage', so the mental model jumps to 'the data is replicated, so both nodes can use it'. The result is silent filesystem corruption and excluded/wrong lock states.
What to do instead
An RBD image is a single-writer block device: either use the ocf:ceph:rbd resource agent so Pacemaker maps it on exactly one node (the agent handles exclusive-lock), or format it with a cluster-aware filesystem (GFS2 via lvmlockd/dlm) if concurrent access is required. For shared files, use CephFS, not raw RBD.
Debugging a CephFS deployment by restarting monitors and OSDs when the real symptom is that 'ceph fs status' shows no active MDS, or creating a filesystem without confirming metadata and data pools exist.
The exam covers 'distributed storage' broadly and candidates over-index on the monitor quorum they just learned, skipping the per-service status output and the fact that CephFS is served by MDS daemons (with standbys for failover) while RBD is not.
What to do instead
Always read 'ceph -s' and then the service-specific view: 'ceph fs status ' for MDS state and active/standby assignment, 'ceph osd tree' and 'ceph pg stat' for placement. Create with 'ceph fs new ' and ensure at least one active and one standby MDS, or standby_count_wanted stays negative.
Converting the root filesystem to an mdadm mirror, writing /etc/mdadm.conf, and rebooting - without regenerating the initramfs or reinstalling grub on every member disk, and without ever booting in degraded mode.
The array works while running, so the job looks done; the assembly information lives in the initramfs, not only in /etc/mdadm.conf, and the bootloader on the first disk knows nothing about the second. The failure appears months later as an unbootable host.
What to do instead
Regenerate the initramfs ('update-initramfs -u' or 'dracut -f' / 'mkinitrd') after 'mdadm --detail --scan >> /etc/mdadm.conf', install the bootloader on each member ('grub-install /dev/sdX'), and on Debian/Ubuntu enable degraded boot (BOOT_DEGRADED=true in /etc/initramfs-tools/conf.d/mdadm). Then prove it: fail and remove one member, reboot, confirm the system starts, then re-add and watch the rebuild finish.
Configuring a link-aggregation bond (especially 802.3ad/LACP or balance-rr) purely in the node's network configuration and declaring the node redundant without configuring the matching switch port-channel or testing a single-link failure.
The bond comes up and pings work over whichever single link the hash selects, so the configuration appears correct; only a downed member or an unconfigured LACP partner reveals that traffic stops or that the hash never used the second link.
What to do instead
Match the switch configuration to the mode (LACP port-channel for 802.3ad, single switch for balance-rr and avoid it), set 'miimon' and 'lacp_rate' explicitly, then verify with 'cat /proc/net/bonding/bond0' showing both slaves up and the correct aggregator. Test by administratively downing each slave in turn and confirming continuous connectivity, and repeat after reboot so a NetworkManager/wicked profile does not silently drop the bond.