All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Horner <james.horner@precedent.co.uk>
To: Gregory Farnum <greg@inktank.com>
Cc: James Horner <james.horner@precedent.co.uk>,
	ceph-devel@vger.kernel.org, Mark Kampe <mark.kampe@inktank.com>
Subject: Re: Client Location
Date: Wed, 10 Oct 2012 10:16:04 +0100 (BST)	[thread overview]
Message-ID: <653431320.70.1349860564219.JavaMail.root@corellia.pncl.co.uk> (raw)
In-Reply-To: <CAPYLRzgznZaZ+xVsY1Er2sYKbF7hfpfewGDPygiHQDSmxDPu6Q@mail.gmail.com>

Hi There

The basic setup Im trying to get is a backend to a Hypervisor cluster, so that auto-failover and live migration works. The mail thing is that we have a number of datacenters with a gigabit interconnect that is not always 100% reliable. In the event of a failure we want all the virtual machines to fail over to the remaining datacenters, so we need all the data in each location.
The other issue is that within each datacenter we can use link aggregation to increase the bandwidth between hypervisors and the ceph cluster but between the datacenters we only have the gigabit so it become essential to have the hyperviors looking at the storage in the same datacenter.
Another consideration is that the virtual machines might get migrated between datacenters without any failure, and the main problem I see with Mark suggests is that in this mode the migrated VM would still be connecting to the OSD's in the remote datacenter.

Tbh Im fairly new to ceph and I know im asking for everything and the kitchen sink! Any thoughts would be very helpful though.

Thanks
James

----- Original Message -----
From: "Gregory Farnum" <greg@inktank.com>
To: "Mark Kampe" <mark.kampe@inktank.com>
Cc: "James Horner" <james.horner@precedent.co.uk>, ceph-devel@vger.kernel.org
Sent: Tuesday, October 9, 2012 5:48:37 PM
Subject: Re: Client Location

On Tue, Oct 9, 2012 at 9:43 AM, Mark Kampe <mark.kampe@inktank.com> wrote:
> I'm not a real engineer, so please forgive me if I misunderstand,
> but can't you create a separate rule for each data center (choosing
> first a local copy, and then remote copies), which should ensure
> that the primary is always local.  Each data center would then
> use a different pool, associated with the appropriate location-
> sensitive rule.
>
> Does this approach get you the desired locality preference?

This sounds right to me — I think maybe there's a misunderstanding
about how CRUSH works. What precisely are you after, James?
-Greg
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2012-10-10  9:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1253073523.409.1349787553083.JavaMail.root@corellia.pncl.co.uk>
2012-10-09 13:14 ` Client Location James Horner
2012-10-09 13:30   ` Wido den Hollander
2012-10-09 13:33     ` james.horner
2012-10-09 16:43   ` Mark Kampe
2012-10-09 16:48     ` Gregory Farnum
2012-10-10  9:16       ` James Horner [this message]
2012-10-10 16:39         ` Sage Weil

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=653431320.70.1349860564219.JavaMail.root@corellia.pncl.co.uk \
    --to=james.horner@precedent.co.uk \
    --cc=ceph-devel@vger.kernel.org \
    --cc=greg@inktank.com \
    --cc=mark.kampe@inktank.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.