Open Stack

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