SGeSAP : configuration to fail over Dialog Instance

[Eric SAUBIGNAC]

Hi all,

I configured a cluster SAP R3 with SGeSAP B.03.12 and HP-UX 11.23 ia64 ...

In the cluster the Central Instance (DBCI) fails over on the Dialog Instance (AS) and this last one is beforehand stopped. Classic (DBCI - > AS) and everything seems OK.

I read in SGeSAP documentation that we could also fail over Dialog Instance on another host including the CI. But I found no piece of information relative to the configuration of SG, SGeSAP or SAP to obtain this result.

In particular there is nothing about the management of the floating IP which could be attributed to the Dialog Instance. Does it means that it is not necessary to have this type of address for AS in the cluster, even if it has to failover ? Roughly it would suppose that the Dialog Instance comes to "register" with the CI with the official name of the sytème on which it is executed. And because it is dynamic there is no need to have a floating IP for the AS (contrary to the CI for which the configuration of some SAP's files must be modified to take care of the floating address) ? As I know only the main part on SAP to achieve a SGeSAP cluster, this hypothesis is maybe false and crazy ... ;-)

Well i have many more questions of that kind ... So, could anybody advise me the good readings on the subject? Unless one of you already realized this type of configuration (DBCI towards AS AND AS towards DBCI) and can provide myself some explanations ?

Thank you in advance for your help

ERIC

(PBFWME ;-)

[Mel Burslan]

Eric,

I am not extremely familiar with the SGeSAP package, but in the very end, it all depends if you can wrap the AS startup files/commands in a SG package startup control file. AS compared to DBCI is much easier to start up and shut down as it does not involve the database part and all the interaction between DB and the CI. So, in theory, if you can create a package and in the customer defined comments section, mount your necessary nfs file systems (or better use autoFS and skip this part) then start the AS instance, that's all there is to it. Then using serviceguard controls, you can start and stop this package on any node on this cluster.

I am not sure if this was your question, but if it is not, please provide more details and you will get more help.

[Eric SAUBIGNAC]

Mel,

I can wrap the AS startup files/commands in an SG package startup control file and make a package with AS.

So, if i extrapolate your answer i understand that there is no matter if a given AS start on a different host if, on the new system, the necessary systemfiles are tipped over and the environment correctly configured (passwd, group, services, etc...) ? No supplementary configuration, as for DBCI package, needs to be done in SAP configuration files ?

[Mel Burslan]

Eric,

Okay, I may have mislead you in my first message. AS, as far as SAP R/3 goes, is a concept where "more, the merrier". So, if an AS failover is being planned, normally, we setup an AS (lest call this instance D09) on the server which will host DBCI as well, a totally separate dialog instance. Also, there is one on the DBCI failover node (call it D01).

So, under the normal circumstances, when everything is running happily as expected, DBCI is running on main node, D09 is inactive and D01 is active on the failover node.

Should something happen to the cluster and DBCI fails over to the secondary node, then D01 gets deactivated and D09 starts chugging along. Thereis nothing wrong, running the dialog instance at the same time with the DBCI on the same server, except the DB performance sucks big time. We have been known to be guilty of this one time when we had a catastrophic root disk failure on the main node, in the past.

I hope I made myself clear.

Cheers...

[Eric SAUBIGNAC]

Hi Mel,

Sorry of this delay... but I had some critical points to handle.

It is effectively an interesting idea to configure a dialogue instance on the two nodes of the cluster with 2 different numbers. However, for many reasons, it is not the strategy I whill retain for the moment.

What I do want is to fail dialog instance D01 from a host to an other one, maybe the central instance, maybe not, knowing that the necessary systemfiles will be also failover, the NFS mount points correctly realized, the UID/GID of accounts adm, ora identical, /etc/services identical on the 2 hosts, and so on ...

So could you answer, in a strict point of vue of SAP, if i am suppose to do any adjusment in SAP configuration, first on the Dialog Instance D01 itself, secondly on the Central Instance, to support the transfert of the Dialog Instance from a node to another ?

Thanks in advance for your answer

Eric

(PBFWME ;-)

[Eric SAUBIGNAC]

:-(