All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Durgin <josh.durgin@inktank.com>
To: Stephen Perkins <perkins@netmass.com>
Cc: ceph-devel@vger.kernel.org
Subject: Re: ESXi and ideal hardware spec
Date: Mon, 27 Aug 2012 13:23:29 -0700	[thread overview]
Message-ID: <503BD741.8000708@inktank.com> (raw)
In-Reply-To: <00b501cd8480$2dc46b60$894d4220$@netmass.com>

On 08/27/2012 11:17 AM, Stephen Perkins wrote:
> Are there any thoughts on placing all Ceph nodes as single virtual machines
> running on top of an ESXi hypervisor?   What I mean by this is that each
> brick runs ESXi and then only runs one virtual machine.

This sounds like it's going to have a bunch of overhead, but if
the performance under ESXi is acceptable to you, it might make sense.
I'm not aware of anyone testing OSDs on ESXi, so you could run into
performance issues that don't appear on real hardware.

> Are there any advantages of running the MON and MDS servers as independent
> virtual machines on the same physical brick as an OSD virtual machine
> (rather than just running the processes)?  Multi-port Ethernet systems can
> segregate traffic between the instances...

If your kernel/glibc doesn't support syncfs(2), running the monitor in
a virtual machine can be beneficial since it won't affect the OSD when
calling sync(2). I don't see many other advantages, since the monitors
are pretty light-weight.

It might be a disadvantage to run the MDS in vm, since it will make a
large chunk of memory unusable by the OSD, even after the MDS stops
using some of it, and vice versa. You may prefer to be able to control
the amount of memory available to each independently, but I don't see
much advantage there. The OSD will require more memory during recovery
than during normal usage, so running the MDS and OSD as processes lets
them use the memory the other doesn't need at the moment. The MDS
effectively serves as a cache, so having lots of memory for it is
important for metadata-heavy workloads.

Josh

      reply	other threads:[~2012-08-27 20:23 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-27 18:17 ESXi and ideal hardware spec Stephen Perkins
2012-08-27 20:23 ` Josh Durgin [this message]

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=503BD741.8000708@inktank.com \
    --to=josh.durgin@inktank.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=perkins@netmass.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.