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- | * Last updated: 2011-06-01 | ||
* Percentage of completion: | * 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). | ||
* | * 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 | 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 | 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 | 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. | ||
* | * 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 | 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 == | ||
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 encryption. There 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: | [[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
- Name: Jeff Darcy
- 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
tcpdumpor 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
mountcommand 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.