From: Evgeniy Polyakov <zbr@ioremap.net>
To: Valdis.Kletnieks@vt.edu
Cc: linux-kernel@vger.kernel.org
Subject: Re: POHMELFS is back
Date: Tue, 20 Sep 2011 18:18:56 +0400 [thread overview]
Message-ID: <20110920141856.GA14739@ioremap.net> (raw)
In-Reply-To: <29686.1316526117@turing-police.cc.vt.edu>
On Tue, Sep 20, 2011 at 09:41:57AM -0400, Valdis.Kletnieks@vt.edu (Valdis.Kletnieks@vt.edu) wrote:
> > If you get 10 times more bandwidth you will not be able to saturate it
> > with 10 times less servers.
>
> The point is that the solutions we're looking at are able to drive enough I/O
> *per server* that we need to look at 10GigE and Infiniband connections. Your
> numbers currently indicate about 5T of disk and 75 megabit of throughput per
> node, while current solutions are doing about 100T and pushing a 10GigE per
> node. So you have a *lot* of per-server scaling work to do still...
Number of server nodes is smaller, and number of physical servers may be
even less. There is a fair number of proxy servers for cluster.
But overall of course every server does not saturate own 1gige link,
since, well, our uplinks are just gigabits :)
> > Scaling to hundreds of server nodes is a
> > good result, since we evenly balance all IO between nodes and no single
> > server is disk or network bound.
>
> You missed the point. Scaling to hundreds of server nodes is a nice
> *theoretical* result, but one that's not going to get a lot of traction out in
> the real world, where the *per server* scaling matters too. Which is my boss
> more likely to be willing to spend money on - a solution that has 50 servers
> per datacenter to deliver 4 Gb/sec per data center, or one that is delivering
> that much *per server*? Remember - servers cost money, rack space costs money,
You are not able to setup 1 server and deliver 4Gb/sec of random IO.
If you think this is possible, than you actualyl did not try to do it
with existing solutions.
> Looked at differently - if I'm currently targeting multiple gigabytes/sec throughput
> to a petabyte of disk from a half-dozen servers, how big and fast a disk farm
> could I build if I had 50 servers in the room, or 200 across datacenters?
A simple question, what RPS rate you got for random reads and writes?
Your solution may scale to bandwifth limits, which is not interesting
for us. Huge single-or-small-node solution is random IO limited, but if
you read big file, then you will be network limited, and can show nice
numbers of Gb/ solution is random IO limited, but if you read big file,
then you will be network limited, and can show nice numbers of Gb/s.
As of GPFS you mentioned, then you did not try to setup cluster with
weak links (i.e. between physically different datacenters), since it
resynchronizes nodes on every glitch and does not scale to RPS, although
quite good ad bulk IO.
So, basically, Elliptics was created for low-latency RPS loads and not
BULK IO.
--
Evgeniy Polyakov
next prev parent reply other threads:[~2011-09-20 14:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-19 6:13 POHMELFS is back Evgeniy Polyakov
2011-09-19 18:10 ` Valdis.Kletnieks
2011-09-20 5:58 ` Evgeniy Polyakov
2011-09-20 13:41 ` Valdis.Kletnieks
2011-09-20 14:18 ` Evgeniy Polyakov [this message]
2011-09-20 6:07 ` Evgeniy Polyakov
[not found] ` <4E78C7CD.3030401@gmail.com>
2011-09-20 17:47 ` Evgeniy Polyakov
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=20110920141856.GA14739@ioremap.net \
--to=zbr@ioremap.net \
--cc=Valdis.Kletnieks@vt.edu \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).