CONTAP-813862: Cloud ONTAP HA Pair May Experience an Unexpected Takeover During a Mixed-Version Upgrade

Based on the public record at NetApp Knowledge Base, CONTAP-813862. Quoted text is the published Issue section; affected versions, workaround and fix require a NetApp support login and are not asserted here.

What the record actually says

NetApp's public KB article CONTAP-813862 describes a failure mode specific to a Cloud ONTAP HA pair that is being upgraded non-disruptively while its two nodes are running different ONTAP versions. The published Issue text is short enough to quote in full:

During a non-disruptive upgrade of a cloud ONTAP HA pair, a takeover while the nodes are running different ONTAP versions may cause the surviving node to initiate an unexpected takeover when a heartbeat timer expires. This can result in a cluster outage.

That paragraph is the whole of the public description. The KB page is marked Public, category ontap-9, specialty hw, article type Reference, confidence Validated — and then stops: affected versions, workaround and fix are behind "Sign in to view the entire content of this KB article."

Why the second takeover is the dangerous part

An HA pair is designed around one assumption: exactly one node carries the partner's storage. A takeover moves LIFs, aggregates and data access to the survivor, and the survivor then runs the whole workload alone.

During an ANDU that is the normal, expected state for a few minutes per node — one node is upgrading, its partner is serving everything. The condition CONTAP-813862 flags is a takeover in that window: the surviving node, already carrying the cluster, meets an expiring heartbeat timer and initiates a further takeover. There is no third node to hand the workload to, so the failure ends as a cluster outage, not a degraded pair.

Nothing in the public text says the takeover is operator-initiated. That matters for how you read the record: the trigger described is a timer expiry during a version-skew window, which is why it belongs in the upgrade checklist rather than the "don't press takeover" checklist.

The mixed-version window is the exposure

Cloud ONTAP HA pairs are the interesting case here because the pair is what gives a cloud deployment its availability story in the first place — the same trade-off discussed in on-prem versus cloud ONTAP: you accept cloud networking and a mediator quorum in exchange for automatic failover. An upgrade temporarily suspends the thing you paid for.

The three commands worth running before and during any upgrade window are the boring ones. They tell you what state you are actually in, rather than what the runbook says you should be in:

storage failover show
system node show -fields version
cluster image show-update-progress

If storage failover show does not show the pair healthy and both nodes eligible before you start, you are not beginning an ANDU — you are beginning an outage with a progress bar. And if system node show -fields version shows two different versions outside a planned window, that skew is the exposure CONTAP-813862 describes, whatever caused it.

What is gated behind a support login

This is where a public KB record stops being an answer. The parts a Cloud ONTAP operator actually needs — which version pairs are affected, whether a workaround exists, and in which release the fix landed — require a NetApp support account. We are not going to guess them, and a headline is not a version list.

What the public page does give you is a precise search string and a category, which is enough to open the right case or find the same record from an authenticated session. Use the article ID, not the symptom: CONTAP records are NetApp's numbered ONTAP issue records, and the ID is what support and the affected-version matrix are keyed on.

What to do before your next upgrade window

• Check the ID against your version pair while logged in. If your source and target versions are both listed, treat the upgrade as conditional on NetApp's workaround, not as routine maintenance.
• Do not add a manual takeover to the window. The record is about an unexpected takeover; a planned one during version skew puts you in the same state on purpose.
• Watch the pair, not just the upgrade job. storage failover show during the window is the cheap signal that the survivor is still behaving as a survivor.
• Keep the window small and the traffic low. Every minute of version skew is a minute the pair is one timer away from the condition in the record.
• Have the rollback path written down before you start — and know that reverting an ONTAP upgrade is a different operation from reverting a config change.

What to watch next

Two things, both checkable rather than speculative: whether NetApp moves the affected-version list into the public part of the record, and whether the fix ships as a maintenance release rather than a documented workaround. The same KB neighborhood already carries a related ANDU failure record — CONTAP-799924, giveback failing and repeatedly triggering NFO after a WAFL/RAID HA RDMA QP reject code 38 during ANDU — which is a reminder that the upgrade path, not steady state, is where HA pairs actually break.

For background on how Cloud ONTAP HA and its mediator fit together, see Cloud Volumes ONTAP and the cloud and hybrid hub.

Sources: NetApp Knowledge Base, CONTAP-813862