<html><head/><body><html><head></head><body>Trying to return to the actual question, the way I handle those is to mount gluster volumes that host the data for those tasks from within the vm. I've done that successfully since 2.0 with all of those services. <br>
<br>
The limitations that others are expressing have as much to do with limitations placed on their own designs as with their hardware. Sure, there are other less stable and/or scalable systems that are faster, but with proper engineering you should be able to build a system that meets those design requirements. <br>
<br>
The one piece that wasn't there before but now is in 3.3 is the "locking and performance problems during disk rebuilds" which is now done at a much more granular level and I have successfully self-healed several vm images simultaneously while doing it on all of them without any measurable delays. <br><br><div class="gmail_quote">Miles Fidelman <mfidelman@meetinghouse.net> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif; margin-top: 0px">Joe Julian wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">It would probably be better to ask this with end-goal questions <br />instead of with a unspecified "critical feature" list and "performance <br />problems".</blockquote><br />Ok... I'm running a 2-node cluster that's essentially a mini cloud stack <br />- with storage and processing combined on the same boxes. I'm running a <br />production VM that hosts a mail server, list server, web server, and <br />database; another production VM providing a backup server for the <br />cluster and for a bunch of desktop machines; and several VMs used for a <br />variety of development and testing purposes. It's all backed by a <br />storage stack consisting of linux raid10 -> lvm -> drbd, and uses <br />pacemaker for high-availability failover of the
production VMs. It all <br />performs reasonably well under moderate load (mail flows, web servers <br />respond, database transactions complete, without notable user-level <br />delays; queues don't back up; cpu and io loads stay within reasonable <br />bounds).<br /><br />The goals are to:<br />- add storage and processing capacity by adding two more nodes - each <br />consisting of several CPU cores and 4 disks each<br />- maintain the flexibility to create/delete/migrate/failover virtual <br />machines - across 4 nodes instead of 2<br />- avoid having to play games with pairwise DRBD configurations by moving <br />to a clustered filesystem<br />- in essence, I'm looking to do what Sheepdog purports to do, except in <br />a Xen environment<br /><br />Earlier versions of gluster had reported problems with:<br />- supporting databases<br />- supporting VMs<br />- locking and performance problems during disk rebuilds<br />- and... most of the gluster documentation implies that it's
preferable <br />to separate storage nodes from processing nodes<br /><br />It looks like Gluster 3.2 and 3.3 have addressed some of these issues, <br />and I'm trying to get a general read on whether it's worth putting in <br />the effort of moving forward with some experimentation, or whether this <br />is a non-starter. Is there anyone out there who's tried to run this <br />kind of mini-cloud with gluster? What kind of results have you had?<br /><br /><br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">On 12/26/2012 08:24 PM, Miles Fidelman wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">Hi Folks,<br /><br />I find myself trying to expand a 2-node high-availability cluster <br />from to a 4-node cluster. I'm running Xen virtualization, and <br />currently using DRBD to mirror data, and pacemaker to failover cleanly.<br
/><br />The thing is, I'm trying to add 2 nodes to the cluster, and DRBD <br />doesn't scale. Also, as a function of rackspace limits, and the <br />hardware at hand, I can't separate storage nodes from compute nodes - <br />instead, I have to live with 4 nodes, each with 4 large drives (but <br />also w/ 4 gigE ports per server).<br /><br />The obvious thought is to use Gluster to assemble all the drives into <br />one large storage pool, with replication. But.. last time I looked <br />at this (6 months or so back), it looked like some of the critical <br />features were brand new, and performance seemed to be a problem in <br />the configuration I'm thinking of.<br /><br />Which leads me to my question: Has the situation improved to the <br />point that I can use Gluster this way?<br /><br />Thanks very much,<br /><br />Miles Fidelman</blockquote><br /><br /><br /><hr /><br />Gluster-users mailing list<br />Gluster-users@gluster.org<br /><a
href="http://supercolony.gluster.org/mailman/listinfo/gluster-users">http://supercolony.gluster.org/mailman/listinfo/gluster-users</a></blockquote><br /></pre></blockquote></div></body></html></body></html>