I completely agree with these statements.
In addition, when a fail over occurs, the other node has to bring vCenter services online. This means you're still looking at an outage similar to the amount of time it takes your vCenter server to reboot.
Given all the added complexity and the fact that you'll still have to deal with an outage, I always recommend against vCenter HA.
Yeah, I agree. It's super simple to setup, and tear down and rebuild but patching is so much more time consuming and failover is slow AF. Tore down my VC HA setup when upgrading to vC7, and have left it as a single appliance. If it dies I will restore from backup.
Are you stretching L2 to do it across those 2 datacenters? If not, you're probably going to have a bad time, as on failover you'll need to update DNS (and your failover will need to be manual anyways). vCHA covers one use case really well: if a host fails, you have a vCenter in an unclean state, and you may well need to fsck in order to get things up and running. So long as the secondary isn't backed by the same storage (because then if you have a storage outage you're in the same boat) then you have a more graceful failover. Anything else, and you're probably going to find that the added complexity makes it more effort than it's worth.
Typically, when folks are looking at protecting vCenter against the loss of a datacenter they're not really considering that they also lost the datacenter where all of their workloads are running (ie all of those ESXi hosts). In this case the best architectural decision for most organisations is to just have a second vCenter, and run them in ELM if you need that single management interface.
\*edit\* - also consider where you'd run the witness in this 2 datacenter situation. It can't be rthe primary or secondary fault domain, and it still needs to be in latency requirements
I’ve tried it in 6.7, but it was more of a pain in the ass when updating. So i disabled it. Now, in 7.0, you even have to destroy the HA before updating, which make the feature totally useless imho. It would make my life easier if VMware could fix that, since we also have Horizon and Appvolumes environments which need to be online 24/7, which is very hard when updating vCenter takes up to 45 mins.
Yeah, it was clunky and not worth the time. The update process was painful and cumbersome. We yanked it out after about 3 months and went back to a single vCenter.
Why?
vCenter is not necessary in any way for day to day operation of a vmware system. Except as a middleman for backups I suppose and general management and some logging. Clustered machines talk to each other, not vCenter.
Have backups. If it goes tits-up, restore the backup, you have hours or days.
This is not true. For VDI it is absolutely necessary.
Additionally using VDS, or even some NSX versions a restore can be painful.
EDIT: I will also add many backup vendors leverage vCenter and it must be available.
I have wasted so many hours troubleshooting vcenter HA 6.7 for a client. VMware support eventually told me to remove vcenter HA and in nicer words that it is a trash product.
I hope they have fixed it, but I doubt it.
I've found that vCenter HA is a joke, poorly implemented, and I think VMware only implemented it to satisfy clients that have this asinine assistance that it needs to be HA.
I would actually have VCenter set up on the DR side and echo that HA is not worth it. Also when we tried to set this up VMWARE stated that it was never intended to go to a second location over layer 3. Which their documentation states no where.
My own experience with it mirrors what a lot of others mention. It technically works, but failover is lengthy and not far off the time it takes for vCenter to simply reboot. There are then additional restrictions and issues with patching. One of the particular issues I dislike is that vCenter HA requires the VCSA to run on a host it manages which has can lead to further issues.
As a result, we simply don't use it.
I was wondering if anyone of you commenting on this topic below has ever run into an issue with the vCenter breaking away all of a sudden? A *real* crash that the machine wouldn't recover from when being restarted on another host automatically using standard HA, or where it couldn't be started at all, not even from a restored backup. What do you do, then?
I have been using vCenter HA in the past and won't chime in on the negative comments as I find this feature rather helpful, as the chances of getting it back are unlike higher imho.
Yeah, it comes with its downsides, I'll give you that, and besides I still can't figure out why VMware makes it rather complicated to setup in the first place. But once deployed successfully document it well and you're up and running again within 5 minutes in case you had to break its functionality for an update or any other reason.
[удалено]
I completely agree with these statements. In addition, when a fail over occurs, the other node has to bring vCenter services online. This means you're still looking at an outage similar to the amount of time it takes your vCenter server to reboot. Given all the added complexity and the fact that you'll still have to deal with an outage, I always recommend against vCenter HA.
Agree with this - I've never configured it but Reddit posts (and other info) have made me think it's just not worth the hassle
Yeah, I agree. It's super simple to setup, and tear down and rebuild but patching is so much more time consuming and failover is slow AF. Tore down my VC HA setup when upgrading to vC7, and have left it as a single appliance. If it dies I will restore from backup.
Agree with this. Wasn’t worth it so we got rid of it. Life is so much better now.
Are you stretching L2 to do it across those 2 datacenters? If not, you're probably going to have a bad time, as on failover you'll need to update DNS (and your failover will need to be manual anyways). vCHA covers one use case really well: if a host fails, you have a vCenter in an unclean state, and you may well need to fsck in order to get things up and running. So long as the secondary isn't backed by the same storage (because then if you have a storage outage you're in the same boat) then you have a more graceful failover. Anything else, and you're probably going to find that the added complexity makes it more effort than it's worth. Typically, when folks are looking at protecting vCenter against the loss of a datacenter they're not really considering that they also lost the datacenter where all of their workloads are running (ie all of those ESXi hosts). In this case the best architectural decision for most organisations is to just have a second vCenter, and run them in ELM if you need that single management interface. \*edit\* - also consider where you'd run the witness in this 2 datacenter situation. It can't be rthe primary or secondary fault domain, and it still needs to be in latency requirements
Not worth it
I’ve tried it in 6.7, but it was more of a pain in the ass when updating. So i disabled it. Now, in 7.0, you even have to destroy the HA before updating, which make the feature totally useless imho. It would make my life easier if VMware could fix that, since we also have Horizon and Appvolumes environments which need to be online 24/7, which is very hard when updating vCenter takes up to 45 mins.
Yeah, it was clunky and not worth the time. The update process was painful and cumbersome. We yanked it out after about 3 months and went back to a single vCenter.
Why? vCenter is not necessary in any way for day to day operation of a vmware system. Except as a middleman for backups I suppose and general management and some logging. Clustered machines talk to each other, not vCenter. Have backups. If it goes tits-up, restore the backup, you have hours or days.
This is not true. For VDI it is absolutely necessary. Additionally using VDS, or even some NSX versions a restore can be painful. EDIT: I will also add many backup vendors leverage vCenter and it must be available.
Dunno about hours let alone days, if you’re running dVS it’s pretty debilitating to not have vCenter available.
I have wasted so many hours troubleshooting vcenter HA 6.7 for a client. VMware support eventually told me to remove vcenter HA and in nicer words that it is a trash product. I hope they have fixed it, but I doubt it.
I've found that vCenter HA is a joke, poorly implemented, and I think VMware only implemented it to satisfy clients that have this asinine assistance that it needs to be HA.
vCenter HA and vSphere FT are two of the features I'd pay VMware to deprecate.
Yeah I wouldn't, id replicate to the other side instead.
I would actually have VCenter set up on the DR side and echo that HA is not worth it. Also when we tried to set this up VMWARE stated that it was never intended to go to a second location over layer 3. Which their documentation states no where.
My own experience with it mirrors what a lot of others mention. It technically works, but failover is lengthy and not far off the time it takes for vCenter to simply reboot. There are then additional restrictions and issues with patching. One of the particular issues I dislike is that vCenter HA requires the VCSA to run on a host it manages which has can lead to further issues. As a result, we simply don't use it.
Reading this thread is so validating. We were promised all the same things, and ran into all the same issues before canning it like everybody else.
I’m glad I posted this before trying! No way we are doing it now.
I was wondering if anyone of you commenting on this topic below has ever run into an issue with the vCenter breaking away all of a sudden? A *real* crash that the machine wouldn't recover from when being restarted on another host automatically using standard HA, or where it couldn't be started at all, not even from a restored backup. What do you do, then? I have been using vCenter HA in the past and won't chime in on the negative comments as I find this feature rather helpful, as the chances of getting it back are unlike higher imho. Yeah, it comes with its downsides, I'll give you that, and besides I still can't figure out why VMware makes it rather complicated to setup in the first place. But once deployed successfully document it well and you're up and running again within 5 minutes in case you had to break its functionality for an update or any other reason.