[Gluster-users] replica count documentation

[Whit Blauvelt]

On Thu, Apr 14, 2011 at 02:20:02PM -0700, Mohit Anchlia wrote:

> Which similar systems are you referring to?

DR:BD has an overlapping use case, although it's pretty much constrained to
mirroring between two storage systems. And it has options to return to the
user after either writing to the first system, or only after writing to the
second - or even _before_ writing to the first if you trust that once it has
the data it will get there. 

DR:BD's also more typically used in primary-secondary arrangements for
failover than in primary-primary arrangements for load sharing. But there
are ways to do the second. I've got one pair of servers mirrored through
DR:BD proving file storage via NFS, and another pair now running Gluster,
also providing NFS service. Both are doing well so far, although my Gluster
use is only a few days, where DR:BD's been running happily for months. 

Gluster is easier to configure, as DR:BD takes cryptic commands, and
requires combination with other daemons to get the job done. But DR:BD is
very good at what it does, and well documented - except that you've got to
cobble together its documentation with that of the other daemons you're
integrating it with to get your result, which can be a bit of a mental
stretch (at least for me). 

DR:BD also, being at the device level and in the kernel, has advantages in
stacking with other stuff. I can put a KVM in an LVM on DR:BD - and KVMs do
well as LVMs, both running efficiently in them and allowing LVM snapshotting
- it's a better format than qcow. As I understand it I can't put an LVM on
top of a Gluster - although it has no problem using ext4-formatted LVMs as
bricks, I doubt it can work in any way with LVMs which are KVMs, with no
file system in between. 

Despite that I'm trying to work out the logic of how to put an HA KVM setup
on a 2-unit replicated Gluster system. It should be possible to get both
failover, and live-migration failback going, once I get the concepts and
incantations right. While KVM is solid, its docs are terse and incomplete.
That seems to be a trend. Book publishers no longer rush out books on the
latest tech, and free software creators who hold back instructions improve
their chance of consulting contracts.

Whit