Bricks are a subset of a volumes and you can have multiple bricks on the same server for a volume. This is important for striping.
Next you have the replica count that is how many replicas you have. I think you can increase them if you rebalance the volume but this isn't something I've tried and I think you would be hard pressed to finds any one else who has.
Finally you have striping and that is how you distribute the files across bricks think raid striping.
Now as far as removing nodes you need to remove the bricks from the volume first so the volume can be rebalanced.
But here is the key point I suspect you may be missing because other people have before. All file operations need to happen on the network attached Gluster volume not the local disk on the individual gluster nodes.
-- Sent from my HP Pre3
On Sep 9, 2014 7:16 PM, Michael Bushey <corwin7@xxxxxxxxx> wrote:
I'm currently using GlusterFS 3.5.2 on a pair of production servers to share uploaded files and it's been reliable and working well with just the two servers. I've done some local tests of trying to add and remove servers and the results have not been good. I'm starting to think I have the wrong idea of what GlusterFS does and I'm trying to stick the square peg in the round hole. Is there some config to say "number of replicas = number of servers"?
My need is to have a copy of the data local on each server. If I have 5 servers, I want five copies of the data. Basically each server should have it's own copy like it's a local ext4/zfs file-system, except it will immediately sync files added or removed on the other servers. I'm not sure the what the gluster definition of brick is, but I believe I want the number of bricks to equal the number of servers (at least for this particular file-system).
I've played around a bit and lost my data every time I've tried to add or remove a node. There is plenty of documentation, but it all says the same thing and doesn't answer the basics.
From `gluster volume info`: Number of Bricks: 1 x 2 = 2
I'm assuming the middle 2 is the number of bricks. I have no clue why we're multiplying by 1 to get itself.
http://gluster.org/community/documentation/index.php/Gluster_3.2:_Displaying_Volume_Information - does not show this magic multiplication. The page for 3.3 does not exist.
We're cloud based and we want to be able to add and remove servers on the fly. If for example I want to scale from 5 to 7 servers, it looks like I need to create a new storage pool with 7 replicas. Would it be the most logical to name my brick with the number of replicas? For example server1 to server5 already have /var/gluster/files5. I could then create /var/gluster/files7 on server1 to server7, create the pool with 7 replicas, then pick a machine like server1 to copy the data from /var/gluster/files5 to /var/gluster/files7, then destroy /var/gluster/files5. This seems extremely convoluted but it does not appear possible to expand a storage pool and expand the number of replicants with it.
Thanks in advance for help and your time to read this.
Michael
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-users
