[gpfsug-discuss] OpenStack Manila Driver

[Bill Owen]

Hi Luke,
Your explanation below is correct, with some minor clarifications

Manila is an OpenStack project which allows storage admins to create and
destroy filesystem shares and make those available to  vm instances and
bare metal servers which would be accessed over NFS.   The Manila driver
runs in the control plane and creates a new gpfs independent fileset for
each new share.  It provides automation for giving vm's (and also bare
metal servers) acces to the shares so that they can mount and use the
share.  There is work being done to allow automating the mount process when
the vm instance boots.

The tenants don’t have root access to the file system, but the Manila
component acts as a wrapper to file system administrative equivalents like
mmcrfileset, mmdelfileset, link and unlink. The shares are created as GPFS
filesets which are then presented over NFS.

The manila driver uses the following gpfs commands:
When a share is created:
mmcrfileset
mmlinkfileset
mmsetquota

When a share is deleted:
mmunlinkfileset
mmdelfileset

Snapshots of shares can be created and deleted:
mmcrsnapshot
mmdelsnapshot

Today, the GPFS Manila driver supports creating NFS exports to VMs.  We are
considering adding native GPFS client support in the VM, but not sure if
the benefit justifies the extra complexity of having gpfs client in vm
image, and also the impact to cluster as vm's come up and down in a more
dynamic way than physical nodes.

For multi-tenant deployments, we recommend using a different filesystem per
tenant to provide better separation of data, and to minimize the "noisy
neighbor" effect for operations like mmunlinkfileset.

Here is a presentation that shows an overview of the GPFS Manila driver:
(See attached file: OpenStack_Storage_Manila_with_GPFS.pdf)

Perhaps this, and other GPFS & OpenStack topics could be the subject of a
future user group session.

Regards,
Bill Owen
billowen at us.ibm.com
GPFS and OpenStack
520-799-4829




From:	Luke Raimbach <Luke.Raimbach at crick.ac.uk>
To:	gpfsug main discussion list <gpfsug-discuss at gpfsug.org>
Date:	06/16/2015 12:37 AM
Subject:	Re: [gpfsug-discuss] OpenStack Manila Driver
Sent by:	gpfsug-discuss-bounces at gpfsug.org



So as I understand things, Manila is an OpenStack component which allows
tenants to create and destroy shares for their instances which would be
accessed over NFS. Perhaps I’ve not done enough research in to this though
– I’m also not an OpenStack expert.

The tenants don’t have root access to the file system, but the Manila
component must act as a wrapper to file system administrative equivalents
like mmcrfileset, mmdelfileset, link and unlink. The shares are created as
GPFS filesets which are then presented over NFS.

The unlinking of the fileset worries me for the reasons stated previously.

From: gpfsug-discuss-bounces at gpfsug.org [
mailto:gpfsug-discuss-bounces at gpfsug.org] On Behalf Of Wahl, Edward
Sent: 15 June 2015 15:00
To: gpfsug main discussion list
Subject: Re: [gpfsug-discuss] OpenStack Manila Driver

Perhaps I misunderstand here, but if the tenants have administrative
(ie:root) privileges to the underlying file system management commands I
think mmunlinkfileset might be a minor concern here.  There are FAR more
destructive things that could occur.

I am not an OpenStack expert and I've not even looked at anything past
Kilo,  but my understanding was that these commands were not necessary for
tenants.  They access a virtual block device that backs to GPFS, correct?

Ed Wahl
OSC



++
From: gpfsug-discuss-bounces at gpfsug.org [gpfsug-discuss-bounces at gpfsug.org]
on behalf of Luke Raimbach [Luke.Raimbach at crick.ac.uk]
Sent: Monday, June 15, 2015 4:35 AM
To: gpfsug-discuss at gpfsug.org
Subject: [gpfsug-discuss] OpenStack Manila Driver
Dear All,

We are looking forward to using the manila driver for auto-provisioning of
file shares using GPFS. However, I have some concerns...

Manila  presumably gives tenant users access to file system commands like
mmlinkfileset and mmunlinkfileset. Given that mmunlinkfileset quiesces the
file system, there is potentially an impact from one tenant on another -
i.e. someone unlinking and deleting a lot of filesets during a tenancy
cleanup might cause a cluster pause long enough to trigger other failure
events or even start evicting nodes. You can see why this would be bad in a
cloud environment.


Has this scenario been addressed at all?

Cheers,
Luke.


Luke Raimbach​
Senior HPC Data and Storage Systems Engineer
The Francis Crick Institute
Gibbs Building
215 Euston Road
London NW1 2BE

E: luke.raimbach at crick.ac.uk
W: www.crick.ac.uk

The Francis Crick Institute Limited is a registered charity in England and
Wales no. 1140062 and a company registered in England and Wales no.
06885462, with its registered office at 215 Euston Road, London NW1 2BE.
The Francis Crick Institute Limited is a registered charity in England and
Wales no. 1140062 and a company registered in England and Wales no.
06885462, with its registered office at 215 Euston Road, London NW1 2BE.
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at gpfsug.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20150617/9ac977b7/attachment-0003.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20150617/9ac977b7/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenStack_Storage_Manila_with_GPFS.pdf
Type: application/pdf
Size: 354887 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20150617/9ac977b7/attachment-0003.pdf>