SEO

Sorry for posting this here but I never got any feedback in the storage
group....

I have enterprise class storage (ESS800) and some lower-end fastt900
storage connected to AIX and Windows hosts.


Is there any benefit in creating smaller LUN's vs bigger LUN's when
connecting an AIX server to the ESS (or FAStT).


I was always lead to believe that the more hdisks the better since you
get more spindles and disk queues. If I create 5 LUN's or 10 LUN's from

the SAN storage then in both cases I may use the same number of
physical disks. So I'm not getting in more physical disks or spindles.
What about disk queues - I'm getting more of them when I create smaller

LUN's but I'm not really sure what (if anything) that is doing for my
performance.


Can someone explain the connection between LUN disk queues and phsical
disks - what do they really mean?

well, queue_depth and cmd_size would give you the number of I/O
operations the LUN can handle at given time, that number should not
exceed the number of I/O operations the controller can handle ( times
the number of controller but not exceed the number of I/O operations
you can perform at storage level )... So, there is no direct answer to
your question, it's more about what I/O you can generate at application
level to sutturate your disks and what's the nature of your
application. Some time you might get by having fewer LUNs and bigger
ones and have less disks to configur/monitor/etc, some times having
more LUNs ( well, there is a limit actually in both AIX and ESS ) of a
smaller size will give you advantage... Keep in mind the more LUNs you
make at storage and having several HBA will add more burden then help...

apples wrote:
> Sorry for posting this here but I never got any feedback in the storage
> group....
>
> I have enterprise class storage (ESS800) and some lower-end fastt900
> storage connected to AIX and Windows hosts.
>
>
> Is there any benefit in creating smaller LUN's vs bigger LUN's when
> connecting an AIX server to the ESS (or FAStT).

I don't know of any performance benefits to using smaller luns, but
there are other considerations (Mostly application related). For
database environments, how do you back up a 1TB pool with one database
on it inside a timely window? (Or restore it for that matter?) Disk
hotspots are easier to deal with when you can shift components of the
database or application into different sets of smaller luns. The IBM
sales guys might say you don't have to worry about 'hot spots' on an
ESS, but the right combination of DBA neglect and developer bloat can
drag any SAN disk system to its knees...

> I was always lead to believe that the more hdisks the better since you
> get more spindles and disk queues. If I create 5 LUN's or 10 LUN's from
> the SAN storage then in both cases I may use the same number of
> physical disks. So I'm not getting in more physical disks or spindles.
> What about disk queues - I'm getting more of them when I create smaller
> LUN's but I'm not really sure what (if anything) that is doing for my
> performance.

As far as performance, no there's no real benefit these days to jamming
more disks into a raid or virtual disk. You have a largish cache on the
SAN controller that throws the old religion out the window (IE, more
spindles doesn't directly give you more performance in a SAN worth it's
beans). Instead of playing ring-around-the-raid, you'll be playing
whack-a-mole with Fibre Channel throughput and array contention with
other systems on your ESS. If you're curious about performance of
different RAID configurations within the ESS you might check out this
IBM benchmark doc on ESS. It's focused on Oracle, but has good numbers
on RAID performance within the ESS:
http://www-03.ibm.com/servers/storag...id5-raid10.pdf

> Can someone explain the connection between LUN disk queues and phsical
> disks - what do they really mean?

LUN disk queues? Not sure what you mean by that, however having the
ability to size luns to anything you want just gives you more control.
However, there are still plenty of reasons to keep small lun sizes
instead of just tossing a 1TB pool at the OS (As stated above). If the
application you support really wants 40GB volumes instead of 36GB (32GB
usable) then you can just request your san group give you 40GB vols
instead of you wrangling multiple disks into the sizes you need.