There are two distinct architectures to consider when talking about "Hyper-V":
- The Microsoft Hyper-V Server
- Using Hyper-V replication for a DR plan.
Hyper-V is supported in so far as our Virtualisation support goes. It's an abstracted layer from Progress OpenEdge, we only really care that the underlying OS that's running supports the OpenEdge version installed. For further information refer to Article 000010894,
Does Progress support or certify any OS virtual server? However
replicating a VM with a running Progress database is not supported and moreover hardly reliable as a DR solution if you're going to bet the farm on crash recovery succeeding.
Virtualization layer backups are unreliable for stateful workloads. VMware and HyperV cannot safely backup a running database if there are no tools to talk to the database and quiesce the
database and filesystem concurrently.
Snapshot mechanisms are never designed to be application aware. "
Use the correct tools for the correct job" and for Progress OpenEdge that means:
- Using PROBKUP online or
- For OS copies (which all 3rd party backup/replication products fall under) the use of the PROQUIET utility, available with an Enterprise database license, to quiesce the online database in order that database buffers are first synchronized to disk.
- OpenEdge Replication for replicated sites.
Hyper-V Replication can be used if a PROQUIET is first issued in order that the
Hyper-V Replication can create a transaction consistent backup of the VM running without having to power it off first. For further detail refer to Article 000010649,
Can Third Party tools be used to perform online or offline backups ? There's no point in having this 'Hyper-V replication' if you cannot ensure successful VM recovery as well as proper recovery of all applications installed on the VM without data loss. Anything that's replicating only the
writes on disk is also not going guarantee a reliable recovery as essentially:
- It is a 'crashed' database that is being recovered and this cannot always be guaranteed.
- There's always the chance that if the database blocksize is larger than that of the filesystem, torn pages could result.
- The data physically on disk is not anything like the data in a running database (assuming production and reasonable workload).
If the database is ever used in single user mode, then do not attempt to use a non-Progress backup to copy the files on disk as the non-Progress tool will most likely catch the files midstream as they are dynamically being updated causing the resultant files to more than likely be out of sync.
Last but not least, the way Hyper-V shares memory between virtual machines causes the applications running on those machines to run into compromised resources which slows things down. It has nothing to do with OpenEdge; it is because of the way the Hyper-V is designed to share resources. If
Hyper-V is the required architecture extensive performance testing should be carried out, possibly with the vendor's engagement, prior to production deployment.