paging file on storage disks

[Eitan Ram]

What is the best practice regarding paging files on storage (eva4000)?

I began to manage a cluster of 2 alpha ES47 recently.
On the storage side (eva) 2 disks were created for each cluster member.
On vms – these 2 x 2 disks were used to create a shadow disk on each cluster member.
Is this configuration considered a good one or just waste of disks ?
Also – I found that the DSAn: disks which hold the paging files are mounted
Cluster-wide.
Should a disk with a paging file be mounted on the other members of cluster?

Thanks.

Eitan.

[Robert Gezelter]

Eitan,

First, a question about your precise configuration. Are there one or two EVAs?

Personally, if I have a choice, I try to isolate page/swap files on a disk separate from both the system and user disks. This is partially a performance comment and partially an operational one.

Page/swap files do not survive a reboot, therefore in an emergency, these volumes can be recreated with ease. Is there any reason why two disks were created? As opposed to three?

While I am an advocate of shared system disks (actually, cloned, shared system disks, see my comment about configuration in my recent HP Technology Forum presentation, slides and audio available at http://www.rlgsc.com/hptechnologyforum/2009/continuous-openvms.html ), I do not see an advantage in sharing the paging/swapping device. In fact, I see the potential for negative results.

I suspect that many will point out that with an EVA, the issue of contention is reduced, and I will not disagree. However, there is also often little reason why the paging/swapping devices cannot be separated. If nothing else, when migrating disk configurations without interruption (one of my presentations from an earlier HP Technology Forum; see "Migrating OpenVMS Storage without Interruption or Disruption" at http://www.rlgsc.com/hptechnologyforum/2007/1512.html ), keeping things segregated means more control over the migration process.

Personally, for most reliability, I would go for:

Shared System A System B
SYSBLUE
SYSGOLD
PAGESWAPA PAGESWAPB
USER

SYSBLUE and SYSGOLD are clones (created with BACKUP/IMAGE). In normal operation, System A runs from SYSBLUE, System B runs from SYSGOLD. However, BOTH disks have full files for both systems. During an update or similar evolution, one of the system disks is updated, the other is retained unchanged. If there is a problem, it is possible to instantly retract the change by rebooting.

I hope the above helps. If I have been unclear, please ask me to clarify.

- Bob Gezelter, http://www.rlgsc.com

[Robert Gezelter]

Eitan,

ITRC mangled the spacing of the table in my previous post in this thread.

A more ITRC-friendly (albeit, less human friendly) table is:

Shared
SYSBLUE
SYSGOLD
USER

System A
PAGESWAPA

System B
PAGESWAPB

My apologies if the earlier table caused any confusion.

- Bob Gezelter, http://www.rlgsc.com

[Richard W Hunt]

I more or less agree with Robert.

Personally, if I have two disks and wanted to use them for swapping, I would never shadow them. I would mount them as standalone volumes and have twice the swap/page space. You can still gain some benefit from them as separate drives based on the odd chance that you have space used on each drive, so you can have distributed seeks.

The problem with mirroring is that you want to remember you have to write twice on a mirror set, once per physical drive - whether it is a host-based or controller-based mirror set. Based on the properies of a RAID-1 drive, you get benefits from that configuration if and only if you are going to read the same data more than once. For page/swap files, the odds greatly favor that you will not. One out-swap, one in-swap. Next time you out-swap, you don't use the old copy, you make a new one. You don't even get a benefit for installed /SHARE files since the pure code doesn't go to the swap or page files. Shared pure code backing store is the original .EXE file itself, unless something changed since the last time I looked.

As to cluster availability, in a previous configuration I cross-mounted my drives so that A could see B's swap drives and vice-versa, but that was for diagnostic and remediation purposes only. Like, having to dissolve and rebuild the swap files while the other system is down. I did that once or twice in 20 years. Never had any other reason to cross-mount swap drives.

[The Brit]

I suspect that the primary reason for shadowing your Pagefile disks would be for redundancy.

With the volume shadowed, loss of one of the units would have zero effect on the system.

If your Paging disk is not shadowed, and that disk goes south.... Well, if you are not doing much paging, it may not have a great effect, however if you are, then you would have just lost all of the pages which were being stored in the pagefile.

You can judge for yourself what effect that might have on those processes which might want to access those pages.

For performance reasons, I would probably recommend moving your pagefiles off the system disk.

Finally, I dont imagine that you will find many people in this forum who think that shadowing is "...just a waste of disks."

Dave.

[Wim Van den Wyngaert]

I would shadow/mirror the pagefile disk. You must survive a disk failure without intervention (unless you're not in a critical environment). All other stuff I agree with Robert.

Wim

[Robert Gezelter]

Eitan (and Wim),

In my post, I said I did not see a strong reason to SHARE the page/swap disk. I did not say not to shadow the page/swap disk.

Indeed, using host-based shadowing (as opposed to controller-based mirroring) makes it potentially possible to completely change mass storage configurations without a reboot. This was the gist of my 2007 HP Enterprise Technology Forum presentation (URL in earlier posting).

- Bob Gezelter, http://www.rlgsc.com

[John Gillings]

Eitan,

And a slightly different opinion...

"Best Practice" depends on circumstance (and personal opinion ;-)

Shadowing is good, regardless of what you're doing with the disk. Waste? Maybe, but I consider it very cheap insurance against disk failure.

Although it could be argued that there's no need to share a paging disk on all nodes in the cluster, having dealt with a few clusters that share some disks and not others, I think it's easier to manage and far more consistent to just share (and mount) everything across the cluster. Don't be concerned that other nodes don't touch the disk. Chances are you won't be using the pagefiles much anyway.

Clusters are supposed to be a homogeneous environment. The fewer exceptions and differences you have between nodes, the better. A nice simple, straight through startup procedure with as little "if this node then that" conditionalisation is likely to be more reliable, robust and maintenance free.

[Hoff]

Apologies if you've already gone through the following and considered these details...

What are your goals here?

What are the operational requirements?

Uptime needs?

I'll presume one vote each and one vote from a shared controller-mirrored quorum disk out on the EVA(s), too.

Comparatively detailed considerations such as the layout of the pagefiles and shadowing (and I'd tend to use controller shadowing and non-mounted-shared disks here) are fairly far along in an investigation. Stuff like "are the backups good?" and "have I tested my backups?" and "are my backups secure?" all tend to be far higher on the list than shadowing. Followed by stuff like loading and running and evaluating T4 data and finding the bottlenecks and the current system and configuration performance limits.

Depending on the box and the buses and the speeds and feeds, I've tossed pagefiles onto controller-based host-local RAID, too.

And tossing a couple of gigabytes at the box can also reduce the need for paging, too; there are steps that can trump the discussion.

[Steve Reece_3]

How are the "disks" presented by the EVA4000? Is it a single EVA4000 or multiple EVA4000s?

If you're in a single EVA4000 with disks presented out of redundant sets (e.g. VRaid 5) then there's no particular benefit in having shadowed disks. The data will be spread across all of the disks in the EVA and, providing that the EVA has been correctly configured, it should be capable of surviving the loss of any disk.

If you're shadowing across nodes then that's sub-optimal: better to have both nodes seeing the storage on the EVA directly and letting both nodes in the cluster shadow the disks.

I've cross-mounted paging disks and left them unmounted on other cluster members, depending on the circumstances. The capability to mount them can be helpful and you might want to use one of them as a quorum disk (though you can't host-based shadow a quorum disk).