11-07-2002 08:13 AM
I guess if it's possible to physically move a disk from a crashed system to another available system, and restart applications on that system (applications and relative data are on the disk).
If this can be considered, what would be the prerequisites on the backup system ?
Solved! Go to Solution.
11-07-2002 08:29 AM
To really answer your question, this list needs to know if you use 'USER VOLUMES' for you applications or not.
If you utilize 'USER Volumes', yes you can just move the cables and recover your data after restoring the appropriate directories, and related PUB.SYS files for your 'USER Volumes' assuming that your backups are done with a 'DIRECTORY' option.
If you use just the MPEXL_SYSTEM_VOLUME_SET, I think you had better get your backup and SLT tapes for a reload.
My $ .04 for inflation,
11-07-2002 08:43 AM
Typically, it is not possible to move disks from one system to another for several reasons:
Often a "system crash" is caused by disk failure. One disk cannot be moved, but an entire system or user volume set can be moved, as long as the set is still healthy-- but typically, one of the disks has failed, and the set is broken. A broken set can be difficult or impossible to recover, and often must be rebuilt from a store tape.
If the "system crash" is caused by system hardware and not disk hardware, then you could connect the system volume set to a new system, change the PRIMPATH to point to LDEV1, and It will boot if the hardware is compatible. If the two systems are not identical, then it is likely you will need to make path changes in SYSGEN and reboot once more.
This discussion leaves-out many details, and this task should be attempted ONLY by someone who has experience with the hardware. For example: SCSI cables should never be disconnected on a "live" machine.
11-07-2002 09:46 AM
1/In my mind, the remaining system has previously been configured to accept the moved disk, so it's no need to reboot it, but just mount the moved disk volumes.
2/Concerning hardware caution, i supposed i can do as for a mirrored disk that you can unplug once it has been unmounted.
3/I consider doing this on USER volumes. Hardware boxes will be identical. Disks will be mirrored so it excludes disk crash. The goal is to define a fast way to make application available again in case of hardware crash (cpu, supply,...)
What is your feeling about it ?
11-07-2002 09:54 AM
When the volume set is created, the system writes a volume label to the disk. That disk will then be owned by that volume set until it is scratched. You cannot change a system volume set without an INSTALL (one exception: you may add a new disk to the set, but that disk will get a new vlume label, and all the data on it will be lost).
If you are moving a user volume set, then again, the ENTIRE set must be moved intact. You cannot take one disk from a uservol set on sys#1 and move that one disk to another uservol set on sys#2.
11-07-2002 12:49 PM
Eric is 1000 % correct. With USER Volumes, ALL the volumes
in the user set must go. Additionally, the host MUST have the same ending addressing path as the original system. We found out about the pathing info from calling the response center.
You might want to see what some of the new features of HP's new HA products can do as I'm not familiar with them.
11-08-2002 03:10 AM
1-hardware path are the same (possible ?) and configured to a LDEV
2- disks are configured so that each user volume set is only one disk.
Then when connecting such a disk to sys#2 and power the disk on, it will be automatically mounted and useable.
What do you think of it ? Did you experienced it ?
11-08-2002 05:52 AM
A few things to note on the e3000.
1.It does not support hot swap in terms of on a raw scsi bus. The disks has to be powered on with the system. This has big implications in terms of that you can plug the cable across and then fire the system up but you can not do it live.
2.The MPEXL_SYSTEM_VOLUME_SET can not be mirrored.
3.Make sure you have the same base tpye system. If you just swap out ldev1 to a new system it can lead to a world of trouble. Not only the pathing, I found that reloading a system is easier than doing that hack.
4.MPE recovers very easy if you have an SLT and decent backups.
5.You have to backup your user account using buldjob in this case cause the user accounting between the 2 different LDEV1's will go out of sync.
This trick will work great if you can use user volume sets and the buldjob every few hours to create a user accounting recovery. Just be sure that everything is powered down when you plug the cables across.
Hope this helps a litle this is just my few cents worth.
11-08-2002 06:25 AM
Thank you for your advices
My issue only concerns user volume sets.
Using backup can't answer my need, although i obviously use it.
Suppose the Cpu of system#1 crashes. Recent data on that cpu's disk is up to date. What I want to do is to use it on another Cpu in order to :
* Make application available as soon as possible
* Avoid loosing recent data (of course, I'll loose it if I restore the last daily backup)
Concerning Scsi cables; As far as I know Mirror/iX lets change a damaged disk without shutting down the system. Is this due to a specific hardware ?
I'm sorry I've not understood your point 5. Could you try again ?
11-08-2002 07:17 AM
What Gerhard was trying to say is
that HP provides you a utility called BULDACCT.PUB.SYS which allows you to ccreate two jobs to migrate your accounting structures. The first job, BULDJOB1 builds accounts, groups, and users complete with MPE passwords. It DOES NOT move SECURITY/3000 passwords or profiles. BULDJOB2 builds and sets User Defined Commands. Knowing how to use this utility is very helpful in preparing for D/R, machine migrations, reloading systems, etc. Syntax listed below (watch wrap).
BUILD ACCOUNT PROGRAM FOR DIRECTORY MIGRATION. Version A.50.23
Program options (use these at BULDACCT prompt (max 80 chars)
"%HELP" to get detailed help on options
"%QUIT" quit from interactive prompt
"[acct_list]%NODIRS" No hierarchical directories
will be migrated to BULDJOB1.
"[acct_list]%ROOT" Migrate hierarchical directories
immediately under ROOT ("/").
"[acct_list]%NOROOT" Don't migrate ROOT hierarchical
directories to BULDJOB1.
"acct_list%VSACCT=user_set" to migrate accounts and groups
to the user_set volume set
"acct_list%FROMVS=user_set" to migrate accounts and groups
from the user_set volume set
"acct_list%VS=user_set" to migrate only the groups
to the user_set volume set
"acct_list%UV[=user_set]" to select accounts with at least
one group on the user_set
Type the info string (max 80 chars, CR for default of @)
11-08-2002 07:29 AM
One more thing to note ... in the event of failure if you look at a process lets say a batch job. If it gets interrupted you might loose cross dataset consistency and this might cause the need of a reload in any case. This is important to look at. Especially if you look past the technical process layer and more at the business logic process layer.
11-08-2002 07:41 AM
Gerhard brings up point #6. If you are using IMAGE logging or have a DBE environment attached to any database on the USER volume, you'll most likely have IMAGE errors reported by the Transaction Manager on the new host and have to re-build your IMAGE log files and rename TURBOGTX to effectively recover a database. If its a cpu crash, just memory dump the system and come back-up. The dump process can be expedited by purchasing HP's AutoRestart/iX. IMHO, it's worth the money and the discdrive needed for the memory dump space.
My $.04 for inflation,
11-08-2002 08:18 AM
I understand I've to think further before deciding to go that way.
I will probably come back to you soon.
11-08-2002 09:33 AM
Have you considered a software solution to your problem? It sounds like you have an idle CPU sitting around. You could use a product like NETBASE to shadow your application data to your second system in real time. Then if your primary system crashes you simply switch your users over to your secondary system and have them up and running again in minutes. Check out the information at this link:http://www.quest.com/high_availability/index.asp