All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Nelson <mark.nelson@inktank.com>
To: Brice Burgess <briceburg@gmail.com>
Cc: ceph-devel@vger.kernel.org
Subject: Re: Hardware Requirements for RADOS Gateway Cluster
Date: Mon, 24 Sep 2012 18:34:21 -0500	[thread overview]
Message-ID: <5060EDFD.1050908@inktank.com> (raw)
In-Reply-To: <5060E5AE.10400@gmail.com>

Hi Brice!

On 09/24/2012 05:58 PM, Brice Burgess wrote:
>I am planning the system architecture around a ceph cluster [my first!].
> While resources for setting up the basic cluster (MON+MDS+OSD) are
> readily available*, I haven't come across anything outlining production
> recommendations for a RADOS Gateway Cluster. Specifically;
>
> 1. Is it preferable to run the RADOS Gateway on a MDS machine [for
> latency issues], or should the Gateway run on seperate hosts/VMs than
> the ODS/MON/MDS servers?
>

It's entirely possible to run the gateway on an OSD/MON/MDS.  I don't 
think we've done any kind of extensive analysis of where the best place 
to run one is.  My guess is that it will only matter in very specific cases.

> 2. I've seen reference that multiple RADOS Gateway servers can be setup
> as a cluster "to scale". Is this possible? Is there an
> example/documentation for this? Is it just 2 standalone gateways with a
> load balancer in front?
>

Yes!  It's entirely possible to run multiple RGWs with a load balancer 
in front.  I'm not sure how much documentation is out there for this 
yet, but it's something that customers of ours have successfully 
implemented.

> My assumption is to provision a dedicated machine for the RADOS Gateway.
> I'd treat this machine as a "front end proxy/caching server" meaning it
> would have a lot of RAM for varnish/nginx and a low latency, high
> throughput network connection to the ODS/MDS machines as well as one to
> the public network.

Sounds good to me.  Other people might chime in with more suggestions.

>
> Any thoughts and suggestions are welcome. Eventually I'd like to release
> a whitepaper of this setup if we can hit the budget to actually
> implement ;)

Some things you'll want to keep in mind:

You'll want to make sure that your testing (especially of small IO) is 
done across many buckets.  Performance of a single bucket can be limited 
by the OSD where it's log is stored (or optionally you can turn the log 
off).  You'll also want to keep in mind that RGW will likely incur 
larger performance overhead for small objects than large ones.

Thanks,
Mark

  reply	other threads:[~2012-09-24 23:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-24 22:58 Hardware Requirements for RADOS Gateway Cluster Brice Burgess
2012-09-24 23:34 ` Mark Nelson [this message]
2012-09-26 16:02 ` Tommi Virtanen

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=5060EDFD.1050908@inktank.com \
    --to=mark.nelson@inktank.com \
    --cc=briceburg@gmail.com \
    --cc=ceph-devel@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 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.