Re: [openstack-dev] [Swift] container forwarding/cluster federation blueprint
Hi, With a global cluster, you can have your replicas stored in different regions within your cluster whereas container forwarding is about storing all objects within a container in a different swift cluster than the one you contacted in the first place. These two clusters could well be co-located. The swift cluster forwarded to may have a different replica count than the other clusters so that you can provide different QoS for different containers or it may just be there to give you extra space to accommodate a large account across several clusters but within a single namespace. The forwarding is happening between proxies of the clusters involved and each cluster is a regular cluster with its own configuration. More details on container-forwarding can be found in this wiki page: https://wiki.openstack.org/wiki/Swift/ClusterFederationBlueprint Eric On 14/10/2013 03:31, Sam Morrison wrote: Hi, I'd be interested in the differences this has to using swift global clusters? Cheers, Sam On 12/10/2013, at 3:49 AM, Coles, Alistair alistair.co...@hp.commailto:alistair.co...@hp.com wrote: We’ve just committed a first set of patches to gerrit that address this blueprint: https://blueprints.launchpad.net/swift/+spec/cluster-federation Quoting from that page: “The goal of this work is to enable account contents to be dispersed across multiple clusters, motivated by (a) accounts that might grow beyond the remaining capacity of a single cluster and (b) clusters offering differentiated service levels such as different levels of redundancy or different storage tiers. Following feedback at the Portland summit, the work is initially limited to dispersal at the container level, i.e. each container within an account may be stored on a different cluster, whereas every object within a container will be stored on the same cluster.” It is work in progress, but we’d welcome feedback on this thread, or in person for anyone who might be at the hackathon in Austin next week. The bulk of the new features are in this patch: https://review.openstack.org/51236 (Middleware module for container forwarding.) There’s a couple of patches refactoring/adding support to existing modules: https://review.openstack.org/51242 (Refactor proxy/controllers obj base http code) https://review.openstack.org/51228 (Store x-container-attr-* headers in container db.) And some tests… https://review.openstack.org/51245 (Container-forwarding unit and functional tests) Regards, Alistair Coles, Eric Deliot, Aled Edwards HP Labs, Bristol, UK - Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN . Registered No: 690597 England The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error, you should delete it from your system immediately and advise the sender. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Swift] container forwarding/cluster federation blueprint
Hi, I'd be interested in the differences this has to using swift global clusters? Cheers, Sam On 12/10/2013, at 3:49 AM, Coles, Alistair alistair.co...@hp.com wrote: We’ve just committed a first set of patches to gerrit that address this blueprint: https://blueprints.launchpad.net/swift/+spec/cluster-federation Quoting from that page: “The goal of this work is to enable account contents to be dispersed across multiple clusters, motivated by (a) accounts that might grow beyond the remaining capacity of a single cluster and (b) clusters offering differentiated service levels such as different levels of redundancy or different storage tiers. Following feedback at the Portland summit, the work is initially limited to dispersal at the container level, i.e. each container within an account may be stored on a different cluster, whereas every object within a container will be stored on the same cluster.” It is work in progress, but we’d welcome feedback on this thread, or in person for anyone who might be at the hackathon in Austin next week. The bulk of the new features are in this patch: https://review.openstack.org/51236 (Middleware module for container forwarding.) There’s a couple of patches refactoring/adding support to existing modules: https://review.openstack.org/51242 (Refactor proxy/controllers obj base http code) https://review.openstack.org/51228 (Store x-container-attr-* headers in container db.) And some tests… https://review.openstack.org/51245 (Container-forwarding unit and functional tests) Regards, Alistair Coles, Eric Deliot, Aled Edwards HP Labs, Bristol, UK - Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN . Registered No: 690597 England The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error, you should delete it from your system immediately and advise the sender. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Swift] container forwarding/cluster federation blueprint
We've just committed a first set of patches to gerrit that address this blueprint: https://blueprints.launchpad.net/swift/+spec/cluster-federation Quoting from that page: The goal of this work is to enable account contents to be dispersed across multiple clusters, motivated by (a) accounts that might grow beyond the remaining capacity of a single cluster and (b) clusters offering differentiated service levels such as different levels of redundancy or different storage tiers. Following feedback at the Portland summit, the work is initially limited to dispersal at the container level, i.e. each container within an account may be stored on a different cluster, whereas every object within a container will be stored on the same cluster. It is work in progress, but we'd welcome feedback on this thread, or in person for anyone who might be at the hackathon in Austin next week. The bulk of the new features are in this patch: https://review.openstack.org/51236 (Middleware module for container forwarding.) There's a couple of patches refactoring/adding support to existing modules: https://review.openstack.org/51242 (Refactor proxy/controllers obj base http code) https://review.openstack.org/51228 (Store x-container-attr-* headers in container db.) And some tests... https://review.openstack.org/51245 (Container-forwarding unit and functional tests) Regards, Alistair Coles, Eric Deliot, Aled Edwards HP Labs, Bristol, UK - Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN . Registered No: 690597 England The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error, you should delete it from your system immediately and advise the sender. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
