Originally posted by: PontiacGeronimo

hello,

to increase paging space device performance, I am thinking of adding two LUNs (each one from another storage box), adding them to rootvg, and moving hd6 mirrored lv to SAN disks (via 3rd LV copy method / mklvcopy/rmlvcopy).

These are full partition systems running on small P7 servers (no VIOS, boot from internal drives) - does anyone has experience or observations how it will work? Any dangers or serious disadvantages eg. boot issues?
kind regards,
p/.

Originally posted by: romeo_ninov

Maybe you will be in trouble when you try to boot machine in case you do not have connection to SAN. Check the traffic/usa

Originally posted by: unixgrl

Why not just make new paging devices on the new disks? I've never seen hd6 moved off to other disks but I've seen TONS of implementations of adding paging spaces to separate LUNs. Ideally, you'd have 1 paging space on each LUN and all paging spaces of equal size.

Originally posted by: JeffGyurko

We were contemplating that here as well and i'll give you a rundown as to why...

We have identical P750's in Corporate and at a DR site. We're contemplating replicating the OS & Data, all on SAN storage to the DR location. One of the things the SAN team is concerned with is replication of swap space. If we can move hd6 off to a SAN lun that we don't have to replicate they'd be more open to that kind of a solution.

What they don't want to see happen, is lots of paging (application deficiency notwithstanding)that they have to replicate when the SWAP is basically useless and cleared at boot time anyway at DR.

We wondered if it was possible to move hd6 off, or make it as small as possible and create larger SWAP luns that aren't replicated. The equal page size I tend to agree with too, so that's another strike against doing that. Any experiences anyone has would be greatly appreciated.

Originally posted by: romeo_ninov

> JeffGyurko wrote:
> We wondered if it was possible to move hd6 off, or make it as small as possible and create larger SWAP luns that aren't replicated. The equal page size I tend to agree with too, so that's another strike against doing that. Any experiences anyone has would be greatly appreciated.

As i remember correctly AIX use round-robin algorithm for use/access paging space (if more that one paging volume), so it is not good idea to make logical volumes for paging with different sizes

Originally posted by: Kosala

If my memory serves me correctly the recommended method for extending paging space is to create new paging volumes. Even in AIX 6.1 (not sure ab 7), hd6 is a hard coded in the startup scripts.

Ko

Originally posted by: morsing

It's correct that hd6 is required as the start-up paging space but it can still be extended. I do agree adding a new space is better though.

Originally posted by: orphy

We got some good comments/suggestions here already but no one mentioned this wiki page.

http://www.ibm.com/developerworks/wikis/display/WikiPtype/Paging+Space

There used to be a very good TechDoc on paging space but I couldn't find it today.

In general, I don't like big paging and thus the need for big paging space. If there are lots of paging going on all the time, there are things one can do to try reducing them. Buying more memory would be ideal but I do know that we have to deal with management, PO, etc, etc so solving things technically without spending money is probably the most lovable fix!

I don't like having hd6 on a SAN LUN unless my rootvg is also there. It just doesn't make me feel good when I got a SAN problem and couldn't boot.

I don't like replicating rootvg for DR either. I mean how often do I change rootvg and when I do, how many files get updated anyway? There are other solutions syncing up rootvg changes that would work better, in my opinion. Really, the biggest thing for me to have a DR site is so that when my Primary is dead, I can go DR pretty quickly and users can get back to work whether they like it or not!. Now, if I messed up my rootvg in Primary which caused my Primary to go bye-bye, the same mess-up would very likely get replicated to DR so how good would my DR be? Better have some mksysbs around!

Anyway, that's my 2 cents!
Orphy

Originally posted by: PontiacGeronimo

but I think the same disadvantages/risks of having paging space devices on SAN should be on LPARs boot from SAN if virtualized environment, right? (VSCSI disk or via NPIV). There is no other choice on such systems - did anyone observed problems with having whole OS on SAN in VIOed environments?

Originally posted by: orphy

What I was trying to say is that I don't like to separate hd6 from the rest of the rootvg LVs. For example, if I have all the LVs on a pair of mirrored hdisks that are physically part of a server, I don't like to have hd6 located on a SAN or virtual disk. I'm sure others might beg the difference and I have no problems with that. From my years of dealing with HACMP, clustering, etc, I always try to recover things as simple as possible. The more complicated you make things, the more issues you could get yourself into during the recovery.

And I completely agree with you that sometimes you simply have no choice but to virtualize everything. That means you will be having LPAR rootvg through a VIO server. If fact, we have been doing this for years and we don't really have any issues with this setup.

I think the bottom line is that, as virtualization becomes more and more popular out there, there are more choices to do things. Whatever path you walk down ought to have pros and cons. There is nothing wrong with doing things differently. Just make sure your decisions don't get you (and your company) into troubles!
Orphy

Originally posted by: JeffGyurko

Orphy,

I'd be interested in hearing about those other solutions. We're just putting in our Virtualized environment and DR is one of the things we're discussing. Replicate, mksysb...all still on the table for acceptance as our DR standard.

Originally posted by: orphy

Not knowing exactly what you have, it's difficult to say but you do have quite a few choices and most of them are documented out there already.

The basics are that you can replicate everything at the SAN level. This setup usually make it easy for you since there is not much you have to do but you would still need to deal with network connectivity (IP address, routing, etc) after a DR site failover.

You can let the SAN replicate the data (e.g. EMC MirrorView) only and you manually handle your OS. This allows you to keep a warm DR site in place and you might even be able to utilize it for testing certain things which is usually not possible with the first solution. The cons of this would require you to manually sync up files that get changed in Primary but a custom scripts and maybe SSH could fix that. Then again, it all depends on how dynamic your Primary is.

A third solution would be to replicate the data at the application level (i.e. Oracle/DB2 archive logs shipping). With this, you are letting your DBAs and application folks take care of the data. You just need to maintain the OS which could be replicated at the SAN level or done manually.

Regardless of what method you use, you should always have some good mksysbs around just in case.
Orphy