[Users] Asking for advice on hosted engine
Giorgio Bersano
giorgio.bersano at gmail.com
Wed Feb 19 08:16:17 EST 2014
2014-02-18 23:25 GMT+01:00 Ted Miller <tmiller at hcjb.org>:
>
> Giorgio,
>
> Gluster on two hosts only is not a good idea. Installed for high
> reliability (quorum activated), gluster requires that >50% of the nodes be
> working before anything can be written. When you have only two nodes, that
> means both nodes must be up before anything can happen.
>
> You can turn off quorum, but then you are almost guaranteeing yourself a
> split-brain headache the first time communication between the two hosts is
> interrupted, even briefly (been there, done that). Ovirt is constantly
> writing to the storage, so if they are not communicating you WILL get
> different things written to the same files in both servers, especially the
> sanlock files. This is called split-brain, and it will give you a splitting
> headache.
>
> For replicated gluster to work well, you need a minimum of three gluster
> nodes in replica mode. Two nodes is a recipe for unhappiness. It is either
> low-availability (quorum on) or a split-brain waiting to spring on you
> (quorum off). You don't want either one.
Hi Ted,
thank you for your precious suggestion.
I was already aware of these two problems.
This setup works if I leave quorum off.
I didn't fear split-brain because - in theory - as the communication
path between the two hosts is fully redundant, it can't happen:
multiple interfaces on different nics connected to multiple switches
having redundant power supply.
Moreover, I'm using this setup exclusively as a storage backend for
the engine VM, nothing else. So - in theory - there is a single
VM/host writing at a time. Maybe not exactly this way during the
migration of the HostedEngine VM from one host to another. Maybe in
that transition there are concurrent write operations from the two
hosts. But usually not.
Now sanlock worries me more. I wasn't considering how sanlock works
(to be honest, I was totally unaware of its operating mode). Maybe
this could be the most probable cause of conflicts.
> Figure out how to use some storage on some third computer to provide a third
> gluster node. That way only two of the three have to be working for things
> to keep working.
>
> Ted Miller
> Elkhart, IN
>
In the beginning I tought of having replication on three (or four)
bricks, for other reasons.
But then I was worried about the performance of a system where every
write operation has to be replicated on more than another single
brick. This was just an hypotesis by me. Do you have any figure about
write performance in this situation? I have found none (probably my
fault).
Anyway thank you very much for your suggestion, I think I'll go down your way.
Better safe than sorry.
Best regards,
Giorgio.
More information about the Users
mailing list