Open Stack

Hello All,
I am able to replicate shares between netapp storages but I have some
questions.
Reading netapp documentation, seems the replication svm must not be enabled
in manila.conf.
The following is what netapp suggests:

enabled_share_backends = svm-tst-nfs-565

[svm-tst-nfs-565]
share_backend_name = svm-tst-nfs-565
driver_handles_share_servers = false
share_driver = manila.share.drivers.netapp.common.NetAppDriver
netapp_storage_family = ontap_cluster
netapp_server_hostname = fas8040.csi.it
netapp_server_port = 80
netapp_login = admin
netapp_password = ******
netapp_transport_type = http
netapp_vserver = svm-tst-nfs-565
netapp_aggregate_name_search_pattern = ^((?!aggr0).)*$
replication_domain = replication_domain_1


[netapp-nfs-566]
share_backend_name = netapp-nfs-566
driver_handles_share_servers = False
share_driver = manila.share.drivers.netapp.common.NetAppDriver
netapp_storage_family = ontap_cluster
netapp_server_hostname = fas.csi.it
netapp_server_port = 80
netapp_login = admin
netapp_password = *****
netapp_transport_type = http
netapp_vserver = manila-nfs-566
netapp_aggregate_name_search_pattern = ^((?!aggr0).)*$
replication_domain = replication_domain_1

As you can see above, the target of replica netapp-nfs-566 is not included
in enabled backends.

When I try to create a replica in this situation, the manila schedule
reports "no valid host found".

It works if I enable in manila.conf the target like this:
enabled_share_backends = svm-tst-nfs-565,netapp-nfs-566

Please, any suggestion ?

Thanks
Ignazio


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

> 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/20210208/6761680b/attachment-0001.html>