My blog is based on past experience while designing technical architecture for some of my clients, who has concurrent users more than 50 and/or language packages installed more than 7.
In this blog I have shown all possible options for load balancing and how do sizing for Sourcing 5.1/CLM2.0 Also I have included Advantages and dis-advantages of each options so that it willl be helpfull for architect to decide which is best suitable option for their client landscape
Sizing: The sizing guidelines are based on a simplistic sizing model for a small and large installation. For the purpose of this sizing guide, when the number of concurrent SAP E-Sourcing users remains less than 50, it is considered a small installation and when the number of concurrent users exceeds 50, it is considered a large installation.
For small installation you would not need any load balancing as SAP sourcing single instance can handle till 50 concurrent users. But for most of the installation concurrent users exceeds 50.
Simple formula for Sizing:
No of instances required = [(total no. of concurrent user/50) + 1]
E-Sourcing Disk, RAM and CPU size can remain same or little higher as per guide
- Dual 2.8 GHz Pentium Xeon, 2MB cache or Dual 1GHz UltraSparc IIIi or equivalent
- 8GB RAM, 70GB Disk
Database size: Initial
- Dual 2.8 GHz Pentium Xeon, 2MB cache or Dual 1GHz UltraSparc IIIi or equivalent
- 8GB RAM, 300GB Disk (Disk size can be increased according to data growth in application)
Sourcing Load Balancing: E-Sourcing implements a basic clustering scheme for application scaling and load balancing. A cluster is a logical group of SAP® E-Sourcing services. Clusters are primarily used to define how end users access the E-Sourcing application. For example, you might configure one cluster for purchasers and another for suppliers. These two groups normally use different hosts and authentication methods.
Load Balancing Options:
Option 1: Multiple Java SID with multiple E-Sourcing instances (as per sizing guide)
- Disadvantage/Risk
- Have to install/manage multiple Java and E-sourcing servers.
- Possibility of E-sourcing application data mismatch.
- After Go-live support will be tough job.
- Advantages
- High availability of E-sourcing server (if one Java SID goes down other one can take charge)
- 50+ concurrent user can login
Option 2: One Java SID, multiple Java server node and single E-Sourcing instance (as per sizing guide)
- Disadvantage/Risk
- Use same java memory for every server node so load will be on single hardware. Over all memory will remain same on hardware.
- Hardware bottleneck
- Advantages
- 50+ concurrent user can login
Option 3: One Java SID, multiple Java dialog Instances (every instance will have at least one server node) and single E-Sourcing instance.
- Disadvantage
- No High Availability of E-Sourcing server
- Advantages
- 50+ concurrent user can login
- Load will be distributed to various dialog instances
Option 4: Two E-Sourcing, 2 Java SID with multiple dialog instances
- Disadvantage/Risk
- Have to install/manage at least 2 E-Sourcing and two Java central instances.
- Advantages
- 50+ concurrent user can login
- Load will be distributed to various instances
- High availability of E-sourcing server
Note: Please share if anyone has used any other method for load balancing in E-Sourcing.
Happy Reading.... 🙂
~Ankush Mittal
