Benefits to load balancing Epicor ERP 10
Load balancing Epicor ERP 10 provides the following key benefits:
- High Availability (HA): Load balancing is crucial for achieving high availability (HA) by distributing user requests and processes across multiple Epicor Application Servers. If one application server fails or requires maintenance, the load balancer automatically redirects all traffic to the remaining healthy servers. This prevents a single point of failure from causing system downtime, ensuring your business-critical ERP system remains accessible to users. It allows for non-disruptive upgrades or patches on individual servers. You can take one server offline, update it, and bring it back, while the others continue to serve users, maintaining business continuity throughout.
- Improved performance: By distributing the workload, load balancing prevents any single server from becoming overwhelmed, leading to faster and more consistent performance for all users. The load balancer intelligently distributes incoming client requests across the server farm, ensuring CPU, memory, and network resources are used efficiently across all available servers. Spreading the concurrent user load prevents resource bottlenecks on the application tier. This results in faster server response times for transactions, data queries (like Business Activity Queries or BAQs), and general navigation within Epicor ERP 10, significantly improving the end-user experience.
- Scalability: Load balancing facilitates a “scale-out” architecture, which is essential for accommodating an expanding user base and increasing transaction volumes. As your business grows (e.g., adding more users, increasing order volume, or integrating more modules), you can simply add more application servers to the load-balanced pool without needing to purchase a single, massive, and expensive “scale-up” server. This modular approach makes it easier and more cost-effective to scale your Epicor environment to match your current and future business needs, providing the flexibility to handle fluctuating or seasonal workloads.
About Epicor ERP 10
Epicor ERP is an enterprise resource planning software consisting of several modules from which companies can choose. It was rebranded in 2021 and is now known as Epicor Kinetic.
These modules include everything a business might need, such as supply chain and production management, planning and scheduling, product data, service management, human capital, sales, CRM, and much more. Each module is highly customizable and uses rule engines rather than fixed code to do specific functions such as rounding, currency, legal numbering, and book structure.
Epicor ERP version 10 enhances the interoperability features and streamlines the ERP use across multiple devices while providing greater deployment choices and simplified use.
For details of Epicor Kinetic 11 solutions, see this deployment guide: Load balancing Epicor Kinetic 11.
Why Loadbalancer.org for Epicor ERP 10?
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 ERP 10
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 ERP 10, using Layer 7 Reverse Proxy is recommended.
Virtual service (VIP) requirements
To provide load balancing and HA for Epicor ERP 10, a single VIP is required:
- ERP 10
Load balancing deployment concept
The load balancer can be deployed as a single unit, although Loadbalancer.org recommends a clustered pair for resilience and high availability.
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.
