From: Wido den Hollander <wido@widodh.nl>
To: Matthew Roy <imjustmatthew@gmail.com>
Cc: Miles Fidelman <mfidelman@meetinghouse.net>,
ceph-devel <ceph-devel@vger.kernel.org>
Subject: Re: ceph for small cluster?
Date: Wed, 02 Jan 2013 13:17:14 +0100 [thread overview]
Message-ID: <50E4254A.5000502@widodh.nl> (raw)
In-Reply-To: <CADXA5U0sGE9tyNKjbESS3_uxuYDrfUxE4rKg9UxC5TLkLcAAvg@mail.gmail.com>
On 01/01/2013 01:13 AM, Matthew Roy wrote:
> On Mon, Dec 31, 2012 at 9:14 AM, Miles Fidelman
> <mfidelman@meetinghouse.net> wrote:
>>
>>
>> Which raises another question: how are you combining drives within each OSD (raid, lvm, ?).
>>
>
> I'm not combining them, just running an OSD per data disk. On this
> cluster it's 2 disks for each of the 3 nodes. I ended up that way
> only because I added the second disk to each node after getting
> started. There was an inktank blog post not too long ago about the
> performance of RAID'ed disks on OSDs that might provide quantitative
> justification for which route to go.
>
> Like Wido suggests, I also use a shared SSD for journal on each node.
> The journal's not really about speeding recovery from failed
> OSDs/disks, it's about being able to ACK writes faster and still
> retain integrity when Bad Things happen. If you're RAIDing with a
> battery-backed cache I think you can run without a journal, but I
> don't know the details on that.
>
That depends on the RAID controller. Some (like Areca I think) cache
O_DIRECT writes in their write cache, but other still flush them
directly to the disks although they have a cache with BBU.
I'd try to prevent using any RAID system with Ceph. Let the replication
handle everything. The less hardware and complexity you add, the less
can fail.
Wido
> Matthew
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2013-01-02 12:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-30 21:38 ceph for small cluster? Miles Fidelman
2012-12-31 9:10 ` Wido den Hollander
[not found] ` <CADXA5U1ATB+1baCfBSHmzozRe3m-HhLxHQr3be1-dASgABPQYw@mail.gmail.com>
2012-12-31 14:14 ` Miles Fidelman
2013-01-01 0:13 ` Matthew Roy
2013-01-02 12:17 ` Wido den Hollander [this message]
[not found] <50E19E34.7080005@meetinghouse.net>
2012-12-31 14:21 ` Miles Fidelman
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=50E4254A.5000502@widodh.nl \
--to=wido@widodh.nl \
--cc=ceph-devel@vger.kernel.org \
--cc=imjustmatthew@gmail.com \
--cc=mfidelman@meetinghouse.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox