VMware Cloud Community
vmproteau
Enthusiast
Enthusiast
Jump to solution

VMware vCenter Server Heartbeat

We are building out a new environment and considering "VMware vCenter Server Heartbeat". I'm trying to justify it. I'm not sure I fully understand all the pros/cons.

  1. Is it easy to implement and manage or am I adding complexity for modest gain.
  2. I read about replication of application data. Does that mean an upgrade of one "node" will be an upgrade of both?
  3. Our DB server is an external SQL2008R2 instance. Does this increase complexity or is it irrelevant to "VMware vCenter Server Heartbeat"
  4. We will be using SMP so, FT wouldn't be an option for us but, if I could use FT, what does "VMware vCenter Server Heartbeat" provide above a Fault Tolerance enabled vCenter server?

For those that use it, please add any benefits or things to consider that may not be obvious.

0 Kudos
1 Solution

Accepted Solutions
joshgray
Enthusiast
Enthusiast
Jump to solution

vmproteau wrote:

We are building out a new environment and considering "VMware vCenter Server Heartbeat". I'm trying to justify it. I'm not sure I fully understand all the pros/cons.

  1. Is it easy to implement and manage or am I adding complexity for modest gain.
  2. I read about replication of application data. Does that mean an upgrade of one "node" will be an upgrade of both?
  3. Our DB server is an external SQL2008R2 instance. Does this increase complexity or is it irrelevant to "VMware vCenter Server Heartbeat"
  4. We will be using SMP so, FT wouldn't be an option for us but, if I could use FT, what does "VMware vCenter Server Heartbeat" provide above a Fault Tolerance enabled vCenter server?

For those that use it, please add any benefits or things to consider that may not be obvious.

1.  This could be debatable on either side.    I would argue it's no more complex than competiting products that do software clustering (MSCS, Veritas..), but any additional layer of software management adds a layer of complexity.

2. No an upgrade on one node does not upgrade both.   The replication refers to the "data" that is "protected" by the application.   Since your DB is external, not a ton of data will be replicated - but some will be (logs, local settings, config file...)

3.  If the DB is external I would say that reduces your complexity a bit.  It's not irrelevant though.  If the DB was local, Heartbeat would protect it also and replicate changes over to the secondary.

4.  FT is entirely different technology.  FT keeps a secondary VM in perfect sync with the primary.  In the event of a host failure that is running the primary, the secondary will come online without rebooting. The memory state is constantly replicated with FT, so that's how it differs from HA.   With HA, the VM is powered on on a surving host.  With Heartbeat - the VC service itself is turned on then on the secondary machine with slight delay.

Glad to answer any more questions for you.   The HB technology is pretty neat, I think we offer a 60 day eval if you want to test it out.  It'll work Virtual-Virtual,  Physical-Virtual,  and Physical-Physical.   The newest version 6.4 introduced a new deployment model so make sure you are using that version and reading documentation for that version as well.

View solution in original post

0 Kudos
4 Replies
JackyWoo
Enthusiast
Enthusiast
Jump to solution

Questions before your questions that needed to be answered first

1. Will your VC be a VM or Physical?

Basically, HeartBeat is to provide a HA for your VC, ensuring there will be a VC for you to manage your environement unless your whole infrastructure is down. I do akin the methodology of setting up the environment to be in correlation on how parnoid is the decision maker.

vmproteau
Enthusiast
Enthusiast
Jump to solution

All VMs. We will have a Management Cluster to eliminate circular dependencies. Assuming this can work across clusters, these would be split across both. Same physical site initially.

0 Kudos
joshgray
Enthusiast
Enthusiast
Jump to solution

vmproteau wrote:

We are building out a new environment and considering "VMware vCenter Server Heartbeat". I'm trying to justify it. I'm not sure I fully understand all the pros/cons.

  1. Is it easy to implement and manage or am I adding complexity for modest gain.
  2. I read about replication of application data. Does that mean an upgrade of one "node" will be an upgrade of both?
  3. Our DB server is an external SQL2008R2 instance. Does this increase complexity or is it irrelevant to "VMware vCenter Server Heartbeat"
  4. We will be using SMP so, FT wouldn't be an option for us but, if I could use FT, what does "VMware vCenter Server Heartbeat" provide above a Fault Tolerance enabled vCenter server?

For those that use it, please add any benefits or things to consider that may not be obvious.

1.  This could be debatable on either side.    I would argue it's no more complex than competiting products that do software clustering (MSCS, Veritas..), but any additional layer of software management adds a layer of complexity.

2. No an upgrade on one node does not upgrade both.   The replication refers to the "data" that is "protected" by the application.   Since your DB is external, not a ton of data will be replicated - but some will be (logs, local settings, config file...)

3.  If the DB is external I would say that reduces your complexity a bit.  It's not irrelevant though.  If the DB was local, Heartbeat would protect it also and replicate changes over to the secondary.

4.  FT is entirely different technology.  FT keeps a secondary VM in perfect sync with the primary.  In the event of a host failure that is running the primary, the secondary will come online without rebooting. The memory state is constantly replicated with FT, so that's how it differs from HA.   With HA, the VM is powered on on a surving host.  With Heartbeat - the VC service itself is turned on then on the secondary machine with slight delay.

Glad to answer any more questions for you.   The HB technology is pretty neat, I think we offer a 60 day eval if you want to test it out.  It'll work Virtual-Virtual,  Physical-Virtual,  and Physical-Physical.   The newest version 6.4 introduced a new deployment model so make sure you are using that version and reading documentation for that version as well.

0 Kudos
vmproteau
Enthusiast
Enthusiast
Jump to solution

I appreciate your detailed response. We have DR strategies to minimize any service disruption based on a lost vCenter server so, I prefer not to add any complexity immediately however, when we do get the new environment flowing I would like to look into this further.

Configuring an empty environment seems ideal but, in your opinion, will adding this to an existing environment pose significant additional challenges or risks.

0 Kudos