The RHEL Resilient Storage add on, read at the cluster edge.

The Red Hat Resilient Storage add on is the supported delivery of the clustered file system stack that sits on top of the Pacemaker and Corosync cluster manager. The add on covers GFS2 as the file system, the clustered logical volume manager that arbitrates shared volume groups across nodes, and the fencing agents that protect data integrity when a node misbehaves. The add on is sold as a separate line on top of the base RHEL subscription, priced per host on the same socket pair or virtual host counting as the base, and is required on every host that mounts the clustered file system or imports the clustered volume group.1

The structural relationship to the High Availability add on is the single most important fact for the buyer side reading. Resilient Storage includes the entire High Availability stack and extends it; a host carrying Resilient Storage does not need a parallel High Availability line, and a host carrying both lines is paying twice for the same Pacemaker and Corosync coverage. The pricing is therefore additive on the catalogue but subtractive in the entitlement register; the renewal cycle is where the buyer captures the difference. The High Availability reading sits in the parallel note on the High Availability add on.

The audit ready artifact for the Resilient Storage reading is the list of hosts that mount a GFS2 file system or that import a clustered volume group. The list is short to produce on a healthy estate and uncomfortable to produce on an estate where the cluster topology has evolved unevenly. The same artifact is read against the entitlement register, against the renewal line catalogue, and against the broader cluster member list maintained by the High Availability assessment. The reading is internally consistent when the three lists reconcile to the same host inventory.

Three counting traps recur on Resilient Storage readings. Each is structural; each has a remediation that fits inside a single renewal cycle.

The first trap is the double line. A host carries both a High Availability add on and a Resilient Storage add on in the procurement register. The double line frequently arose when GFS2 was added to an existing failover cluster and the procurement team purchased the add on as a fresh line rather than as a conversion from the existing High Availability entitlement. The reading is overpayment, not exposure; the remediation is to retire the High Availability line at the next renewal and to carry only the Resilient Storage line on the host going forward.

The second trap is the unentitled GFS2 mount. A host mounts a GFS2 file system; the procurement register carries only a High Availability add on, or no add on at all, for the host. The mount frequently arrived through a database tier expansion that the engineering team executed during a maintenance window and that the procurement cycle did not see. The audit reading is unentitled Resilient Storage for the period of GFS2 operation. The remediation is to attach the Resilient Storage line, retire the High Availability line, and add the mount to the cluster member list of record.2

The third trap is the retired file system. A buyer migrated off GFS2 to a different shared storage architecture; the host no longer mounts the clustered file system; the procurement register continues to renew the Resilient Storage add on at each cycle. The reading is overpayment, not exposure. The remediation is to retire the Resilient Storage line at the next renewal and to attach a High Availability add on if the host remains a failover cluster member, or to retire both add ons if the host has fully exited the cluster. The pattern overlaps with the broader treatment in phantom entitlements and the recoverable cost reading in over entitlement that is recoverable.

Three cluster topologies determine the right add on line for a given host. The buyer side reading begins with the topology and ends with the entitlement; the procurement register should follow, not lead, the topology decision.

The first topology is the active passive failover cluster on local storage. Two or more nodes share no block device; the failover hands the workload from a primary node to a secondary node and the secondary node mounts its own local storage. The cluster needs High Availability, not Resilient Storage. The pattern is the most common on small Pacemaker clusters and on application failover clusters where the data tier sits behind a separate replication mechanism.

The second topology is the shared block file system. Multiple nodes mount the same GFS2 file system at the same time; the cluster manager arbitrates locks across nodes; the workload reads and writes through any node. The cluster needs Resilient Storage on every node that mounts the file system. The pattern is common on database tiers that share a clustered file system for log or temporary space and on application tiers that share a common content repository. The shared block storage interaction with the broader Ceph treatment is in the Ceph storage subscription and with the OpenShift counting reading in RHEL on IBM Power where the cluster topology often diverges.

The third topology is the clustered logical volume only. Multiple nodes import the same clustered volume group; the file system on the volume is a non shared file system mounted by only one node at a time; the cluster manager arbitrates the volume group import rather than file system locks. The cluster needs Resilient Storage, because the clustered logical volume manager is part of the Resilient Storage add on, not the High Availability add on. The reading frequently surprises buyers who treated the clustered logical volume as a High Availability artifact; the topology pulls the add on up to Resilient Storage even without a GFS2 mount.3

The audit reading on Resilient Storage walks four data sources end to end. The host inventory of GFS2 mounts. The host inventory of clustered logical volume group imports. The procurement register of Resilient Storage entitlements. The procurement register of High Availability entitlements on the same hosts. The reading is internally consistent when every host on either of the first two lists carries a Resilient Storage entitlement and no parallel High Availability entitlement; when every host on the High Availability list is not on either of the first two; and when every Resilient Storage entitlement maps to a host on the first or second list.

Three inconsistencies recur. The first is the GFS2 mount on a host with only a High Availability entitlement. The reading is exposure; the remediation is the conversion at the next renewal cycle and the retroactive treatment of the period of GFS2 operation in any audit settlement. The interaction with the broader audit defense reading sits in audit defense.

The second is the Resilient Storage entitlement attached to a host that no longer mounts GFS2 or imports a clustered volume group. The reading is overpayment; the remediation is the retirement of the line at the next renewal. The savings frequently fund the conversion costs on the first inconsistency and the engagement is net positive on the trailing twelve month basis. The reading frames the cluster topology as the artifact, not the procurement register.

The third is the Resilient Storage entitlement on a host that the buyer's documentation has identified as exited from the cluster but which the host telemetry continues to show in the Pacemaker configuration. The reading depends on the telemetry, not the documentation. The Pacemaker configuration on the host is the audit ready artifact; the buyer's narrative is not. The reading frequently uncovers retired cluster members that were left in the configuration for operational caution and which the audit reads as active cluster members for the period of presence.4

The renewal posture on Resilient Storage has three habits. The list is short on purpose; the practice's observation is that the same three habits, applied honestly, retire the recurring drift patterns on most estates within a single renewal cycle.

The first habit is the GFS2 and clustered volume group inventory. A short artifact, owned by the storage team, that names every host that mounts a GFS2 file system or imports a clustered volume group, and that names the file systems and volume groups by name. The artifact is reviewed quarterly and the entitlement register is reconciled against it. The same artifact also drives the broader assessment treatment in the 90 day subscription assessment and the storage specific reading in storage subscription assessment.

The second habit is the High Availability retirement at conversion. Whenever a host moves from a High Availability only line to a Resilient Storage line, the High Availability line is retired at the next renewal cycle, and the procurement register reflects the retirement before the next audit cycle. The most common renewal miss in the practice's observation is the parallel line that persists for a year after the conversion. The miss is captured in the broader treatment of recoverable over entitlement.

The third habit is the topology aware sizing. The Resilient Storage entitlement count is sized to the host count that mounts the file system or imports the volume group, not to the cluster member count. A four node cluster with two nodes mounting GFS2 carries two Resilient Storage entitlements and two High Availability entitlements. The sizing is rarely the same as the cluster member count, and the renewal cycle is the right time to confirm it. The broader sibling treatment of healthcare audit posture for clustered storage estates is in healthcare audit considerations.

For the practice hub, see the RHEL practice. For the broader subscription assessment service, see subscription assessment. For an engagement against the desk, see the contact form.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.