Benefits of load balancing Dell ObjectScale
Load balancing for Dell ObjectScale is highly recommended by Dell to ensure the system handles high-performance S3 and Atmos workflows efficiently. By distributing traffic across multiple service nodes, the workflow transitions from a single-point-of-entry to a distributed, resilient architecture, offering the following benefits:
- High Availability and resilience: The load balancer constantly monitors the health of ObjectScale nodes. If a specific node or service fails, the load balancer automatically reroutes traffic to the remaining healthy nodes. This prevents application downtime and ensures that data remains accessible even during hardware maintenance or unexpected node failures.
- Optimized storage efficiency: For multi-site deployments, load balancing is critical for ObjectScale’s XOR-based erasure coding. To take advantage of XOR data reduction, write operations must be distributed across different Virtual Data Centers because if an application writes to only one site, ObjectScale cannot efficiently XOR that data across the federation. While multi-site load balancing ensures writes are balanced across sites, maximizing storage savings and improving local read hit rates.
- Performance scaling and SSL offloading: ObjectScale is designed to scale horizontally, but without a load balancer, traffic often bottlenecks at a single IP or node. Load balancing evenly distributes data loads, preventing any single node from becoming a performance bottleneck during peak PUT/GET operations. It is also possible to terminate SSL/TLS connections at the load balancer level. This offloads the heavy computational task of encryption and decryption from the ObjectScale nodes, freeing up their CPU resources to focus entirely on data ingestion and retrieval.
About Dell ObjectScale
Dell ObjectScale is a software-defined object storage platform designed to run on Kubernetes. It is the evolution of Dell’s legacy ECS (Elastic Cloud Storage), redesigned to be cloud-native.
Its primary language is the Amazon S3 API, allowing for the management of billions of objects across different geographic locations as if they were in one giant folder.
Why Loadbalancer.org for Dell ObjectScale?
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 Dell ObjectScale
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 Dell ObjectScale, using Layer 7 Reverse Proxy mode is recommended.
Port requirements
By default, the appliance uses the following TCP and UDP ports:
| Protocol | Port | Purpose |
|---|---|---|
| TCP | 22 | SSH |
| TCP & UDP | 53 | GSLB |
| TCP & UDP | 123 | NTP |
| TCP & UDP | 161 | SNMP |
| UDP | 6694 | Heartbeat between Primary & Secondary appliances in HA mode |
| TCP | 7778 | HAProxy persistence table replication |
| TCP | 9000 | Gateway service for ADC Portal comms |
| TCP | 9080 | WebUI – HTTP (disabled by default) |
| TCP | 9081 | Nginx fallback server |
| TCP | 9443 | WebUI – HTTPS |
| TCP | 25565 | Shuttle service for ADC Portal comms |
Load balancing deployment concept
Once the load balancer is deployed, clients connect to the Virtual Services (VIPs) rather than connecting directly to one of the Dell ObjectScale servers. These connections are then load balanced across the Dell ObjectScale servers to distribute the load according to the load balancing algorithm selected:
About Layer 7 Reverse Proxy
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 network diagram for this mode.
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.
Requires no mode-specific configuration changes to the load balanced Real Servers.
Port translation is possible with Layer 7 Reverse Proxy, e.g. VIP:80 → RIP:8080 is supported.
You should not use the same RIP:PORT combination for Layer 7 Reverse Proxy VIPs and Layer 4 SNAT mode VIPs because the required firewall rules conflict.
