From: Daniel Swarbrick <daniel.swarbrick-EIkl63zCoXaH+58JC4qpiA@public.gmane.org>
To: ceph-users-idqoXFIVOFJgJs9I8MT0rw@public.gmane.org
Cc: ceph-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Crushmap ruleset for rack aware PG placement
Date: Tue, 16 Sep 2014 12:02:36 +0200 [thread overview]
Message-ID: <lv91s9$4j2$1@ger.gmane.org> (raw)
In-Reply-To: <alpine.DEB.2.00.1409150826060.513-vIokxiIdD2AQNTJnQDzGJqxOck334EZe@public.gmane.org>
On 15/09/14 17:28, Sage Weil wrote:
>
> rule myrule {
> ruleset 1
> type replicated
> min_size 1
> max_size 10
> step take default
> step choose firstn 2 type rack
> step chooseleaf firstn 2 type host
> step emit
> }
>
> That will give you 4 osds, spread across 2 hosts in each rack. The pool
> size (replication factor) is 3, so RADOS will just use the first three (2
> hosts in first rack, 1 host in second rack).
I have a similar requirement, where we currently have four nodes, two in
each fire zone, with pool size 3. At the moment, due to the number of
nodes, we are guaranteed at least one replica in each fire zone (which
we represent with bucket type "room"). If we add more nodes in future,
the current ruleset may cause all three replicas of a PG to land in a
single zone.
I tried the ruleset suggested above (replacing "rack" with "room"), but
when testing it with crushtool --test --show-utilization, I simply get
segfaults. No amount of fiddling around seems to make it work - even
adding two new hypothetical nodes to the crushmap doesn't help.
What could I perhaps be doing wrong?
next prev parent reply other threads:[~2014-09-16 10:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-15 7:47 Crushmap ruleset for rack aware PG placement Amit Vijairania
[not found] ` <CADgBPFCVUVQZtHNkSsuMhskL2X-FTBTYy6zcav3CRpNCBGHJgg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-09-15 15:28 ` Sage Weil
2014-09-15 18:21 ` Amit Vijairania
[not found] ` <alpine.DEB.2.00.1409150826060.513-vIokxiIdD2AQNTJnQDzGJqxOck334EZe@public.gmane.org>
2014-09-16 10:02 ` Daniel Swarbrick [this message]
[not found] ` <54184711.3080002@dachary.org>
[not found] ` <lv9p5b$1h1$1@ger.gmane.org>
[not found] ` <D03E84B7.B8D%johnugeo@cisco.com>
[not found] ` <541945F8.60001@dachary.org>
2014-09-17 14:42 ` [ceph-users] " Johnu George (johnugeo)
2014-09-17 16:10 ` Loic Dachary
2014-09-17 20:03 ` Johnu George (johnugeo)
2014-09-17 20:11 ` Loic Dachary
2014-09-17 22:40 ` Johnu George (johnugeo)
2014-09-18 2:03 ` Chen, Xiaoxi
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='lv91s9$4j2$1@ger.gmane.org' \
--to=daniel.swarbrick-eikl63zcoxah+58jc4qpia@public.gmane.org \
--cc=ceph-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=ceph-users-idqoXFIVOFJgJs9I8MT0rw@public.gmane.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.