Open Stack

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210205/0b323b1c/attachment.html>