Load balancing Epicor Kinetic ERP 11
Updated on October 21, 2025
•
Published on April 16, 2024
Benefits of load balancing Epicor Kinetic ERP 11
Load balancing Epicor Kinetic ERP 11 are High Availability, optimal performance, and enhanced scalability:
- High Availability (HA): Load balancing ensures that your Epicor Kinetic ERP 11 application is always available to users by eliminating single points of failure. By distributing traffic across a pool of multiple application servers, if one server fails or goes offline, the load balancer automatically redirects all new user requests to the remaining healthy servers. This prevents system downtime and ensures continuous service, which is critical for an enterprise resource planning (ERP) system that manages core business operations. The load balancer constantly monitors the health of all backend servers. If a server becomes unresponsive, it’s immediately taken out of the distribution pool until it recovers, maintaining a seamless user experience.
- Optimal performance: Load balancing improves the overall speed and stability of the ERP system by efficiently managing the workload. It prevents any single server from becoming overwhelmed by distributing incoming user requests (transactions, inquiries, report generation) evenly. This promotes equal server utilization and ensures resources are used efficiently. By preventing server overload, load balancing avoids bottlenecks that cause slow response times. This results in faster load times for the Kinetic UI, quicker transaction processing, and a more responsive application, even during peak usage periods.
- Scalability: Load balancing provides the flexibility to grow your system capacity and manage maintenance with zero downtime. As your business grows or traffic increases, you can easily and quickly add new application servers to the existing pool. The load balancer automatically incorporates the new servers to handle the increased load, allowing for seamless horizontal scaling without requiring an overhaul of your infrastructure. Servers can be isolated and taken offline for maintenance, upgrades, or patching (e.g., applying an Epicor patch) without affecting the availability of the application. The load balancer simply directs traffic to the remaining active servers, greatly reducing risk and eliminating the need for scheduled downtime during business hours.
About Epicor Kinetic ERP
Epicor Kinetic ERP 11 enables business users to handle a combination of scheduling obligations remotely from a single area of the system.
Easy-to-use visual tools permit resource optimization, capability-based scheduling, change management, and more.
Why Loadbalancer.org for Epicor Kinetic ERP?
Loadbalancer’s intuitive Enterprise Application Delivery Controller (ADC) is designed to save time and money with a clever, not complex, WebUI.
Easily configure, deploy, manage, and maintain our Enterprise load balancer, reducing complexity and the risk of human error. For a difference you can see in just minutes.
And with WAF and GSLB included straight out-of-the-box, there’s no hidden costs, so the prices you see on our website are fully transparent.
More on what’s possible with Loadbalancer.org.
How to load balance Epicor Kinetic ERP
The load balancer can be deployed in 4 fundamental ways: Layer 4 DR mode, Layer 4 NAT mode, Layer 4 SNAT mode, and Layer 7 Reverse Proxy (Layer 7 SNAT mode).
For Epicor Kinetic ERP 11, Layer 7 Reverse Proxy is recommended.
Virtual service (VIP) requirements
To provide load balancing and HA for Epicor Kinetic ERP 11, the following VIP is required:
| Ref. | VIP Name | Mode | Port(s) | Persistence Mode | Health Checks |
|---|---|---|---|---|---|
| VIP 1 | EPICOR_KINETIC | Layer 7 Reverse Proxy | 80, 139, 443, 445 | Source IP | HTTPS (OPTIONS) |
Load balancing topology
Layer 7 Reverse Proxy can be deployed using either a one-arm or two-arm configuration. For two-arm deployments, eth1 is typically used for client side connections and eth0 is used for Real Server connections, although this is not mandatory since any interface can be used for any purpose.
For more on one and two-arm topology see Topologies & Load Balancing Methods.
About Layer 7 Reverse Proxy load balancing
Layer 7 Reverse Proxy uses a proxy (HAProxy) at the application layer. Inbound requests are terminated on the load balancer and HAProxy generates a new corresponding request to the chosen Real Server. As a result, Layer 7 is typically not as fast as the Layer 4 methods. Layer 7 is typically chosen when either enhanced options such as SSL termination, cookie based persistence, URL rewriting, header insertion/deletion etc. are required, or when the network topology prohibits the use of the Layer 4 methods.
The image below shows an example Layer 7 Reverse Proxy network diagram:
Because Layer 7 Reverse Proxy is a full proxy, Real Servers in the cluster can be on any accessible network including across the Internet or WAN.
Layer 7 Reverse Proxy is not transparent by default, i.e. the Real Servers will not see the source IP address of the client, they will see the load balancer’s own IP address by default, or any other local appliance IP address if preferred (e.g. the VIP address).
This can be configured per Layer 7 VIP. If required, the load balancer can be configured to provide the actual client IP address to the Real Servers in 2 ways. Either by inserting a header that contains the client’s source IP address, or by modifying the Source Address field of the IP packets and replacing the IP address of the load balancer with the IP address of the client. For more information on these methods, please refer to Transparency at Layer 7 in the Enterprise Admin Manual.
