Upgrade may fail after node evacuation if a VCS parallel service group is OFFLINE on a partial set of nodes at the beginning of the upgrade
If a VCS parallel service group is in OFFLINE state on few nodes (partial set of nodes) and ONLINE on other nodes at the start of the upgrade, upgrade may fail after the node evacuation step (hastop -evacuate). This happens because as a part of the VCS service group check after the hastop -evacuate command is executed, the parallel service group should be ONLINE on all the nodes. But if such a group was in OFFLINE state on a partial set of nodes at the beginning of the upgrade, it remains in OFFLINE state on those nodes and the VCS service group check fails after waiting for 3-4 hours. (IA-40597)
Workaround:
Perform the following steps and restart upgrade.
Identify the parallel service groups.
# hagrp -display | grep -i parallel
Service groups with 1 in the 4th column are parallel service groups.
For example:
# hagrp -display | grep -i parallel CanHostNLM Parallel global 1 GLOBAL_API_SERVER Parallel global 0 ManagementConsole Parallel global 0 NBUMasterBrain Parallel global 0 NBUMasterWorker Parallel global 0 NFSShareOfflineGrp Parallel global 0 NLMGroup Parallel global 0 NicMonitorGrp Parallel global 1 Phantomgroup_pubeth0 Parallel global 1 Phantomgroup_pubeth1 Parallel global 1 Phantomgroup_pubeth2 Parallel global 1 VVRInfra_Grp Parallel global 1
Before you start the upgrade, check if any of the parallel service group is OFFLINE on partial set of nodes and online on other nodes.
# hagrp -state <SG name>
For example:
# hagrp -state VVRInfra_Grp #Group Attribute System Value VVRInfra_Grp State dellsite1-01|ONLINE| VVRInfra_Grp State dellsite1-02|OFFLINE| VVRInfra_Grp State dellsite1-03|OFFLINE| VVRInfra_Grp State dellsite1-04|ONLINE|
Try to online the parallel service groups on all the nodes of the cluster before upgrade.
# hagrp -online <SG Name> -sys <nodename>
For example:
# hagrp -online VVRInfra_Grp -sys dellsite1-02