Reconfiguring a server to act as another

[Filipe_1]

Folks,

I have a running HP-UX box, with patches installed, access to storage via powerpath and so forth.

This server (N4000) is intended to be another, which is already in production.

I have two strategies:

1 ) reconfiguring it entirely to act as another (both servers are in trust mode). IP addresses, hostname, OV agents, Netbackup agents, etc.

2) Cold installing it, and reconfiguring it.

Not sure at this point how is the most reliable way to do that. Is there a out-of-the-box way to “unconfiguring” a running HP-UX box to accept configurations of other servers? Or is more secure and reliable cold installing it?

Thanks in advance,

Filipe.

PS: yes, it is kind of a double post. Need replies, and will assign points.
swap of make recoveries is out of question, unfortunately.

[James R. Ferguson]

Hi Filipe:

As far as hostname and network (address, gateway, DNS, etc.) parameters are concerned, one way is to run '/sbin/set_parms' to reconfigure these.

As far a user accounts are concerned, these could be copied from one server to the other.

Perhaps this helps.

Regards!

...JRF...

[Jakes Louw]

Use Ignite on the current production server to create an installation image, and build the new server with the image?
Read up on make_tape_recovery.

[Alzhy]

Not sure exactly what you're asking but I'll give it a shot.

You want an N4000 to serve as "another"? I assume you want this N4000 to become a failover machine to take the duties of another - manually. And you want the current environment on this N4000 preserved?

If you're not concerned with your mirrors .. then I will certainly use the other internal disk. I will use dd to copy the OS disk of your current production machine to this N4000 (I assume the current production machine is the same architecture PA8600+?). I will do:

From my current Production machine:

dd if=/dev/rdsk/cXtYdZ bs=4096k |ssh n400server dd of=/dev/cXtYdZ

On the N4000 macchine (assuming it has ready Fibre connection to your EMC and zoned accordinigdly):

boot lvm maintenance mode on the disk that youd performed dd
fix vg00
fix ioconfig
fix networking
boot live...
(there should be many references on this forum how to go about ficing and adapting a transported disk --- which basically is what you have as a result of the dd operation)

Of course ensure your original production environment is already down when you bring up the "another" N4000 machine.

[Lolupee]

If you are used to igniting servers. your best bet is to have an image of the former either as a golding image and reignite the new server with the golden image or create a make_tape_recovery of the production server with all the file systems selected and ignite the new server with the produciton image.

I have chosen make_tape_recovery because you did not give an indication that you know how to use ignite. make_net_recovery may be faster but make_tape_recovery would be safer for you. This would isolate your production server from being ignited, because the LAN address could be misleading.

Please, read trough make_tape_recovery to get all the options.

[Filipe_1]

James, thanks for the set_parms command, it is one of the things I was looking for.

But as I said, both servers are in trusted mode. How can I "transfer" all security information that is not in /etc/passwd and /etc/group to other server that is in trusted mode too?

And kernel parameters? I have to manually set one by one or there is another more practical way to kinda replicate them to other box?

Nelson, actually the N4K will act as a L3K, this last one is on production. My problem is detailed on this thread: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=993498

Folks, the fact is we have to "swap" two servers that are being in production. Using ignite is unfortunately out of question, we tried it. See the thread referenced on this thread for details on this sad story. Making a long story short, when we tried to restore a make_recovery from the L on the N, it crashed beyond any possibility of troubleshooting (Trap 14). We tested everything involved and all seemed OK.


DDing boot disks are also not an option, due to some hardware incompatibility (something related to disks cradles, AFAIK).

[Alzhy]

In that case, I will approach it this way (having done many migrations in the past):

1. dd or ignite restore the N-Class OS image to the L3K. (Use different hostname/ip initially and comment all SAN/EMC /etc/fstab entries, comment out all APPs startup, etc,). After this exercise, your L3K should have all the OS attribs and accounts (trusted db,etc.).

2. I suggest you use the existing L3K's HBAs and prepare so it can "see" the same EMC LUNs that are currently in use on the N-Class (of course you'll need zoning/san changes to do this but it will make your migration a whole lot easier).

3. OS fully restored (of course give it a different name/IP), EMC SAN Issues (and Powerpath licening etc.) - LUNS seen on L3K --- It is CutOver day which should proceed as follows:

A. For each VG on N-Class environment, vgexport with the VGID option. Copy mapfiles to the L3K environment.

B. Shut down the N-Class.

C. On the L3K, still named as something else -- vgimport the N-Class Volumegroups from step A using the mapfiles generated earlier. Edit /etc/fstab and mount the filesystems.

D. Rename the L3K to the N-Class' hostname via: "set_parms initial" (which is the equiv of your Solaris's "sys-unconfig") or if you're comfortable with manually editing files to change the network/hostnames.

E. Reboot and Done. You should now be on the L3K and the fact that you earlier prepped up the L3K both OS and SAN/VG-LVM wise will make your migration painless as it's been with mine on several large migrations now...

[Filipe_1]

Nelson, the point is: we have already tried restoring the L make_recovery on the N box and it crashed (trap) even before the first dialog appeared. If it worked, your strategy would fit greatâ ¦

We are aware now that we will have to make things manually, besides the fact the, yes, we will move the HBAs from the original box to the N. Of course it will make things easier (assuming some powerpath configurations). Our concerns at this point is 1 â the extended security information and 2 - the kernel parameters. The basic question: what is the easiest way one can copy these configurations from one box to another (assuming both HP-UX 11.11)?

Thanks anyway!

[Alzhy]

I am not exactly sure why your restore/ignite recovery would result in an unstable environment. Is the L3K PCI based and at least PA8600? From my experience - I have been able to dd/ignite restore from a SuperDome nPar to a small N-Class - with no issues whatsoever.

To copy over your TCB/Trusted DB:

cp /etc/passwd, /etc/group and CPIO of /tcb

Here's how to CPIO TCB - on your :
cd /
find ./tcb -depth -print|cpio -o>/tmp/tcb.cpio

To extract on your L-Class:

cpio -idvmu

[Filipe_1]

Nelson, the point is: we have already tried restoring the L make_recovery on the N box and it crashed (trap) even before the first dialog appeared. If it worked, your strategy would fit great...

We are aware now that we will have to make things manually, besides the fact the, yes, we will move the HBAs from the original box to the N. Of course it will make things easier (assuming some powerpath configurations). Our concerns at this point is 1 - the extended security information and 2 - the kernel parameters. The basic question: what is the easiest way one can copy these configurations from one box to another (assuming both HP-UX 11.11)?

Thanks anyway!

[Alzhy · Accepted solution]

I forgot, for your kernel, just copy over your /stand/system file and build your kernel on the L3K.

Once i get my hands on an L3K -- I will try doing the dd and/or ignite recovery approach to swap the environments.

Or maybe even create a "golden image" of each and use ignite. If that works - then you can simply copy tcb/kernel, work your EMC configs..

Let us know how you finally proceeded...