[stein][manila] share migration misconfiguration ?

Ignazio Cassano ignaziocassano at gmail.com
Tue Feb 9 06:58:04 UTC 2021


Hello Douglas , so if I want to change the snapmirror schedule I cannot do
it using openstack api but I must use netapp api/ansible or manually, right
?
Thanks
Ignazio

Il Lun 8 Feb 2021, 19:39 Douglas <viroel at gmail.com> ha scritto:

> Hi Ignazio,
>
> The 'replica_state_update_interval' is the time interval that Manila waits
> before requesting a status update to the storage system. It will request
> this information for every replica that isn't 'in-sync' status yet. The
> default value of this config option is actually 300 seconds, not 1 hour.
> You can also manually request this update by issuing 'share-replica-resync'
> operation[1].
> I believe that you might be mixing with the 'snapmirror' schedule concept.
> Indeed, snapmirror relationships are created  with 'schedule' set to be
> hourly. This 'schedule' is used to update the destination replica,
> incrementally, after the snapmirror becames in-sync (snapmirrored), since
> we use Asynchronous SnapMirror[2].
>
> [1]
> https://docs.openstack.org/api-ref/shared-file-system/?expanded=resync-share-replica-detail#resync-share-replica
> [2]
> https://docs.netapp.com/ontap-9/topic/com.netapp.doc.pow-dap/GUID-18263F03-486B-434C-A190-C05D3AFC05DD.html
>
> On Mon, Feb 8, 2021 at 3:01 PM Ignazio Cassano <ignaziocassano at gmail.com>
> wrote:
>
>> Hello All,
>> I have another question about replication sync time, please.
>> I did not specify any option in manila.conf and seems netapp set it one
>> time every hour.
>> I did not understand if replica_state_update_interval is the replication
>> sync time frequency or only checks the replica state.
>> Is there any parameter I can use to setup the replica sync time ?
>> Thanks
>> Ignazio
>>
>>
>>
>> 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
>>>
>>>
>
> --
> Douglas Salles Viroel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210209/282575a1/attachment-0001.html>


More information about the openstack-discuss mailing list