New idea that is dependent on failure behaviour of the cache tier... Carve the ssds 4-ways: each with 3 partitions for journals servicing the backing data pool and a fourth larger partition serving a write-around cache tier with only 1 object copy. Thus both reads and writes hit ssd but the ssd capacity is not halved by replication for availability.
...The crux is how the current implementation behaves in the face of cache tier OSD failures? Cheers, Blairo On 16/04/2014 4:45 PM, "Blair Bethwaite" <blair.bethwa...@gmail.com> wrote: > Hi all, > > We'll soon be configuring a new cluster, hardware is already purchased - > OSD nodes are Dell R720XDs (E5-2630v2, 32GB RAM, PERC 710p, 9x 4TB NL-SAS, > 3x 200GB Intel DC S3700, Mellanox CX3 10GE DP). 12 of these to start with. > > So we have a 3:1 spindle:ssd ratio, but as yet I'm not sure how we'll > configure things... > > Obviously the ssds could be used as journal devices, but I'm not really > convinced whether this is worthwhile when all nodes have 1GB of hardware > writeback cache (writes to journal and data areas on the same spindle have > time to coalesce in the cache and minimise seek time hurt). Any advice on > this? > > I think the timing should work that we'll be deploying with Firefly and so > have Ceph cache pool tiering as an option, but I'm also evaluating Bcache > versus Tier to act as node-local block cache device. Does anybody have real > or anecdotal evidence about which approach has better performance? > > -- > Cheers, > ~Blairo >
_______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
