Exalogic Virtual 2.0.6.0.X, 2.0.6.1.X, 2.0.6.2.X Releases ONLY: Increase O2CB Cluster Heartbeat Timeout On Dom0 OVS Compute Nodes (Doc ID 1995593.1)

Last updated on SEPTEMBER 10, 2021

Applies to:

Oracle Exalogic Elastic Cloud Software - Version 2.0.6.0.0 to 2.0.6.0.2
Oracle Exalogic Elastic Cloud Software - Version 2.0.6.1.0 to 2.0.6.1.2
Oracle Exalogic Elastic Cloud Software - Version 2.0.6.2.1 to 2.0.6.2.170117
Linux x86-64
Oracle Virtual Server x86-64

★★★★ O2CB Timeout Settings in this Note DOES NOT APPLY to 2.0.6.3.X and 2.0.6.4.X Versions ★★★★

IMPORTANT NOTE: The procedure in this document is intended to be performed as part of applying the April 2015 PSU (EECS 2.0.6.2.1) and higher. The documentation for the April 2015 PSU (and higher) for Virtual contains a link to this MOS note. Implementing this procedure in a standalone manner (not as part of April 2015 PSU) on earlier EECS releases requires explicit approval from the Exalogic Development team.

Purpose

IMPORTANT NOTE

Please note, procedure in this Note to increase o2cb timeput value on Dom0 compute nodes applies to only below Exalogic Virtual releases.

2.0.6.0.X
2.0.6.1.X
2.0.6.2.X

Procedure in this Note to increase o2cb timeout value DOES NOT APPLY to 2.0.6.3.X & 2.0.6.4.X Virtual releases.

A detailed step-by-step procedure is provided in this document to increase the O2CB cluster heartbeat timeout from 5 min to a very large value of 24 hr. The increased timeout effectively prevents a catastrophic reboot of all compute nodes on an Exalogic rack in a virtual configuration due to fencing, in the event of ZFS taking a long time to complete a takeover. A ZFS takeover is performed during the upgrade of the ZFS software version, as well as during an HA failover event when the standby control head becomes active.

The reconfiguration will also stop fencing from all long ZFS and network availability conditions including:

NFS server unreachable/non-responsive
Hardware failure (ZFS or on-node HCA)
Network outage conditions on individual compute nodes or in the fabric (failures unrelated to ZFS)
Any other condition where the NFS service becomes unavailable - both planned and unplanned

Note that this configuration change may cause applications and control stack behavior to be indeterminate in the case of very long network or storage availability conditions.

NOTE: The 24hr timeout is really an arbitrarily large value used to turn off the OCFS2 node fencing feature entirely rather than just to extend the timeout.