Migrating from CX to VNX - performance with AIX

We recently went through the same thing.

We settled on using larger pools = More spindles

Fast Cache and FAST VP

2 to 4 LUNs (depending on LUN size and number of Host CPU Sockets):

- More LUN's More = More queues

- Better Host CPU utilization (Was told more LUNs made CPU's more efficient due to better utilization with multiple threads - I haven't confirmed this, but it sounded reasonable and the reason I posted to see if anyone else agrees or disagrees with this.)

- Ability to split IO between SP's on the VNX

i would imagine that you would get more bandwidth with 2 x 400G LUNs split between SPA/SPB and striped in LVM, not necessarily more throughput.

jps00 wrote: IMHO, I think continuing to implement your LVMs on traditional RAID groups, as you original describe, would give you higher, more deterministic performance, and higher capacity utilization.

for ultra performance sensitive apps i would agree, but i hate to lose the ability to use FAST with traditional RGs. Even with pooled LUNs "hot" slices will bubble up to the top tier or get serviced by Fast Cache if available ( i know Fast Cache will service traditional RG). What's your opinion ?

I would defer to the learned dynamox's advice.  A pool allocates LUNs to SPs in a 'round robin' fashion.  You want at least two LUNs to engage both SP A & B.  I would also create a single pool for the LUNs to avoid contention.

I think you should also consider the level-of-abstraction that implementing your LVM "on top" of a pool will entail. 

LVMs and pools are analogous in function.  In implementation they are both 'logical storage constructs' layered on top of the physical drives.  By putting your LVM within a pool, you're putting a logical construct (LVM) on top of a logical construct (Pool).  The multiple levels of abstraction are going to cost you in both capacity and overall performance.

IMHO, I think continuing to implement your LVMs on traditional RAID groups, as you original describe, would give you higher, more deterministic performance, and higher capacity utilization.

Guys, thanks for the feedback.  I also like the advantages of FAST and the pools - I don't feel the need for old Raid Groups.  But I still like multiple LUNs and LVM striping on AIX.  I've noticed on AIX that if you create a standard Logical Volume/file system with multiple LUNs it will write only to the first LUN. Once that LUN is full it will then write to the second LUN.  If I stripe it will write one AIX PP to the first LUN and the second write will go to the second LUN.  If I do thousands of writes it will balance the writes perfeclty between the two LUNs.  If I put each LUN on a different SP then the SPs will be balanced perfectly.   This is important for file systems that may sit iddle part of the time but have extreme bursts at other times.

Does this make sense?

I would add one caution. With Pools you must be careful about assigning the default SP owner as you can do with raid group LUNs. WIth Pools you want the array to assign the SP owner if you create multiple LUNs at one time (create 20 LUNs and "auto" selected), each LUN will get assigned to alternating SP's. If you create one LUN at a time, then you need to manaully assign the SP for each LUN to alternate between each SP. In the one LUN at a time method and if you select the "auto" instead of SPA or SPB, then each new LUN will be assigned to SPB. With mutilple LUNs and "auto" selected, the LUNs will be assigned alternating SP's.

Once you have your LUNs setup the way you want, DO NOT trespass any Pool LUN. Trespassing Pools LUNs will impact overall performance. Pools LUNs should always be on the "default" owner. This is much more important than it was when using raid group LUNs.

glen

Fast Cache works with traditional LUNs.

For the capacity the OP is considering (800 GB),  that's going to be a small pool.  Its tough to come-up with a tiered pool topology (FAST VP) for < 1TB.  To maintain performance, he'll need to create at least four private RAID groups within the pool.

HTH