On 02/10/2015 06:14 AM, Valeriy Ponomaryov wrote:
Hello Jason,
On Tue, Feb 10, 2015 at 10:07 AM, Jason Bishop <[email protected]
<mailto:[email protected]>> wrote:
When a share is created (from scratch), the manila scheduler
identifies a share server from its list of backends and makes an
api call to create_share method in the appropriate driver. The
driver executes the required steps and returns the export_location
which is then written to the database.
It is not correct description of current approach. Scheduler handles
only capabilities and extra specs, and there is no logic for filtering
based on share servers for the moment.
Correct would be following:
Scheduler (manila-scheduler) chooses host, then sends request "create
share" to chosen manila-share service, which handles all stuff related
to share servers based on share driver logic.
This is something I'd like to change. The scheduler should know about
where the existing (usable) share servers are, and should be able to
prefer a backend with an existing share server over a backend with no
existing share server for share types that would require share servers.
The administrator should control how strongly to weigh this information
within the scheduler.
On Tue, Feb 10, 2015 at 10:07 AM, Jason Bishop <[email protected]
<mailto:[email protected]>> wrote:
Proposed scheme:
The proposal is simple in concept. Instead of the driver
(GenericShareDriver for example) returning both share server ip
address and path in share export_location, only the path is
returned and saved in the database. The binding of the share
server ip address is only determined at share mount time. In
practical terms this means share server is determined by an api
call to the driver when _get_shares is called. The driver would
then have the option of determining which IP address from its
basket of addresses to return. In this way, each share mount
event presents an opportunity for the NFS traffic to be balanced
over all available network endpoints.
It is specific only to GenericShareDriver and mentioned public IP
address is used once for combining export_location from path and this
IP. Other share drivers do not store it and not forced to do it at
all. For example, in case of share driver for NetApp Clustered Data
OnTap stored only one specific information, it is name of vserver. IP
address is taken each time via API of backend.
It is true, that now we have possibility to store only one export
location. I agree, that it would be suitable to have more than one
export_location. So, idea of having multiple export_locations is good.
We absolutely need multiple export locations. But I want that feature
for other reasons than what Jason mentions. Typically, load balancing
can be achieved by in-band techniques such as pNFS which only needs one
export location to get started. The main value of the multiple export
locations for me is to cover cases when a client wants to perform a
mount during a failover event when one or more export locations are
temporarily unreachable.
On Tue, Feb 10, 2015 at 10:07 AM, Jason Bishop <[email protected]
<mailto:[email protected]>> wrote:
I see following cons:
o slow manila list performance
o very slow manila list performance if all share drivers are
busy doing long operations such as create/delete share
First of all, manila-api service does know nothing about share drivers
or backends, that are meanings of different service/process -
manila-share, manila-api uses DB for getting information.
So, you just can not ask share drivers with "list" API call. API
either reads DB and returns something or sends some RPC and returns
some data and does not expect result of RPC.
If you want to change IP addresses, then you need to update DB with
it. Hence, it looks like requirement to have "periodic" task, that
will do it continuously.
Yes. Changing IP addresses would be a big problem because right now
manila doesn't provide a way for the driver to alter the export location
after the share is created.
I prefer to have more than one export locations and allow users to
chose any of them. Also I assume possibility when IP addresses just
changed, in this case we should allow to update export locations.
And second, if we implement multiple export locations for shares,
better to not return it within "list" API response and do it only
within "get" requests.
Agreed.
Valeriy
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
