Using LVM with EVA Disk Array

[Mike Railton]

We are about to start implementing a HP EVA5000 disk array with our exiting HP 9000 HP-UX 11.0 servers. On these servers we use the standard LVM supplied with HP-UX 11.0 (we do not have On-Line JFS on some of our servers).

I have a couple of questions relating to LVM set up for the EVA, Business Copy and snapshots.

As I understand the situation, with HP-UX and Business Copy for the EVA, HP recommends creating Volume Groups (VG) with a single LUN from the EVA (i.e. one EVA Virtual Disk per VG). On the EVA you can only snap one Virtual Disk at a time and by having one Virtual Disk per VG you ensure any ???snap??? is for the whole VG and is fully consistent.

1. If this recommendation is correct how do you increase the size of the VG without adding a further LUN (i.e. a further EVA Virtual Disk)?

2. On the EVA it is possible to increase the size of a Virtual Disk (and therefore the LUN presented to the server) but can HP-UX 11.0 with standard LVM cope with the LUN size change?

Many Thanks
Mike.

[Alzhy]

We are also about to embark on exactly the same enterprise as you. I earlier questioned the wisdom of using Array-based cloning/mirroring tools because of such limitations. I believe LVM won't be able to handle LUN size changes for which your only option is use Online JFS (aka Veritas FileSystem - VxFS) - wherein you vgextend your VG by adding another LUN instead of expanding the existing LUN... But then such would go against HP's recommendation of 1 LUN per VG... so..

What I am proposing we proceed is just use host-based "mirroing" or backups to floating LVM VG's or VxVM Diskgroups. This will be possible by exploiting the EVA's LUN multipathing capabilities. This means creating a group of LUNs that are all visible from all your servers (what's the multipathing limit on EVA's - anyone?). Either by mirroring software of just plain copies of data to be backed up to these floating LUN's -- one can thence "import" all those LUN's that were earlier controlled by the servers to be backed up to your backup server... The result - you "floated" a sizable amount of data to your backup server that you can now stage to tape media...

You'll save on backup software licenses (SSO, or DDS) and you really onlyhave to connect your tape backup systems to your backup server... I've already prototyped such a scheme using the base Veritas Volume Manager (VxVM) that comes with HPUX 11i...

server1 --- will have a diskgroup named server1 which contains a single Filesystem to store backup data from server1. server1 DiskGroup will have LUN(s) that are accessible by both server1 and the backup server...

srver2.. likewise will have such

serverN .... ditto...

bkpsrvr -- wil just simply do a vxdg import of those servers that're done backing up to the floaters...from here, it can stage to tape at its leaisure...

[Mike Railton]

Nelson,

Thanks very much for you info, it has given me a few ideas, it is also a disappointment as we had originally been told that standard LVM would handle LUN size changes but I was suspicious it may not. I will take your comments onboard and see how we can use your approach locally.

Mike.

[Bill Costigan]

We've done some testing with LVM and the EVA.

1. You can (and I think, should) use more than one LUN in a volume group. You need to be sure that all the LUNs are copied at the same time so that one PV is not out of sync with the others.) You do not want to be writing to the lvols while making a business copy.

If possible umount the file systems, make a business copy of all the PVs (LUNS) remount the file systmes. Then on the copied side re-activate the VG with a vgchange -a y, fsck all the rlvols, and mount the file systems.

2. You cannot increase the size of a LUN and have HP-UX/LVM use it. Therefore, if you want to extend an lvol/VG you'll need to add LUNs (PVs)to the VG.

Pick a reasonble PV size and max number of PVs when creating the VG (e.g. PV size 50GB, max PVs 40, initial VG size 500GB - 10 LUNS of 50GB each)

3. You may want to use Secure Path on the EVA/HPUX. The eva does not behave well using alternate paths. (some controller ports are not active or seem to be read only.) Newer EVA firmware might fix this, but I'm not sure compaq sees this as a problem.

[Mike Railton]

Bill

Many thanks for your input. I was aware of much of what you said but am not that happy that HP is apparently recommending one LUN and one logical volume per volume group if you want to use business Copy.

In the first instance we can stop all activity on the volume group but in later implementations this is not going to be possible as we run some high availability systems that cannot be shutdown on a regular basis for backup purposes.

Regarding your third point re Secure Path it was my understanding that the only HP supported route for HP-UX/EVA is to use se is to use the Secure Path product.

Mike.

[Bill Costigan]

Mike,

Even with a single LUN, you need some way to ensure the data on the disk is consistent. According to the va7x00 documents, HP recomends either unmounting the filesystem or using some feature in the application to achieve this. E.g. putting all the oracle tablespaces into backup mode before starting the business copy operation.

I haven't scripted a BC backup on the EVA but have on the va. In that case we put the oracle tablespaces into backup mode, bc each LUN then take the tablespaces out of backup mode. We then fsck all the BC lvols and make sure we backup the archive logs and control files. [This is similar to the technique Omniback uses to do a split mirror backup of oracle on EMC.]

The way I view it, BC is similar to pulling the power on a JBOD. Hopefully, JFS and the oracle logs together will be able to restore the database to a usable state.

[kavanagh_1]

Business Copy on the EVA is different to that on the VA/XP in that 'all' work is done for you with regards to vgimporting/mounting or umounting/vgexporting. You define a job on the EVA appliance to split then mount either a single lvol (by referencing a specific existing mountpoint) on to a specified mountpoint (hence the 1 lun/1 vg suggestion from HP) *OR* you can split the volume group in it's entirity. When you split the vg all lvols are mounted (optionally) on either whatever host you have a BC agent on under the same mountpoint structure or you can specify a mountpoint prefix. This prefix in my opinion is in the wrong place - it will mount /data/file and /data/index as /data/prefix_file and /data/prefix_index. These management appliance jobs can be invoked using the /opt/CPQevm/bin/evmcl command where you would, say, put your database into backup mode before running the job.

One pain I have suffered with BC is that if I take a copy of an LV and mount it then make this filesystem busy (cd into it)and run the 'undo' job then this job, happily, fails because it can't umount. IF however I manually umount the filesystem before calling the 'undo' then the remaining mountpoints are left mounted (therefor the vg is kept (vg01_BCV_0 for example), securepath shows all paths to this copy as *FAILED* and the volume is deleted from the EVA. You might wonder why I umounted it in the first place? I want to snapshot database A and mount it elsewhere as database B and splitting by VG seemed to be the answer.

[Rocky_8]

Hi,

This is a very interesting post for me, as i will be required to assist my customers in implementing EVA BC on Linux Adv server 3 with Oracle, and Sun Sol 8 with Sybase 12.x.
I was aware of the fact that there are recommendations for the capacity on the EVA.
LVM (UNIX) however is not really my game i'm afraid.
What i do see now (from these posts) that this will be the main focus of things with BC's.
This includes the Vdisk config in your EVA and how many you present to your host.
I knew Unix machines do not like it when you extend a VDISK on the EVA side, as the file system cannot coop with the extra blocks it then sees ? (windows has the same problem, it treats the extra space as a new partition, thus Drive letter / mount point).
Any LVM recommendations would be appreciated, with regards to BC EVA.
Maybe a quickdoc on LVM is helpfull...

The one thing that keeps moving around in my head is the One Vdisk per VG issue.
I think i know why this is, has to do with the umounting al Lvol's in the VG ? to get a consistent state for the BC.
Some clarification is appreciated also.
The documentation on BC is not very clear.

Regards,

Rocky