From: Gregory Meno <gmeno@redhat.com>
To: Sage Weil <sweil@redhat.com>
Cc: John Spray <john.spray@redhat.com>,
ceph-calamari@ceph.com, ceph-devel@vger.kernel.org
Subject: Re: [ceph-calamari] disk failure prediction
Date: Thu, 19 Feb 2015 10:59:48 -0500 (EST) [thread overview]
Message-ID: <1616949710.23204723.1424361588930.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1502190644490.3074@cobra.newdream.net>
----- Original Message -----
> From: "Sage Weil" <sweil@redhat.com>
> To: "John Spray" <john.spray@redhat.com>
> Cc: ceph-calamari@ceph.com, ceph-devel@vger.kernel.org
> Sent: Thursday, February 19, 2015 9:58:21 AM
> Subject: Re: [ceph-calamari] disk failure prediction
>
> On Thu, 19 Feb 2015, John Spray wrote:
> >
> > On 18/02/2015 23:20, Sage Weil wrote:
> > > We wouldn't see
> > > quite the same results since our "raid sets" are effectively entire pools
> >
> > I think we could do better than pool-wide, e.g. if multiple drives in one
> > chassis are at risk (where PG stores at most one copy per chassis), we can
> > identify that as less severe than the general case where multiple at-risk
> > drives might be in the same PG. Making it CRUSH-aware like this would be a
> > good hook for users to take advantage of the ceph/calamari SMART monitoring
> > rather than rolling their own.
>
> Yeah, sounds good. The big question in my mind is whether we should try
> to pull this into the osd/mon or have calamari do it. It seems like a
> good fit for calamari...
I agree that calamari is a good place for this. We have the ability to target
nodes by capability and the ability to distribute modules/install packages
to run checks. What is missing in my opinion is a service that aggregate the
data and easy routing to the api.
Also we should be able to connect more dots for the consumer of this data
now that calamari is beginning to understand CRUSH and how it maps
to the physical entities that make up a cluster.
>
> BTW, a bit more color on the original paper (after talking to Paul): the
> EMC workload in the paper was backup/archival with heavy heavy write, and
> any time there was a read failure it triggered a rewrite and triggered a
> relocated sector. Other studies have shown some pretty different results.
> For example, one showed that the best preditor was actually not SMART at
> all but (carefully measured) read latency.
>
> In any case, it seems like the bits that are gathering and aggregating
> SMART should be general, and we should make it easy to plug in various
> policies (or delegate to an external agent) for responding to that data.
Allowing an easy way to add specific checks and alerting
in calamari would be easier to manage than making it part of ceph.
We had discussed a plugin system for calamari in the past. it may be easier
to just document how to do it with a good example and then iterate to
make it easier. I want to focus on more data gathering and alerting in
calamari in general going forward.
-Gregory
prev parent reply other threads:[~2015-02-19 15:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-18 23:20 disk failure prediction Sage Weil
2015-02-19 8:56 ` [ceph-calamari] " John Spray
2015-02-19 14:58 ` Sage Weil
2015-02-19 15:59 ` Gregory Meno [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=1616949710.23204723.1424361588930.JavaMail.zimbra@redhat.com \
--to=gmeno@redhat.com \
--cc=ceph-calamari@ceph.com \
--cc=ceph-devel@vger.kernel.org \
--cc=john.spray@redhat.com \
--cc=sweil@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox