Open Stack

Hi Ignazio,

The way you set it up is correct with "enabled_share_backends =
svm-tst-nfs-565,netapp-nfs-566". You need both backends enabled for the
feature to work.

Regards,

Rodrigo

On Mon, Feb 8, 2021 at 8:52 AM Ignazio Cassano <ignaziocassano at gmail.com>
wrote:

> 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
>>>
>>

-- 
Rodrigo Barbieri
MSc Computer Scientist
OpenStack Manila Core Contributor
Federal University of São Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210208/9877d2fd/attachment-0001.html>