jeremy.page at gilbarco
Apr 8, 2011, 6:34 AM
Views: 1553
Permalink
|
|
RE: Distribute aggregate across shelves or limit to one shelf?
[In reply to]
|
|
I'd second Stefan's comment. User error is generally the cause of
downtime, not hardware outages (assuming a reasonably architected sytem
from a redundancy standpoint). Complicating things generally makes you
more prone to outages, not less.
-----Original Message-----
From: owner-toasters [at] mathworks [mailto:owner-toasters [at] mathworks]
On Behalf Of Stefan Funke
Sent: Friday, April 08, 2011 2:18 AM
To: toasters [at] mathworks
Subject: Re: Distribute aggregate across shelves or limit to one shelf?
Whatever you do, there is always a tradeoff between reliability,
performance and efficiency. I think all concerns are well answered in
NetApps storage resiliency paper: Do Raid-DP, do backups, do HA, do
multi-pathing, do disk auto assign, have spare parts (etc) and you'll
have 99,999% availability and a max of performance, as long as you can
afford it.
And btw., limiting you and your system to have 1 aggregate/shelf
produces a lot of work reassigning disks/spares over time when your
systems grows. After 10+ years of operating netapp systems, I always had
my aggregates (volumes earlier) spread across all shelves and never had
any trouble with it.
-SF
Am 07.04.2011 21:58, schrieb Ray Van Dolson:
> Best practice (based on my reading of the archives) seems to be to
> distribute disk membership in an aggregate across disk shelves.
>
> This would appear to be for performance reasons primarily (less chance
> of saturating a shelf's "uplink" to the controller), but how does it
> affect reliability?
>
> If I limit myself to one aggregate per shelf, if I lose that shelf I
> lose only the one aggregate. If aggregates are distributed I could
> lose all of them.
>
> My thought is that the chance of the shelf failing is actually pretty
> slim as its hardware isn't all that sophisticated.
>
> And obviously there are performance penalties for limiting to one
> aggregate per shelf (disk count maximums).
Please be advised that this email may contain confidential
information. If you are not the intended recipient, please notify us
by email by replying to the sender and delete this message. The
sender disclaims that the content of this email constitutes an offer
to enter into, or the acceptance of, any agreement; provided that the
foregoing does not invalidate the binding effect of any digital or
other electronic reproduction of a manual signature that is included
in any attachment.
|
