On Mon, Jul 8, 2019 at 10:39 AM Eyal Shenitzky <eshenitz(a)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? 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?
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....
Opinions?
Thanks in advance,
Gianluca