From Fedora Project Wiki
No edit summary
Line 11: Line 11:
== Current status ==
== Current status ==
* Targeted release: [[Releases/16 | Fedora 16]]  
* Targeted release: [[Releases/16 | Fedora 16]]  
* Last updated: 2011-04-11
* Last updated: 2011-06-01
* Percentage of completion: 20%
* Percentage of completion: 80%


== Detailed Description ==
== Detailed Description ==
Line 21: Line 21:
* Encryption, both on the wire and at rest.
* Encryption, both on the wire and at rest.


* Multi-tenancy (isolating tenants' namespaces from one another).
* Multi-tenancy (isolating tenants' namespaces and IDs from one another).


* Quota and accounting support.
* A management framework (CLI and web app) to configure the other features.


All of these features can be implemented in a modular way, so that users can deploy only those they deem necessary or appropriate for their situation.
All of these features can be implemented in a modular way, so that users can deploy only those they deem necessary or appropriate for their situation.


The long-term plan for CloudFS includes multi-site replication, but that is '''not''' part of the current proposal.
The long-term plan for CloudFS includes performance/scalability enhancements and multi-site replication, but those are '''not''' part of the current proposal.


== Benefit to Fedora ==
== Benefit to Fedora ==
Line 33: Line 33:


== Scope ==
== Scope ==
The scope of work for this feature is mostly limited to the existing <code>glusterfs</code> package, though it might also require creation of a new package with that as a dependencyEach of the features described above can be implemented as a "translator" (separately loadable module/plugin).  There might need to be some enhancement of the GlusterFS CLI etc. to support configuration of currently-unrecognized translators using standard commands.  Lastly, some features will also require commands/libraries to manage tenants and tenant-associated artifacts (e.g. encryption keys), to set quotas, to retrieve usage information, etc.
The scope of work for this feature mostly consists of the <code>CloudFS</code> package.  Some of the code is also part of the existing <code>glusterfs</code> package, either in the form of CloudFS-related patches or whole features (e.g. SSL-based authentication and transport encryption).


== How To Test ==
== How To Test ==
As a distributed filesystem, testing requires at least two and ideally four or more server nodes.  Since the specific goal of CloudFS is to provide various kinds of protection between tenants it's best to have at least two client nodes mounting as different tenants.  All of these nodes must have the <code>glusterfs</code> package installed, and can be virtual for testing purposes.
As a distributed filesystem, testing requires at least two and ideally four or more server nodes.  Since the specific goal of CloudFS is to provide various kinds of protection between tenants it's best to have at least two client nodes mounting as different tenants.  All of these nodes must have a current and compatible version of the <code>glusterfs</code> package installed, and can be virtual for testing purposes.


Configuration is mostly as described at [http://www.gluster.com/community/documentation/index.php/Main_Page], with additional '''TBD''' options on the "gluster volume create" line to load CloudFS-specific translators.
Configuration is mostly as described in [http://git.fedorahosted.org/git/?p=CloudFS.git;a=blob;f=doc/mgmt_manual.md;h=bfcbbe9769f8726ecd1aefcf19e1159074971110;hb=HEAD the official manual] and [http://cloudfs.org/2011/05/new-management-interface/ web screenshots].  At a minimum, you'll need to create a pool/cluster and a volume first. Testing from that point is largely feature-dependent.  Referring to the above feature list:
 
Testing is largely feature-dependent.  Referring to the above feature list:


* Auth*: verify that different users can mount and use their own portions of the shared filesystem, and not mount/use each other's.
* Auth*: verify that different users can mount and use their own portions of the shared filesystem, and not mount/use each other's.
Line 46: Line 44:
* Encryption: verify that data are being encrypted in transit (using <code>tcpdump</code> or similar), that they are encrypted on disk, that a user with the appropriate keys and configuration can successfully "unwind" both stages of encryption to arrive back at plaintext.
* Encryption: verify that data are being encrypted in transit (using <code>tcpdump</code> or similar), that they are encrypted on disk, that a user with the appropriate keys and configuration can successfully "unwind" both stages of encryption to arrive back at plaintext.


* Multi-tenancy: verify that tenant identities are being determined correctly, that files are being placed into appropriate tenant-specific areas, that tenants cannot see or modify each other's files.
* Multi-tenancy: verify that tenant identities are being determined correctly, that files are being placed into appropriate tenant-specific areas, that tenants cannot see or modify each other's files, and that tenant-specific UIDs/GIDs are being stored/retrieved (which involves some mapping to/from server-specific values) properly.


* Quota/accounting: verify that a user cannot exceed quota, that the reported usage matches actual usage.
* Management: verify that tenants can be defined and associated with volumes, that volumes can be started/stopped on the servers and mounted (including tenant authentication etc.) on clients, all using the CLI and/or web GUI.


== User Experience ==
== User Experience ==
Line 58: Line 56:


* How hard is it for the tenant, once access to a resource (directory on the shared filesystem) has been configured, to construct the necessary <code>mount</code> command lines and actually access the resource?
* How hard is it for the tenant, once access to a resource (directory on the shared filesystem) has been configured, to construct the necessary <code>mount</code> command lines and actually access the resource?
* How hard is it for the tenant to configure and use on-disk encryption, or (in cooperation with the provider) transport encryption?


* Is the observed performance, reliability, etc. of storage in CloudFS consistent with users' other expectations of performance in the cloud?
* Is the observed performance, reliability, etc. of storage in CloudFS consistent with users' other expectations of performance in the cloud?


== Dependencies ==
== Dependencies ==
The only major dependency is CLI support from the <code>glusterfs</code> upstream, as noted aboveEven that's not a hard dependency; if worst comes to worst all of the additional CloudFS functionality can be managed using separate programs/libraries.
The only major dependency is on a compatibly-patched version of <code>glusterfs</code>.  For encryption, there is also a dependency on OpenSSL.


== Contingency Plan ==
== Contingency Plan ==
Line 68: Line 68:


== Documentation ==
== Documentation ==
TBDIt's not that it doesn't exist; it's just not very organized yet.
There's a [http://git.fedorahosted.org/git/?p=CloudFS.git;a=blob;f=doc/mgmt_manual.md;h=bfcbbe9769f8726ecd1aefcf19e1159074971110;hb=HEAD management manual] which needs expansion to include setup for both forms of encryptionThere is also a [http://git.fedorahosted.org/git/?p=CloudFS.git;a=blob;f=scripts/README.ssl;h=3547f6b354d8b3455359ea019f6db9ce74862d2e;hb=cloudfsd separate document] describing the setup of SSL authentication/encryption within the management code itself, which needs to become part of a more general installation manual.


== Release Notes ==
== Release Notes ==
Line 77: Line 77:




[[Category:FeaturePageIncomplete]]
[[Category:FeatureReadyForWrangler]]

Revision as of 16:01, 1 June 2011

CloudFS

Summary

A "cloud ready" version of GlusterFS, including additional auth*/crypto/multi-tenancy.

Owner

  • Email: jdarcy@redhat.com

Current status

  • Targeted release: Fedora 16
  • Last updated: 2011-06-01
  • Percentage of completion: 80%

Detailed Description

CloudFS is intended to be a version of an existing distributed/parallel filesystem that's suitable for deployment by a provider as a permanent, shared service. It could also be used as infrastructure for hosting virtual-machine images, and in fact the underlying technology (GlusterFS) is often used in this role currently. Users can already deploy this class of filesystem privately in the cloud, within their own virtual machines, but they pay both a performance and an administrative cost for doing so. Running servers natively and doing the configuration/administration only once could be a compelling option for anyone building a Fedora-based cloud, but requires some additional features. Specifically, CloudFS provides:

  • Stronger authentication and authorization.
  • Encryption, both on the wire and at rest.
  • Multi-tenancy (isolating tenants' namespaces and IDs from one another).
  • A management framework (CLI and web app) to configure the other features.

All of these features can be implemented in a modular way, so that users can deploy only those they deem necessary or appropriate for their situation.

The long-term plan for CloudFS includes performance/scalability enhancements and multi-site replication, but those are not part of the current proposal.

Benefit to Fedora

Best-in-class cloud storage with a full and familiar POSIX API, high performance, and strong security. This functionality can be used either as infrastructure for the cloud itself, or as a service providing additional functionality directly to users.

Scope

The scope of work for this feature mostly consists of the CloudFS package. Some of the code is also part of the existing glusterfs package, either in the form of CloudFS-related patches or whole features (e.g. SSL-based authentication and transport encryption).

How To Test

As a distributed filesystem, testing requires at least two and ideally four or more server nodes. Since the specific goal of CloudFS is to provide various kinds of protection between tenants it's best to have at least two client nodes mounting as different tenants. All of these nodes must have a current and compatible version of the glusterfs package installed, and can be virtual for testing purposes.

Configuration is mostly as described in the official manual and web screenshots. At a minimum, you'll need to create a pool/cluster and a volume first. Testing from that point is largely feature-dependent. Referring to the above feature list:

  • Auth*: verify that different users can mount and use their own portions of the shared filesystem, and not mount/use each other's.
  • Encryption: verify that data are being encrypted in transit (using tcpdump or similar), that they are encrypted on disk, that a user with the appropriate keys and configuration can successfully "unwind" both stages of encryption to arrive back at plaintext.
  • Multi-tenancy: verify that tenant identities are being determined correctly, that files are being placed into appropriate tenant-specific areas, that tenants cannot see or modify each other's files, and that tenant-specific UIDs/GIDs are being stored/retrieved (which involves some mapping to/from server-specific values) properly.
  • Management: verify that tenants can be defined and associated with volumes, that volumes can be started/stopped on the servers and mounted (including tenant authentication etc.) on clients, all using the CLI and/or web GUI.

User Experience

Filesystems are notoriously "invisible" to users when they work. The real "user" experience for CloudFS is actually the experience of the cloud provider or cloud tenant (account holder) as they configure their respective parts of the system. This experience includes the following aspects.

  • How hard is it for the provider to add/remove tenants, either manually or as part of their general cloud-provisioning UI (including self-service)?
  • How does the provider manage quotas, retrieve usage information for billing, etc.?
  • How hard is it for the tenant, once access to a resource (directory on the shared filesystem) has been configured, to construct the necessary mount command lines and actually access the resource?
  • How hard is it for the tenant to configure and use on-disk encryption, or (in cooperation with the provider) transport encryption?
  • Is the observed performance, reliability, etc. of storage in CloudFS consistent with users' other expectations of performance in the cloud?

Dependencies

The only major dependency is on a compatibly-patched version of glusterfs. For encryption, there is also a dependency on OpenSSL.

Contingency Plan

None necessary. The existing glusterfs functionality will remain intact.

Documentation

There's a management manual which needs expansion to include setup for both forms of encryption. There is also a separate document describing the setup of SSL authentication/encryption within the management code itself, which needs to become part of a more general installation manual.

Release Notes

None needed.

Comments and Discussion