All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Durgin <josh.durgin@inktank.com>
To: Dennis Jacobfeuerborn <dennisml@conversis.de>
Cc: ceph-devel@vger.kernel.org
Subject: Re: What would a good OSD node hardware configuration look like?
Date: Mon, 05 Nov 2012 16:14:47 -0800	[thread overview]
Message-ID: <50985677.6090708@inktank.com> (raw)
In-Reply-To: <5097F3BD.2000904@conversis.de>

On 11/05/2012 09:13 AM, Dennis Jacobfeuerborn wrote:
> Hi,
> I'm thinking about building a ceph cluster and I'm wondering what a good
> configuration would look like for 4-8 (and maybe more) 2HU 8-disk or 3HU
> 16-disk systems.
> Would it make sense to make each disk an individual OSD or should I perhaps
> create several raid-0 and create OSDs from those?

This mainly depends on your ratio of disks to cpu/ram. Generally we
recommend 1GB ram and 1Ghz per OSD. If you've got enough cpu/ram,
running 1 OSD/disk is pretty common. It makes recovering from a
single disk failure faster.

> Also what is the best setup for the journal? If I understand it correctly
> then each OSD needs its own journal and that should be a separate disk but
> that would be quite wasteful it seems. Would it make sense to put in two
> small SSD disks in a raid-1 configuration and create a filesystem for each
> OSD journal on it?

This is certainly possible. It's a bit less overhead if you give each
osd it's own partition of the ssd(s) instead of going through another
filesystem.

I suspect it would be better to not use raid-1, since these ssds will be
receiving all the data the osds write as well. If they're in raid-1 
instead of being used independently, their lifetimes might be much
shorter.

> How does the number of OSDs/Nodes affect the performance of say a single dd
> operation? Will blocks be distributed over the cluster and written/read in
> parallel or does the number only improve concurrency rather than benefit
> single threaded workloads?

In cephfs and rbd, objects are distributed over the cluster, but the
OSDs/node ratio doesn't really affect the performance. It's more
dependent on the workload and striping policy. For example, with
a small stripe size, small sequential writes will benefit from more
osds, but the number per node isn't particularly important.

Josh

  reply	other threads:[~2012-11-06  0:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-05 17:13 What would a good OSD node hardware configuration look like? Dennis Jacobfeuerborn
2012-11-06  0:14 ` Josh Durgin [this message]
2012-11-06  2:49   ` Dennis Jacobfeuerborn
2012-11-06 19:30     ` Josh Durgin
2012-11-07  1:35       ` Dennis Jacobfeuerborn
2012-11-07  7:35         ` Wido den Hollander
2012-11-07  8:17           ` Gandalf Corvotempesta
2012-11-07  8:21             ` Wido den Hollander
2012-11-07  8:29               ` Gandalf Corvotempesta
2012-11-06  7:36   ` Stefan Priebe - Profihost AG

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=50985677.6090708@inktank.com \
    --to=josh.durgin@inktank.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=dennisml@conversis.de \
    /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.