Received: (qmail 2488 invoked from network); 6 Jun 2012 11:42:08 -0500
Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180)
  by static-ip-85-25-126-90.inaddr.ip-pool.com with SMTP; 6 Jun 2012 11:42:00 -0500
Received: from localhost (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 45CE2ED23A9;
 Wed,  6 Jun 2012 12:41:20 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=freelists.org;
 s=turing; t=1339000880; bh=T7YjJ05NqWpsZbMNPCI0bhpcBFQ7ol4ImXtq5pGg
 ZTo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:
	 From:To:Cc:Content-type:Content-Transfer-Encoding:Sender:Reply-To:
	 List-help:List-unsubscribe:List-Id:List-subscribe:List-owner:
	 List-post:List-archive; b=cv9em0VK1BrCL286ACe9R87rk+uvgKmKl8wTqh2K
 5a5CdPi0WS+dt0VjlIc/f0+2Ey6kIjuuj19+gYANosXWwjSmkcrip5JlkFabNs+a+EU
 9EUmXYpD6BJNpgXoPR8U7p0duFRCdTqP9jhec4I/17yfBHZiBWpeUfIJdjk+iET0=
X-Virus-Scanned: Debian amavisd-new at localhost.localdomain
Received: from turing.freelists.org ([127.0.0.1])
 by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id LKAKqbj2FLVF; Wed,  6 Jun 2012 12:41:20 -0400 (EDT)
Received: from turing.freelists.org (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 92399ED2315;
 Wed,  6 Jun 2012 12:40:37 -0400 (EDT)
Received: with ECARTIS (v1.0.0; list oracle-l); Wed, 06 Jun 2012 12:39:56 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id C3658ED0A4B
 for <oracle-l@freelists.org>; Wed,  6 Jun 2012 12:39:55 -0400 (EDT)
Received: from turing.freelists.org ([127.0.0.1])
 by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id GlvhqJcmeXja for <oracle-l@freelists.org>;
 Wed,  6 Jun 2012 12:39:55 -0400 (EDT)
Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id E0426ECFF8C
 for <oracle-l@freelists.org>; Wed,  6 Jun 2012 12:39:53 -0400 (EDT)
Received: by obbup19 with SMTP id up19so10318273obb.10
        for <oracle-l@freelists.org>; Wed, 06 Jun 2012 09:39:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding:x-gm-message-state;
        bh=Mfc8uVshSPCb4AvtaXHJK9otmn7/FeXNmiGhnvzP/eQ=;
        b=doftWiJxXdv8Ocfycus9FTL68uXN8FXN3vWs62g1wAZt2OvounSrmloFrk4/lWmOrq
         18Q3AvMS5lx7C/d+u+s7gRN+qHUXTpQrZ4YF6LATcOORLwdyu54VXc1/IW6j/ZiW1ulT
         Hnp1T90Z1OJfO+6Agi0KrxswmK1dj4lfnRXwIMc7ZWQtQtSqZyc9f3gICpnTEsiv/CqO
         uyZVkUhSmXzacDYDiFHSfPfKju2xCCmrmFN2JZ8yLYxqqcRQkP5Mkqys7q+7Iu/foo/+
         AKVHsk7aEMlHmoeMv7rfKyj747xenfeVpgQpNOYJLWAtzCv3pz+hyMy+XPuHj/TR8Wls
         UdvA==
MIME-Version: 1.0
Received: by 10.182.18.137 with SMTP id w9mr21099296obd.75.1339000791335; Wed,
 06 Jun 2012 09:39:51 -0700 (PDT)
Received: by 10.76.34.69 with HTTP; Wed, 6 Jun 2012 09:39:51 -0700 (PDT)
In-Reply-To: <C5533BD628A9524496D63801704AE56D75B286AB13@SPOBMEXC14.adprod.directory>
References: <C5533BD628A9524496D63801704AE56D75B286A95E@SPOBMEXC14.adprod.directory>
 <CAJ7936xX=9p6mnnXRVS8dRDWaGchNd1ftjGwAE-ZX5MGTxuB7A@mail.gmail.com>
 <C5533BD628A9524496D63801704AE56D75B286AAF5@SPOBMEXC14.adprod.directory>
 <CAJ7936zQZrBCFZkeKtAhV5Q=nbz9PW_2Gvxn1vVSU0sWW-_uOw@mail.gmail.com>
 <C5533BD628A9524496D63801704AE56D75B286AB13@SPOBMEXC14.adprod.directory>
Date: Wed, 6 Jun 2012 12:39:51 -0400
Message-ID: <CAJ7936wsFu5hFTfvNEtAsMi1LBXaDAh_srfbhnbxnQTHvvrWNA@mail.gmail.com>
Subject: Re: VLDB ASM & SAN Striping Question
From: Matthew Zito <matt@crackpotideas.com>
To: "Taylor, Chris David" <ChrisDavid.Taylor@ingrambarge.com>
Cc: "oracle-l@freelists.org" <oracle-l@freelists.org>
Content-type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Gm-Message-State: ALoCoQmKQnas9bqFzbqsP6Is83hg3MYH8/SFemWKUq71zX9GZZLQqPH8S1xPlEzKr7Y8d6XwZnuW
X-archive-position: 43200
X-ecartis-version: Ecartis v1.0.0
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
X-original-sender: matt@crackpotideas.com
Precedence: normal
Reply-To: matt@crackpotideas.com
List-help: <mailto:ecartis@freelists.org?Subject=help>
List-unsubscribe: <oracle-l-request@freelists.org?Subject=unsubscribe>
List-software: Ecartis version 1.0.0
List-Id: oracle-l <oracle-l.freelists.org>
X-List-ID: oracle-l <oracle-l.freelists.org>
List-subscribe: <oracle-l-request@freelists.org?Subject=subscribe>
List-owner: <mailto:steve.adams@ixora.com.au>
List-post: <mailto:oracle-l@freelists.org>
List-archive: <http://www.freelists.org/archives/oracle-l>
X-list: oracle-l

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@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@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-l


