After Cluster switch, one of node became disable for switching

[Dmitriy_16]

I use HP Cluster Manager B8324BA B.01.04 HP Cluster Object Manager on 2 RP5470 HP servers.
Cluster works in Cold Standby Mode.
I switched from Active to Standby node (stop some of application managed by cluster for example informix %onmode -ky) and switching was successful. But then when i checked cluster status #cmviewcl -v i found out that standby node became disabled for switching.
Result of cmviewcl -v after switching from scp2 to scp1.

# cmviewcl -v

CLUSTER STATUS
scpcluster up

NODE STATUS STATE
scp1 up running

Network_Parameters:
INTERFACE STATUS PATH NAME
PRIMARY up 0/0/0/0 lan0
PRIMARY up 0/8/0/0 lan1
STANDBY up 0/9/0/0 lan2

PACKAGE STATUS STATE AUTO_RUN NODE
scppkg up running enabled scp1

Policy_Parameters:
POLICY_NAME CONFIGURED_VALUE
Failover configured_node
Failback manual

Script_Parameters:
ITEM STATUS MAX_RESTARTS RESTARTS NAME
Service up 0 0 scp_service
Subnet up 10.11.11.0

Node_Switching_Parameters:
NODE_TYPE STATUS SWITCHING NAME
Primary up enabled scp1 (current)
Alternate up disabled scp2

NODE STATUS STATE
scp2 up running

Network_Parameters:
INTERFACE STATUS PATH NAME
PRIMARY up 0/0/0/0 lan0
PRIMARY up 0/8/0/0 lan1
STANDBY up 0/9/0/0 lan2


This situation appears time to time. Sometimes SWITCHING stay enable sometimes it became disable for standby node (So if active node will be halted services will not switch again to standby node).
Is it normal work for HP cluster?

[Duncan Edmonstone]

This is normal behaviour

This is a neat way of forcing admins to manage their clusters effectively something just failed on scp2 - the package had to switch to scp1 - you don't want it failing back until you have had a chance to checkout what caused the failure and rectify it... once your happy that scp2 is OK again you can re-enable easy enough using:

cmmodpkg -e -n scp2 scppkg


HTH

Duncan

[Artyom Voronchihin]

Hello!
See Policy_Parameters section. failback is set to MANUAL. It's default behaviour. "The MANUAL policy means no attempt will be made to move the package back to its primary node when it is running on an adoptive node".
Change it to AUTOMATIC in the package config file for switching automaticaly then package's primary node becomes available to run packages.

[melvyn burnard]

so the way I understand it, you have forced a sitch of the package from one node to the other. If so, this is the default behaviour.
Check the package log on the node that you failed the package on as well as the syslog.log on both nodes, you should see it logged that package switching has been disabled on the failed node.