> I think just defining each SSD as a single Gluster brick may
provide
> the best performance for VMs, but my understanding of this is
> theoretical, so I leave it to the Gluster people to provide further
> insight.
>
Barak, very interesting, I had never thought of doing it this way but
your idea does make sense.
I assume Gluster is able to tolerate drive failures in the array?
I'm also interested in hearing what the Gluster folks think about your
approach?
On 2017-06-11 01:20, Barak Korren wrote:
On 11 June 2017 at 11:08, Yaniv Kaul <ykaul(a)redhat.com> wrote:
>
>> I will install the o/s for each node on a SATADOM.
>> Since each node will have 6x SSD for gluster storage.
>> Should this be software RAID, hardware RAID or no RAID?
>
> I'd reckon that you should prefer HW RAID on software RAID, and some
> RAID on
> no RAID at all, but it really depends on your budget, performance, and
> your
> availability requirements.
>
Not sure that is the best advice, given the use of Gluster+SSDs for
hosting individual VMs.
Typical software or hardware RAID systems are designed for use with
spinning disks, and may not yield any better performance on SSDs. RAID
is also not very good when I/O is highly scattered as it probably is
when running multiple different VMs.
So we are left with using RAID solely for availability. I think
Gluster may already provide that, so adding additional software or
hardware layers for RAID may just degrade performance without
providing any tangible benefits.
I think just defining each SSD as a single Gluster brick may provide
the best performance for VMs, but my understanding of this is
theoretical, so I leave it to the Gluster people to provide further
insight.