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@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@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@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@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@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@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@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-rep... > [2] > https://netapp-openstack-dev.github.io/openstack-docs/victoria/manila/exampl... > [3] https://bugs.launchpad.net/manila/+bug/1896949 > > On Fri, Feb 5, 2021 at 8:16 AM Ignazio Cassano < > ignaziocassano@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@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@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@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