Open Stack

Thanks, Douglas.
On another question:
the manila share-replica-delete delete the snapmirror ?
If yes, source and destination volume become both writable ?

Ignazio

Il giorno ven 5 feb 2021 alle ore 13:48 Douglas <viroel at gmail.com> ha
scritto:

> Yes, it is correct. This should work as an alternative for
> host-assisted-migration and will be faster since it uses storage
> technologies to synchronize data.
> If your share isn't associated with a share-type that has
> replication_type='dr' you can: 1) create a new share-type with
> replication_type extra-spec, 2) unmanage your share, 3) manage it again
> using the new share-type.
>
>
>
> On Fri, Feb 5, 2021 at 9:37 AM Ignazio Cassano <ignaziocassano at gmail.com>
> wrote:
>
>> 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
>>>>
>>>
>
> --
> Douglas Salles Viroel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210205/c9717472/attachment.html>