Open Stack

Many Thanks, Rodrigo.


Il giorno lun 8 feb 2021 alle ore 12:56 Rodrigo Barbieri <
rodrigo.barbieri2010 at gmail.com> ha scritto:

> 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/87efaba0/attachment-0001.html>