DR scenarios - local hosts and remote host - vCenter or direct ESXI?

[leviu]

We have a customer with 2 local ESXI hosts and one remote DR host (on a different subnet). There is a single vCenter deployed locally on one of the hosts. Local hosts have per-host storage (local disks).

My question boils down to a single scenario - should I use vCenter for replication in this scenario?
To speed up RTO, in case of one of the localhosts fails, I have configured replication for certain larger critical servers (500GB to 1TB) between the 2 local hosts every couple of hours. I have done so via vCenter. However, in case the host with vCenter fails I would have to restore the vCenter first or use vPower NFS (Quick restore) to use Veeam for proper replication (and to be replicate back). This adds an extra step for which I cannot see a good reason for. Should I just switch to replicate directly via ESXI hosts?

I have read through this post and what veremin links to (this). If I replicate via ESXI hosts directly, then there shouldn't be any issues like the ones mentioned in the second post I linked.

On a side note, I am already connecting directly to the remote DR server in Veeam for replication, as it is in another subnet and changing IPs in vCenter in a DR situation is a no go. The customer isn't about to buy another vCenter license just to make DR easier.
On a side side not, Veeam B&R (10a) allows me to add SOME hosts directly via IP, where they are already appear in the connected vCenter via IP. However, it does not allow me to do so for others since I guess they appear in the connected vCenter ¯\_(ツ)_/¯. Whatever.

Veeam B&R 10a.
vCenter/ESXI 6.7

[soncscy]

>However, it does not allow me to do so for others since I guess they appear in the connected vCenter ¯\_(ツ)_/¯. Whatever.

on this, what's so confusing? An added host is an added host, it doesn't matter if it's directly or via vCenter; it's a host being tracked. Use /etc/hosts hacks on the VBR server to easily bypass this.

For your setup I think that there's no need to overthink it -- if the vCenter goes down, you need to restore it anyways and the replicas being interrupted temporarily should be okay. If you hit a failover event in this case, iirc, this shouldn't even matter as the source machine isn't touched, just the DR site.

Is the DR site managed by the same vCenter? If so, __that__ feels like a weakness in your clients' strategy and it should be corrected (a single host cannot be "that" difficult to mange in an extra tab/bookmark...)