Virtual Disk Size Increase at SAN level (no LVM)

[Adam Garsha]

Does anyone use disk based filesystems and onlineJFS to facilitate direct control over filesystem size at the SAN level?

i.e. increase LUN size with SAN (e.g. EVA) and then propigate larger size to the disk based filesystem by using fsadm?

i.e. abandon LVM and manage size/redundancy at the SAN level?

What are drawbacks? Does HP support this?

Right now, coming from a Tru64 world, this seems like a very attractive route... vs. having to present new LUNs to increase VG size and then LV size and then filesystem size.

In short, it seams to have less moving parts and also is simpler to increase the size of a filesystem.

What about ServiceGuard? Can you think of any problems here?

[Mel Burslan]

Well, all you are talking about eliminating the LVM component out of the disk management game.

I personally prefer the granularity of the management than lumping all activities together into one single bundle and managing everything using this bundle. This is why I like to have a command line instead of using SAM to manage systems. Or use unix instead of Redmond's finest (well this is not a good analogy I know :)

By taking away LVM, you are telling the system admin that "I do not trust you to do your function correctly and I am taking away your options of how you do your job. Now you need to do it correctly and I will tell you what is correct and what is not"

To tell you the truth, this would not bode well with me and I am sure most people here will feel the same way. This is why we all choose to be UNIX admins not windows. I personally like to have the opportunity to do my job in a way I like to do it not in a way that I am told.

I am not sure what the attraction is on T-64 unix side as I try not to touch that part of the data center too much, hence I can not comment on that but more you take out of management level more you stray away from open systems. There is no way that such an interface will know all the SAN/NAS devices under the sun and know how to handle all of them from one central interface. Hence some less common devices will be left out, which will reduce your options of what hardware to use.

As you can see this question is more of a politics of systems management related than technical. Hardcore techies will always choose the feasibly most granular way of doing their task rather than having dictated how to do it.

[A. Clay Stephenson]

The biggest drawback is that you are throwing away alternate paths so that if one path is disabled an alternate path to the same LUN is available. This ability might be available with custom device drivers but that would depend upon your array; you get this redundancy "for free" with LVM or VxVM. I haven't actually tried to increase the size of a whole disk (that's HP-UX speak for a LUN/disk) on the fly to see if the system is aware of the increased size.

If the number of "moving parts" bothers you then you are doing it incorrectly. That's why you write scripts.

In general, for a tiny bit of overhead (especially true with LVM; replace "tiny" with "small" for VxVM), you gain a huge degree of flexibility and redundancy. If you look at how LVM is implemented internally, it's amazingly simple; in essence, it's one extra lookup in the device switch table.

[Duncan Edmonstone · Accepted solution]

Adam,

sounds like a great plan... but I'm afraid I'll have to throw a spanner in the works.

If you resize a LUN on the SAN, the HP-UX kernel won't pick up on that until you reboot the host. The kernel just won't see the extra space until you reboot.

Thats never been a problem for HPUX admins, as we all use LVM and simply create a new LUN and extend our volume group/logical volume.

Now throw in Serviceguard and you have more problems:

i) Serviceguard manages access to shared disk resources that are part of LVM or VxVM. Raw disks it won't protect, so you do increase your chances of accessing the disks from both systems simultaneously and corrputing your data.

ii) If your cluster is of 3 nodes or less you will need some sort of quorum solution. SOme people now use a quorum server, but a simpler and more popular method is to use a quorum (cluster lock) disk. A cluster lock disk MUST be a LVM disk, as a portion of the LVM header is used for cluster lock functions.

LVM is so easy and straightforward compared to LSM/VxVM that I think you will grow to like it. IT might not have *all* the features of VxVM, but as you have pointed out most people do all their RAID on hardware now anyway.

HTH

Duncan

[Thayanidhi]

Hi,
I am afraid this is supported by hp-ux LVM. Even after reboot, the LVM's PE per PV cannot be altered in a VG. So, how it would be possible to use the new space unless PE per PV already set on the VG.
I support adding a new LUN to the same VG and extending LV/FS.

Note:I have not tried increasing the LUN on hp-ux.

Regds
TT

[Adam Garsha]

Thanks, all:

I am both the sysadmin and the san admin... I am looking to reduce steps and simplify rather then dictate to anyone.

I argue that the fewer layers and less complexity that you have the more robust the system. Usually, simplicity of management requires more complexity in the tools, but I think in this case, if LVM were removed (or if AdvFS had made it to HP-UX), it would make system management both easier and more robust (that is _IF_ a system reboot wouldn't have been required for the kernel to notice the increased disk size _AND_IF_ Service Guard managed node access to disks as it does with volume groups .)

In short, if I could have done what I had wanted, then I would have fewer LUNs to worry about and fewer unix commands to issue to increase space for our dba's. Further, I would have removed one layer of breakable software from the picture.

But, according to posts (thanks, guys):

nail-in-the-coffin #1: is that you need to reboot to notice size change if a disk is increased at the SAN level.

AND

nail-in-the-coffin #2: is that ServiceGuard will only activate/deactive Volume groups and won't arbitrate disk level node access so there is danger of collision.