Cloud Load Balancing Services

1
91

Load-balancers are all about availability, scalability and performance of mission critical web-based applications. Therefore, cloud load balancing services are needed to enable enterprises to migrate their mission and performance critical application to the cloud. Mission critical web-based applications are typically multi-tier and distributed. The load balancer connects the application to the external network and load-balancing incoming web-client sessions between the different frontend web-servers.

 

 

Cloud Server Load BalanceThis provides:

  • Availability, which is managed by continuously monitoring the health of the application’s frontend web-servers, and re-directing incoming web-client sessions only to the healthy ones. Such that, frontend web-server outage will have no impact on application overall availability. To avoid single point of failures, load balancers are typically deployed in active-standby or active-active pairs
  • Scalability, which is managed by participating in the careful orchestration of frontend web-servers scaling out to meet increase in the number of concurrent web-client sessions and scaling back in during off-peak times. Scaling out and in requires online reconfiguration of the load-balancer to dynamically increase or decrease the size of frontend web-server pool. Scaling in also requires gracefully disconnecting frontend web-servers only after all in-flight sessions have been successfully terminated.
  • Performance, which is managed in many different ways. By load-balancing policies that make sure no single frontend web-server is overloaded to the level that it negatively impacts its responsiveness. Performance is also managed by offloading SSL processing from the frontend web-server to the load-balancer, as well as, compression and WAN optimization techniques.

Using hardware appliances or virtual appliances can provide cloud load balancing services. While hardware appliances would typically provide higher and predictable performance in terms of throughput and latency, load-balancing virtual appliances leverages the same cloud computing infrastructure and run side-by-side with of the virtualized applications’ VMs. That way, cloud service providers may use both types of load-balancing form factors to provide tiered load-balancing services.

Cloud load balancing services can be provided by sharing a load-balancer between different tenants or by dedicating a distinct load-balancer for each tenant or even for each tenant’s application. Sharing a load-balancer between different tenants may introduce tight interdependency between tenants applications’ performance. Unless the shared load-balancer is natively multi-tenant (e.g. Radware’s Alteon-VX) such that each tenant is provisioned with its own fully isolated virtual load-balancer instance on the shared appliance with its own dedicated computing resources. We can relate to such virtual load-balancer instance on a truly multi-tenant shared appliance as a dedicated load balancer.

Cloud load balancing services can be provisioned by cloud service providers and consumed by tenants in different ways. All need to address the above aspects of availability, scalability and performance management. Specifically, cloud load balancing service provider needs to provide means for the cloud load balancing service consumer to manage the life-cycle of the load balancing service in the cloud, including:

  • Provisioning
  • Configuration (Virtual IP, TCP ports, LB policy, SSL, …)
  • Operating (scaling out/in)
  • Decommissioning

We have identified four different types of cloud load balancing service solutions that differ in the load balancing service management aspects, which are supported by the cloud self-management portal:

Flow Chart load Balancing

Traditional hosting – No load balancing service management exists in the self-management portal, or there is no self-management portal (this is why we call it “traditional hosting”). Load balancing service provisioning and management is done by the cloud/hosting service provider typically at the hosted application initial deployment time. All types of load balancer appliances (physical and virtual) and both types of service deployment patterns (shared and dedicated) are applicable for this service solution.

Self-Managed – Tenant user is using the cloud service self-management portal to provision a load balancing service, configure it, manage its ongoing operation (scaling out/in) and decommissioning it. As the tenant user is granted management privileges, a dedicated load balancer is needed for this service solution, ether a dedicated virtual appliance (e.g. Alteon VA) or a dedicated load balancer instance on a truly multi-tenant physical appliance (e.g. Alteon VX). When the solution is based on multi-tenant physical appliances, then some level of integration is needed between the cloud service platform and its self-management portal (e.g. VMware vCloud Director) with the load balancing appliances management system (e.g. Radware vDirect). Such integration is also needed in the case that a pair of virtual appliances is provisioned for highly available deployment.

Semi-Self-Managed – Load balancing service provisioning is done by the service provider, and then the tenant customer can directly manage the load balancer. A dedicated load balancer is needed for this service solution. No integration with self-management portal is required.

Fully Managed – Tenant user is also using the cloud service self-management portal to provision a load balancing service to configure it. Self-management portal is also used to manage operations like scaling out and in. We call it “fully managed” as the load balancing service is fully managed through the self-managed portal and also because the cloud service provider is fully managing the load balancer. A tight integration is needed between the cloud service platform and its self-management portal (e.g. VMware vCloud Director) and the load balancing appliances management system (e.g. Radware vDirect) to cover the full life-cycle management (provisioning, configuration, operation and decommissioning).

The table below summarizes the main differences in deployment of the above cloud load balancing service solutions.

 

Shared

Dedicated

Self-Management Portal Integration

   

Provision

Configuration/Operation

Traditional hosting    
Self-Managed    
Semi-Self-Managed      
Fully Managed  

1 COMMENT

  1. Update: @kexik as mentioned via pravite email, and since it could potentially help other API users, please note that your problem is related to a bug in ASIHTTPRequest (popular Objective-C HTTP library). We’ve already identified this bug, contacted ASIHTTPRequest’s author via Twitter and also opened a pull request: . Feel free to refer to this pull request for more technical details.In the meanwhile we’ve also applied this patch to our official Moodstocks iPhone SDK () that’s why we strongly encourage our API users to work with it as far as their iPhone apps are concerned. Since the SDK provides a high-level abstraction, it makes easy to integrate our solution without getting your hands dirty with such technical stuff!

LEAVE A REPLY

Please enter your comment!
Please enter your name here