I was carrying out fail over testing for a new customer install of System IPCC and have come up against a problem. After a fairly brutal power off test on Side A PG it was rebooted. At windows login it went into shutdown. I managed to eventually get in and run stopshut.
Everytime I restarted the PG this happened again until I cycled services on the B side and then restarted the A and everything came up fine.
Any idea what caused this? the only previous time I have had similar failures was because the private link had failed, not the case here however.
ICM is performing as it should, attempting to activate when Node Manager notices that the PIM is nolonger Active, And under a "normal failover sequence" when the PIM is failed over and the PG remains powered up, you state that the failover works. The only problem that is introduced is when the PG is actually powered off with the PIM in the Active state, once this is done the PIM cannot failover, and when the PG that was powered off is brought back online and services started, that PG cannot go active either, it is not until the PDI card is rebooted that the Rockwell allows one of the PIM to go active.
I believe that this is a Rockwell problem as you have to reboot the PDI card in order to reset the ports to allow the PG to connect to the Spectrum. The Rockwell is not shutting down the port when the PG is powered down with an active PIM, The Rockwell needs to recgonize that the PIM is no longer connected, and break down that port to allow the PG's duplexed peer to take over.
When the PG is failed over with power remaining, EG: the services are cycled or the PIM is shot, there is a level of communication that goes on there that actually signals to the Spectrum that we are disconnecting, and the Rockwell takes down the port in that instance fine, allowing the duplexed peer to take over and go active
Indeed it is a system IPCC install so no Rockwell issues.
What has appeared to cured the issue is to switch off the reboot on failure option. Looking at the logs it looks like it was a case of the links not coming up fast enough to allow the services to talk with each other. By diabling the reboot command it allows more time so the services can all start ok and communicate with thier peers.
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.