[ovirt-users] oVirt DR: ansible with 4.1, only a subset of storage domain replicated
Maor Lipchuk
mlipchuk at redhat.com
Thu Feb 8 11:36:10 UTC 2018
On Thu, Feb 8, 2018 at 10:34 AM, Luca 'remix_tj' Lorenzetto <
lorenzetto.luca at gmail.com> wrote:
> On Tue, Feb 6, 2018 at 9:33 PM, Maor Lipchuk <mlipchuk at redhat.com> wrote:
> [cut]
> >> What i need is that informations about vms is replicated to the remote
> >> site with disk.
> >> In an older test i had the issue that disks were replicated to remote
> >> site, but vm configuration not!
> >> I've found disks in the "Disk" tab of storage domain, but nothing on VM
> >> Import.
> >
> >
> >
> > Can you reproduce it and attach the logs of the setup before the disaster
> > and after the recovery?
> > That could happen in case of new created VMs and Templates which were not
> > yet updated in the OVF_STORE disk, since the OVF_STORE update process was
> > not running yet before the disaster.
> > Since the time of a disaster can't be anticipated, gaps like this might
> > happen.
> >
>
> I haven't tried the recovery yet using ansible. It was an experiment
> of possible procedure to be performed manually and was on 4.0.
> I asked about this unexpected behavior and Yaniv returned me that was
> due to OVF_STORE not updated and that in 4.1 there is an api call that
> updates OVF_STORE on demand.
>
> I'm creating a new setup today and i'll test again and check if i
> still hit the issue. Anyway if the problem persist i think that
> engine, for DR purposes, should upgrade the OVF_STORE as soon as
> possible when a new vm is created or has disks added.
>
If engine will update the OVF_STORE on any VM change that could reflect the
oVirt performance since it is a heavy operation,
although we do have some ideas to change that design so every VM change
will only change the VM OVF instead of the whole OVF_STORE disk.
> [cut]
> >>
> >> Ok, but if i keep master storage domain on a non replicate volume, do
> >> i require this function?
> >
> >
> > Basically it should also fail on VM/Template registration in oVirt 4.1
> since
> > there are also other functionalities like mapping of OVF attributes which
> > was added on VM/Templates registeration.
> >
>
> What do you mean? That i could fail to import any VM/Template? In what
> case?
>
If using the fail-over in ovirt-ansible-disaster-recovery, the VM/Template
registration process is being done automatically through the ovirt-ansible
tasks and it is based on the oVirt 4.2 API.
The task which registers the VMs and the Templates is being done there
without indicating the target cluster id, since in oVirt 4.2 we already
added the cluster name in the VM's/Template's OVF.
If your engine is oVirt 4.1 the registration will fail since in oVirt 4.1
the cluster id is mandatory.
>
> Another question:
>
> we have 2 DCs in main site, do we require to have also 2 DCs in
> recovery site o we can import all the storage domains in a single DC
> on recovery site? There could be uuid collisions or similar?
>
I think it could work, although I suggest that the clusters should be
compatible with those configurd in the primary setup
otherwise you might encounter problems when you will try to fail back (and
also to avoid any collisions of affinity groups/labels or networks).
For example if in your primary site you had DC1 with cluster1 and DC2 with
cluster2 then your secondary setup should be DC_Secondary with cluster_A
and cluster_B.
cluster1 will be mapped to cluster_A and cluster2 will be mapped to
cluster_B.
Another thing that might be troubling is with the master domain attribute
in the mapping var file.
That attribute indicates which storage domain is master or not.
Here is an example how it is being configured in the mapping file:
- dr_domain_type: nfs
dr_primary_dc_name: Prod
dr_primary_name: data_number
dr_master_domain: True
dr_secondary_dc_name: Recovery
dr_secondary_address:
...
In your primary site you have two master storage domains, and in your
secondary site what will probably happen is that on import of storage
domains only one of those two storage domains will be master.
Now that I think of it, it might be better to configure the master
attribute for each of the setups, like so:
dr_primary_master_domain: True
dr_secondary_master_domain: False
>
> Thank you so much for your replies,
>
> Luca
> --
> "E' assurdo impiegare gli uomini di intelligenza eccellente per fare
> calcoli che potrebbero essere affidati a chiunque se si usassero delle
> macchine"
> Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716)
>
> "Internet è la più grande biblioteca del mondo.
> Ma il problema è che i libri sono tutti sparsi sul pavimento"
> John Allen Paulos, Matematico (1945-vivente)
>
> Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , <
> lorenzetto.luca at gmail.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20180208/03ecf6d0/attachment.html>
More information about the Users
mailing list