[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