> Keep in mind that 1.6TB P4600 is going to last about as long as your 400GB > P3700, so if wear-out is a concern, don't put more stress on them. > I've been looking at the 2T ones, but it's about the same as the 400G P3700 > Also the P4600 is only slightly faster in writes than the P3700, so that's > where putting more workload onto them is going to be a notable issue. The latency is somewhat worse than the P3700. When you're talking journal device latency will be more important than bandwidth, specially on small and/or sync writes. > >> I've seen some talk on here regarding this, but wanted to throw an idea >> around. I was okay throwing away 280GB of fast capacity for the purpose of >> providing reliable journals. But with as much free capacity as we'd have >> with a 4600, maybe I could use that extra capacity as a cache tier for >> writes on an rbd ec pool. If I wanted to go that route, I'd probably >> replace several existing 3700s with 4600s to get additional cache capacity. >> But, that sounds risky... >> > Risky as in high failure domain concentration and as mentioned above a > cache-tier with obvious inline journals and thus twice the bandwidth needs > will likely eat into the write speed capacity of the journals. I tend to agree. Also the cache tier only starts to be interesting if it's big enough overall... If you have to keep promoting/demoting because it's full it'll kill the whole cluster very quickly. > > If (and seems to be a big IF) you can find them, the Samsung PM1725a 1.6TB > seems to be a) cheaper and b) at 2GB/s write speed more likely to be > suitable for double duty. > Similar (slightly better on paper) endurance than then P4600, so keep that > in mind, too. As I'm more than happy for the 400G size, and given the price of the P4600 2T, for slightly more (10%) I'm considering the P4800X. This is for a full SSD cluster. _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |