On Fri, Mar 21, 2014 at 2:02 PM, Justin Dossey <jbd@xxxxxxxxxxxxx> wrote: > The more bricks you allocate, the higher your operational complexity. One > brick per server is perfectly fine. I don't agree that you necessarily have a "higher operational complexity" by adding more bricks per host. Especially if you're using Puppet-Gluster [1] to manage it all ;) I do think you'll have higher complexity if your cluster isn't homogenous or your bricks per host isn't symmetrical across the cluster, or if you're using chaining. Otherwise, I think it's recommended to use more than one brick. There are a number of reasons why you might want more than one brick per host. * Splitting of large RAID sets (might be better to have 2x12 drives per RAID6, instead of one giant RAID6 set) * More parallel IO workload (you might want to see how much performance gains you get from more bricks and your workload. keep adding until you plateau. Puppet-Gluster is a useful tool for deploying a cluster (vm's or iron) to test a certain config, and then using it again to re-deploy and test a new brick count). * More than one brick per server is required if you want to do volume chaining. (Advanced, unsupported feature, but has cool implictions.) And so on... The famous "semiosis" has given at least one talk, explaining how he chose his brick count, and detailing his method. I believe he uses 6 or 8 bricks per host. If there's a reference, maybe he can chime in and add some context. HTH, James [1] https://github.com/purpleidea/puppet-gluster _______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-users
