On Tue, Jul 23, 2019 at 6:11 PM Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Mon, Jul 8, 2019 at 10:39 AM Eyal Shenitzky <eshenitz@redhat.com> wrote:
I don't see any reason not to do it in case the SD replicas are separated storage domain.
Just note that for the DR, you should prepare a separated DC with a cluster.

P.S - I most to admit that I didn't try this configuration - please share your results.

Thanks for your insights Eyal. 
I'm going ahead with the tests.
One question arose after creating disaster_recovery_maps.yml and the need to populate all the "secondary_xxx" variable mappings.

In my scenario the primary DC DC1 in Site A has the same network configuration of the primary DC DC2 in Site B.
In fact the main target is to reach better utilization of available resources and so potentially VMs in DC1 communicates with VMs in DC2 in normal conditions.
Now to configure DR I have to create a mapping of DC1 in Site B: if I want to leverage hosts' resources in Site B I'm forced to set it to DC2, correct?

You can use the following manual to understand what is required for the DR process -
https://ovirt.org/documentation/disaster-recovery-guide/active_passive_overview.html

You need the following entities in the secondary site:
  • An active Red Hat Virtualization Manager.
  • A data center and clusters.
  • Networks with the same general connectivity as the primary site.
  • Active hosts capable of running critical virtual machines after failover.
It means you should have at least a dedicated host to perform all the operations on the secondary site (if you have many running VMs you will need more than one host in order to provide a full backup solution).

 
That is the current primary for its storage domain SD2, otherwise I will have no hosts to assign to the cluster inside it... what is the risk of overlapping of objects in this case (supposing I personally take care to not have Vms in DC1 with same name of VMs in DC2, and the same for storage domains' names)? I could have an object, such a disk id that during import would overlap with existing objects n the database? Or will the engine re-create new ids (for vnics, disks, ecc.) while importing them?

The IDs of the entities remains the same as they were in the primary site.
It means that if you are using a site that contains entities and runs operations during the DR process you are risking duplications of names and in low probabilities of duplicated IDs.

Also, the host may not be available to handle the DR and operation may be failed.

 

Other scenario could be to create inside Site B environment another Datacenter with name DC1-DR, and I think I have to create also the same logical networks of DC1 (and DC2 incidentally) and in case of DR I have to take off one of the hosts of DC2 and assign it to DC1-DR....

This option is the best option for DR.
An isolated Data-center that is dedicated to a DR scenario.
It is a trade-off - resources VS robustness

 

Opinions?

Thanks in advance,
Gianluca

 




--
Regards,
Eyal Shenitzky