i'm trying to build a 3-node storage cluster which should be able to
withstand 1 node going down.
first I tried glusterfs 1.3.0-pre2.2, but had some memory leakage
which seems to be fixed in the source checked from the repository
i'm exporting 3 bricks with this configs like this:
volume brick[1-3]
type storage/posix
option directory /mnt/export/shared/[1-3]
end-volume
volume server
type protocol/server
option transport-type tcp/server # For TCP/IP transport
option listen-port 699[6-8] # Default is 6996
subvolumes brick[1-3]
option auth.ip.brick[1-3].allow * # Allow access to "brick" volume
end-volume
my client config looks like this:
volume b[1-3]
type protocol/client
option transport-type tcp/client # for TCP/IP transport
option remote-host 127.0.0.1 # IP address of the remote brick
option remote-port 699[6-8] # default server port is 6996
option remote-subvolume brick[1-3] # name of the remote volume
end-volume
volume afr
type cluster/afr
subvolumes b1 b2 b3
option replicate *:2
option scheduler rr
option rr.limits.min-free-disk 512MB
option rr.refresh-interval 10
end-volume
i didnt activate any performance-enhance translators.
This setup sort of works, except that i saw files created only on
bricks1 and 2, brick3 got only the directories and symlinks created on
it. After killing the brick2 glusterfsd, the filesystem stayed up,
which is promising, but still no files are created on brick3.
is this setup supposed to work? can i get comparable functionality set
up with current glusterfs? preferably in a way that can be extended to
5 nodes, withstanding 2 going down. is there any plan for some
raid6-like functionality, or this would kill performance alltogether?
--
Tibor Veres
address@hidden
_______________________________________________
Gluster-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/gluster-devel