Is anyone doing disaster recovery for a J2EE application?

[Former Member]

We generally use database log shipping to maintain a standby database for our ABAP instances. We can successfully fail over our production application to our disaster recovery site with no real issues. With the J2EE instances (EP, ESS/MSS, BI, etc), we have a few concerns:

• hostname cannot change, without going through a system copy procedure, so we would have to keep the hostnames in DR the same. (for example, ref: oss note 757692 - changing hostname is not supported)

• fully qualified domain name - from what I understand, there are potentially issues with changing the fqdn, for example SSO certificates, BSPs, XI has issues, etc.

• we can't keep both hostname and fqdn the same between DR and production, or we could never do a DR test.

Has anyone implemented disaster recovery for any SAP J2EE application that has run into these concerns and addressed them? Input would be greatly appreciated regarding how you addressed these issues, or how you architected your disaster recovery implementation.

Regards,

David Hull

The Walt Disney Company

[Former Member]

We also have same consern in one projet.

In our case the trouble of the different hostname is solved by CI export / import in sapinst.

But it means reinstall CI and Dialog instance in DR site. so it takes at least a hour.

So it's not best solution.

Now Im searchig better way to solve the difference of J2EE hostname problem...

Regards

MASAKI

[former_member273222]

Well I believe that it says, "not automatically supported by SAP." So really you need to contact SAP to get the real answer on whether they will support your configuration or not. If memory serves, a lot of HA configurations are not "officially supported" by SAP even though they document them. And they often pass the buck onto the HA vender. That's just the nature of the beast.

But as far as SSO credentials needing the same domain, that's because SAP Logon Tickets exist as cookies on the users browser. So if the ticket issuing system is in a different domain from ticket recieving system, it gets tricky because a browser will only pass a cookie to servers in the same domain as the server that created the cookie. This is just the nature of Cookies and Browsers not SAP Logon Tickets themselves. There are some workarounds for this issue out there, but I've never tried any of them.

Anyway, I recomend contacting SAP directly to find out what they will and will not support you on.

Good Luck,

Glenn

[Former Member]

Thanks, I have contacted SAP, in the form of opening a customer message. Unfortunately, the only answers I've gotten from them are "we don't support disaster recovery functionality - you need to work with your platform vendor for that."

Regards,

David Hull

[Former Member]

David,

We are also in the middle of DR planning for Java instances. We have installed all new systems in our landscape using the logical hostnames (sapinst option SAPINST_USE_HOSTNAME). The DR site will use physical name, but during DR the logical name of DR server(s) will be changed to the logical hostname. We are in the process of changing our abap and dual stack to logical names also. ABAP systems are relatively easy, our end users already use logical names to connect to our systems. We do have some dual stack and standalone java systems that use physical hostnames. We are going to recreate them with logical hostnames using system copies.

-RK

[Former Member]

Dear Nandi,

Im doing the same thing and was unclear on one point. when u say "The DR site will use physical name, but during DR the logical name of DR server(s) will be changed to the logical hostname. " do u mean that the physical hostname will be changed to the logical hostname which is your primary Servers hostname.

Regards,

Samant Kumar

[sukhdev_kaloor]

Hi Samanth,

Is the problem resolved?.

I believe the DR SAP systems will have to be installed on a virtual host.Once installed the systems will be kept in shutdown mode.To use the DR SAP applications the virtual host name has to be available. This virual hostname will be nothing but the hostname on which the primary is running. If the primary is down the ip address of the primary will be free and this will be used by the DR SAP application.

Is this the way its working?

regards,

dev

Edited by: Sukhdev Kaloor on Jan 10, 2010 5:05 AM

[Former Member]

Dear David Hull,

Could you able to set up disaster recovery for J2EE application. If so, appreciate if you can share the methodology for the same.

cheers/gopal

[former_member273222]

I haven't done this personally, but I do have some experience with these issues in different HA environments.

To your first point: You can change the hostname, note 757692 tells you exactly how to do it. However like the note says, "Changing the name of a host server in a production system is not automatically supported by SAP." When it says "supported by SAP" I think it means SAP the company, not SAP's software. So I would contact SAP to see if this configuration would be covered under your service agreement. Then you have to think about whether you want to do something that isn't "officially supported" by SAP. Also I'm sure you'll need some kind of additional licensing for the DR systems as their hardware keys will de different.

To your second point: As for SSO certs (SAP Login Tickets), I think they should still work as long as the SID and client number of the issuing system remain the same. I don't think they are hostname or fqdn dependant. For BSPs I would think they would still work as long as they use relative paths rather than absolute paths. And for XI... I have no idea what kind of issues may arise, I'm not an XI guy.

Again, I haven't done what you're describing myself. This is just based on my HA experiences.

Hope this helps a little,

Glenn

[Former Member]

Yes, you're right, the note does tell you how to change the hostname. But it also says that, while the J2EE engine will start, they can't guarantee any applications within the J2EE will run. Management will hardly sign on to a DR strategy when an SAP note says "we won't support you if you do that" so, unless I find a note to the contrary, I'm afraid my hands are tied there, even if it may technically work.

I am told that SSO certificates are in fact tied to the domain. Not the hostname, since the same certificate will work for multiple application servers, but all servers must be in the same fqdn. Of course, I have found many notes indicating requirements to use the fqdn, as well as the installation manual itself... the problem is in determining which of them are still valid. With the J2EE engine changing as much as it is, I find many differences in an SPS, much less a version upgrade.

And I know the logical response is simply to test it. But it is not realistic to test all scenarios, including those which may not be in development today, and to predict which of those may fail in the future due to utilizing an undocumented, if not documented as unsupported, method for maintaining a DR instance.

Regards,

David Hull

[Former Member]

Hi

You need to isolate the DR network and use an network alias as a workaround and it will work fine.

Regards,

Shaji

[Former Member]

Well, I'm not sure how isolating the DR network works, since we have to somehow keep the DR system in sync with production (eg: with database log shipping, as we do on the ABAP side). Also, using a network alias doesn't address the problem I raised at all, since the J2EE engine checks the hostname it's running on, not the alias.

Regards,

David Hull