[prev in list] [next in list] [prev in thread] [next in thread] 

List:       veritas-vx
Subject:    RE: [Veritas-vx] Advice : Max # of columns
From:       "Sebastien Daubigne" <sebastien.daubigne () atosorigin ! com>
Date:       2005-09-15 8:39:47
Message-ID: 02d601c5b9d1$0857c380$32950237 () daubigne
[Download RAW message or body]


Just to add some background :
We rarely do LUN addition.
Usually we plan disk space for 2 years.
So we usually grow our VxVM volume without relayout (we just add space from
the same LUNs, vertically).
When disk space has exhausted, we generally move to another disk array due
to financial/performance reasons (the transfer is easy : offline volume copy
or online mirroring).
There has however been some rare situations where we've added LUNs. Thus we
used online relayout, but this is not usual.

Now about our configuration :

The storage array is an IBM ESS, with 44 RAID-5 array groups ("rank" of 8
physical disks). The database is a Datawarehouse, so the I/O pattern is
mainly sequential (many full scan of large tables).
We configured each rank as a single 250 Gb LUN.
Then we stripe each VxVM volume on a definite number of LUNs (the number is
the purpose of this thread).
Hence the are two level of stripping : one level inside the array (don't
cross physical disks dependencies), and one level with VxVM (crossing disks
dependencies).
The idea is to provide the entire I/O throughput of the array to each volume
in all situations.

--
Sebastien DAUBIGNE
Sebastien.daubigne@atosorigin.com
mailto:Sebastien.daubigne@atosorigin.com>  - +33(0)5.57.26.56.36
AtosOrigin Infogerance - IMS/ERP/Pessac


-----Message d'origine-----
De : Ronald S. Karr [mailto:tron@veritas.com]
Envoye : mercredi 14 septembre 2005 21:11
A : Sebastien Daubigne
Cc : veritas-vx@mailman.eng.auburn.edu
Objet : Re: [Veritas-vx] Advice : Max # of columns


There are no internal performance issues in VxVM caused by "excessive"
numbers of stripe columns.  The internal algorithms don't generate any
more locks, performance from VxVM itself is affected only by how many
stripe units the I/O crosses and how big the stripe units are.  If the
stripe unit size is 64K, then an I/O of 1MB will cross 16 stripe units
and will submit 16 I/Os to the SAN, irrespective of whether those 16
stripe units are stored on 4 columns (thus yielding 4 I/Os to each
LUN) or 1,000 columns (thus leaving almost all LUNs unaffected by the
I/O).

I am not personally in favor of pure SAME allocation, but that is
mostly because of management problems that it causes for users.  In
particular, it is rather time consuming with pure SAME striping to add
more disk space by adding LUNs.  Restriping is slow and moves a LOT of
data, so you end up wasting disk bandwidth to do the operation, yet the
operation takes long enough that the grow can't respond quickly.

For flexbility, it is much easier to use, say, an 8 column stripe and
then add 8 LUNs at a time when growing.  Alternately, if you have a
disk array that stripes internally, then striping in VxVM really
doesn't buy you anything, unless you are striping across disk arrays
as well, so don't bother with it.
--
        Ronald S. Karr
        tron |-<=>-|    tron@veritas.com

On September 14, 2005, Sebastien Daubigne wrote:
 >Hi,
 >
 >We have 44 luns which are on separate physical disks (hardware : Fujitsu
 >PW1500 + IBM ESS2105-800 + 4xEmulex LP10000DC).
 >The luns are multipathed via 8 channels with DMP.
 >We want to create a collection of RAID0 striped volumes using the SAME
 >(Stripe-And-Mirror-Everything) method for an Oracle database..
 >
 >If we follow this guideline (the SAME theory), we should allocate each
 >volume striped on the 44 luns (44 stripe colums).
 >
 >But I just wonder if there is any "performance limitation" for VxVM on the
 >number of columns of a striped volume, considering the fact that for each
 >volume, VxVM will have to manage at least 46 vxvm objects ? Would it
 >generate VxVM internal kernel spin/locks or something similar ?
 >In other words, would it be better to create 44-colums stripes, or subsets
 >(2 sets of 22-colums striped volumes, or 4 sets of 11-columns striped
 >volumes) ?
 >
 >The only goal here is performance, manageability is not an issue with VxVM
 >(we had 20-colums stripes on another database, it was not a problem thanks
 >to VxVM online relayout facility).
 >
 >Thanks for advices.
 >
 >--
 >Sebastien DAUBIGNE
 >Sebastien.daubigne@atosorigin.com - +33(0)5.57.26.56.36
 >AtosOrigin Infogerance - IMS/ERP/Pessac

_______________________________________________
Veritas-vx maillist  -  Veritas-vx@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
[prev in list] [next in list] [prev in thread] [next in thread]