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
