Il 30 set 2016 1:46 PM, "Gandalf Corvotempesta" < gandalf.corvotempesta at gmail.com> ha scritto:> I was thinking about creating one or more raidz2 to use as bricks, with 2ssd. One small partition on these ssd would be used as a mirrored SLOG and the other 2 would be used as standalone arc cache. will this worth the use of SSD or would be totally useless with gluster?> > I don't know if use gluster hot tiering or let zfs manage everything >No advice here? I'm still looking for advice, i would like start the new cluster with the new year and i still have to choose and buy hardware -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20161005/c55beef1/attachment.html>
On Wed, Oct 5, 2016 at 1:29 PM, Gandalf Corvotempesta < gandalf.corvotempesta at gmail.com> wrote:> Il 30 set 2016 1:46 PM, "Gandalf Corvotempesta" < > gandalf.corvotempesta at gmail.com> ha scritto: > > > I was thinking about creating one or more raidz2 to use as bricks, with > 2 ssd. One small partition on these ssd would be used as a mirrored SLOG > and the other 2 would be used as standalone arc cache. will this worth the > use of SSD or would be totally useless with gluster? > > > > I don't know if use gluster hot tiering or let zfs manage everything > > > > No advice here? > I'm still looking for advice, i would like start the new cluster with the > new year and i still have to choose and buy hardware >The mirrored slog will be useful. Depending on what you put on the pool l2arc may not get used much. I removed mine as it got such a low hit rate serving VM's. I also re-did my bricks from raidz2 to using mirrored pairs. I felt that with 3 server redundancy the performance benefits from a more raid10 type layout would be more useful than raidz2 for the pool. I could see where some might want more security though in their data I myself wouldn't experiment with tiering for my use case. .I haven't heard any positive feedback from anyone using tiering yet to want to be testing.> > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://www.gluster.org/mailman/listinfo/gluster-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20161005/d701ad38/attachment.html>
On 6/10/2016 4:29 AM, Gandalf Corvotempesta wrote:> > > I was thinking about creating one or more raidz2 to use as bricks, > with 2 ssd. One small partition on these ssd would be used as a > mirrored SLOG and the other 2 would be used as standalone arc cache. > will this worth the use of SSD or would be totally useless with gluster? > > > > I don't know if use gluster hot tiering or let zfs manage everything > > > > No advice here? > I'm still looking for advice, i would like start the new cluster with > the new year and i still have to choose and buy hardware >slog definitely makes a huge difference fro sync writes, which is most of glusters operation. L2ARC depends on your workload. For me its not useful - VM hosting on a sharded volume, never got better than 6% cache hits. The vast majority of hits were via ARC (memory). ZFS seems to be really good at that :) There's a really nice script here: http://louwrentius.com/zfs-on-linux-monitor-cache-hit-ratio.html That live monitors your cache hit ratios - fascinating to watch on a live cluster. Hot tiering - not sure, the brief play I had with it had showed worse performance. Ceph has had a similar feature for a while and found it only useful for very limited workloads - the cost of promoting/demoting blocks is very high. slog doesn't really work as a write journal, In normal operation slog is never flushed to disk. *sync* writes are written sync to slog and async to the pool. Once the write to the pool is confirmed its safe. If there is a outage the writes to the slog are replayed to the pool. Have the slog allows sync writes to effectively be async and coalesced etc. -- Lindsay Mathieson