From: Tomasz Chmielewski <mangoo@wpkg.org>
To: Gregory Farnum <gregf@hq.newdream.net>
Cc: Wido den Hollander <wido@widodh.nl>, ceph-devel@vger.kernel.org
Subject: Re: Ceph on just two nodes being clients - reasonable?
Date: Wed, 19 Jan 2011 17:21:30 +0100 [thread overview]
Message-ID: <4D370F8A.3080601@wpkg.org> (raw)
In-Reply-To: <AANLkTimHi64ZB5_AY1_eQu5abHB+S+bvcSShL_NE3Me0@mail.gmail.com>
On 19.01.2011 16:57, Gregory Farnum wrote:
>> Currently, I'm running glusterfs in such a scenario (two servers, each being
>> also clients), but I wanted to give ceph a try (glusterfs has some
>> performance issues with lots of small files), also because of its nice
>> features (snapshots, rbd etc.).
> Rather than running 3 monitors you could just put a monitor on one of
> the machines -- your cluster will go down if it fails, but in a 2-node
> system it's not like resilience from one-node failure would be very
> helpful anyway.
OK, I could imagine starting the monitor on just one node i.e. with the
help of heartbeat - so if the node with the monitor goes down, heartbeat
starts the monitor process on the other machine.
> However, there is a serious issue with running clients and servers on
> one machine, which may or may not be a problem depending on your use
> case: Deadlock becomes a significant possibility.
Sounds like the "freezes" issue mentioned by Dong Jin Lee?
> This isn't a problem
> we've come up with a good solution for, unfortunately, but imagine
> you're writing a lot of files to Ceph. Ceph dutifully writes them and
> the kernel dutifully caches them. You also have a lot of write
> activity so the Ceph kernel client is doing local caching. Then the
> kernel comes along and says "I'm low on memory! Flush stuff to disk!"
> and the kernel client tries to flush it out...which involves creating
> another copy of the data in memory on the same machine. Uh-oh!
Uh-oh, it doesn't sound encouraging, and will likely happen sooner or later.
Would some sort of zero-copy help here? But perhaps it's not that easy
to solve, otherwise, we wouldn't be discussing it here.
I think swapping over NFS (or, iSCSI) has a similar problem ("need to
write, but the network buffer is full, so we can't write over network ->
deadlock"), and there were some patches floating around some years ago
to solve it. Not sure what's the state of it and how similar it is to
Ceph though.
Last I checked, 2 < 3, so having a budget HA solution which just needed
2 servers instead of 3 would be a great thing to have! ;)
--
Tomasz Chmielewski
http://wpkg.org
next prev parent reply other threads:[~2011-01-19 16:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-19 10:33 Ceph on just two nodes being clients - reasonable? Tomasz Chmielewski
2011-01-19 11:30 ` DongJin Lee
2011-01-19 11:41 ` Wido den Hollander
2011-01-19 11:55 ` would you recommend me a solution to store xen-imgfile Longguang Yue
2011-01-19 17:06 ` Sage Weil
2011-01-19 12:14 ` Ceph on just two nodes being clients - reasonable? Tomasz Chmielewski
2011-01-19 15:57 ` Gregory Farnum
2011-01-19 16:21 ` Tomasz Chmielewski [this message]
2011-01-19 17:55 ` Colin McCabe
2011-01-19 20:03 ` Tommi Virtanen
2011-01-19 21:09 ` Colin McCabe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D370F8A.3080601@wpkg.org \
--to=mangoo@wpkg.org \
--cc=ceph-devel@vger.kernel.org \
--cc=gregf@hq.newdream.net \
--cc=wido@widodh.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.