creating a new system identical

[lawrenzo_1]

Hello,

We have a test cluster where there are quite a few subtle difference's expecially between the volume group configs. What would be the best way to syncronise these two machines?

we have two packages running on one side and 3 on the other - I have been considering rebuilding the server from scratch.

any advice will be of great help.

Thanks

[A. Clay Stephenson · Accepted solution]

Well, if the machines are identical with respect to hardware then I would consider doing an Ignite Golden Image but this may not be necessary. There are differences and then there are significant differences. I'm not sure where subtle falls in the spectrum.
If you are concerned about differences in vg00 then you will pretty much have to either install or Ignite. The real key is making /stand and / big enough initially since they must be contiguous although about 200MB for / and 160MB for /stand should be more than adequate. The other LVOL's can be expanded as needed using OnlineJFS. The key is to leave unused space.

I find that itis far more important to be concerned about kernel & network tuning and patch levels than it is to be concerned about the size of a given lvol on a box. In a cluster, most of the LVOL's are going to be moved between the boxes anyway. Of course, I'm one of those whackos who moves the binaries (e.g. Oracle) with the package.

[James R. Ferguson]

Hi:

I agree with Clay too, and would add one other suggestion.

Since this is a test cluster, why not perform the learning exercise of creating an Ignite image and rebuilding the "odd" node to match the other? Another opportunity might be to cold-install one of the nodes from scratch; install MCSG and rejoin the cluster. You could follow this with an Ignite image and a rebuild of the otehr node.

It sounds like you have an excellent opportunity to practice disaster recovery and/or produce some useful documentaton. I'd consider taking advantage of it.

Regards!

...JRF...

[Steven E. Protter]

Hardware differences can make this very hard.

Tools:

make_tape_recovery

You make the tape on one system and recover to the second. There is a method for manual intervention to deal with volume group differences that you report.

It would be best if the source system were idle and all databases and applications not running when you make the backup. This will insure the best chance of getting clean copies of data, should this be a concern.

another tool:

Ignite Golden Images:

This is more complex but can beat major hardware differences:

I prefer to link manuals to explain this:
http://www1.itrc.hp.com/service/james/dispDoc.do?docURL=http%3A%2F%2Fsearch.hp.com%2Fredirect.html%3Furl%3Dhttp%253A%2F%2Fdocs.hp.com%2Fen%2FB2355-90893%2Fch05.html%26qt%3D%2BIgnite%2BGolden%2BImage%26hit%3D1&aid=SEARCH_MANUAL&pil=1&serStr=Ignite+Golden+Image

http://www1.itrc.hp.com/service/james/dispDoc.do?docURL=http%3A%2F%2Fsearch.hp.com%2Fredirect.html%3Furl%3Dhttp%253A%2F%2Fdocs.hp.com%2Fen%2FB2355-90893%2Fch05s01.html%26qt%3D%2BIgnite%2BGolden%2BImage%26hit%3D2&aid=SEARCH_MANUAL&pil=2&serStr=Ignite+Golden+Image

http://www1.itrc.hp.com/service/james/dispDoc.do?docURL=http%3A%2F%2Fsearch.hp.com%2Fredirect.html%3Furl%3Dhttp%253A%2F%2Fdocs.hp.com%2Fen%2FB2355-90893%2Fch05s02.html%26qt%3D%2BIgnite%2BGolden%2BImage%26hit%3D5&aid=SEARCH_MANUAL&pil=5&serStr=Ignite+Golden+Image

SEP

[Stephen Doud]

Your message is a bit terse. What would you like to synchronize exactly? If it is just the LVM information that is out of sync, do you have any specific messages that tell us this? To synchronize a volume group, do the following:
1) on the node where the VG functions properly:
# vgexport -pvs -m map.vg?? /dev/vg??
# rcp map.vg?? othernode:/etc/lvmconf/

2) on the other node where the VG is out of sync:
# ll /dev/vg??/group - copy the 'minor' number
# vgexport vg??
# mkdir /dev/vg??
# mknod /dev/vg??/group c 64 0xNN0000 (NN= original minor number)
# vgimport -vs -m /etc/lvmconf/map.vg?? /dev/vg??
--- end procedure ---

Use 'strings /etc/lvmtab' to see if the same number of dsk files are included for the VG on each node. If you learn that half of the dsk paths are missing on the primary node, use the same procedure above (after deactivated the VG by halting the package on the node) to allow LVM to find and include the other paths (pvlinks).

A note to Clay: transferring the application binaries with the data (via package control) is not an HA practice. If the binary is corrupted, the package cannot start on the adoptive node.

[A. Clay Stephenson]

I'm hardly concerned about binaries getting corrupted when they are only read. The probability that the Oracle binaries might get corrupted is at least two orders of magnitude less likely than that the Oracle data files will become corrupted (and render the instance unusable) which are typically written to hundreds of times per second. Moving the binaries assures me that the patch levels remain constant and match the package data regardless of the currently active node. Just to disturb you even more, I dedicate a listener to each package as well.

On the other hand, maybe I've just been lucky all those years with zero unplanned downtime.

[lawrenzo_1]

Thanks everyone.

This is great info - we were looking to rebuild using iginte.

Great advice again.



Merry Xmas everyone ..............