Origin load balancing

PUSHR's advanced load balancing feature allows for rapid scalability of new and existing web projects with just a few clicks inside your account dashboard. Up to 3 origins can be added to each CDN zone. 

Benefits

• Rapid scalability, high performance and low latency
• Virtually unlimited number of connections 
• Complete abstraction of the load balancing layer from the customer's cloud, dedicated or on-premises infrastructure
• Multi-Origin and Multi-Region balancing with active failover
• Eliminates cloud vendor lock-ins

Load balancing on the edge

PUSHR's load balancers run in each of our edge network locations. The closest edge data center is selected automatically for improved latency and high throughput to the origins of the customer. Once a data center has been designated as the load balancer for a given set of origin servers, all other edge data centers are automatically configured to forward requests for uncached content to it. In a single-region load balancing, where all of the customer's origins physically reside in the same geographical region, a single PUSHR edge data center is used as a load balancer. In a multi-region setup, where the customer's data may be replicated or distributed across different geographical regions and cloud vendors, multiple edge data centers are automatically configured as load boalancers. The rest of PUSHR's edge network will then auto-configure itself and each edge data center will attempt to connect to the closest load balancer for maximum performance. 

Load balancing modes explained

The following modes are supported for origins residing in the same geographical region: 

• Primary + Backup
• Round Robin
• Least Connections

For multi-region load balancing, the currently supported modes are:

• Latency-Based Load Balancing

Primary + Backup
Requests for uncached content are sent to the first origin in the group, which is marked as primary in the CDN origins tab in your account's dashboard. In the event of failure, requests are then forwarded to the second origin in the group. If this origin fails too, the third origin is used. 

Round Robin
Requests are distributed to all origins in a random order. If an origin fails or becomes overloaded, it will be temporarily removed from the load balancing group. PUSHR will then wait for a predefined interval before attempting to forward requests to this origin again. 

Least Connections
Requests are forwarded to the origin server to which the load balancer has the lowest number of currently active connections. The load is distributed equally and PUSHR will assume that all origins to be of the same type and have the same processing power. If any origin fails to respond within a predefined time frame, it will be temporarily excluded from the load balancing group.

Latency-Based Load Balancing
Requests will be distributed to the origin that is closest to the edge server the request for uncached content comes from, based on measured latency and geographical proximity. In this mode a full redundancy can be achieved if the content is replicated across all origins, and a complete failure of one region will not affect the availability of the customer's content. 

Additional features

The following features have been made available to provide a more granular control over how the CDN load balancers will forward requests to the customer's origin servers. Please note that some features are not available with some load balancing modes. For reference, please see the considerations section at the end of this page.

404 Error Handling
In the event that a 404 error is returned by an origin server, PUSHR will query the rest of the origins for the content before returning an 404 file not found error to the visitor.

Session Stickiness
When enabled, this feature will route all requests from a given visitor to the same origin server to avoid broken sessions.

Important considerations

Host header
All origin servers that you want to load balance must recognize and respond equally to the same $host header. PUSHR automatically sets the value of the $host header with the hostname of your primary origin, as defined in your dashboard, and you should set all your origins to repond to this same hostname. 

Example:
You have two origins that you want to load balance - ww1.example.com and ww2.example.com. Both of them should have their server names configured to recognize the hostname of the primary origin. As ww1.example.com already recognizes it's name, only the configuration of ww2.example.com needs editing:

Apache:

<VirtualHost *>
    ServerName ww1.example.com ww2.example.com
</VirtualHost> 

Nginx:

server_name ww1.example.com ww2.example.com;

HTTPS
The requirement for the same host header to be recognized across all load-balanced origins may lead to issues with your current SSL setup. The easiest way to enable HTTPS without breaking the load balancing functionality is to use wildcard certificates and ensure that origins operate on subdomains of the same domain. In the above example, ww1.example.com and ww2.example.com both operate under the example.com domain. As such a widcard certificate for example.com should be issued and installed on all origins.

Balancing modes
Depending on the selected load balancing mode, the 404 Error Handling and sticky session functionalities may not be available. Additionally, selecting a multi-region balancing mode when your origin servers are located in the same geographical region, as well as selecting a single region balancing mode when the origins reside in different regions will cause your load balancer to misbehave. 
Please refer to the table matrix below regarding supported modes and features

Known issues

• All load-balanced origins must use either HTTP or HTTPS. Mixing protocols is not possible.
• If the IP address of an origin server changes, it has to be removed and then re-added to the origins list for PUSHR to detect the change