Quest Sponsor Message

Russian Roulette

By Scott Hirsh

We know what’s good for us, and yet… we don’t eat a balanced diet, we don’t exercise, we don’t clean our gutters or rotate our tires. So why should I be surprised that in the Year 2000 I’m still seeing systems with just one volume set — the system volume set — and I’m being asked to tell system managers the equivalent of eat your spinach?

I think it’s unlikely that many subscribers to the NewsWire need an explanation of why it’s a good idea to break your large system volume set into user volume sets. But just in case someone slipped through the guru filter in the subscription department, let us review.

MPE Volumes Are Striped

MPE volumes have been striped as long as I have worked with the HP3000, dating back to the early 1980s. Perhaps someone out there remembers the Series 0.1 where some other arrangement was experimented with, but for us civilians, this means files are broken up into pieces (extents) and distributed among individual volumes (disk drives) in the volume set. The good news: I/O performance is enhanced as multiple drives are put to work servicing read and write requests. The bad news: if any one drive fails in the volume set, you’re hosed.

Old Habits

In the old days — MPE/V — practically speaking we were stuck with one system volume set because so-called private volumes were exotic and, anecdotally, buggy (hence risky). Most of us lived with and were accustomed to one volume set. But then MPE/XL came along, and user volumes were an essential part of system configuration. It was more risky not to create “user” (no longer “private”) volume sets. Like many of you out there, it took me a while to get used to the idea of having volume sets on my system, but now it’s not really something I give a lot of thought to. User volume sets are the norm.

No User Volume Sets, No Fault Tolerance

Converting a system with one large system volume set — say, the one I saw recently with all 15 drives in the system volume set — is time consuming and risky (if you’re not careful about backing up). So why do it, besides the law of probability? One very good reason: no user volume sets, no mirroring. That’s right, only user volume sets can be mirrored (as of now). Sure, this leaves a fault tolerance gap (the remaining and required system volume set) that must be filled by hardware (RAID arrays) if you want 100 percent fault tolerance, but for most of us it’s enough to get us motivated to break up our system volume set. Of course, this points out a simple truth: the longer you wait to convert to user volume sets, the larger the system volume set, the more difficult and time consuming it is to convert.

Some shops are selective about what they mirror, as mirroring is not an all-or-nothing proposition. So the important production volume sets get mirrored, but not the QA volume set, for example. This might save you some cash if you don’t want mirrored pairs across the board.

User Volume Sets Can Improve Performance

Not only do you improve your prospects for system uptime when you break user volume sets out of your system volume set, but you may get a performance kicker as well. Each user volume set gets its own transaction manager, and if you mirror you get multi-threaded reads courtesy of the mirroring software. (You can also take advantage of split-mirror backups, if that’s a better alternative than on-line backup.) So don’t make your case to management for volume set configuration based on performance, but do note that it’s a nice side benefit.

User Volume Sets Are (Almost) Invisible

Most users won’t even know you have implemented user volume sets once you’ve reconfigured, but your users aren’t “most” users, are they? No, they demand SM or run GOD as they please. And those users need a little education. Why? Because they build groups which will now need to be placed on user volume sets, unless they belong on the system volume set. The easiest way to deal with the “ONVS” and “HOMEVS” issue is to download the volume maintenance UDCs from HP’s CSY division Jazz Web server at jazz.external.hp.com/src/index.html. Otherwise, once you’ve created user volume sets and moved everything around, users who don’t modify the account structure should not notice any difference.

You will need to be aware of where groups are being built — especially if you kept your system volume set to a minimum to limit exposure. And you will need to tweak your backups to make sure you get all the directories residing on user volume sets.

User Volume Sets Are More Manageable

Because your disk drives are physically segregated into volume sets, you no longer need to worry about somebody using up all your system disk space. (True, you can impose file limits without volume sets, but politically you tend to be better off designating a set of drives to a department or other subdivision of your company. Personally, I have had much better luck managing space with volume sets than I did using account structure.) And if the development volume set should experience a hardware failure (and it’s not mirrored), your production users are none the wiser.

So what does it take to get there? In a nutshell, here’s what I do:

1. Plan what it is you want to do. (Rule of thumb: eight drives max in the system volume set. But if the system volume set will not be protected with RAID, try to preserve the smallest system volume set that will serve your needs (spooling, transient space, etc.). Consider the increase in drives that mirroring — if you plan to mirror — will impose on your system and make sure you have enough IO slots and interfaces. Create scripts/jobs or explicit notes in advance so you don’t have to wing it when it’s time to use VOLUTIL.

2. (Optional) If you’re implementing mirroring, you can install mirroring software at any time, regardless of volume set configuration. It installs like a patch.

3. Capture your existing account structure with BULDACCT and create VOLUTIL scripts to reconfigure your new volume sets. Creating a job to purge the accounts/groups that will reside in volume sets is recommended, as are jobs to perform the necessary restores.

4. Perform a full and complete backup of your system. You need to make sure you back up absolutely everything because you’ll be blowing away your current system volume set and rebuilding everything to accommodate your new, user volume sets. Don’t forget to use the DIRECTORY option to get the system directory.

5. Create an SLT to reflect the last known good state of your system.

6. (Optional) If you’re adding disk drives to accommodate mirroring, you would do that now.

7. (Optional) Create an SLT. You will use this to perform an install.

8. When you’re absolutely sure you have a good full backup and a good SLT, shut your system down then bring it up on an INSTALL. You will boot with LDEV 1 only.

9. Use VOLUTIL to build your new system volume set.

10 Restore the system directory.

11. Restore the SYS account (don’t forget OLDDATE!), where you kept your restore jobs and VOLUTIL scripts.

12. Use your VOLUTIL scripts to build new volume sets.

13. Stream your job that purges all accounts except the ones that are to remain in the system volume set.

14 Stream the jobs you created with BULDACCT that build the first part of the account structure on the new volume sets. Don’t run the second job (that sets UDCs) until you have restored everything that resides in your new user volume sets — or there will be no UDC files to set (been there, done that).

15. Stream the restore job to restore everything but SYS (which is already restored).

16. Verify that everything was restored properly.

17. Stream the second group of BULDACCT jobs that set passwords and UDCs.

18. Create new SLT.

19. Shutdown system and restart to verify that system boots properly.

20. Test accounts for proper passwords and UDCs. Review all $STDLISTs for errors.

Okay, admittedly this extensive list is something you want to do only once. But you can see that STORE/RESTORE time is the critical factor here, so don’t wait until your system volume set is so huge you couldn’t possibly carve out the time to convert. Keep in mind that the alternative is even uglier: do nothing, and you’ll be facing a full system restore when you least expect it and can least afford it. And then you’ll have to explain why your system went down for a failure that was preventable.

Scott Hirsh, former chairman of the SIG-SYSMAN Special Interest Group, is a partner at Precision Systems Group, an authorized HP Channel Partner which consults on HP OpenView, Maestro, Sys*Admiral and other general HP 3000 and HP 9000 automation and administration practices.