On Mon, Nov 26, 2012 at 3:07 AM, Jimmy Tang <jt...@tchpc.tcd.ie> wrote: > > On 24 Nov 2012, at 16:42, Gregory Farnum wrote: > >> On Thursday, November 22, 2012 at 4:33 AM, Jimmy Tang wrote: >>> Hi All, >>> >>> Is it possible at this point in time to setup some form of tiering of >>> storage pools in ceph by modifying the crush map? For example I want to >>> have my most recently used data on a small set of nodes that have SSD's and >>> over time migrate data from the SSD's to some bulk spinning disk using a >>> LRU policy? >> There's no way to have Ceph do this automatically at this time. Tiering in >> this fashion traditionally requires the sort of centralized metadata that >> Ceph and RADOS are designed to avoid, and while interest in it is heating up >> we haven't yet come up with a new solution. ;) >> > > that makes sense that tiering in this fashion makes it un-ceph like. > >> If your system allows you to do this manually, though — yes. You can create >> multiple (non-overlapping, presumably) trees within your CRUSH map, one of >> which would be an "SSD" storage group and one of which would be a "normal" >> storage group. Then create a CRUSH rule which draws from the SSD group and a >> rule which draws from the normal group, create a pool using each of those, >> and write to whichever one at the appropriate time. >> Alternatively, you could also place all the primaries on SSD storage but the >> replicas on regular drives — this won't speed up your writes much but will >> mean SSD-speed reads. :) >> -Greg > > Ok, so it's possible to set pools of disks/nodes/racks as primary copies of > data from which the client can read data from?
Yep. This is accomplished via the crush "take" and "choose" commands — "take" is the starting point for picking OSDs from, and you can have multiple "take" commands in a single rule whose contents are "emit"ted in order. :) -Greg -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
