All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joao Eduardo Luis <joao.luis@inktank.com>
To: Ulysse 31 <ulysse31@gmail.com>
Cc: Gregory Farnum <greg@inktank.com>,
	Wido den Hollander <wido@widodh.nl>,
	ceph-devel@vger.kernel.org
Subject: Re: ceph replication and data redundancy
Date: Mon, 21 Jan 2013 13:08:42 +0000	[thread overview]
Message-ID: <50FD3DDA.6060502@inktank.com> (raw)
In-Reply-To: <CAFSDvD1M-7ZJWR=PQBZwkEWOM9ijQ0ManWPGrKBZTPvOWrb4KQ@mail.gmail.com>

On 01/21/2013 08:14 AM, Ulysse 31 wrote:
> Hi everybody,
>
> In fact, i found searching the doc on section "adding/removing a
> monitor", infos about the paxos system used for quorum establishment.
> Following the documentation, in a catastrophy scenario, i need to
> remove the other monitors configured on the other buildings.
> For better efficiency, i think i'll keep 1 monitor per building, and,
> if two other building fails, i will delete those two monitors from the
> configuration in order to access data again.
> I'll simulate that and see if it goes well.
> Thanks for your help and advices.

If you are set on that approach, you could just as well add a third 
monitor on one of the buildings (whichever you feel to be more 
resilient), and cut down the chances of an unavailable cluster if the 
other fails.

It doesn't solve your problem, but if the building with just one monitor 
fails, your cluster will still be available; if it's the other way 
around, you could do the manual recovery just the same anyway.

   -Joao


  reply	other threads:[~2013-01-21 13:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-17  9:55 ceph replication and data redundancy Ulysse 31
2013-01-20 17:29 ` Wido den Hollander
2013-01-20 22:27   ` Gregory Farnum
2013-01-20 22:29   ` Gregory Farnum
2013-01-21  8:14     ` Ulysse 31
2013-01-21 13:08       ` Joao Eduardo Luis [this message]
2013-01-21 13:40         ` Wido den Hollander

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=50FD3DDA.6060502@inktank.com \
    --to=joao.luis@inktank.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=greg@inktank.com \
    --cc=ulysse31@gmail.com \
    --cc=wido@widodh.nl \
    /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.