Service groups fail to failover after node failure when HAD fails with V-16-1-10113 - System is in DDNA Membership
Article ID: 100025168
Updated On:
Description
Error Message
For a cluster with 2 nodes (Server1 and Server2), the engine_A.log from %VCS_HOME%\log path would report the below details:
VCS INFO V-16-1-10077 Received new cluster membership
VCS NOTICE V-16-1-10112 System (Server2) - Membership: 0xE, DDNA: 0x1
VCS ERROR V-16-1-10113 System Server1 (Node '0') is in DDNA Membership - Membership: 0xE, Visible: 0x0
VCS ERROR V-16-1-10322 System Server1 (Node '0') changed state from RUNNING to FAULTED
VCS NOTICE V-16-1-10449 Group ServiceGroup1 autodisabled on node Server1 until it is probed
As seen above, Server1 goes into DDNA membership and the overall cluster membership is updated. After this, all service groups are moved to autodisabled state on Server1.
Cause
DDNA is a condition in which the High Availability Daemon (HAD) on a node fails, but the node is running. In a DDNA condition, the HAD does not have information about the state of service groups on the node. So, the cluster places all the service groups that were online on the affected node in the AutoDisabled state. The service groups that were online on the node cannot failover.
Resolution
Manual intervention is required to enable failover of AutoDisabled SG.
The cluster administrator can perform the below steps:
1) Address the issues on the impacted node that caused the node to go in DDNA state.
2) Login to the cluster from any other node in the cluster
3) Autoenable the SG(s)
4) Clear any faults, if present.
5) Online the required SG(s) on the next node in the cluster.
Issue/Introduction
Additional Information
