Hi all, After lots of looking at just about all the distributed file systems out there I have decided that I like the simple setup of GlusterFS the best and not having to have a metadata server seems like a good idea.. The issue I have is working out the best way to setup the cluster we are trying to create.. We have existing hardware that will be used which may throw a few spanners in the works.. The sole purpose of the system is for virtualisation.. The Hardware 2 x 1U Dual Xeon Quad core servers with 2x2TB SATA drives which will be setup in a RAID1 configuration.. 2 x 2U Dual Xeon Quad core servers with 6x2TB SATA drives which will be setup in a RAID10 configuration.. Features we are trying to achieve are.. - Live migration of VM's between any of the nodes.. - High performance (reading and writing to multiple servers) and high availability (loss of a drive or a whole server won't stop any VM's running for any length of time. VM's running on the failed server can be booted immediately on another server) - Scalability - We want to be able to add more nodes to the cluster as and when needed to expand computing power and/or storage.. Firstly can GlusterFS support bricks of different sizes in a volume? I have not been able to find details on this.. Now it seems to me what's needed is a block/chunk level distribution of data rather than file level because VM's run in single large files so if files are distributed at file level it will mean an entire VM image will be stored on one brick which won't help performance.. Am I right in thinking that this is what the "stripe" translator does as opposed to the "distributed" translator? If so how do you achieve high availability with a "stripe" because it would need to be "replicated" as well.. Is this possible?? On different sized bricks?? Then the issue is with scalability.. How do you expand a "striped" and "replicated" volume?? If starting with 4 servers would I have to add another 4 in order to expand the cluster or could I add one at a time?? These are the things I can't figure out with GlusterFS where systems like Ceph allow incremental expansion and the data is then redistributed so there are n copies of each block somewhere in the cluster (its not a strict mirror redundancy but rather distributed redundancy throughout the cluster), at least that's what their documentation says.. If anyone can give any pointers on these issue or advise on how to put it together I would be most grateful.. Thanks in advance... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20120420/66ead1b2/attachment.html>