Large LUN vs more luns

[joseph morrison_3]

Hi

I need to create 2x 1.5 TB VGs on a new HP EVA 5000 using HP-UX 11.00.Is there any advantage to creating multiple smaller luns than 1x1.5TB lun per VG?
1 disk group has been configured on the EVA.
Both VGs will contain identical copies of an Oracle DB.

Are there any LVM issues/gotchas with this size lun besides increasing PE size?

[Arockia Jegan]

If you are going to have one or two LUN with a TB size the queue depth is going to be less that will affect your system performance. But if you have multiple LUNS the queue depth is going to be high and give you good performance.

Also if you are planning to go for double striping(hardware and software) you have to go with more LUNS.

[Jeff Schussele]

Hi,

I've always believed that more LUNs give you a slight performance gain as the odds of the data being spread out over more spindles is higher.
Of course it's up to the person designing & creating the LUNs to make that happen.
So I'd go with smaller LUNs - possibly 10 x 150Mb.

And yes beside PE size (-s) you should also consider increasing max-pv (-p) & max-pe (-e) to accomodate any possible future extensions to the VG.

My 2 cents,
Jeff

[Jeff Schussele]

Of course that should have been.....

10 X 150Gb

Jeff

[Geoff Wild]

We are about to migrate from one EMC to a new one - and we have determined that for our Applications, going with 33GB striped meta's is the way to go. Currently we are on 8.6 GB Hypers...for a 1.5 TB DB....in our case we need 47 lun's...


Rgds...Geoff

[Sunil Sharma_1]

Hi,
it's always recommended to create multiple LUN and Ideal size of lun is 36-72 GB .

so it's better if you create small lun and stripe it for batter performence.

Sunil

[Animesh Chakraborty]

Hi,
I had 4 & 8 GB Luns and soon the number of luns reached 255.It was EMC symm 8730.
EMC said it can not support more than 255 luns /per fibre port.
We had to reconfigure the whole box making bigger size of luns which reduced the number of luns.
Not sure if there is any limitation on HP.Please check it out.

[joseph morrison_3]

Thanks for your responses.

The number of spindles is not an issue with the EVA as a lun is spread across all spindles(currently 72x72Gb disks).The queue depth might be worth considering, although I suspect that performance won't be a problem on the EVA( 2Gb FC spindles,2Gb FC controllers)

[Claudiu Schmidt]

Hi,

we did some 8 weeks of testing with the EVA and the Clariion from EMC ,we measured performance with both systems. The EVA has the advantage of spreading the information on all the disks in a diskgroup, so the larger the diskgroup, the more spindles you get for the lun's. To get the same performance on the clariion, you need to create more luns in different raid groups.
The performance of the EVA was not affected by the number of luns, neither by the blocksize or number of concurrent io requests, so i don't think you will reach any bottleneck with this system.

Rgds,

Claudiu

[Victor BERRIDGE]

If I agree with what said above, nevertheless I continue to be in favor of many LUNs when it comes to performance because how will your interface(S) cope with your "Giant LUN" when it come to try to balance the load? with multiple LUNS you can staticaly do some load balancing using primary/alternate pathing and better still if did distribute the LUNS between your controllers, stripe on few LUNS...

All the best

Victor

[Claudiu Schmidt]

Victor,

EVA works only with Secure Path under HPUX, and this software will load ballance over all path to this lun.


Rgds,

Claudiu

[Pete Randall]

This is probably naive, but doesn't one giant LUN present a SPOF (Single Point Of Failure) risk?


Pete

[Marco Santerre]

Pete, I guess the answer to your question is not necessarily. The thing is that LUN being logical more than physical, if you have two paths to your LUN(s), you're not in a SPOF situation. As for the hardware itself, though I'm not familiar with EVA, if you have some Raid capacity, this should all be internal to the array. So I guess a large LUN doesn't represent a SPOF necessarily. I, for one, always liked more luns as opposed to larger LUNs. Though I understand the statements made before about performance, and if they are correct, that means that it wouldn't matter whether you have one LUN or many LUNs. I still believe for manageability of your VGs and the whole structure, it is easier to manage with smaller sized LUNs. Again, just a preference and opinion.

[Pete Randall]

Marco,

Yeah, I understand. I guess I was thinking more along the lines of how LVM utilizes the LUN. One LUN=one VG. It's probably not much of a risk, but I was curious (and naive, as I said - I've never done it).


Pete

[Sridhar Bhaskarla]

Hi,

I would not say "many" luns but a reasonable number of LUNs instead of one big LUN. The system may develop hot luns over a course of time and if you have one big lun, you cannot attempt to move the data across the other luns. For me, I would create a maximum size of 120 G and a minimum for 30G for a 1.5TB VG. Since you have quite a bit of data, consider using load sharing by keeping some disks on the alternate path.

-Sri

[Marco Santerre]

Pete,

I understand also what you mean. What I'm starting to think though, and maybe I'd be concerned with that is more along the lines of : what if you have a physical drive failure and you have one LUN as opposed to many LUNs. So that means you'll have to recover the whole LUN (unless it is already mirrored with the hardware) as opposed to recovering one smaller LUN if one physical inside that LUN fails. Now I understand that this is for an Oracle DB and therefore, chances are you'd have to recover the whole base anyway. But maybe something to think about?

[Pete Randall]

Yeah, more LUNs sounds like the way to go, at least to me.


Pete

[Leif Halvarsson_2]

Hi.
I know that one must not generalize to much here, there is differences between traditional RAID systems and the EVA systems but ...

Marko and Pete:
Are you perhaps confusing between RAID-sets and LUNs. As long the LUNs is in the same RAID-set (set of physical disks) there is no advantage with several small LUNs compared to one big, either with performance or with security. And, if you want smaller filesystems for faster backup/restores you can partition the LUN on OS level more easy (logical volumes).

[Jeff Schussele]

Hi Marco,

I understand what you're saying, but I've never suffered a drive failure with any BIG array - EMC, Hitachi, HP XP, etc.
They're ALL protected by RAID-5 & hot spares at a minimum.
AT least ones set up by knowledgable personnel....
The key here is "spreading the load" across multiple spindles, LVs & HBA paths.
So in a properly prepared array, you should *never* see a LUN failure unless you have extremely bad karma & suffer multiple drives failure in a time span where the inherent protection doesn't have *enough* time to mitigate it.

Rgds,
Jeff

[joseph morrison_3]

Thanks everyone for your input.I think a minimum of 2 LUNs per VG is a good idea, if only for load balancing.

Actually this customer is not using Secure Path-this is a single HBA environment (I know its a waste-but its what the cu wants and it is supported).So 1 FCA,1 controller,1 port per lun.

[Sunil Sharma_1]

Hi,

I think by creating more number of LUNs you will have flexibility to manage disk space and you can take out some space if required later point of time and you can add also.

Sunil

[Brian Watkins]

You'll be better off using multiple 36GB or 72GB LUNs in the VG. This will give you more physical spindles to spread the IO across, which will help prevent IO bottlenecks and improve IO performance.

If you use 36GB or 72GB LUNs along with striping, your new DBs should really scream.

We just migrated a customer off of an old FC60 onto our Symmetrix. Their DB was around 300GB, so we gave them a 360GB volume group comprised of 10x36GB LUNs striped across all members at 128K and they've done nothing but marvel at how much better the DB performs now.

[John Payne_2]

You are using 1 HBA now, but is there a possibility that you will have 2 later? If so, you want to use secure path now to manage the luns so that it doesn't come around and stomp on things now. Also, secure path can do load balancing on the controller side, even with 1 HBA.

We have an EVA here, and I have the HW/Mass Storage guys set luns to 250GB, but that was just for conformities sake. We have 1 machine with 1TB divided into 4 luns. We really didn't get much out of it, performance seems to be the same as with a gigantic lun. (We tested this before the EVA was in production here...) With Oracle, the DBA's just wanted a bunch of filesystems to point to anyway. We have our redo logs on a separate lun as the data, etc. This seems to had mitigated a risk issue in the minds of the DBA's.

With our configuration, we are very happy, but we really didn't see a difference from a large lun to several smaller luns, except you have more VG's to deal with.

The secure path failover with 2 HBA's is almost transparent, by the way.

Hope it helps

John

[Alzhy]

I am for one large LUN.

RAID groups on modern arrays (EVA, HDS, etc..)from which LUNs are carved and assembled now usually deal with 73GB physical disks (minimum) with 144GB and 288+GB physical disks on the way. Most common array configs these days are 2x2 stripe-mirrors or 3+1P RAID5. So we're talking about 140GB to 210GB RaidGroups here which could be presented as single LUN's or assembled into larger LUN's depending on your array -- or carved up into smaller LUN's (LUNlet as I would call them).

Presenting RAIDgroups as large LUN's (TB sized for that matter) should pose no performance issues - rather it simplifies things - dealing with smaller disk/lun objects that one has to deal with in your choice of VM- volume manager (logical). Your VM can carve up this gigantic LUN into smaller slices or volumes if you wish.

It is still a religious debate whether presenting one gigantic LUN (say 1.5 TB LUN) as a single filesystem say for Oracle or FIleshare use. The most common issues - allegedly performance and inherent risks. The others would be backups -- obviously it will be a challenge for traditional backup systems to backup one gigantic filesystem -- sepcially for those that still use tapes. I would decline to comment - but I am for large or lerger LUN presentations from modern arrays and somewhat selective whether I would want to present this large lun as just one filesystem.

[doug mielke]

I'm a big lun fan, if it comes down to vote counting.

My real reason for this post is a 'bug?' as salesman described, with the last version of secure path ( prior to March, 03)

All my luns failed to be presented upon first reboot. Having multiple arrays, this resulted in hardware paths pointing to wrong devices. A mess.

I was told to run an SP update command, (sorry, my notes are home) and relink kernel, and that this is fixed in the March version of secure path.