The RHEL High Availability add on, priced beside the base.

The RHEL High Availability add on is the Red Hat supported delivery of the Pacemaker and Corosync cluster stack with the matching fencing agents. The add on is sold as a separate subscription line on top of the base RHEL subscription. Every host that runs the cluster stack requires both the base RHEL entitlement and the High Availability add on entitlement, sized to the same socket pair or virtual host count as the base. The add on is not bundled into RHEL Server; it is not bundled into RHEL for Virtual Datacenters at the base tier; it is a separate purchase that the buyer attaches to each cluster member.1

The mechanic is straightforward in principle. A two node failover cluster on two socket physical hosts consumes two base RHEL entitlements and two High Availability add on entitlements. A four node cluster on four hosts consumes four of each. A cluster on a virtual datacenter host consumes one Virtual Datacenter base entitlement covering all guests on that hypervisor and one High Availability add on entitlement covering only the cluster member guests on that hypervisor; the add on does not inherit the unlimited guest count of the Virtual Datacenter base. This last interaction is where the counting most frequently drifts and is discussed in the RHEL Virtual Datacenter deep dive.

The buyer side reading begins with three artifacts: the Pacemaker cluster configuration on each host, the host inventory of paid base RHEL subscriptions, and the host inventory of paid High Availability add on subscriptions. The three must reconcile. A cluster member without a paid add on entitlement is the most common finding. A paid add on entitlement attached to a host that no longer runs the cluster stack is the second most common finding. Both readings appear in the same engagement when the cluster topology has shifted and the entitlement register has not caught up.

Three counting traps recur across signed engagements on High Availability add on readings. Each is structural rather than malicious; each has a remediation that the practice has walked clients through repeatedly.

The first trap is the silent cluster member. A host runs the Pacemaker daemon and is wired into a Corosync ring; the operations team treats the host as an in cluster member; the procurement record carries no High Availability add on entitlement for that host. The host frequently arrived through a cluster expansion that the engineering team executed for capacity reasons and that the procurement cycle did not learn about for months. The audit reading is unentitled add on for the period of operation. The remediation is to attach the add on going forward and to make the cluster member list a quarterly inventory artifact, not an annual one.

The second trap is the orphan add on. A host carries a paid High Availability add on entitlement attached to a base RHEL line that the operations team retired six months ago when the host was repurposed. The add on continues to renew at each cycle because the procurement register treats it as an active line. The reading is overpayment, not exposure; the remediation is to retire the line at the next renewal. The orphan is also the answer when a buyer asks why the add on count is higher than the cluster member count; the audit reading and the renewal reading point in opposite directions on the same data and the buyer should pursue both. This pattern overlaps with the broader treatment in phantom entitlements.

The third trap is the virtual host miscount. The cluster runs as guests on a Virtual Datacenter base host; the operations team counts the physical hypervisor once for the add on, treating it as covered by the unlimited guest reading of the Virtual Datacenter; the audit reading counts the cluster member guests, one add on entitlement per cluster member regardless of the base topology. The remediation is to size the add on to the guest count, not the hypervisor count, and to record the distinction in the entitlement register so the next operations rotation does not retread the same path.2

The High Availability add on does not include the cluster file system. GFS2 and the matching clustered logical volume manager arrive through a separate add on, the Resilient Storage add on, which is a strict superset of High Availability and therefore replaces, rather than supplements, the High Availability entitlement on the same host. Buyers who run a shared file system across the cluster require Resilient Storage; buyers who run only failover without a clustered file system require High Availability alone. The two add ons are mutually exclusive on a given host; both add ons priced on the same host is overpayment, not double coverage. The Resilient Storage reading is treated separately in the Resilient Storage add on licensing note.

The interaction has a practical edge when a cluster expands its scope. A two node failover cluster moves to a four node clustered file system topology to support a database tier that needs concurrent block access; the operations team adds GFS2 to the existing Pacemaker configuration; the procurement register continues to renew the High Availability add on without converting to Resilient Storage. The audit reading is unentitled clustered file system for the period of GFS2 operation. The remediation is to convert the line at the renewal cycle, with the conversion priced against the difference between the two add ons rather than as a fresh purchase.

The reverse migration is equally common. A buyer retires the clustered file system tier in favour of a different storage architecture; the add on register continues to carry Resilient Storage; the renewal posture should retire Resilient Storage and add back High Availability where the failover stack remains. The conversion is again priced against the difference, and the buyer captures the savings as part of the broader treatment in recoverable over entitlement cost.

Two RHEL specialised platforms bundle the High Availability add on into the base line at a different price point. The RHEL for SAP Applications and RHEL for SAP HANA subscriptions include the add on within the per host price; a separate High Availability line attached to the same host is overpayment, not redundancy. The bundling is the result of the SAP certification model, which requires the cluster stack for the supported HANA topology and therefore folds the add on into the platform line. Treatment of the SAP variants is in RHEL for SAP Applications and RHEL for SAP HANA.

The RHEL real time kernel subscription, used for telco, finserv, and other latency sensitive workloads, does not bundle the High Availability add on; the buyer who runs a real time cluster pays for both the real time base and the add on separately. The interaction is covered in the real time kernel licensing note. Specialised platforms with their own cluster stack semantics, such as the cluster topology used in container hosts, sit outside this discussion and frequently overlap with container registry licensing in the broader OpenShift ecosystem.

The buyer side reading on bundled add ons turns on the catalogue line. A line that reads RHEL for SAP HANA does not need a parallel High Availability line; a line that reads RHEL Server does. The catalogue line is the audit ready artifact, and the practice reads it before reading any of the host telemetry.

The renewal posture on the High Availability add on has three habits the practice recommends across engagements. The habits are unglamorous; they are also the difference between a clean reading and a finding at the next audit cycle.

The first habit is the cluster member of record list. A single artifact, maintained by the engineering team and reviewed by the procurement team, that names every host running Pacemaker and Corosync, names the base entitlement that covers it, and names the add on entitlement that covers it. The list is reviewed quarterly. New cluster members appear within the quarter, retired cluster members are reconciled within the quarter, and the renewal cycle sees a list that matches the entitlement register. The broader reading is part of the 90 day subscription assessment.

The second habit is the conversion logic at each renewal cycle. The list of paid add on entitlements is read against the cluster member list, the orphan lines are retired, the silent cluster members are entitled, and the GFS2 conversions are priced against the difference between High Availability and Resilient Storage. A renewal cycle that does not reconcile the add on against the cluster member list is a renewal cycle that renews the gaps. The reconciliation is short; the omission is expensive.

The third habit is the bundling check. The catalogue lines on RHEL for SAP, RHEL for SAP HANA, and any specialised platform line are read for bundled add on coverage; the parallel add on lines that the procurement register continues to carry from a prior catalogue revision are retired at the renewal. The bundling check is the most frequent source of recoverable over entitlement on add on readings in the practice's observation. The broader renewal posture is treated in renewal negotiation; the assessment that supports it is treated in subscription assessment; and the cross industry reading on the audit interaction is in financial services audit considerations.3

For the practice hub on RHEL more broadly, see the RHEL practice. 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.