On 02/04/2015 07:01 PM, Li, Chen wrote:
Hi,
Thanks very much for the reply.
Really sorry for the late response.
In your case if you have a driver that doesn't handle share servers,
then the network is complete out of scope for Manila. Drivers that
don't manage share servers have neither flat not segment networking in
Manila, they have NO networking.
ðSo, you mean there is no way I can work as I want, right ?
But, is it possible to enable that ?
I think you missed the point when I say networking is out of scope for
non-share-server-handling drivers. All that that means is that Manila
will not be involved with the management of the network resources for
the backend or the network paths between the clients and the server. The
reason for this is to allow administrators to configure the network
however they like. Arbitrarily complicated network designs are possible
when you use a driver with driver_manages_share_servers=False because
you're free to do what you want and Manila doesn't care.
I think people sometimes forget that Manila doesn't want to be involved
with network management. We only touch the network where it's
unavoidable, such as when we have to create new virtual machines that
need to be reachable over the network from existing VMs. There already
exist many other great tools inside and outside of OpenStack for doing
network management and we want to avoid duplicating or overlapping with
their functionality as much as possible.
If you noticed, we’re trying to enable HDFS in manila:
https://blueprints.launchpad.net/manila/+spec/hdfs-driver
That’s the main reason I want to emphasize on my driver do not handle
share server.
Big data users want to have a unify storage when they’re working in cloud.
Because instances are not reliable resource in cloud. Put data
together with instances while making sure data’s reliability would be
complicated.
The biggest difference between HDFS and all currently backends manila
support is:
HDFS has different control path and data path.
For a HDFS cluster, it has one name node and multi data nodes.
Client would talk to “name node” first, get data location and then
talk to data nodes to get data.
The “Export location” represent “name node” information only.
ðWe can’t put any “share-server” in the middle of user instances and
HDFS cluster.
But, it do possible to let the HDFS work in the cloud with restrictions
ðIt can only support one share-network at one time.
This actually restrict the ability of the manila backend, no
multi-tenancy at all.
We want to use HDFS like this:
Connect users’ “share-network” and “HDFS-cluster-network” by router.
Similar to currently generic driver’s behavior when
“connect_share_server_to_tenant_network = False” while no
“share-server” exist.
Access control is achieved based on its own user.
We can add some access control based on keystone users and keystone
tenants to avoid bad users to connect to HDFS cluster at very
beginning if that’s possible.
Thanks.
-chen
*From:*Ben Swartzlander [mailto:b...@swartzlander.org]
*Sent:* Wednesday, January 28, 2015 12:35 PM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [Manila]Questions about using not
handle share-servers drivers with "Flat network"
On 01/27/2015 06:39 PM, Li, Chen wrote:
Hi list,
I have some questions.
Hope can get help from you guys.
Manila has two driver modes.
For handle share server drivers, the share-network is easy to understand.
For not handle share-servers drivers, manila request admin to do
everything before manila-share service start, and when the service is
running, it only serves requests do not contain "share-network".
I kept confusing about which/why users would create shares without
"share-network". Although when working with this kind of driver, the
manila-share service can only support one specific network restricted
by the backend. But “users” do not know backends, they should always
want to create shares with "share-network", because users always want
to connect shares to their instances that lives in the cloud with
“share-network”.
Then I have been told that these shares created without
"share-network" are assumed to be used on a "public network".
The "public network" do make a clear explanation about why
"share-network" not matter anymore.
But, when I build my cloud with Manila, what I want to do is let
backends to serve my “Flat network”.
I want to have 2 backends in Manila, both of them are “*/not/*
handle share-servers drivers”.
I set 192.168.6.253 for backend1 and create a “Flat network” in
neutron with subnet 192.168.6.0/24 with IP range from
192.168.6.1-192.168.6.252.
I set 192.168.7.253 for backend2 and create a “Flat network” in
neutron with subnet 192.168.7.0/24 with IP range from
192.168.7.1-192.168.7.252.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
The reason I build my cloud like this is because I want to do
some performance tests on both backends, to compare the two backends.
I think it should not hard to do it, but manila do not support
that currently.
So, is this the behavior should work ?
Or anything else I missed ?
Manila needs to support backends that can create share servers and
backends that can't create share servers. We do this because of the
reality that different storage systems have different capabilities and
designs, and we don't want to block anything that can reasonably
described as a shared filesystem from working with Manila.
For the purposes of Manila, a share server is a logically isolated
instance of a file share server, with its own IP address, routing
tables, security domain, and name services. Manila only tracks the
existence of share servers that were created as the result of a
share-create operation. Share servers created by manila have IP
addresses assigned by Manila, and can be expected to be deleted by
Manila sometime after the last share on that share server is deleted.
Backends that simply create shares on a preexsting storage systems are
not referred to as share servers and networking concerns for those
systems are out of scope for Manila.
The reason we distinguish between so-called "flat" and "segmented"
networks is to accommodate the reality that in the real world, storage
systems often exist inside labs and datacenters where the network is
not under the control of the storage admin. This was a key point we
identified during Juno and one of the major reasons for the network
rearchitecture during Kilo. If a storage controller is connected into
a flat subnet it may be able to create share servers on that subnet,
but nothing more fancy. To participate in multiple subnets some form
of network virtualization or segmentation is required and oftentimes
that's not possible either due to lack of support on the storage
controller, lack of support in the network due to physical or
administrative limitations, or even lack of sophistication on the part
of the deployer (don't discount this last one -- the difficulty of
getting the network right is a major blocker for admins who want to
try out Manila).
What flat network means from Manila's perspective is that share
servers may be created but only on a network predefined by the
administrator, and not on any tenant-defined network. Connectivity
between the tenant network and the share server network is considered
out of scope for Manila. Segmented network means that Manila presumes
complete control of the network through some powerful plugin such as
Neutron such that Manila can connect share servers to any network
specified by the tenant, and Manila assumes responsibility for
establishing any needed routes.
In your case if you have a driver that doesn't handle share servers,
then the network is complete out of scope for Manila. Drivers that
don't manage share servers have neither flat not segment networking in
Manila, they have NO networking.
I'll do a followup mail on the UI changes that are coming around share
networks and the mess that they have become. For now, you just have to
know that share networks should not be used with drivers that don't
manage share servers, and they should be used with drivers that do
manage share servers.
-Ben Swartzlander
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
