Re: VLDB ASM & SAN Striping Question
Date: Wed, 6 Jun 2012 12:39:51 -0400
Message-ID: <CAJ7936wsFu5hFTfvNEtAsMi1LBXaDAh_srfbhnbxnQTHvvrWNA_at_mail.gmail.com>
Well, so - now we're stepping into territory beyond what I know *specifically* about the EVA and more generally about these types of arrays. So take everything I say with a grain of salt.
First, most of these arrays, when you create a disk group, will typically auto-allocate disks based on some sort of balanced controller/shelf mechanism. So, you tell it to make a disk group out of 4 disks when there are 4 shelves hooked up to the array, one disk will come from each shelf, and each shelf maps to 1 controller, or something like that. I think the EVA puts some number of shelves per controller, but whatever.
So - you could just say, "4 disk group", and it *should* go out and do the best it can do stripe things across controllers and shelves. That being said, the admin utility almost certainly can show you disks and their controllers, though it may not actually allow you to select specific disks.
All that being said, your approach specifically subverts the architectural approach of your storage array, which wants you to make very large disk groups striped across many disks, and let the array worry about placement. Every LUN is striped across all of the disks, and there's even some sort of rebalancing capability, though I've never worked with it specifically. In addition, you're going to need to dedicate disk space for redundancy, so starting to make three-disk groups means you lose 1/3 of your space to redundancy. HP often recommends disk groups with 50+ disks in it, and then carving LUNs out of that.
Matt
On Wed, Jun 6, 2012 at 12:18 PM, Taylor, Chris David
<ChrisDavid.Taylor_at_ingrambarge.com> wrote:
> Okay - now I'm following. My apologies.
>
> So the key is to focus on disk groups - and in a different product, a SAN administrator should be able to identify specific disks easily to assign to a disk group? I would assume this would follow to controllers as well?
>
> Something like this:
>
> 1. Identify Controllers (primary controllers as I assume more than 1 controller can control the same disk in case of failure in the controller?)
> 2. Identify Disks attached to that controller
> 3. Create DG from those disks attached to that controller
>
> *OR* would it make more sense from an IO perspective to:
>
> 1. Identify Controllers
> 2. Identify Disks attached to all controllers
> 3. Create DG from disks from each controller (instead of disks on 1 controller?)
>
> I'm imagining a scenario like:
>
> Disks 1,2,3,4 on controller1
> Disks 5,6,7,8 on controller2
>
> Create DG#1 on Disks 1,5 instead of Disks 1,2 to spread IO across both the disks and the controllers?
>
>
> Chris Taylor
>
> "Quality is never an accident; it is always the result of intelligent effort."
> -- John Ruskin (English Writer 1819-1900)
>
> Any views and/or opinions expressed herein are my own and do not necessarily reflect the views of Ingram Industries, its affiliates, its subsidiaries or its employees.
>
>
> -----Original Message-----
> From: Matthew Zito [mailto:matt_at_crackpotideas.com]
> Sent: Wednesday, June 06, 2012 11:13 AM
> To: Taylor, Chris David
> Subject: Re: VLDB ASM & SAN Striping Question
>
> Right, and my point was just that when you create a disk group, every LUN gets striped across *all* of the disks. So the right way to handle this is to just request a 1 LUN = 1 DG mapping, that way, when you stripe across LUNs you're guaranteed to be on different disks.
>
> However, odds are, you have a giant disk group, and are making LUNs out of that disk group. There is no way, in an EVA, to say, "Map this LUN to just these two disks in the disk group". Everything is striped across all disks in the disk group.
>
> With these kinds of arrays, it is almost impossible to attempt to optimize at an Oracle level for physical placement, and in my experience, it is almost never worth the effort in terms of time and cost.
>
> Matt
>
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Jun 06 2012 - 11:39:51 CDT