Benefits of load balancing IBM Cloud Object Storage (COS)

The three main benefits of load balancing for IBM Cloud Object Storage (COS) are High Availability (HA), scalability, and improved performance:

• High Availability (HA): Load balancing ensures that the object storage service remains accessible and reliable, even if individual components fail. Load balancers continuously monitor the health of the underlying IBM COS Accesser nodes. If an Accesser node fails or goes offline, the load balancer automatically stops sending new traffic to that node and redirects requests to the remaining healthy nodes. This failover mechanism prevents a single point of failure from disrupting service, maintaining high availability and a consistent user experience.
• Scalability: Load balancing provides an easy way to scale the object storage system horizontally to handle massive data growth and increasing numbers of users. It allows administrators to add or remove IBM COS Accesser nodes as needed without changing the public endpoint (Virtual IP) that clients connect to. By distributing incoming connections across the expanding pool of Accesser nodes, the system can handle growing data volumes and increasing concurrent requests without performance degradation.
• Improved performance: By intelligently distributing the workload, load balancing prevents any single component from becoming a bottleneck, which optimizes overall system performance. It spreads client requests evenly across all available IBM COS Accesser nodes. This prevents “hot spots”—where a single node is overloaded—and ensures that all resources are utilized efficiently. By balancing the load, each request can be processed more quickly, which minimizes response time and reduces latency for data access and retrieval

About IBM Cloud Object Storage

The IBM Cloud Object Storage system is a breakthrough platform that helps solve petabyte (and beyond) storage challenges for enterprises worldwide.

It uses an innovative and cost-effective approach for storing large volumes of unstructured data while still ensuring scalability, security, availability, reliability, manageability, and flexibility.

Why Loadbalancer.org for IBM Cloud Object Storage?

Why Loadbalancer.org for RedHat OpenShift?

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 IBM Cloud Object Storage

A variety of load balancing methods are currently supported by IBM Cloud Object Storage Accessor nodes, dependent on customer infrastructure, including Layer 4, Layer 7, and geo GSLB / location affinity.

When the IBM Accessor nodes are deployed with the load balancer, clients connect to the Virtual Service (VIP) on the load balancer rather than connecting directly to one of the Accessor nodes.

The VIP can be configured using either Layer 4 or Layer 7, depending on the architecture of the network. In this case we recommend using Layer 7 Reverse Proxy as no network changes are required and SSL termination can be implemented.

This mode offers high performance and implementation flexibility, however as Layer 7 is a reverse proxy the client source IP address is not visible at the real server: instead, the IP address of the load balancer is visible at the real server. In order to retain the client source IP address, the load balancer inserts an X-Forwarded-For header into the load balanced traffic, which the IBM Accessor nodes can log for troubleshooting issues while seeing the true source IP address of connecting clients.

Virtual service (VIP) requirements

To provide load balancing for IBM COS Accessor nodes the following VIP is required:

• Accessor Cluster

Load balancing deployment concept

When the IBM Accessor nodes are deployed with the load balancer, clients connect to the Virtual Service (VIP) on the load balancer rather than connecting directly to one of the Accessor nodes.

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. 

Related Resources