Change Details

Newer versions of Swift include support for per-container storage policies (http://docs.openstack.org/developer/swift/overview_policies.html) to be able to provide different level of durability/guarantees on a container. In our deployment this would come handy for example to store less than three copies for container thumbnails or allocate "low latency" containers on SSDs instead of spinning disks. Broad steps to make storage policies a reality: [x] All swift backends to jessie and a minimum (TBD) version of swift [x] Test in esams how adding storage policies would work and e.g. what stats and tools it affects [x] Consider what storage policies make sense, I think at least two dimensions: replication guarantees (e.g. 1/2/3 times) and latency "guarantees" (ssd/hdd) [] Run `swift-dispersion-populate` for each policy to get runtime dispersion stats == SSD considerations == As of Nov 2016 we have a mixture of SSDs sizes across the cluster, those are used for the OS (raid1, space varies 40-50G) and swift (each SSD on its own, ~90G) for containers and accounts. The remaining space is allocated to a partition of ~40G (200G SSD) or ~140G (300G SSD) which we can reuse for objects instead.

Newer versions of Swift include support for per-container storage policies (http://docs.openstack.org/developer/swift/overview_policies.html) to be able to provide different level of durability/guarantees on a container. In our deployment this would come handy for example to store less than three copies for container thumbnails or allocate "low latency" containers on SSDs instead of spinning disks. Broad steps to make storage policies a reality: [x] All swift backends to jessie and a minimum (TBD) version of swift [x] Test in esams how adding storage policies would work and e.g. what stats and tools it affects [x] Consider what storage policies make sense, I think at least two dimensions: replication guarantees (e.g. 1/2/3 times) and latency "guarantees" (ssd/hdd) [x] Run `swift-dispersion-populate` for each policy to get runtime dispersion stats == SSD considerations == As of Nov 2016 we have a mixture of SSDs sizes across the cluster, those are used for the OS (raid1, space varies 40-50G) and swift (each SSD on its own, ~90G) for containers and accounts. The remaining space is allocated to a partition of ~40G (200G SSD) or ~140G (300G SSD) which we can reuse for objects instead.

Newer versions of Swift include support for per-container storage policies (http://docs.openstack.org/developer/swift/overview_policies.html) to be able to provide different level of durability/guarantees on a container. In our deployment this would come handy for example to store less than three copies for container thumbnails or allocate "low latency" containers on SSDs instead of spinning disks. Broad steps to make storage policies a reality: [x] All swift backends to jessie and a minimum (TBD) version of swift [x] Test in esams how adding storage policies would work and e.g. what stats and tools it affects [x] Consider what storage policies make sense, I think at least two dimensions: replication guarantees (e.g. 1/2/3 times) and latency "guarantees" (ssd/hdd) [x] Run `swift-dispersion-populate` for each policy to get runtime dispersion stats == SSD considerations == As of Nov 2016 we have a mixture of SSDs sizes across the cluster, those are used for the OS (raid1, space varies 40-50G) and swift (each SSD on its own, ~90G) for containers and accounts. The remaining space is allocated to a partition of ~40G (200G SSD) or ~140G (300G SSD) which we can reuse for objects instead.