We know whats good for us, and yet we dont eat a balanced diet, we dont exercise, we dont clean our gutters or rotate our tires. So why should I be surprised that in the Year 2000 Im still seeing systems with just one volume set the system volume set and Im being asked to tell system managers the equivalent of eat your spinach?
I think its unlikely that many subscribers to the NewsWire need an explanation of why its 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, youre hosed.
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 its 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 youre not careful about backing up). So why do it, besides the law of probability? One very good reason: no user volume sets, no mirroring. Thats 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 its 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 dont 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 thats a better alternative than on-line backup.) So dont make your case to management for volume set configuration based on performance, but do note that its a nice side benefit.
User Volume Sets Are (Almost) Invisible
Most users wont even know you have implemented user volume sets once youve reconfigured, but your users arent 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 HPs CSY division Jazz Web server at jazz.external.hp.com/src/index.html. Otherwise, once youve created user volume sets and moved everything around, users who dont 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 its not mirrored), your production users are none the wiser.
So what does it take to get there? In a nutshell, heres 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 dont have to wing it when its time to use VOLUTIL.
2. (Optional) If youre 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 youll be blowing away your current system volume set and rebuilding everything to accommodate your new, user volume sets. Dont 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 youre 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 youre 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 (dont 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. Dont 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 dont wait until your system volume set is so huge you couldnt possibly carve out the time to convert. Keep in mind that the alternative is even uglier: do nothing, and youll be facing a full system restore when you least expect it and can least afford it. And then youll 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.
Copyright The 3000 NewsWire. All rights reserved.