Rocket iCluster licensing: high availability priced on IBM i capacity.

Rocket iCluster is a high availability and disaster recovery product for IBM i, the operating environment that runs on IBM Power servers and carries the lineage of the AS/400 and iSeries. It uses logical replication to maintain a hot standby copy of IBM i applications, data, and objects on a second server, continuously monitoring the replication stream, identifying problems, and self correcting where it can, so that a planned or unplanned failover keeps applications available with minimal data loss and downtime. Rocket acquired the iCluster business from IBM, and the product now sits inside Rocket's IBM i portfolio, where it is run as a standalone HA and DR solution or, through iCluster HA Assist, as a complement to an IBM PowerHA deployment. For estates that pair IBM i workloads with a mainframe footprint, iCluster is the resiliency control plane for the Power i side of the house.

Rocket iCluster is licensed on the capacity of the IBM i servers and partitions it protects, typically anchored to the IBM Power processor group or tier and the number of partitions in the replication topology, rather than by user count or transaction volume. Because high availability needs at least a production node and a target node, the entitlement usually has to cover the capacity on both sides of the replication pair, and any additional disaster recovery or test targets behind it. Rocket has been moving its portfolios toward subscription, so the contract vehicle can be a traditional perpetual license with annual maintenance or a subscription depending on the agreement, and the basis is the Power capacity of the protected partitions, not the seat count. What you hold is best read against the full replication topology, not a single node.

Directional and pattern level. Confirm the processor tier basis, the per node terms, and whether the target and disaster recovery nodes are inside your entitlement before modeling a renewal.

The first driver is the Power processor tier of the protected partitions, which is the headline on a capacity priced HA tool and moves every time the IBM i hardware is refreshed to a larger group. The second is node count, because a replication topology with a production node, a high availability target, and a separate disaster recovery site multiplies the entitlement, and each node typically carries capacity of its own. The third is the contract model, since the shift toward subscription changes the cash profile from maintenance on a perpetual license to a recurring fee, and the arithmetic of the two over a renewal term rarely matches the sales framing. The fourth is the acquisition transition, where the move of iCluster from IBM to Rocket can leave older entitlements ambiguous about what is currently granted. Replication volume is rarely the cost; the Power tier, the node count, and the contract model are.

iCluster exposure is mostly node count and capacity attribution across the topology. Common traps we see at pattern level:

Because iCluster is a capacity priced HA tool spread across a replication topology, the levers are about nodes, capacity, and the contract model. The five that pay:

IBM i high availability is a contested category, with IBM PowerHA SystemMirror for i and logical replication products from other vendors all offering production to target resiliency, which makes a credible alternative real rather than imaginary. But an HA and DR switch is high risk by nature, because the whole point of the product is that it must work at the moment of failure, and a migration carries reconfiguration of the replication topology, retraining of operations staff, and revalidation that failover genuinely holds under load. Where iCluster is already embedded as the resiliency control plane, the practical approach is to validate the topology, right size the Power tier, and choose the contract model first, where most of the saving sits, and to keep a costed move to PowerHA or a competing product as genuine leverage that disciplines the renewal. Disruption for its own sake is rarely worth it on a tool whose job is to prevent disruption.