Talk:GlusterFS
From GlusterDocumentation
Contents |
replicate with 5 nodes - and adding more nodes in the future
Hello, we are testing glusterfs 1.2 and I have few questions -
1. we are going to store millions of small jpg files that will be read by webserver - is glusterfs good solution for this ?
2. we are going to run both server+clients on each node together with apache
3. replicate *:2
the way i think doing replicate is defining on each server 2 volumes and using AFR:
server1: a1, a2
server2: b1, b2
server3: c1, c2
server4: d1, d2
server5: e1, e2
afr1: a1+b2
afr2: b1+c2
afr3: c1+d2
afr4: d1+e2
afr5: e1+a2
and then unify = afr1+afr2+afr3+afr4+afr5 with replicate option
is this correct way ?
and what to do on the future when we add more nodes ? when changing the afr (adding and changing the couples) making glusterfs
redistribute the files the new way ?
4. what happens when a hard drive goes down and replaces, the cluster also redistribute the files ?
Thanks, Shai
What am I doing wrong if this error is printed in the logs?
Wed Jan 24 15:32:39 2007 [ERROR] libglusterfs/xlator: xlator_set_type: dlopen(/usr/local/lib/glusterfs/xlator/cluster/automatic-file-replication.so): /usr/local/lib/glusterfs/xlator/cluster/automatic-file-replication.so: cannot open shared object file: No such file or directory
--Gbruchha 06:56, 24 January 2007 (PST)
wrong 'type'
Hi Gbruccha, You have given the 'type' option in the volume spec wrongly. Please see our examples on wiki for available options (or you can refer to 'docs/' directory in source). see here for 'type' options
While asking any doubts on GlusterFS, it would be great if you post the volume spec with the question, which helps the developers to understand the problem and reproduce it.
--bulde [Amar Tumballi]
Does still not work
Hi Amar,
Thanks for your fast response. I took the type information from: GlusterFS UG #automatic-file-replication. But the features/mirror results in a somewhat similar error:
Thu Jan 25 10:52:05 2007 [ERROR] libglusterfs/xlator: xlator_set_type: dlopen(/usr/local/lib/glusterfs/xlator/features/mirror.so): /usr/local/lib/glusterfs/xlator/features/mirror.so: cannot open shared object file: No such file or directory
My configuration is still very incomplete but looks very similar to the provided sample files.
Here we go:
,----[ /etc/glusterfs/glusterfs-client.vol ]
| volume client
| type protocol/client
| end-volume
|
| volume writeback
| type performance/write-back
| subvolumes client
| end-volume
|
| volume readahead
| type performance/read-ahead
| subvolumes writeback
| end-volume
|
| volume afr
| type features/mirror
| #type cluster/automatic-file-replication
| option replicate:* 2
| end-volume
`----
,----[ cat /etc/glusterfs/glusterfs-server.vol ]
| volume brick
| end-volume
|
| volume server
| type protocol/server
| subvolumes brick
| end-volume
`----
What I am looking for is a configuration which makes my two nodes high available. If one dies the other should still have a copy of the data. If the dead node comes back then it shall automatically resynchronize itself. To admit, I have not yet figured out if this is possible with GlusterFS. Also what would happen if a split-brain situation arises?
Thanks!
--Gbruchha 02:30, 25 January 2007 (PST)
--
performance/mirror not yet there :|
Actually mirror translator is not yet implemented :| its in our road map we should be finishing it by another 15 days. as of now, to cluster filesystems we have only cluster/unify translator.
--Bulde [Amar Tumballi]
Nested arc. bug
There's a bug with archives. My configuration:
brick1 brick2 brick3 in afr1 \ brick4 brick5 brick6 in afr2 \ afr1 afr2 in stripe (1MB block)
fuse 2.7.2gfs8 glusterfs 1.3.7 all from debian pakage: http://lmello.virt-br.org/debian distr. Ubuntu server 7.10
when i tried to do tar fxvj (or xvj) on linux-<KERNEL_VERSION>.tar.bz2 it causes an error and created a fake directory that i was unable to delete from mounted GlusterFS untill i've deleted it in brick's real folders. however bzip2 -d on linux-<KERNEL_VERSION>.tar.bz2 worked just fine and then tar x on linux-<KERNEL_VERSION>.tar worked fine too. so i guess that that's an issue in nested archives only. i'm planning to give this configuration a try in a production environment a bit later. and one more question... can i use .limits.min-free-disk with a stripe or stripe with schedulers that can give me a bit more options besides block size? unify is ok when u have a lot of small files but if u have a lot of large files a stripe is must.
