|
|
| (42 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| − | | + | #REDIRECT [[Manila]] |
| − | * '''Launchpad Entry''': cinder-protocol-enhancements
| |
| − | * '''Created''': 29 Sep 2012
| |
| − | * '''Contributors''': Robert Esker, Ben Swartzlander
| |
| − | | |
| − | == Introduction ==
| |
| − | | |
| − | This document is intended to vet a concept and establish a vision for establishing a shared file system service to OpenStack. The primary consumption of shares would be across OpenStack Compute instances, but the capability is intended to be available as an independent generalized service as well in line with the modular design established by other OpenStack services. More detailed blueprints (in Launchpad) and further detail in this specification will follow as necessary.
| |
| − | | |
| − | | |
| − | == Background ==
| |
| − | | |
| − | === Cinder characteristics ===
| |
| − | A partial list of things to consider about Cinder relevant to the File Shares Service:
| |
| − | | |
| − | * The [[OpenStack]] [[Cinder]] project separates the former nova-volume into an independent block storage service debuting in the Folsom release.
| |
| − | * Cinder provides a data persistence model for application data and Nova instances which are otherwise assumed ephemeral.
| |
| − | * Ad hoc requests for storage, whether by running instances or outside of the Nova context can be accommodated either programmatically via the Cinder API or via the python-cinderclient tool.
| |
| − | * Cinder, in the initial form and as a legacy of nova-volume, provides a block only construct.
| |
| − | * Cinder volumes (aka block devices) are not (as of the Grizzly release) shareable among multiple simultaneous instances
| |
| − | * Cinder, in it's original role as a control plane for block device access, provides facility for many of the concepts that a File Shares service would depend upon. The present Cinder concepts of volume_types, extra_specs, snapshots, clones, the filter scheduler and more are broadly applicable to both. Storage concepts such as initiator (client), target (server), and capacity are likewise common conceptually (if not entirely semantically).
| |
| − | | |
| − | == High-level proposal ==
| |
| − | | |
| − | Concordant with the transition from nova-volume to Cinder, the opportunity to define a broader vision for storage provisioning in [[OpenStack]] exists. An expanded vision for Cinder is both appropriate for an independent project / service in [[OpenStack]] and is also timely given a variety of user driven requirements advocating for expanded capabilities. We propose and intend to act to evolve Cinder as the canonical storage provisioning control plane in [[OpenStack]] independent of storage protocol type (whether block or file). This proposal and associated blueprints intend to, in phases, accommodate file-based storage as well. Please note that object storage is not considered in scope given well established API and mechanisms (i.e. Swift). This blueprint should be treated as an overarching / umbrella design document with separate blueprints defined for each of the phases and to also account for "whole experience" interaction.
| |
| − | | |
| − | == Blueprints ==
| |
| − | | |
| − | The master blueprint is here: [https://blueprints.launchpad.net/cinder/+spec/cinder-protocol-enhancements Cinder Protocol Enhancements]
| |
| − | | |
| − | === 1) File-Based Volume Driver ===
| |
| − | | |
| − | Implementation of a Cinder file-based volume driver. This makes use of files as virtual block devices for mounted file systems already present at the hypervisor. The hypervisor would still present the file into the instance as a block device.
| |
| − | | |
| − | [https://blueprints.launchpad.net/cinder/+spec/nfs-files-as-virtual-block-devices Allow the use of NFS files as virtual block devices]
| |
| − | | |
| − | Note: the above provides generic NFS support as a reference implementation
| |
| − | | |
| − | [https://blueprints.launchpad.net/cinder/+spec/netapp-nfs-cinder-driver NetApp-NFS Driver for Cinder]
| |
| − | | |
| − | === 2) Extension of the Cinder API ===
| |
| − | | |
| − | Extension of the [http://api.openstack.org Cinder API] to accommodate:
| |
| − | | |
| − | * Creation of file system shares (e.g. the create API needs to support a "protocol" & a permissions "mask" and "ownership" parameters)
| |
| − | * Coordination of mounting file system shares
| |
| − | * Creation & deletion of snapshots & clones
| |
| − | * List, show, provide and deny access to file system shares
| |
| − | * Unmounting file systems shares
| |
| − | * Deletion of file systems shares
| |
| − | * Snapshot, list snapshots, and delete snapshots of file system shares
| |
| − | | |
| − | The API description is here: [[CinderProtocolEnhancementsAPI|Cinder Protocol Enhancements API Proposal]]
| |
| − | | |
| − | === 3) Extended API Reference Driver ===
| |
| − | | |
| − | Creation of a reference Cinder driver for shared file system use under the proposed expanded API. As an example, a [[NetApp]] driver for this would be able to advertise, accept, and respond to requests for NFSv3, NFSv4, NFSv4.1 (w/ pNFS), & contemporary CIFS / SMB protocols (eg versions 2, 2.1, 3). Additional modification of python-cinderclient will be necessary to provide for the expanded array of request parameters.
| |
| − | | |
| − | === 4) Control of NAS Storage Mounting from Cinder ===
| |
| − | | |
| − | Proposal for handling injection / updates of mounts to instantiated guests operating in the Nova context. A listener / agent that could either be interacted directly or more likely poll or receive updates from instance metadata changes would represent one possible solution.
| |
| − | | |
| − | === 5) Quantum Support ===
| |
| − | | |
| − | Full consideration for cross-instance network encapsulation as part of a Quantum & Keystone integrated security model.
| |
| − | | |
| − | == Reference ==
| |
| − | | |
| − | Please refer to the [[OpenStack]] [[Glossary]] for a standard definition of terms. Additionally, the following may clarify, add to, or differ slightly from those definitions:
| |
| − | | |
| − | * volume: persistent (non-ephemeral) block-based storage. Note that this definition may (and often does) conflict with vendor-specific definitions.
| |
| − | * file system: a system for organizing and storing data in directories and files. A shared file system provides (and arbitrates) concurrent access from multiple clients generally over IP networks and via established protocols.
| |
| − | * NFS: [http://en.wikipedia.org/wiki/Network_File_System Network File System]
| |
| − | * CIFS: [http://en.wikipedia.org/wiki/Server_Message_Block Common Internet File System]
| |
| − | * GlusterFS: [http://en.wikipedia.org/wiki/GlusterFS GlusterFS]
| |
| − | * Ceph: [http://en.wikipedia.org/wiki/Ceph_(storage)#File_System Ceph]
| |
| − | ----
| |
| − | [[Category:Spec]] | |
