Load balancing Scality RING

How to load balance Scality RING

The function of the load balancer is to distribute inbound connections across a cluster of Scality RING nodes, to provide a highly available and scalable service. One virtual service is used to load balance the S3 aspect of RING. Client persistence is not required and should not be enabled.

SSL termination on the load balancer is recommended for load balancing Scality RING. The S3 service uses the “Negotiate HTTP (GET)” health check. For multi-site RING deployments, it is possible to use the load balancer’s GSLB functionality to provide high availability and location affinity across multiple sites. Using this optional, DNS based feature, in the event that a site’s RING service and/or load balancers are off-line then local clients are automatically directed to a functioning RING cluster at another site.

For deployments that are read-intensive, it is possible to use an alternative load balancing method known as direct routing. This allows reply traffic to flow directly from the back end servers to the clients, thus removing the load balancer as a potential bottleneck for reply traffic. Direct routing can benefit read-intensive deployments with a large reply traffic to request traffic ratio.

• High Availability (HA): Traffic is directed to healthy Scality Ring nodes only, based on application-level health checks.
• Resilience: Automated failover and location-based traffic steering for multi-site
• Scalability: Optimized for Scality Ring’s distributed architecture to facilitate easy scale out of application workloads and concurrent users.

The load balancer can be deployed as a single unit, although we recommend a clustered pair for resilience and high availability. Details on configuring a clustered pair can be found on page 25 of our deployment guide, below.