[Gluster-users] Production cluster planning

Lindsay Mathieson lindsay.mathieson at gmail.com
Wed Oct 5 20:12:30 UTC 2016


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



More information about the Gluster-users mailing list