Load balancing DataCore Swarm Gateway
Benefits of load balancing DataCore Swarm Gateway
The top three benefits of load balancing the DataCore Swarm Gateway are:
- High Availability (HA): Load balancing distributes incoming client traffic (like S3/HTTP requests) across multiple Gateway servers. If one Gateway server fails or goes offline, the load balancer automatically redirects traffic to the remaining healthy servers. This prevents a single point of failure, ensuring the application remains always available and resilient to hardware or software issues.
- Optimal performance: By distributing the workload, load balancing prevents any single Gateway server from becoming overloaded or creating a ‘hot spot’. This optimization of resource usage maximizes the system’s throughput and minimizes response times, providing stable, optimal performance for client applications accessing the object storage.
- Scalability: Load balancing makes the Swarm Gateway layer highly scalable. You can add new Gateway servers to the pool to handle increased demand without interrupting service. Crucially, it also enables zero-downtime maintenance; servers can be isolated, upgraded, or removed from the cluster one at a time while the load balancer routes all new traffic to the remaining active servers.
About DataCore Swarm Gateway
DataCore Swarm Gateway provides an on-premise object storage solution allowing S3/HTTP access to any application, device, or end-user.
These services are presented via gateway servers. These gateways need to be load balanced in order to provide highly available and resilient service access.
How to load balance DataCore Swarm Gateway
The load balancer can be deployed in 4 fundamental ways: Layer 4 DR mode, Layer 4 NAT mode, Layer 4 SNAT mode, or Layer 7 Reverse Proxy (Layer 7 SNAT mode).
For DataCore Swarm Gateway, Layer 4 DR mode is recommended. It offers the greatest raw performance and is particularly well suited to read-intensive storage scenarios.
However Layer 7 Reverse Proxy must be used if the gateway servers are on a different network segment to the load balancers (no Layer 2 connectivity between them) or when it is not possible to make administrative changes to the gateway servers for some reason.
Virtual service (VIP) requirements
To provide load balancing and HA for DataCore Swarm Gateway, the following VIP is required:
- Gateway Access
Load balancing deployment concept

About Layer 4 DR mode
Layer 4 DR (Direct Routing) mode is a very high performance solution that requires little change to your existing infrastructure. The image below shows an example network diagram for this mode:

DR mode works by changing the destination MAC address of the incoming packet to match the selected Real Server on the fly which is very fast.
When the packet reaches the Real Server it expects the Real Server to own the Virtual Services IP address (VIP). This means that you need to ensure that the Real Server (and the load balanced application) respond to both the Real Server’s own IP address and the VIP.
The Real Servers should not respond to ARP requests for the VIP. Only the load balancer should do this. Configuring the Real Servers in this way is referred to as Solving the ARP problem.
On average, DR mode is 8 times quicker than NAT for HTTP, 50 times quicker for Terminal Services and much, much faster for streaming media or FTP.
The load balancer must have an Interface in the same subnet as the Real Servers to ensure Layer 2 connectivity required for DR mode to work.
The VIP can be brought up on the same subnet as the Real Servers, or on a different subnet provided that the load balancer has an interface in that subnet.
Port translation is not possible with DR mode, e.g. VIP:80 → RIP:8080 is not supported. DR mode is transparent, i.e. the Real Server will see the source IP address of the client.

