automated cross-host VM replication in remote sites

[marauli]

What VM replication or cloning mechanism is most suitable for remote sites each running two ESXi hosts with local storage, with the goal of protecting the site from a single host failure?

• Existing license: vSphere Standard for Retail and Branch Offices (no DR or HA included).
• 15+ remote sites, each with two ESXi hosts. Each ESXi host runs a unique set of VMs.
• Each host has local storage only. No shared storage is used.
• The objective is to protect sites from single host failures by regularly (once a day) replicating all VMs across hosts within each site. If one of the hosts goes down or loses VMs (e.g. if its internal storage get corrupted), the other host would be able to bring those VM clones (replicas) up.
• All sites and ESXis are managed with a single central vCenter instance.

What I imagine (being fairly new to VMware) is something like this:

• Clone all VMs from one host to the other (and the other way around), replacing previous clones, every night at 3am.
  
  • (The "replacing previous clones" part is a fairly important as the hosts have limited storage, and are unlikely to accommodate more than one clone of each VM from the other side.)
  • Should one of the hosts fail, powering up the clones can (and should) be done manually, as some reconfiguration will be needed. I.e. there is no requirement for the time being for the cloned VMs to be powered up automatically should the original ones fail.
  • The mechanism has the added benefit of snapshot-like short-term data backup: should data loss occur within one of the VMs (e.g. due to human error), that data can be restored from the clone of the VM made the previous night. (Snapshots are generally better for this purpose, of course - I am just describing one of the considerations.)
  • If this cloning can be done differentially, i.e. by updating the changed data only in the previously made clone - that would be awesome.

Can this be done exactly like described above using any of the vSphere built-in services like DR or HA? (If not exactly like described above, what's the next best option?)

If not, can something like this be scripted fairly easily, especially the "replace existing clones during cloning" part?

Thanks!

[marauli]

Looks like with respect to scripting, there are fairly similar questions already covered here:

• Clone a VM with a script

...Where a PowerCLI script could check for an existing clone, delete it if needed, start a new clone.

"Scheduled Tasks" was a promising option until it became clear a new clone would fail if there's an existing clone with the same name, and that this existing clone couldn't be renamed or deleted via "Scheduled Tasks".

The two remaining questions are:

• What are the best practices in hosting such a script? (Where to run from - some random Windows machine?, how to securely store needed credentials, how to maintain it - e.g. track changes.)
• Does vSphere DR/HA offer a good alternative? (I.e. can this task be automated there?)

[scott28tt]

vSphere Replication?

https://www.vmware.com/products/vsphere/replication.html

[marauli]

5 hours into this rabbit hole (figuring out how to download, deploy and configure this thing), it looks like it requires a peer vCenter instance?

... which something we don't have:

---

All sites and ESXis are managed with a single central vCenter instance.

---

I.e. vSphere Replication is not for us?

P.S. The "vSphere Replication" article you linked to lists this as one of the use cases:

Data protection locally, within a single site

---

Does this use case still require a "peer" vCenter instance? If not:

• Does it do what I need it to do? (Replicate VMs between two hosts in a remote site.)
• is there a decent "explain this to me like I am a 10-year-old" article telling me how to configure it, what the prerequisites are?
• Is it an overkill for this use case? (Deploying and configuring this appliance to each of the 15+ remote sites where there are limited support resources, i.e. can't afford spending hours on configuring and maintaining it.)