1:37 a.m.
On Tue, Jul 23, 2019 at 6:11 PM Gianluca Cecchi <gianluca.cecchi(a)gmail.com>
wrote:
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?
You can use the following manual to understand what is required for the DR
process -
https://ovirt.org/documentation/disaster-recovery-guide/active_passive_ov...
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