vCenter Auto-start with Heartbeat

[badazws6]

I have vCenter protected by Heartbeat in several environments and none appear to be allowing vCenter to automatically start from a cold state (where both nodes in heartbeat are powered off).  To bring vCenter up I have to boot both nodes and then manually start the application (vCenter). 

On top of that it appears that I always have to start the application (vCenter) on the same node it was on before both nodes where powered off.

I suspect I have something misconfigured here, can anyone point me in the right direction?

vCenter 5.0.2, heartbeat 6.5, both nodes are virtual

Thanks,

MR

[djciaro]

Hi,

If I understand you perform a power off of both vCenter nodes? So not a clean shutdown of Heartbeat. In order for Heartbeat to complete replication and sync without data loss or other issues you should always perform a shutdown of Heartbeat first then shutdown windows.

If you do want to power off in this manner and want to bring Heartbeat backup on the passive node, you would need to power on VM, stop heartbeat service, launch the vCenter Server Heartbeat Configure Server wizard and click the Machine tab. In the Current Role section, choose Active and click Finish, then start heartbeat. You will need to do the opposite on the active server (set current role to passive)

Do you mind if I ask under what circumstances you would need to power off both nodes and want to bring Heartbeat protected services on the previously passive node after starting the servers?

Regards

Ciaran

[badazws6]

It is mainly just "what if scenarios" nothing specific.  Mainly I would just expect as a matter of best practice that if the secondary node came up and the primary is not there that it would automatically pick up.  Obviously there would need to be something in place to protect against split brain but having the first available node automatically pick up seems like a fairly basic HA tenet to me.  Lots of things I could come up where the primary node is lost and the secondary is available would be simple accidental deletion or the VM's on different raid sets and you loose the raid set the primary is on.  I agree, somewhat unlikely but I have seen crazier things.