Benefits of load balancing Cloudian HyperStore

Load balancing Cloudian HyperStore S3 object storage provides a number of key benefits, including:

• High Availability (HA): Load balancing is crucial for ensuring guaranteed uptime and consistent data access. It continuously monitors the health of all HyperStore nodes. If a node fails or becomes unresponsive, the load balancer automatically and instantly reroutes client traffic to the remaining healthy nodes. Eliminates Single Point of Failure (SPOF): By distributing traffic across multiple nodes and often being deployed in a High Availability (HA) pair itself, the load balancing layer removes any single point of failure for client access to the storage cluster. This resilience is vital for mission-critical data.
• High performance: Load balancing maximizes the throughput and responsiveness of the HyperStore cluster. Intelligent Traffic Distribution: It evenly distributes the workload across all active storage nodes. This prevents any single node from becoming a bottleneck or overloaded, ensuring that the parallel processing architecture of HyperStore can be fully utilized. By balancing requests, it helps achieve consistent response times for data access and file transfers. For solutions like Cloudian’s HyperBalance, advanced techniques like Layer 7 routing can optimize request handling further.
• Enhanced scalability: Load balancing simplifies and optimizes the process of growing your storage environment. HyperStore’s scale-out architecture allows you to add new nodes to increase capacity. A load balancer ensures that as soon as a new node is added, it is immediately included in the traffic distribution pool, instantly boosting both total storage capacity and aggregate system throughput without any disruption to ongoing operations. It presents the entire massive, scale-out storage cluster as a single Virtual IP address (VIP) to the client applications. This single access point simplifies network management and allows the cluster to grow limitlessly behind the scenes without requiring client configuration changes.

About Cloudian HyperStore

Cloudian HyperStore solves major storage challenges, allowing companies of all sizes to realise the benefits of object storage in their own data centres.It provides scalable enterprise object storage, with 100% native Amazon S3-API support.

Placing a load balancer in front of Cloudian HyperStore architecture supports High Availability (HA) clustering. Load balancers also monitor and perform health checks on a node to ensure traffic is routed correctly to healthy nodes. Without the use of a load balancer, an offline or failed node would still receive traffic, causing failures.

A variety of load balancing methods are currently supported by Cloudian HyperStore, dependent on customer infrastructure, including Layer 7, multi-site GSLB, and GSLB direct to node. The HyperStore services that should be load balanced are:

• S3, Cloudian Management Console (CMC)
• Admin-API
• Identity and Access Management

Why Loadbalancer.org for Cloudian HyperStore?

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 Cloudian HyperStore

The load balancer sits in front of multiple HyperStore nodes and can be deployed in a number of different ways, namely Layer 7 Reverse Proxy, multi-site GSLB, or GSLB direct to node.

For Cloudian HyperStore, Layer 7 Reverse Proxy is recommended.

Virtual service (VIP) requirements

Four virtual services are used to load balance the different aspects of HyperStore:

• CMC – for Cloudian Management Console requests
• S3-HTTP – handles requests from S3 client applications via HTTP.
• S3-HTTPS – handles requests from S3 client applications via HTTPS.
• API – handles APO requests via HTTPS.

Single site load balancing scenario

In a single site scenario, multiple HyperStore nodes and two load balancers (configured as a high-availability pair) are deployed to ensure redundancy. Clients access the HyperStore nodes via the virtual IP address (VIP)

Multi-site load balancing scenario

Under normal conditions, each site works as described in the single site scenario. Should all HyperStore nodes in one site become inaccessible, local client traffic is routed to the virtual IP address presented in the other site.

External clients can either be bound to a particular site, or to protect against site failure, the load balancer’s built-in global server load balancer (GSLB) can be leveraged to provide intelligent DNS name resolution & site connectivity.

Layer 7 Reverse Proxy deployments (recommended)

• The default, traditional, and recommended deployment type
• Flexible and simple: the load balancer acts as a reverse proxy
• Use this deployment method unless you have a specific reason not to

Direct to node GSLB deployments

• Round-robin DNS with health checking
• Client traffic flows directly to the Cloudian Nodes and directly back again – the load balancer is entirely removed from the path of HyperStore traffic
• Useful when network throughput is paramount while retaining the load balancer’s active health checking of HyperStore nodes

Multi-site GSLB deployments

• Uses DNS to provide high availability across multiple sites
• Assumes that each site’s own HyperStore cluster is being load balanced using Layer 7 SNAT Mode (Default)
• Clients at a site with a failed HyperStore service are automatically directed to a functioning site
• Provides optional location affinity (by default) to ensure clients connect to their local HyperStore service

Related Resources