Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is there any way to run GlusterFS in a replicated mode, but with the ability to dynamically scale the volume up and down?

Say you have 3 servers all running glusterd. your Gluster volume would have to be setup with replica 3

gluster volume create test-volume replica 3

You would then mount it as say \mnt\gfs_test

What happens when I want to add 2 more servers to the storage pool and then also use them in this volume? Is there any easy way to expand the volume AND increase that replica count to 5?

My end goal is to run this on EC2 instances, say 3 Apache front ends, with the webroot setup on the gluster volume mount. My concern is that if I ever need to spin up a server, I would want the server to not only be an additional Apache front end, but also another server in the gluster file system, adding to fault tolerance as well as possibly giving a slight boost in read speed.

Maybe there are better options that would fit the bill here?


share|improve this question
The only work around I can think of at this time would be to use GlusterFS's migrate / delete / add brick features. However, I would have to initially setup a very high replica / brick count (say 8) which would all initially be stored on the first primary server. Once a new server is spawned, you use the migrate brick function to migrate one of those bricks to the new server. Rince and repeat as servers are spun up and down. – ChrisV Jun 28 '11 at 17:38

I won't suggest raising replica count in linear fashion with your web workers. it seems to me pretty a waste of space.

I would instead do a profiling of your web load and define a reasonable amount of replicas from the start. then when new workers are added just deploy $replica_count new gluster nodes and add them as stripe brick to the existing volumes; after a rebalance you will have more performance and more capacity. If you have to scale down you can always remove $replica_count nodes without losing data.

About safety constraints consider trying zfs as underlying fs, since it high resiliance to data loss.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.