Open Stack

Hello, I am sorry.

I read the documentation.

SMV must be peered once bye storage admimistrator or using ansible playbook.
I must create a two backend in manila.conf with the same replication domain.
I must assign to the source a type  and set replication type dr.
When I create a share if I want to enable snapmirror for it I must create
on openstack a share replica for it.
The share on destination is read only until I promote it.
When I promote it, it become writable.
Then I can manage it on target openstack.

I hope the above is the correct procedure

Il giorno ven 5 feb 2021 alle ore 13:00 Ignazio Cassano <
ignaziocassano at gmail.com> ha scritto:

> Hi Douglas, you are really kind.
> Let my to to recap and please correct if I am wrong:
>
> - manila share on netapp are under svm
> - storage administrator createx a peering between svm source and svm
> destination (or on single share volume ?)
> - I create a manila share with specs replication type  (the share belongs
> to source svm) . In manila.conf source and destination must have the same
> replication domain
> - Creating the replication type it initializes the snapmirror
>
> Is it correct ?
> Ignazio
>
> Il giorno ven 5 feb 2021 alle ore 12:34 Douglas <viroel at gmail.com> ha
> scritto:
>
>> Hi Ignazio,
>>
>> In order to use share replication between NetApp backends, you'll need
>> that Clusters and SVMs be peered in advance, which can be done by the
>> storage administrators once. You don't need to handle any SnapMirror
>> operation in the storage since it is fully handled by Manila and the NetApp
>> driver. You can find all operations needed here [1][2]. If you have CIFS
>> shares that need to be replicated and promoted, you will hit a bug that is
>> being backported [3] at the moment. NFS shares should work fine.
>>
>> If you want, we can assist you on creating replicas for your shares in
>> #openstack-manila channel. Just reach us there.
>>
>> [1]
>> https://docs.openstack.org/manila/latest/admin/shared-file-systems-share-replication.html
>> [2]
>> https://netapp-openstack-dev.github.io/openstack-docs/victoria/manila/examples/openstack_command_line/section_manila-cli.html#creating-manila-share-replicas
>> [3] https://bugs.launchpad.net/manila/+bug/1896949
>>
>> On Fri, Feb 5, 2021 at 8:16 AM Ignazio Cassano <ignaziocassano at gmail.com>
>> wrote:
>>
>>> Hello, thanks for your help.
>>> I am waiting my storage administrators have a window to help me because
>>> they must setup the snapmirror.
>>> Meanwhile I am trying the host assisted migration but it does not work.
>>> The share remains in migrating for ever.
>>> I am sure the replication-dr works because I tested it one year ago.
>>> I had an openstack on site A with a netapp storage
>>> I had another openstack on Site B with another  netapp storage.
>>> The two openstack installation did not share anything.
>>> So I made a replication between two volumes (shares).
>>> I demoted the source share taking note about its export location list
>>> I managed the destination on openstack and it worked.
>>>
>>> The process for replication is not fully handled by openstack api, so  I
>>> should call netapp api for creating snapmirror relationship or ansible
>>> modules or ask help to my storage administrators , right ?
>>> Instead, using share migration, I could use only openstack api: I
>>> understood that driver assisted cannot work in this case, but host assisted
>>> should work.
>>>
>>> Best Regards
>>> Ignazio
>>>
>>>
>>>
>>> Il giorno gio 4 feb 2021 alle ore 21:39 Douglas <viroel at gmail.com> ha
>>> scritto:
>>>
>>>> Hi Rodrigo,
>>>>
>>>> Thanks for your help on this. We were helping Ignazio in
>>>> #openstack-manila channel. He wants to migrate a share across ONTAP
>>>> clusters, which isn't supported in the current implementation of the
>>>> driver-assisted-migration with NetApp driver. So, instead of using
>>>> migration methods, we suggested using share-replication to create a copy in
>>>> the destination, which will use the storage technologies to copy the data
>>>> faster. Ignazio didn't try that out yet, since it was late in his timezone.
>>>> We should continue tomorrow or in the next few days.
>>>>
>>>> Best regards,
>>>>
>>>> On Thu, Feb 4, 2021 at 5:14 PM Rodrigo Barbieri <
>>>> rodrigo.barbieri2010 at gmail.com> wrote:
>>>>
>>>>> Hello Ignazio,
>>>>>
>>>>> If you are attempting to migrate between 2 NetApp backends, then you
>>>>> shouldn't need to worry about correctly setting the data_node_access_ip.
>>>>> Your ideal migration scenario is a driver-assisted-migration, since it is
>>>>> between 2 NetApp backends. If that fails due to misconfiguration, it will
>>>>> fallback to a host-assisted migration, which will use the
>>>>> data_node_access_ip and the host will attempt to mount both shares. This is
>>>>> not what you want for this scenario, as this is useful for different
>>>>> backends, not your case.
>>>>>
>>>>> if you specify "manila migration-start --preserve-metadata True" it
>>>>> will prevent the fallback to host-assisted, so it is easier for you to
>>>>> narrow down the issue with the host-assisted migration out of the way.
>>>>>
>>>>> I used to be familiar with the NetApp driver set up to review your
>>>>> case, however that was a long time ago. I believe the current NetApp driver
>>>>> maintainers will be able to more accurately review your case and spot the
>>>>> problem.
>>>>>
>>>>> If you could share some info about your scenario such as:
>>>>>
>>>>> 1) the 2 backends config groups in manila.conf (sanitized, without
>>>>> passwords)
>>>>> 2) a "manila show" of the share you are trying to migrate (sanitized
>>>>> if needed)
>>>>> 3) the "manila migration-start" command you are using and its
>>>>> parameters.
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>> On Thu, Feb 4, 2021 at 2:06 PM Ignazio Cassano <
>>>>> ignaziocassano at gmail.com> wrote:
>>>>>
>>>>>> Hello All,
>>>>>> I am trying to migrate a share between a netapp backend to another.
>>>>>> Both backends are configured in my manila.conf.
>>>>>> I am able to create share on both, but I am not able to migrate share
>>>>>> between them.
>>>>>> I am using DSSH=False.
>>>>>> I did not understand how host and driver assisted migration work and
>>>>>> what  "data_node_access_ip" means.
>>>>>> The share I want to migrate is on a network (10.102.186.0/24) that I
>>>>>> can reach by my management controllers network (10.102.184.0/24). I
>>>>>> Can mount share from my controllers and I can mount also the netapp SVM
>>>>>> where the share is located.
>>>>>> So in the data_node_access_ip I wrote the list of my controllers
>>>>>> management ips.
>>>>>> During the migrate phase I checked if my controller where manila is
>>>>>> running mounts the share or the netapp SVM but It does not happen.
>>>>>> Please, what is my mistake ?
>>>>>> Thanks
>>>>>> Ignazio
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Rodrigo Barbieri
>>>>> MSc Computer Scientist
>>>>> OpenStack Manila Core Contributor
>>>>> Federal University of São Carlos
>>>>>
>>>>>
>>>>
>>>> --
>>>> Douglas Salles Viroel
>>>>
>>>
>>
>> --
>> Douglas Salles Viroel
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210205/d9275dee/attachment.html>