Using EVA LUNs without LVM

[Burhan Halilov_1]

EVA array allows you to increase the size of a LUN. Unfortunately there is no such thing like pvextend on HPUX, and in order to extend a VG you need a new LUN.

What I was thinking is to create a FS directly on the LUN without using LVM at all. This will allow me to extend the FS dynamically in just two steps - increase the LUN size, then fsadm to extend the FS.

What do you gurus think, any drawback of this ?

Burhan

[A. Clay Stephenson]

You could certainly do that but one of the things that LVM does "for free" is alternate paths so that if a cable/controller fails the system will automatically attempt to use another SCSI path.

[Burhan Halilov_1]

Thanks Stephenson

The LUNs I'm going to use are already protected against path failure, unfortunately you can't use pvlinks with the EVA arrays, you MUST buy SecurePath sowftware for that. SecurePath masks the real EVA LUNS and creates SecurePath disk devices under the pseudo-HW paths 255.0.0.*

Any other thoughts ?

[Dave Polshaw]

We have just gone through the same thought process! The word from HP support was there is no reason why not - but you would be on your own as no-one else is doing it! Perhaps if there is more than one doing this we may get a better answer;-)

There will, however, be more than the two steps you suggest.

Firstly the physical disk type (as you get with diskinfo) is in the kernel. You would need to ensure the device file is recreated as the new size. I think an rmsf/ioscan/insf should do this for you but a reboot would be the preferred way.

Secondly, unless you have OnlineJFS you will need to unmount the fs before extending it and then remount it after.

Good luck and keep us posted.

:D

[Stefan Farrelly · Accepted solution]

Burhan,

you do NOT have to purchase SecurePath to use pvlinks under LVM for an EVA. We dont. We do have securepath on some servers but not all and pvlinks work fine on our servers without SecurePath.

The normal procedure to increase a filesystem size is add a new LUN from the EVA, add it to an existing VG, then lvextend, then fsadm to extend filesystem on the fly - works fine. I wouldnt bother trying something nobody has done before and that HP wouldnt support - in case you have problems.

[Alzhy]

"...The LUNs I'm going to use are already protected against path failure, unfortunately you can't use pvlinks with the EVA arrays, you MUST buy SecurePath sowftware for that..."

Right on the money Burhan... To date, I have not received/heard/read of any official confirmation from HPQ that one can already do away with SecurePath and just use PVLINKS on EVA/HSG80 Arrays...

There is some talk of a Universal Filesystem or a tweak to the current VM's/FS (LVM, Veritas, etc..) so that when you're using an EVA and happen to have a Filesystem/LVOL on top of a single EVA LUN -- enlarging your EVA LUN also enlarges your LVOL/Filesystem.. I think this functionality already exists on OpenVMS connected EVA's.. I guess such functionality will happen with the unified Itanic/PARISC HPUX V. 3.0 release? which will blend Tru64's features with HPUX....?

[Todd McDaniel_1]

Stefan,

Burhan was saying he is NOT using LVM so he cant use pvlinks... not that he cant use use pvlinks on EVA, but that he cant do it b/c he isnt wanting to do it.


Burhan,
I am very curious why you are foregoing LVM? Like was said above, you will be without support from HP. I utilize LVM and PowerPath on all my larger boxes/Frames and it is a boon for my SA work. I can't imagine turning away from a great tool like LVM, unless you have a great reason, more than saving a few command line entries...

What is the benefit of managing your disks this way? Please elaborate if you have the time.

[Dave Polshaw]

Our reason for considering it was simply to eliminate one level of management from the equation. The reason for LVM was to enable simpler management of disks, particularly JBODs. Now all that management can be provided at RAID level so why have the extra complexity of LVM? In addition LUNs on a RAID array can grow outside the LVM restrictions of PE size x No of PV's etc.

I agree wholeheartedly that LVM is a great product but that should be no reason not to move onto a better model should the opportunity arise:-) I imagine that, eventualy and if enough people are of the same opinion, HP will move the standard storage model from Logical Volumes to LUNs.

The bigger drawback to moving from LVM in my mind is the number of different types of RAID management there are! At least LVM provides a consistent interface to the LUNs while the different offerings in the RAID market all seem to differ in how their LUNs are managed:-( With LVM at least HP can provide consistent support, regardless of what is behind the LUN!

Cheers

:D

[Todd McDaniel_1]

Thanks Dave,

I just wish my company would move to Veritas FS and Filemanager...

It is much more robust than LVM, but that would require a lot of downtime for my boxes to be rebuilt.

[Alzhy]

Todd... you are already using Veritas FS on all your HP's (As HP's jfs and Online Jfs are the very same Veritas FileSystem or VxFS product) ... Did you mean you wish you were on Veritas Volume Manager?

As to a VM defeating and Filesystem neutral storage subsystem, so that array LUNs (from whatever array) will no longer require a L.VM layer on the OS -- expect it to happen in the near future... IBM for one already has some prototype of a vendor neutral Universal "Filesystem"... so you size/resize or carve your SAN/Array disks.. and it will filter up to the OS level, no more need for any resizing on the OS side...

[Todd McDaniel_1]

yes the Veritas proprietary versions... mistyped...

no points here.

[Simon White]

Burhan,

We are about to have the same discussions abouth EVA and HP-UX and whether LVM is in the picture and why. HP don't seem to say either way.
What did you decide to do in the end?
In our tests I was unable to dynamically extend the filesystem after increasing the size of the LUN - How id you overcome this?

Regards
Simon

[Guy Humphreys]

Hi Folks,

I thought I would reply to this query as I am faced with the self same dilemma.

I recently attended the HP course 'managing EVA arrays' in preparation for my company buying an EVA5K. What the instructor their was saying is to NOT use LVM as it was not needed anymore and had all the PV size expansion limitations - when applied to EVAs.

We have our EVA5K now and I have tested the above scenario, here's what I did

first I created a LUN and presented it to my host, then on the host:

ioscan -fnC disk
insf -H 255/255 etc. etc
ioscan -fnC disk (take note of /dev/dsk path)
newfs /dev/rdsk/c13t0d1
mount /dev/dsk/c13t0d1 /mountpoint

all well and good I can access the disk and copy files to and from it.

Then I increased the size of the LUN on the EVA and again from the host:

umount /mountpoint
extendfs /dev/rdsk/c13t0d1
mount /dev/dsk/c13t0d1 /mountpoint

and all looks OK, I also did a diskinfo of the LUN in question and it reported the new size without doing a rmsf/ioscan/insf combo. I am also assuming that if we had online JFS I would not even need to umount the disk!?

What is the current thinking on LVM on EVAs? Is this method above approved as all I can see that you lose is the nice nameing abilities of LVM. (I am not concerned with pvlinks as we have securepath)

HTH
Guy

[Alzhy]

Guy,

Interesting test. I MUST test as well - we do have OnlineJFS (a.k.a. Veritas File System).

What HP-UX release did you use? Also, what EVA5K - older HSV110 or newer HSV111 based?

Are you using SecurePath ? WHich version?


Exciting news indeed.

[Pat Obrien_1]

Why to use LVM with an EVA5000 vcs 3.x in an HPUX 11iv1.0 environment. Without LVM, the lun is presented to the os, and a fs can be added with the newfs commands. However, every once in a while you may have a disk failure, and this failure may cause loop issues. I previous versions of the vcs code, a failing disk could disappear, and reappear when the loop went looking for the missing disk in self diagnostic testing, and then fail again. This algorithm took several minutes during which the the scsi commands would timeout because the default scsi timer is 30 seconds. Being a good SA, yo will run fsck to correct fs issues deleting your valuable data. Now if you were using LVM, you can set a lvm timer greater than 30 seconds to allow for the self diagnotics to complete in this rare event, and then io continues. Suggestion is to use timeout value greater than 60 seconds in more recent version of vcs.

[Guy Humphreys]

Nelson,

I have an EVA5K with the HSV110 controllers, using VCS 3028

my hosts are all HPUX 11i V1 with SP installed ver 3.0F active-passive

HTH
Guy

[Guy Humphreys]

Pat, you say that a previous version of the vcs code there is this problem with not using LVMS. Does this apply to 3028? or ver 4xxx when that comes out?

Thanks
Guy

[Pat Obrien_1]

You still need LVM when using 3.028 vcs yes. In vcs3.028 your time variable can be 75 seconds instead on minutes in previous version of vcs. I am still converting TB of storage to lvm since the event over a year ago as this non-lvm was my reciepe for deploying storage for a long time. But once being whacked hard in the side of the head, you see the light.

[Hilary Palmer]

I still cannot believe that Microsoft of all companies can allow LUNs to resize and LVM cannot!!

From what I understand the whole point of the SAN is to allow you to dynamically grow your disk as required so you only have to purchase the disk that you need now and add more as you grow. Having to create more LUNs and add them to the Volume Group is still the old scheme of things. Plus eventually we could run out of LUNs. Isn't 255 the max available LUNs to a system? What is the point of the SAN then (other than having more spindles, site-to-site failover, and snapshots)? You might as well have dedicated local disk.

I am going through the same pains right now. Plus, to pour more salt on my wounds, I didn't specify my physical extend size. So for one of my volume groups I can only add 25GB LUNs at a time... add anything more than that I am wasting space because I can't get to it.

I know Linux has some stuff in Beta to allow LUNs to grow on the fly. I hope HP-UX jumps on that boat once it is figured out. For now I will just have to have a messy SAN.

[Pat Obrien_1]

During the last 2 weeks, I have been unfortunate to have 2 different EVAs crash and reboot do to defective disks. One rebooted in 22 seconds and the other in 2 seconds. I figure the lvm withthe timeout is why no users knew this happened verses the last time without lvm we had to perform at 14tb restore.

your mileage may vary.

[Guy Humphreys]

Wow! two EVAs failing in two weeks - how unlucky is that?!! I am a bit peturbed that the EVA is not as robust as I was lead to belive!!

anyhoo - for the lvm timeout command is it just a matter of using pvchange -t 75 to increase the timeout from the default of 30 secs?

thanks for your help
Guy

[Guy Humphreys]

Pat, (and anyone else who may be interested)

I have created a new thread to ask my questions in so I can assign points, see below

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1003960

Guy