smudger
Enthusiast
Enthusiast

SRM, vCenter & vCenter Heartbeat

Hi,

Maybe this is obvious but I wanted to ask anyway for my own sanity! We are about to evaluate SRM for obvious reasons of improving vm workload failover/recovery. Another steam of the project is to increase availability of vCenter (more and more 3rd party products are using vCenter for providing stats, driving backups and other automation functions).

My question is: If we implement SRM, is there still a need for vCenter heartbeat ? Part of me thinks no, as the service will be protected by SRM. However it would appear (heartbeat) offers a higher level of resilience for vCenter, as in a live-live type configuration rather than active/passive as with SRM.

Any comments or experiences welcomed.

Thanks,

Neil

Tags (3)
0 Kudos
2 Replies
mal_michael
Commander
Commander

Hi,

In SRM deployment you have vCenter instance at each of your sites. Each vCenter manages ESX hosts of its site.

Protecting vCenter server with SRM doesn't make much sence in my opinion.

You run SRM failover when major failure occurs at you primary site, not when single VM or host fails. In this situation SRM powers on your VMs at recovery site and they will be managed by recovery site's vCenter. What is the point to recover protected site's vCenter? Furthermore, if you have BSOD in vCenter's OS and you are not able to solve it, in case of sync replication that corruption will be replicated to the recovery site too and the OS won't start either. In case of async replication you do have a chance Smiley Happy.

Protectiong vCenter with SRM maybe useful only if you failover part of the environment and still want be able to manage the remaining part. However, what about vCenter's IP address? Do you have stretched VLANs, because changing vCenter's IP may be painful (reconnecting ESX hosts, third-party products).

Do you have the required ports opened between the sites for vCenter to connect to the environment successfully? What about the ports for third-party products?

vCenter Heartbeat is more suitable to protect vCenter server. Secondary vCenter instance usually reside at the same site (preferably at different cluster / storage for maximum redundancy). In case you want the secondary to reside at the remote site, you have to answer the same questions as before (IP, latency, ports).

Michael.

smudger
Enthusiast
Enthusiast

Hi Michael,

Thanks for your reply. We have the ability to cater for layer2 adjacency, ports and latency are not a problem. You make an excellent point re SRM and vCenter using sync replication/bsod/data corruption - that in itself is enough to warrant the Heartbeat product.

Regards,

Neil

0 Kudos