Managing system unavailibility by moving disk to another available system (379 Views)
Reply
Occasional Advisor
Bonina
Posts: 8
Registered: ‎09-11-2002
Message 1 of 14 (379 Views)
Accepted Solution

Managing system unavailibility by moving disk to another available system

Hi
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 ?
Thank's
Honored Contributor
Chuck Ciesinski
Posts: 830
Registered: ‎10-03-2000
Message 2 of 14 (379 Views)

Re: Managing system unavailibility by moving disk to another available system

Bonina,

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,

Chuck Ciesinski

"Show me the $$$$$"
Honored Contributor
Eric Sorensen_1
Posts: 573
Registered: ‎10-08-2000
Message 3 of 14 (379 Views)

Re: Managing system unavailibility by moving disk to another available system

Hello Bonina,

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.
A problem well defined is half solved.
Occasional Advisor
Bonina
Posts: 8
Registered: ‎09-11-2002
Message 4 of 14 (379 Views)

Re: Managing system unavailibility by moving disk to another available system

Thank you both
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 ?
Honored Contributor
Eric Sorensen_1
Posts: 573
Registered: ‎10-08-2000
Message 5 of 14 (379 Views)

Re: Managing system unavailibility by moving disk to another available system

Hello Bonina,

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.
A problem well defined is half solved.
Honored Contributor
Chuck Ciesinski
Posts: 830
Registered: ‎10-03-2000
Message 6 of 14 (379 Views)

Re: Managing system unavailibility by moving disk to another available system

Bonina,

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.
"Show me the $$$$$"
Occasional Advisor
Bonina
Posts: 8
Registered: ‎09-11-2002
Message 7 of 14 (379 Views)

Re: Managing system unavailibility by moving disk to another available system

Thank you again
Suppose :
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 ?
Respected Contributor
Gerhard Roets
Posts: 427
Registered: ‎02-20-2001
Message 8 of 14 (379 Views)

Re: Managing system unavailibility by moving disk to another available system

Bonina

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.

Gerhard Roets
Occasional Advisor
Bonina
Posts: 8
Registered: ‎09-11-2002
Message 9 of 14 (379 Views)

Re: Managing system unavailibility by moving disk to another available system

Hello Gerhard
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 ?
Honored Contributor
Chuck Ciesinski
Posts: 830
Registered: ‎10-03-2000
Message 10 of 14 (379 Views)

Re: Managing system unavailibility by moving disk to another available system

Bonina,

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).

HTH,

Chuck Ciesinski

CCIESINS.SYS:buldacct.pub

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 @)

BULDACCT:
"Show me the $$$$$"
Respected Contributor
Gerhard Roets
Posts: 427
Registered: ‎02-20-2001
Message 11 of 14 (379 Views)

Re: Managing system unavailibility by moving disk to another available system

Well Chuck explained my point 5 really good :)

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.

Regards
Gerhard
Honored Contributor
Chuck Ciesinski
Posts: 830
Registered: ‎10-03-2000
Message 12 of 14 (379 Views)

Re: Managing system unavailibility by moving disk to another available system

bonina,

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,

Chuck Ciesinski
"Show me the $$$$$"
Occasional Advisor
Bonina
Posts: 8
Registered: ‎09-11-2002
Message 13 of 14 (379 Views)

Re: Managing system unavailibility by moving disk to another available system

Thanks to every one for your relevant answers.
I understand I've to think further before deciding to go that way.
I will probably come back to you soon.
Bye
Esteemed Contributor
Dan Clifford
Posts: 201
Registered: ‎03-25-1998
Message 14 of 14 (379 Views)

Re: Managing system unavailibility by moving disk to another available system

Bonina,

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

Dan Clifford
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.