[Gluster-users] how well will this work
Joe Julian
joe at julianfamily.org
Fri Dec 28 03:06:08 UTC 2012
I have 3 servers with replica 3 volumes, 4 bricks per server on lvm
partitions that are placed on each of 4 hard drives, 15 volumes
resulting in 60 bricks per server. One of my servers is also a kvm host
running (only) 24 vms.
Each vm image is only 6 gig, enough for the operating system and
applications and is hosted on one volume. The data for each application
is hosted on its own GlusterFS volume.
For mysql, I set up my innodb store to use 4 files (I don't do 1 file
per table), each file distributes to each of the 4 replica subvolumes.
This balances the load pretty nicely.
I don't really do anything special for anything else, other than the php
app recommendations I make on my blog (http://joejulian.name) which all
have nothing to do with the actual filesystem.
The thing that I think some people (even John Mark) miss apply is that
this is just a tool. You have to engineer a solution using the tools you
have available. If you feel the positives that GlusterFS provides
outweigh the negatives, then you will simply have to engineer a solution
that suits your end goal using this tool. It's not a question of whether
it works, it's whether you can make it work for your use case.
On 12/27/2012 03:00 PM, Miles Fidelman wrote:
> Ok... now that's diametrically the opposite response from Dan Cyr's of
> a few minutes ago.
>
> Can you say just a bit more about your configuration - how many nodes,
> do you have storage and processing combined or separated, how do you
> have your drives partitioned, and so forth?
>
> Thanks,
>
> Miles
>
>
> Joe Julian wrote:
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> Miles Fidelman <mfidelman at meetinghouse.net> wrote:
>>
>> Joe Julian wrote:
>>
>> It would probably be better to ask this with end-goal
>> questions instead of with a unspecified "critical feature"
>> list and "performance problems".
>>
>>
>> Ok... I'm running a 2-node cluster that's essentially a mini
>> cloud stack
>> - with storage and processing combined on the same boxes. I'm
>> running a
>> production VM that hosts a mail server, list server, web server, and
>> database; another production VM providing a backup server for the
>> cluster and for a bunch of desktop machines; and several VMs used
>> for a
>> variety of development and testing purposes. It's all backed by a
>> storage stack consisting of linux raid10 -> lvm -> drbd, and uses
>> pacemaker for high-availability failover of the
>> production VMs. It all
>> performs reasonably well under moderate load (mail flows, web
>> servers
>> respond, database transactions complete, without notable user-level
>> delays; queues don't back up; cpu and io loads stay within
>> reasonable
>> bounds).
>>
>> The goals are to:
>> - add storage and processing capacity by adding two more nodes -
>> each
>> consisting of several CPU cores and 4 disks each
>> - maintain the flexibility to create/delete/migrate/failover virtual
>> machines - across 4 nodes instead of 2
>> - avoid having to play games with pairwise DRBD configurations by
>> moving
>> to a clustered filesystem
>> - in essence, I'm looking to do what Sheepdog purports to do,
>> except in
>> a Xen environment
>>
>> Earlier versions of gluster had reported problems with:
>> - supporting databases
>> - supporting VMs
>> - locking and performance problems during disk rebuilds
>> - and... most of the gluster documentation implies that it's
>> preferable
>> to separate storage nodes from processing nodes
>>
>> It looks like Gluster 3.2 and 3.3 have addressed some of these
>> issues,
>> and I'm trying to get a general read on whether it's worth
>> putting in
>> the effort of moving forward with some experimentation, or
>> whether this
>> is a non-starter. Is there anyone out there who's tried to run this
>> kind of mini-cloud with gluster? What kind of results have you had?
>>
>>
>>
>> On 12/26/2012 08:24 PM, Miles Fidelman wrote:
>>
>> Hi Folks, I find myself trying to expand a 2-node
>> high-availability cluster from to a 4-node cluster. I'm
>> running Xen virtualization, and currently using DRBD to
>> mirror data, and pacemaker to failover cleanly. The thing
>> is, I'm trying to add 2 nodes to the cluster, and DRBD
>> doesn't scale. Also, as a function of rackspace limits,
>> and the hardware at hand, I can't separate storage nodes
>> from compute nodes - instead, I have to live with 4 nodes,
>> each with 4 large drives (but also w/ 4 gigE ports per
>> server). The obvious thought is to use Gluster to assemble
>> all the drives into one large storage pool, with
>> replication. But.. last time I looked at this (6 months or
>> so back), it looked like some of the critical features
>> were brand new, and performance seemed to be a problem in
>> the configuration I'm thinking of. Which leads me to my
>> question: Has the situation improved to the point that I
>> can use Gluster this way? Thanks very much, Miles Fidelman
>>
>> ------------------------------------------------------------------------
>> Gluster-users mailing list Gluster-users at gluster.org
>> http://supercolony.gluster.org/mailman/listinfo/gluster-users
>>
>>
>
>
More information about the Gluster-users
mailing list