Hi guys, My first post, so sorry if it is something that was covered before. I read quite a bit of the documentation and archived posts, but couldn't find the answers: 1) Can I configure GlusterFS so it can withstand a complete 'brick' failure without users loosing access to their data? 2) If Yes, can I configure how many redundant copies of the files are store, e.g. 2x, 3x? 3) Can I control the amount of replication per user? 4) Is it correct to assume that after a failed 'brick' comes back online, the auto-heal functionality will take care of the re-sync'ing? 5) As GlusterFS stores Metadata along with the normal data, what is the capacity overhead in %? Any feedback is hugely appreciated. Phil Huber
Hello ! Philipp Huber wrote:> 1) Can I configure GlusterFS so it can withstand a complete 'brick' > failure without users loosing access to their data?Yes.> 2) If Yes, can I configure how many redundant copies of the files are > store, e.g. 2x, 3x?Yes.> 3) Can I control the amount of replication per user?No.> 4) Is it correct to assume that after a failed 'brick' comes back > online, the auto-heal functionality will take care of the re-sync'ing?Yes (but not in the background...)> 5) As GlusterFS stores Metadata along with the normal data, what is the > capacity overhead in %?That's a good question. :) -- Daniel Maher <dma+gluster at witbe.net>
Philipp Huber wrote:> Daniel, > > Fantastic, thanks very much for your reply. We are very excited about GlusterFS and are working on a business case for a Cloud Storage product that would complement our Cloud Computing platform. > > One quick question re your #4 answer, does that mean you will have to take the volume down for a re-sync? > > Thanks for your reply, > PhilPlease direct your replies to the list, mate. :) As for question #4 : > 4) Is it correct to assume that after a failed 'brick' comes back > online, the auto-heal functionality will take care of the re-sync'ing? The volume doesn't need to be taken down, no, but replication won't happen by magic either. Basically, for a node to realise that its copy of the file is no longer current (or that it shouldn't be there, or should be there, or whatever), the file has to be accessed. On a webserver or something like that, the access might easily occur organically (a graphic or html page being served). On file servers where there's less interactivity, running a simple script that will find and, say, stat the files in the exported tree (for example) will ensure coherency. -- Daniel Maher <dma+gluster at witbe.net>