[Gluster-users] Distributed Replicated Volumes and 'same server redundancy'
Stefan de Konink
stefan at konink.de
Sat Nov 27 12:49:45 UTC 2010
-----BEGIN PGP SIGNED MESSAGE-----
Currently I have multiple servers having 12 SATA disks each. Access to
the individual disks is faster than one big volume in RAID5. Given that
the potential failure and recovery time for RAID0 from the network is
big, I decided distributed replicated volumes might be more interesting.
If I create a Trusted Storage Pool consisting of the servers exporting
each different disk as new brick and would combine them as 'one'
distributed replicated volume I am unable to guarantee that the files
that are mirrored are in fact mirrored on servers in the network rather
than for example two copies on the same physical server.
I have read about 'afr' and 'unify', and its ability of combining each
different disk with a remote pair.
When I read about unify I see:
"Unify being part of a file system, has a requirement. It will create
directories on all the child nodes and files in anyone of the child
nodes. It expects this to be followed properly."
If I take the following setup:
Unify => AFR1 => BRICK1a
AFR2 => BRICK2a
(Where BRICK1a and BRICK2a are in the same server.)
Now; what does it mean if a new file/directory is made? It will end up
in either of BRICK1a/1b or BRICK2a/b? Is the file itself duplicated by
Unify or only its 'namespace'?
Is there any other way to guarantee files are mirrored across servers?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the Gluster-users