2:17 p.m.
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--deVVEXUdPHOeuenfhO5VGUjVsuc3DdN5d
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
On 09/09/2015 10:54 AM, Simone Tiraboschi wrote:
=20
=20
On Wed, Sep 9, 2015 at 10:14 AM, Richard Neuboeck
<hawk(a)tbi.univie.ac.at <mailto:hawk@tbi.univie.ac.at>> wrote:
=20
On 04.09.15 10:02, Simone Tiraboschi wrote:
> Is there a reason why it has to be exactly replica 3?
>
>
> To have a valid quorum having the system being able to decide wit=
ch is
> the right and safe copy avoiding an issue called split
brain.
> Under certain circumstances/issues (network issue, hosts down or
> whatever could happen) the data on different replica could diverg=
e: if
> you have two and just two different hosts that claim each
other
that its
> copy is the right one there is no way to automatically take the r=
ight
> decision. Having three hosts and setting the quorum
according to =
that
> solves/mitigates the issue.
=20
=20
Thanks for the explanation. I do understand the problem but since
I'm somewhat limited in my hardware options is there a way to
override this requirement? Meaning if I change the checks for
replica 3 in the installation scripts does something else fail on
the way?
=20
=20
I'm advising that it's not a safe configuration so it's not
recommended for a production environment.
Having said that, as far as I know it's enforced only in the setup
script so tweaking it should be enough.
Otherwise, if you have enough disk space, you can also have a
different trick: you could create a replica 3 volume with 2 bricks
from a single host.
I've thought about that but since that would obviously only help to
fool the installation script there is nothing else in this setup
that would improve the situation. Worse the read/write overhead on
the second machine would be a performance downgrade.
It's not a safe procedure at all cause you still have only 2
hosts,
so it's basically just replica 2, and in case of split brain the
host with two copies will win by configuration which is not always
the right decision.
Right. I'm thinking of trying to add a dummy node as mentioned in
the RHEL documentation. This would (in theory) prevent the read only
state in the split brain scenario and make it possible to access the
storage. But still the installation requirement of replica 3 would
not be satisfied.
=20
In my case coherence checks would come from outside the storage and=
vm host setup and fencing would be applied appropriately.
=20
=20
Can I ask how?
Multiple machines separated from the storage and virtualization
machines that will check communication (in general and of several
services) and try to intervene if there is something going awry
first by accessing the machines directly (if possible) and then by
deactivating those machines by remote management.
Cheers
Richard
=20
I would very much appreciate it if the particulars of the storage
setup could be either selected from a list of possibilities or be
ignored and just a warning be issued that this setup is not
recommended.
=20
Thanks!
Richard
=20
=20
--
/dev/null
=20
=20
--=20
/dev/null
--deVVEXUdPHOeuenfhO5VGUjVsuc3DdN5d
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlXwFVQACgkQnGohgOrO9GEd0QCgk58o8mOE/RFp6zvXuzOUvhRm
YOoAoK56/9X5or7oIa5K7QA3PTUdyZei
=v/NJ
-----END PGP SIGNATURE-----
--deVVEXUdPHOeuenfhO5VGUjVsuc3DdN5d--