Hello, On Sat, 22 Oct 2016 16:12:37 +0200 Zoltan Arnold Nagy wrote: > Hi, > > The 2.0 release notes for Red Hat Ceph Storage deprecate cache tiering. > > What does this mean for Jewel and especially going forward? > Lets look at that statement in the release notes: --- The RADOS-level cache tiering feature has been deprecated. The feature does not provide any performance improvements for most Ceph workloads and introduces stability issues to the cluster when activated. Alternative cache options will be provided by using the dm-cache feature in future versions of Red Hat Ceph Storage. --- There are several items here and I very much would welcome a response from a Ceph/RH representative. 1. Is that depreciation only in regards to RHCS, as Nick seems to hope? Because I very much doubt that, why develop code you just "removed" from your milk cow? 2. Is that the same kind of depreciation as with the format 1 RBD images, as in, will there be a 5 year window where this functionality is NOT removed from the code base and a clear, seamless and non-disruptive upgrade path? For me this is a significant issue, as cache-tiering is a perfect fit for my main use case. The current main cluster has 3-4 years to go before HW renewal and while not happy about it, I could basically freeze it in the current state. However I do have a new cluster (similar to the current one, up to 800 VM clients) coming up early next year. Which means it is way too early for a BlueStore design and the inherent (promised) performance improvements. The same goes for any dm-cache shenanigans, as in there are no official noises about this I'm aware of, nor would I trust this in production w/o a significant lead time. So _IF_ cache-tiering is being terminally abandoned, I would have to design a "classic" cluster (likely with unused slots/drive bays for a future dm-cache NVMes/SSDs expansion) to meet our requirements, which would be significantly larger and more expensive than what I had planned. > Can someone shed some light why cache tiering is not meeting the original expectations technically? I think that has been answered both by that statement and what Nick wrote, alas a this point in time I would also concur with Nick that these initial problems are moot. Christian -- Christian Balzer Network/Systems Engineer chibi@xxxxxxx Global OnLine Japan/Rakuten Communications http://www.gol.com/ _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |