DRBD vs. GlusterFS for replication

This is a classic scale-out use case, and IMO GlusterFS should fit the bill. You can give it a try - just bring a few VMs up, set up a few bricks to be used for repository storage and run a stress test.

DRBD is not an option here anyway - it doesn't scale. If anything, I'd look at other object storage projects (Swift for example), if Gluster doesn't work well enough, but none of them are extremely performance oriented

I had a similar set up for cyrus mail servers in which gluster has proven not to be able to handle the load during stress tests. we originally chose gluster because it was simple but had to move back to drbd. however as dyasny highlighted, drbd activs/active cfg is not advisable (not to mention the pain). if you need all servers to mount the shared storage at the same time drbd is not an option. Another thing you may want to look at is clvmd with lock manager. lvm2 now have support for raid type lv and use man code for that purpose. this mixed with the appropriate filesystem (some cluster aware ones if needed) can be an option. however I never tested it myself in production, only as PoC.

The problem you will have with Gluster is mainly latency between the nodes. I would advise you give it a try and see if it handles your workload. If your servers are are powerful enough and have a fast interconnect you should get a fairly good performance. Also you might want to try the built-in NFS server, which, talking from my experience, handles small files a little bit faster.

But if you need your solution as fast as possible GlusterFS probably isn't for you. Other options would be commercial products like Git Clustering(haven't tested that, though) or you could build your own solution with free tools like gitmirror.

If you are considering Gluster (which in my experience is usable with many small files but YMMV), you might want to have a look at Ceph as well http://ceph.com/