All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Sławomir Skowron" <szibis@gmail.com>
To: Tommi Virtanen <tommi.virtanen@dreamhost.com>
Cc: "ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>
Subject: Re: Tier and MetroCluster
Date: Fri, 17 Feb 2012 23:50:49 +0100	[thread overview]
Message-ID: <-4752001628700025891@unknownmsgid> (raw)
In-Reply-To: <CAORUGqByVskXRNDA+8USz1_0jTHy6BPyHV9rjayr4fmpfrCLyA@mail.gmail.com>

Dnia 17 lut 2012 o godz. 19:06 Tommi Virtanen
<tommi.virtanen@dreamhost.com> napisał(a):

> 2012/2/17 Sławomir Skowron <szibis@gmail.com>:
>> 1. Is there any plan about tier support. Example:
>> I have ceph cluster with fast SAS drives, and a losts of RAM, and SSD
>> acceleration, and 10GE network. I use only RBD, and RadosGW. Cluster
>> have relative small capacity, but its fast.
>> I have a second cluster with diffrent configuration, with a large
>> number of big SATA drives, and smaller number of RAM, 1Gb ethernet.
>> Same usage as above.
>> All i need is to have phisical 2 clusters, but with some tier
>> function, to move old objects from fast to slow cluster (for archive),
>> and opposite.
>
> You can do this right now, by having just one cluster, specifying
> different crush rulesets for different pools, and then moving your
> objects from one pool to another as they get "old". You'll need to
> manage the migration yourself -- with RADOS, explicitly creating
> objects in the "old" pool, with Ceph DFS, "cephfs PATH set_layout
> --pool MYPOOL" only affects new files. For radosgw, this doesn't
> currently exist, and I'm not sure how it would behave, but it is
> conceivable.
>
>> If ceph will be very stable this can be done inside one cluster it
>> will be much simpler, but crush need to know what is faster, and what
>> is slower.
>
> There are no extra smarts about it. For RADOS, there most likely will
> be no automatic thing here -- after all, we are intentionally avoiding
> any lookup tables -- for the Ceph DFS, I can see that the set_layout
> logic could be extended to migrate existing files too. And radosgw
> might get this as an automatic feature, one day.

Thanks for advice.

From the economical point of view its very nice feature, and i will be
happy to see it in radosgw in some future maybe :)

Yes, you have right, It can be done by the tool in offline via RADOS,
and it's good idea. Maybe storing, a key=>value counters for a object
inside ceph, or outside, but it is simple my mind storming :)

>
>> 2. Like above two clusters this time same configurations and size, but
>> with async replication between.
>> Replication can be done by the external replication darmon on top of
>> rados, or other solution.
>>
>> Is there any plans with any of this ?? Or something like this ??
>
> I think this is something a lot of people will want, so it probably
> will get done at some point. It is not being developed, currently.

Thanks, and i am waiting for some new exciting features in ceph project :)
--
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-02-17 22:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-17 16:13 Tier and MetroCluster Sławomir Skowron
2012-02-17 18:05 ` Tommi Virtanen
2012-02-17 22:50   ` Sławomir Skowron [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=-4752001628700025891@unknownmsgid \
    --to=szibis@gmail.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=tommi.virtanen@dreamhost.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.