[Gluster-users] GlusterFS 3.1 on Amazon EC2 Challenge
Gart Davis
gdavis at spoonflower.com
Mon Oct 25 18:13:26 UTC 2010
Barry, Josh,
Thank you both for helping me out with this.
Restating:
> Here's my challenge: I have several 1 tb ebs volumes now that are
> un-replicated and reaching capacity. I'm trying to suss out the most
> efficient way to get each one of these into its own replicated 4 tb
> gluster fs.
To keep things simple, I'm going to focus on a single 1 tb EBS volume
that is 85% full and contains about 2 million thumbnails.
So, based on Barry's first bullet, here is my current working recipe:
1. Spin up two EC2 large intances, load gluster, and peer them
2. Snapshot the production EBS
3. Restore the snapshot onto a new 1 tb EBS, mount it to one of the file servers
4. Create a new blank 1 tb EBS and mount it to the other file server
5. Create a single gluster volume with 'replica 2' and both the above
as brick1 and brick2
6. On a third machine, mount the gluster volume using FUSE
7. From this third machine, trigger the heal process using 'find . | xargs stat'
8. Mount a blank 1 tb EBS to each file server, perform addbrick,
adding these 2 additional bricks to the gluster volume, and perform a
rebalance
9. All else working, shut down production, do a final rsync, and mount
the gluster volume in place of the production EBS
My priincipal concerns with this relate to Barry's 3rd bullet: Gluster
does not rebalance evenly, and so this solution will eventually bounce
off the roof and lock up.
Forgive my naivete Barry, when you say 'just use larger replicate
volumes instead of distribute', what does that mean? Are you running
multiple 1 tb EBS bricks in a single 'replica 2' volume under a single
file server? My recipe is largely riffing off Josh's tutorial.
You've clearly found a recipe that you're happy to entrust production
data to... how would you change this?
Thanks!
Gart
More information about the Gluster-users
mailing list