Serviceguard
cancel
Showing results for 
Search instead for 
Did you mean: 

MC/SG and SAP R/3 integration using SGeSAP - problems - please help - long

 
Zbigniew Klos
Occasional Visitor

MC/SG and SAP R/3 integration using SGeSAP - problems - please help - long

 
4 REPLIES 4
harry d brown jr
Honored Contributor

Re: MC/SG and SAP R/3 integration using SGeSAP - problems - please help - long

Zbigniew,

I don't have an answer for you, but I'll float it back to the top, maybe someone can help.

live free or die
harry
Live Free or Die
Zbigniew Klos
Occasional Visitor

Re: MC/SG and SAP R/3 integration using SGeSAP - problems - please help - long

That's me again.
I made a mistake a the beginning of problem desciption - of course I was going to say that packages start in sequence upon cluster startup (not that they do not !!!).
I quickly managed with the problem with cluster halting - I deleted packages from the cluster and added them back again in opposite order. Now, during cluster halt, apprd01 halts first, then goes ciPRD and finally dbPRD so NFS is not an issue anymore. It has no impact on cluster startup because dbPRD is the only one that starts automatically - the two other are started by its preceding package.

Problem with a deadlock during concurrent package startup at failover is still an issue however :-(

Regards,
Zbigniew Klos
Stephen Doud
Honored Contributor

Re: MC/SG and SAP R/3 integration using SGeSAP - problems - please help - long

Hi Z,

Perhaps the ASTREAT and DELAY_INTERVALS parameters in the /opt/cmcluster/sap/SID/sap.conf file may be of some help to you.

Also, "Managing MC/ServiceGuard Extension for SAP R/3" may help you configure the SGeSAP toolkit. The document is located here:
http://docs.hp.com/hpux/ha/index.html#ServiceGuard%20Extension%20for%20SAP

-s.

Re: MC/SG and SAP R/3 integration using SGeSAP - problems - please help - long

Hello,

in my opinion it's not a quite good idea to start one package from the other (if i understood you start application server from central instance package). We have a configuration here, where we start db and ci in one package and have up to three application servers always trying to start up in parallel. We simply check if the dbci-package is running in the customer_defined_run_commands of the app-packages in a while loop (10 tries, 20 seconds sleep), and if this succeeds the package can go on to start it's sap-application-server. So it's YOU who checks for db and ci and not the sap-script, which should not end up in a deadlock situation.

The second question is not quite clear to me. The only situation where the db-package is going down before the others should be a failure. If you are bringing the cluster down manually, it's only a question of discipline. Ok, it's possible that you have a failure of the db-package alone and then you are in a mess, i see (should be very rare condition). A possible solution is, that you are using a seperat NFS-package for this. The only problem now is, that mostly the NFS-package is the first to fail if there are any problems, but it should also be the first one that come up on the other node.
As i said, we only have dbci and app seperated and each one has all necessary binaries in the package, giving you much overhead but good stability in cluster operations.

Hope i really understood your problem and giving some hints here.

Heinz