MC Service Guard

[Assoufi_1]

Hi all,
I have here a MC-SG cluster with 2 nodes.
the nodes has the same configuration ,I have 3 packages ,2 on the first server and one on the second server.
the first one is NIS master.
Now we are facing serious problem with the second one it crashes during an application upgrade.
I managed to run all packages on the first one.
But my big problem is the customer didn't have any ignite backup for that server.
I'm thinking to take an ignite backup from the first one ( with -Avi ) and restore it in the second and change hostname and ip address during the restore.
I need some one to help me !
is this idea good ?
if OK what is the procedure to restore , should I disconnect the server from network to prevent any conflict with the running one , at witch stage the system will ask me to change IP address and hostname , should I take care about any other config file


Thanks

[Steve Steel · Accepted solution]

Hi


Good basic ignite stuff at

http://web.tampabay.rr.com/batcave/ignite.htm#New



Steve Steel

[Mark Nieuwboer]

Hi,

Make sure your machine isn't in the cluster.
cmhaltnode -n [second cluster]
Because if you put the ignite on the second server everything crash because the cluster can't work with the same name.

and make the /etc/rc.config.d/netconf correct.

grtz Mark

[Assoufi_1]

Hi all,
the faulty server is out of the cluster, the cluster is now running on the first server.
should I change NIS configuration ?
also we are using OSI ( CLNS ) should I update NSAP address and all this staff.


Thanks

[Mark Nieuwboer]

Hi,

I don't no OSI but for NIS you have to change in the file /etc/rc.config.d/namesvrs
NIS_MASTER_SERVER=1 to 0
NIS_SLAVE_SERVER=0 to 1

grtz. Mark

[B. Hulst]

Hi,

If each cluster node has an OSI address then change it of course.

If the packages have those addresses then you leave the package OSI address unchanged.

Also check you NFS mounts, if any...

Regards,
Bob

[Assoufi_1]

Thanks for your help.
I managed to clone the server.
The server is now up and running properly.
But when I tried to start the cluster, it fails with the following error:

Feb 12 08:14:12 omcrsrv2 cmcld: Heartbeat Subnet: 18.168.1.0
Feb 12 08:14:12 omcrsrv2 cmcld: Heartbeat Subnet: 21.168.1.0
Feb 12 08:14:12 omcrsrv2 cmcld: The maximum # of concurrent local connections to the daemon that will be supported is 36.
Feb 12 08:14:12 omcrsrv2 cmcld: DLPI ack error for primitive 11, errno 8, unix errno 0
Feb 12 08:14:12 omcrsrv2 cmcld: Unable to get DLPI attach ack from ppa 1, 22: Invalid argument
Feb 12 08:14:12 omcrsrv2 cmcld: cl_abort: abort cl_kepd_printf failed: Invalid argument
Feb 12 08:14:12 omcrsrv2 cmcld: cl_kepd_printf, fstat: kepd_fd=7, st_dev=1073741827, st_ino=585, st_rdev=-486539264
Feb 12 08:14:12 omcrsrv2 cmcld: Aborting! Unable to attach to network interface


The ioscan shows lan interfaces : Lan0 ( heartbeat) , lan2 and lan 3 but the cluster is looking for lan1 witch exist in the binary config file .
I tried to backup cluster configuration and recompile it again, but it fails with the same error and also because of one faulty disk in the JBOD (belonging to a VG assigned to the cluster).

Isâ it possible to change the Lan card PPA, or should I just unplug it and replace it in the right slot (0/0/1.0)

Is the faulty disk can prevent cluster to form

Note: the cluster can be run properly on the first node: cmruncl â v â

[B. Hulst]

Hi,

Does the command

cmcheckconf -P /package.cfg

say anything?

Check also if all the readable .ascii files in /etc/cluster have all the information correct for the restored host since you copied them directly from the other host during the restore...

Regards,
Bob

[Assoufi_1]

Thanks for all,
I get the second server up . the pblem was is the cluster binary configuration file.
I just execute cmgetcnf -c "clustername", cmcheckonf -v -k -C ascii file and then cmapplyconf and it works.
I also got some problems on OTS but I just disable it on the second server since it should be up on just on server to prevent conflict for my applicatin processes


Thanks for your great help

[B. Hulst]

Hi,

About the OTS, if you manually disabled something you should verify if a cluster package switch to the other node has a working OSI stack and address.

Regards,
Bob