Sourcing Load Balancing/High Availability Setup

[Former Member]

Hello

We are planning to install SAP Sourcing 7.0. We have two App Server and one DB Server. We are exploring Load Balancing/High Availability Setup and had few questions

As per my understanding since we have only one App server HA is ruled out. Correct me if I am wrong.

I would like to know how to setup Load balancing in the production environment. I have gone through the following link but there is very minimal information

http://help.sap.com/saphelp_sourcing_70_p/helpdata/en/11/d66fa7619e406887a8788391dd7894/content.htm

So any pointers from the experts will be helpful.

Regards,

S Tripathi

[Former Member]

We did a Load Balancing Setup.

[former_member238852]

Hello ST,

Could you please share the Custer Configuration Setup screenshot/details after masking the host names?

Thank you,

Sri

[Former Member]

Hi,

HA requires at least 2 instances on virtually or ideally physically distinct machines to ensure continued productivity for the business users in the case of a catastrophic failure of one of these servers.

Load balancing is typically handled by an external load balancer that controls the domain that the Sourcing instances are part of. Typical load balancers are F5, BigIP, and the SAP WebDispatcher.

Load balancing is setup within the Cluster configuration where the loadbalancing domain is set and external load balancing is turned on. If automatic load balancing is enabled within sourcing then users will automatically be redirected to the cluster member with the lowest concurrent active sessions.

I'll see if I can dig out some information on the Web Dispatcher as a load balancer and post it as a blog.

Thanks,

Paul

[Former Member]

Hi Paul,

Thanks a lot for your response. It will be great if you can publish the blog.

However I have certain queries which I am unable to find answers. If you can help answer the same that will be of great help.

Our Landscape

We have a hardware load balancer in our DMZ instead of SAP Web Dispatcher which we are planning to setup in Round Robin method. We have 2 Physical App Server and 1 Physical DB Server. We plan to use SAP recommended NW UME as the driver in the Policy Configuration.

Setup Planned

We understand that without 2 DB boxes true HA is not possible. However we still want better availability and trying the following option:

- We will install 2 seperate instances of SAP CE on App1 and App2 with 2 DB Instances on DB Server

- Install SAP Sourcing on both App1 and App2. Provide the same connection string such that on DB it refers to the same Sourcing Instance

However in this scenario the following points are not clear

- How will directory configuration work as the NW UME is different on two App Servers. So the users created will be created on which App Server?

- What shold be the cluster configuration for this setup as on both the App Servers? When I goto Cluster config in App1 will I see App2 also listed?

- What is the purpose of the Services we add during Cluster Configuration? Is it used during load balancing.

Any answers in this direction will be really helpful.

Regards,

ST

[Former Member]

Paul,

Thank you for the VERY helpful discussion we had today.  I would like to post here for posterity and hopefully save a few days of heads banging on a wall for people trying to configure eSourcing to use multiple instances with multiple server nodes through a load balancer.  Please feel free to correct me if I misrepresent any of this information.

I ran into 4 areas that were keeping me from configuring this system properly.

1. How do you register a new dialog instance?
2. Why are there 5 URL redirects, including one directly to the server in the cluster, before the first page is displayed?
3. How are you supposed to configure the eSourcing clusters?
4. Why would I sometimes get redirected to the physical server which was not defined anywhere in my cluster configurations?

1.  Registered Servers – There is an eSoucing “registered server” configuration for each server node in a system.  There is an application property on the eSourcing application defining the path to the eSourcing database.  The default value is specified during the creation of the eSourcing SCA for deployment which must be changed from the default of “localhost” to the physical hostname of the database server.  If defined properly, the application will “register” itself as a service with the eSourcing configuration on startup.  This includes installing a new dialog instance as well as adding additional server nodes to an existing instance.  These registered servers are then added as members to the eSourcing clusters.

For our sandbox system, we have two instances with two server nodes each.  Here is the list of services that are registered:

ptlcen10_10_00

ptlcen10_10_01

ptldia22_22_00

ptldia22_22_01

Our load balancer configuration sends the request to ptlcen10 and ptldia22 in a round robin.

2. Why are there five Redirects before the first page is displayed?  Not a bug but as designed.

Reason: since the application was designed originally for tomcat, there are several redirects to populate all the Sourcing cookies necessary for the application to run properly. This is done by URL redirects so it will be a client side request. 

Because this is an external facing application, the hostname for each cluster member would have to be the external URL and port because one of the redirects is from the cluster member defined in the list.  If you define the server names in this cluster as described in the help files, this hostname would be presented externally to your vendors.  It would be a blank page which would display properly with a refresh.

Since the load balancer and the Netweaver ICM will maintain stickiness using cookies, the user ends up on the same instance and server node for all of the redirects so, although inefficient, it will always work.

At some point, this application should be redesigned to utilize the saplb_* cookie created by the ICM to avoid 5 redirects.

3. Cluster Configuration:  The Sourcing cluster that will be used for an incoming request is determined by matching the hostname parameter of the cluster and the hostname in the request.  The cluster member to be used is based on the service name passed by the application sending the request which is dynamic based on the instance and server node (i.e. ptlcen10_10_00, etc.).

Typically, you need two clusters defined.  One for the System Default and one for the External facing URL. 

The Default System Cluster should have !!DEFAULT!! as the hostname so it will be used if the hostname in the request does not match another cluster defined.  The members of this cluster would be the actual hostname and port of the underlying java system.  If you want to access the fsbuyer and fsvendor applications from the Default cluster (i.e. directly from a server without using the LB), you will have to assign a Context and a Directory Configuration.

The External cluster would have the hostname defined as the external URL and each member of the cluster would also have the hostname and port of the External URL. 

4. Why do I see redirects to the physical hostname?

Each cluster must have all the registered servers as members (one for each server node installed).  If you do not have EVERY registered server as a member of the clusters, you will get redirected to the physical hostname of that system (i.e. js200prd00).  During my fumbling around trying to guess at configurations, I had deleted the cluster member for my server 1 node of the instance and each time I landed on that server node, I would get the physical hostname because it did not find the entry in the defined cluster.  Very frustrating if you don’t understand how it’s architected. 

This is how our system is now configured: 

This example would assume an external facing URL (sourcing.company.com) that would point to a load balancer (F5, Web Dispatcher, etc).  The Load Balancer would just round robin to the server IP addresses and ports for the java system, i.e. ptlcen10:51000, etc.  Once the request reached the application, the eSourcing cluster configuration takes over.

ExternalCluster

hostname = sourcing.company.com

members:

ptlcen10_10_00 - sourcing.company.com - 443

ptlcen10_10_01 - sourcing.company.com - 443

ptldia22_22_00 - sourcing.company.com - 443

ptldia22_22_01 - sourcing.company.com - 443

System Default Cluster

hostname = !!DEFAULT!!

members:

ptlcen10-10-00 - ptlcen10.company.com - 51000

ptlcen10-10-01 - ptlcen10.company.com - 51000

ptldia22-22-00 - ptldia22.company.com - 52200

ptldia22-22-01 - ptldia22.company.com - 52200

[Former Member]

Hi,

Check /people/ankush.mittal2/blog/2011/06/13/sap-sourcing-51-clm-sizing-and-load-balancing

applicable for sourcing 7 as well

Regards

Ankush Mittal

[Former Member]

Hi Ankush,

Thanks for your blog. I posted certain queries on your blog. Kindly answer if possible.

Regards,

S Tripathi