SSO/vCenter redundancy

[PerryR]

Hej,

we are currently preparing our 5.1 environment and plan to setup SSO servers as HA for failover. We think about putting it on VMs as it is supported by VMware and will run in an ESX Cluster. Multiple sites will be connected to.

Can the other designs, i.e. using 2 physical nodes or using one physical and one VM be a good/safe option?

How can redundancy be ensured for vCenter apart from vCenter Heartbeat license? Having a "hot standby" vCenter VM?

It will be an mid-size environment (around 20-30 hosts)

What are your toughts and experience?

Thanks

[LordISP]

This dream is about to burst because your database must be consistent for your so called "hot standby vcenter". This is one of the reason why sphere heartbeat makes sense.

What about vSphere HA? It doesn't protect you from interruptions but you don't have an outage.

If you need a cheep site protection you can build stretched ha cluster for your foundation services but keep in mind this might be network challenge.

[markdjones82]

Heartbeat is really your only good option other than using the built in HA, but a powered off VM is an option, but then you ahve to keep it up to date if any changes are made.  That being said, Heartbeat can be a bit flaky in my opinion and we just use vmware HA for our redundancy because even Heartbeat is a short downtime while the services restart, so in essense it is the same type of failover as when a host fails.

My recommendation is to run your Vcenter servers and all component servers on an isolated VM cluster or setup DRS rules so you know where they are and rely on the vsphere HA.  Heartbeat can protect from service failures, but in my experience when this happens you usually have a problem with your DB that a failover won't really resolve.