You would normally always work with /mnt/glusterfs (the glusterfs mount) because every change will immediately will be replicated and this is what you want normally. Maybe there some confusion what is meant by locally. Basically in this setup everything is locally ;-) If you look in the glusterfsd.vol file you see a "option directory". This directory has to exist on both hosts if you want a "RAID 1" setup which means that your data will be stored on both backends which in turn means that the data will be duplicated on different hosts. This will save you the data if one hosts explodes ;-) This is what glusterfsd will do for you. It stores the data in the directory specified in "option directory" in glusterfsd.vol. This directory is really local for every backend. But you would normally do any changes in this directory. Strictly speaking: Do NOT change anything there. But something has to do the replication. And this is what the client/mount will do for you. If you mount glusterfs.vol on /mnt/glusterfs e.g. on both hosts you get a GlusterFS mount. In our case it is a replicated mount. As you see in "volume replicate" the option "subvolumes remote1 remote2" will to the magic. It basically says: "If someone copies a file to /mnt/glusterfs store it on remote1 and remote2 in directory /opt/glusterfsbackend (to get back to my example below)". So in our case not glusterfsd will replicate the data but the client/mount will do it. As long as you can live with some inaccuracy you can do read only things like "find, du, ..." in the backend directory /opt/glusterfsbackend. This will be much faster. But don't change anything there (I know someone will bashing me for this ... ;-) ). - Robert On 04/16/10 16:08, Jenn Fountain wrote: > Jumping on this thread with a relevant (I think question) - I am new to gluster as well. > > Where do you typically work with the files - local or gluster mount? IE: /repl/export - local /mnt/glusterfs - gluster mount > > Would you work with the files on /repl/export and then copy them (automate this via a script or can gluster automate this) to the /mnt/glusterfs so they replicate or work with them on the /mnt/glusterfs and have them replicate? Sorry for the novice question but I am a novice. > > -Jenn > > > > > > On Apr 16, 2010, at 10:01 AM, RW wrote: > >> >>> many thanks Robert for your quick reply, >>> I still probably am missing/misunderstanding the big picture here, what >>> about this: >>> >>> box a < -- > box b >>> /dir_1 /dir_1 >>> ^ ^ >>> serivces locally services locally >>> read/write to dir_1 read/write to /dir_1 >> >> This is basically the setup I described with my config files. >> /dir_1 (or /some_folder in you former mail) is the client mount. >> Everything you copy in there will be replicated to box a and >> box b. It doesn't matter if you do the copy in box a or b. >> But you need a different location for glusterfsd (the GlusterFS >> daemon) to store the files locally. This could be /opt/glusterfsbackend >> for example. You need this on both hosts and you need the mounts >> (client) on both hosts. >> >>> - can all these local services/processes, whatever these might be, >>> not know about mountig and all this stuff? >> >> You need to copy glusterfsd.vol on both hosts e.g. /etc/glusterfs/ >> Then you start glusterfsd (on Gentoo this is "/etc/init.d/glusterfsd >> start"). Now you should see a glusterfsd process on both hosts. >> You also copy glusterfs.vol to both hosts. As you can see in my >> /etc/fstab I supply the glusterfs.vol file as the filesystem >> and glusterfs as type. You now mount GlusterFS as you would do >> with every other filesystem. If you now copy a file to /some_folder >> on "box a" it will automatically be replicated to "box b" and after >> that it will be immediately be available at "box b". The replication >> is done by the client (the mountpoint in your case if this >> helps to better understand). The servers basically only provide the >> backend services to store the data somewhere on a brick (host). >> In my example above this was /opt/glusterfsbackend. >> >>> - and server between themselves make sure(resolve conflicts, etc.) >>> that content of dir_1 on both boxes is the same? >> >> Most of the time ;-) There're situations where conflicts can >> occur but in this basic setup they're seldom. You have to monitor >> the log files. But GlusterFS provides self healing which means >> that if a backend (host) goes down the files generated on the >> good host - while the bad host is down - will be copied to the failed >> host if it is up again. But this will not happen immediately. >> This is the "magic part" of GlusterFS ;-) >> >>> - so whatever happens(locally) on box_a is replicated(through "servers") >>> on box_b and vice versa, >>> possible with GlusterFS or I need to be looking for something else? >> >> As long as you copy the files into the glusterfs mount (in your >> case /some_folder) the files will be copied to "box b" if you >> copy it on "box a" and vice versa. >> >>> and your configs, do both files glusterfsd and glusterfs go to both >>> box_a & box_b? >> >> Yes. >> >>> does mount need to be executed on both boxes as well? >> >> Yes. >> >> - Robert >> >> >>> thanks again Robert >>> >>> >>> >>> On 16/04/10 13:42, RW wrote: >>>> This is basically the config I'm using for replicate >>>> a directory between two hosts (RAID 1 if you like ;-) ) >>>> You need server and client even both are on the same >>>> host: >>>> >>>> ########################## >>>> # glusterfsd.vol (server): >>>> ########################## >>>> volume posix >>>> type storage/posix >>>> option directory /some_folder >>>> end-volume >>>> >>>> volume locks >>>> type features/locks >>>> subvolumes posix >>>> end-volume >>>> >>>> volume server >>>> type protocol/server >>>> option transport-type tcp >>>> option transport.socket.bind-address ....... >>>> option transport.socket.listen-port 6996 >>>> option auth.addr.locks.allow * >>>> subvolumes locks >>>> end-volume >>>> >>>> ######################### >>>> # glusterfs.vol (client): >>>> ######################### >>>> volume remote1 >>>> type protocol/client >>>> option transport-type tcp >>>> option remote-host <ip_or_name_of_box_a> >>>> option remote-port 6996 >>>> option remote-subvolume locks >>>> end-volume >>>> >>>> volume remote2 >>>> type protocol/client >>>> option transport-type tcp >>>> option remote-host <ip_or_name_of_box_b> >>>> option remote-port 6996 >>>> option remote-subvolume locks >>>> end-volume >>>> >>>> volume replicate >>>> type cluster/replicate >>>> # optionally but useful if most is reading >>>> # !!!different values for box a and box b!!! >>>> # option read-subvolume remote1 >>>> # option read-subvolume remote2 >>>> subvolumes remote1 remote2 >>>> end-volume >>>> >>>> ##################### >>>> # /etc/fstab >>>> ##################### >>>> /etc/glusterfs/glusterfs.vol /some_folder glusterfs noatime 0 0 >>>> >>>> "noatime" is optional of course. Depends on your needs. >>>> >>>> - Robert >>>> >>>> >>>> On 04/16/10 14:18, pawel eljasz wrote: >>>> >>>>> dear all, I just subscribed and started reading docs, >>>>> but still not sure if I got the hung of it all >>>>> is GlusterFS for something simple like: >>>>> >>>>> a box <-> b box >>>>> /some_folder /some_folder >>>>> >>>>> so /some_folder on both boxes would contain same data >>>>> >>>>> if yes, then does setting only the servers suffice? or client side is >>>>> needed too? >>>>> can someone share a simplistic config that would work for above simple >>>>> design? >>>>> >>>>> cheers >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Gluster-users mailing list >>>>> Gluster-users at gluster.org >>>>> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users >>>>> >>>> _______________________________________________ >>>> Gluster-users mailing list >>>> Gluster-users at gluster.org >>>> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users >>>> >> _______________________________________________ >> Gluster-users mailing list >> Gluster-users at gluster.org >> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users >
