All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Nelson <mark.nelson@inktank.com>
To: Gandalf Corvotempesta <gandalf.corvotempesta@gmail.com>
Cc: Florian Haas <florian@hastexo.com>, ceph-devel@vger.kernel.org
Subject: Re: OSD nodes with >=8 spinners, SSD-backed journals, and their performance impact
Date: Tue, 15 Jan 2013 11:46:36 -0600	[thread overview]
Message-ID: <50F595FC.7020903@inktank.com> (raw)
In-Reply-To: <CAJH6TXir4HL0Z7jtEg2r0Or7LygawXQHp0Ou+jF-ow1zXZAryg@mail.gmail.com>

On 01/15/2013 03:31 AM, Gandalf Corvotempesta wrote:
> 2013/1/14 Mark Nelson <mark.nelson@inktank.com>:
>> The advice that I usually give people is that if performance is a big
>> concern, try to match filestore disk and journal performance is nearly
>> matched.  In my test setup, I use 1 intel 520 SSD to host 3 journals for
>> 7200rpm enterprise SATA disks.  A 1:4 ratio or even 1:6 ratio may also work
>> fine depending on various factors.  So far the limits I've hit with very
>> minimal tuning seem to be around 15 spinning disks and 5 SSDs for around
>> 1.4GB/s (2.8GB/s including journal writes) to one node.
>
> Is this a ratio based on OSDs/SSDs or on OSDs/Server ?
> For example, a server with 12 spinning disks plus 2 internal SSD should be used
> for 12 OSDs. The first 6 will have journal on SSD1, the latest 6 will use SSD2.
>
> In this case, ratio is 1:6, right?
> Or are you referring to the whole server?
>

OSDS/SSD I think if I understand you correctly. Basically you just want 
to match OSD and Journal (and network) throughput to be relatively 
similar.  That's not always easy given budgets and whether you are more 
interested in sequential throughput or IOPs.

I think the 12 bay supermicro 2U "A" chassis with 12 spinning disks, 
10GbE, and two controllers is potentially a really nice balanced 
combination.  You could go cheap controllers plus 2 fast SSDs (like 
400-500MB/s seq) or more expensive controllers with WB cache and just 
use the 12 spinning disks for data and journals (and keep the rear 
drives for OS/logs/etc).  Either could potentially be good solutions 
with slightly different performance characteristics.

Of course if you are going all out for IOPs, you probably would be 
looking at a somewhat different kind of solution anyway.

Mark

  reply	other threads:[~2013-01-15 17:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-14 12:17 OSD nodes with >=8 spinners, SSD-backed journals, and their performance impact Florian Haas
2013-01-14 13:28 ` Tom Lanyon
2013-01-14 13:41   ` Florian Haas
2013-01-14 13:46 ` Mark Nelson
2013-01-14 14:09   ` Florian Haas
2013-01-14 17:34     ` Gregory Farnum
2013-01-14 20:17       ` Florian Haas
2013-01-15  9:31   ` Gandalf Corvotempesta
2013-01-15 17:46     ` Mark Nelson [this message]
2013-01-15 21:24       ` Gandalf Corvotempesta
2013-01-15 21:40         ` Mark Nelson
2013-01-15 21:58           ` Gandalf Corvotempesta
2013-01-16  7:41             ` Stefan Priebe - Profihost AG
2013-01-16 17:31               ` Gandalf Corvotempesta
2013-01-18 18:54           ` Simon Leinen
2013-01-18 23:48             ` Gandalf Corvotempesta
2013-01-19  8:18               ` Simon Leinen

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=50F595FC.7020903@inktank.com \
    --to=mark.nelson@inktank.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=florian@hastexo.com \
    --cc=gandalf.corvotempesta@gmail.com \
    /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.