Open Stack

Yes, you are correct. We didn't provide this configuration and you probably
don't need to worry about it when promoting a share. If you call
'replica-promote' api, for your 'dr' replica, the NetApp driver will
automatically trigger a snapmirror sync to get the last minute updates,
before actually breaking the relationship.

On Tue, Feb 9, 2021 at 3:58 AM Ignazio Cassano <ignaziocassano at gmail.com>
wrote:

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

-- 
Douglas Salles Viroel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210209/a56b813a/attachment-0001.html>