On Mon, Feb 11, 2019 at 10:18 AM Ignazio Cassano ignaziocassano@gmail.com wrote:
Hello, the manila replication dr works fine on netapp ontap following your suggestions. :-) Source backends (svm for netapp) must belong to a different destination backends availability zone, but in a single manila.conf I cannot specify more than one availability zone. For doing this I must create more share servers ....one for each availability zone. Svm1 with avz1 Svm1-dr with avz1-dr ......... Are you agree??? Thanks & Regards Ignazio
Yes, until the Stein release, you cannot specify multiple availability zones for a single manila share manager service, even if your deployment has multiple storage backends. However, you can run another manila share manager process with a different "storage_availability_zone" parameter as you described.
Il giorno Gio 7 Feb 2019 06:11 Ignazio Cassano ignaziocassano@gmail.com ha scritto:
Many thanks. I'll check today. Ignazio
Il giorno Mer 6 Feb 2019 21:26 Goutham Pacha Ravi gouthampravi@gmail.com ha scritto:
On Wed, Feb 6, 2019 at 12:16 PM Tom Barron tpb@dyncloud.net wrote:
On 06/02/19 17:48 +0100, Ignazio Cassano wrote:
The 2 openstack Installations do not share anything. The manila on each one works on different netapp storage, but the 2 netapp can be synchronized. Site A with an openstack instalkation and netapp A. Site B with an openstack with netapp B. Netapp A and netapp B can be synchronized via network. Ignazio
OK, thanks.
You can likely get the share data and its netapp metadata to show up on B via replication and (gouthamr may explain details) but you will lose all the Openstack/manila information about the share unless Openstack database info (more than just manila tables) is imported. That may be OK foryour use case.
-- Tom
Checking if I understand your request correctly, you have setup manila's "dr" replication in OpenStack A and now want to move your shares from OpenStack A to OpenStack B's manila. Is this correct?
If yes, you must:
- Promote your replicas
- this will make the mirrored shares available. This action does
not delete the old "primary" shares though, you need to clean them up yourself, because manila will attempt to reverse the replication relationships if the primary shares are still accessible
- Note the export locations and Unmanage your shares from OpenStack A's manila
- Manage your shares in OpenStack B's manila with the export locations
you noted.
Il giorno Mer 6 Feb 2019 16:32 Tom Barron tpb@dyncloud.net ha scritto:
On 06/02/19 15:34 +0100, Ignazio Cassano wrote: >Hello Tom, I think cases you suggested do not meet my needs. >I have an openstack installation A with a fas netapp A. >I have another openstack installation B with fas netapp B. >I would like to use manila replication dr. >If I replicate manila volumes from A to B the manila db on B does not >knows anything about the replicated volume but only the backends on netapp >B. Can I discover replicated volumes on openstack B? >Or I must modify the manila db on B? >Regards >Ignazio
I guess I don't understand your use case. Do Openstack installation A and Openstack installation B know *anything* about one another? For example, are their keystone and neutron databases somehow synced? Are they going to be operative for the same set of manila shares at the same time, or are you contemplating a migration of the shares from installation A to installation B?
Probably it would be helpful to have a statement of the problem that you intend to solve before we consider the potential mechanisms for solving it.
Cheers,
-- Tom
> > >Il giorno Dom 3 Feb 2019 11:05 Tom Barron tpb@dyncloud.net ha scritto: > >> On 01/02/19 07:28 +0100, Ignazio Cassano wrote: >> >Thanks Goutham. >> >If there are not mantainers for this driver I will switch on ceph and or >> >netapp. >> >I am already using netapp but I would like to export shares from an >> >openstack installation to another. >> >Since these 2 installations do non share any openstack component and have >> >different openstack database, I would like to know it is possible . >> >Regards >> >Ignazio >> >> Hi Ignazio, >> >> If by "export shares from an openstack installation to another" you >> mean removing them from management by manila in installation A and >> instead managing them by manila in installation B then you can do that >> while leaving them in place on your Net App back end using the manila >> "manage-unmanage" administrative commands. Here's some documentation >> [1] that should be helpful. >> >> If on the other hand by "export shares ... to another" you mean to >> leave the shares under management of manila in installation A but >> consume them from compute instances in installation B it's all about >> the networking. One can use manila to "allow-access" to consumers of >> shares anywhere but the consumers must be able to reach the "export >> locations" for those shares and mount them. >> >> Cheers, >> >> -- Tom Barron >> >> [1] >> https://netapp.github.io/openstack-deploy-ops-guide/ocata/content/manila.exa... >> > >> >Il giorno Gio 31 Gen 2019 20:56 Goutham Pacha Ravi < >> gouthampravi@gmail.com> >> >ha scritto: >> > >> >> Hi Ignazio, >> >> >> >> On Thu, Jan 31, 2019 at 7:31 AM Ignazio Cassano >> >> ignaziocassano@gmail.com wrote: >> >> > >> >> > Hello All, >> >> > I installed manila on my queens openstack based on centos 7. >> >> > I configured two servers with glusterfs replocation and ganesha nfs. >> >> > I configured my controllers octavia,conf but when I try to create a >> share >> >> > the manila scheduler logs reports: >> >> > >> >> > Failed to schedule create_share: No valid host was found. Failed to >> find >> >> a weighted host, the last executed filter was CapabilitiesFilter.: >> >> NoValidHost: No valid host was found. Failed to find a weighted host, >> the >> >> last executed filter was CapabilitiesFilter. >> >> > 2019-01-31 16:07:32.614 159380 INFO manila.message.api >> >> [req-241d66b3-8004-410b-b000-c6d2d3536e4a >> 89f76bc5de5545f381da2c10c7df7f15 >> >> 59f1f232ce28409593d66d8f6495e434 - - -] Creating message record for >> >> request_id = req-241d66b3-8004-410b-b000-c6d2d3536e4a >> >> >> >> >> >> The scheduler failure points out that you have a mismatch in >> >> expectations (backend capabilities vs share type extra-specs) and >> >> there was no host to schedule your share to. So a few things to check >> >> here: >> >> >> >> - What is the share type you're using? Can you list the share type >> >> extra-specs and confirm that the backend (your GlusterFS storage) >> >> capabilities are appropriate with whatever you've set up as >> >> extra-specs ($ manila pool-list --detail)? >> >> - Is your backend operating correctly? You can list the manila >> >> services ($ manila service-list) and see if the backend is both >> >> 'enabled' and 'up'. If it isn't, there's a good chance there was a >> >> problem with the driver initialization, please enable debug logging, >> >> and look at the log file for the manila-share service, you might see >> >> why and be able to fix it. >> >> >> >> >> >> Please be aware that we're on a look out for a maintainer for the >> >> GlusterFS driver for the past few releases. We're open to bug fixes >> >> and maintenance patches, but there is currently no active maintainer >> >> for this driver. >> >> >> >> >> >> > I did not understand if controllers node must be connected to the >> >> network where shares must be exported for virtual machines, so my >> glusterfs >> >> are connected on the management network where openstack controllers are >> >> conencted and to the network where virtual machine are connected. >> >> > >> >> > My manila.conf section for glusterfs section is the following >> >> > >> >> > [gluster-manila565] >> >> > driver_handles_share_servers = False >> >> > share_driver = manila.share.drivers.glusterfs.GlusterfsShareDriver >> >> > glusterfs_target = root@10.102.184.229:/manila565 >> >> > glusterfs_path_to_private_key = /etc/manila/id_rsa >> >> > glusterfs_ganesha_server_username = root >> >> > glusterfs_nfs_server_type = Ganesha >> >> > glusterfs_ganesha_server_ip = 10.102.184.229 >> >> > #glusterfs_servers = root@10.102.185.19 >> >> > ganesha_config_dir = /etc/ganesha >> >> > >> >> > >> >> > PS >> >> > 10.102.184.0/24 is the network where controlelrs expose endpoint >> >> > >> >> > 10.102.189.0/24 is the shared network inside openstack where virtual >> >> machines are connected. >> >> > >> >> > The gluster servers are connected on both. >> >> > >> >> > >> >> > Any help, please ? >> >> > >> >> > Ignazio >> >> >>