0002969: load-balancing for lazy-applications

Viewing Issue Advanced Details [ Jump to Notes ]

[ View Simple ] [ Issue History ] [ Print ]

Category

Severity

Reproducibility

Date Submitted

Last Update

0002969

[Resin]

minor

always

09-25-08 11:57

07-22-11 12:31

Reporter

ferg

View Status

public

Assigned To

ferg

Priority

normal

Resolution

fixed

Platform

Status

closed

Projection

none

OS Version

ETA

none

Fixed in Version

4.0.21

Product Version

Product Build

Summary

0002969: load-balancing for lazy-applications

Description

(rep by Daniel Bjuhr)

We need a load balancing setup that share the load for many web applications on multiple backend servers, but we don?t want the web apps to be activated on all backend servers at the same time. We want to configure all apps as ?lazy? on all backend servers. They will then be activated when the first request to their DNS is made. Then the app is started on that backend server.

We have hundreds of apps and each backend server will become very slow if all apps are activated on all backend servers. The preferred solution would therefore be to not call all DNS names on all backend servers but to share the load based on the DNS name in the requests. Sticky-session or sticky source-IP won?t be enough to solve this as they only stick to each user session.

If User-A request www.siteA.com he may be redirected to backend server 1 and then be kept there. But if User-B then requests the same www.siteA.com he may be redirected to backend server 2 and then be kept there. This means that the web application for siteA will be activated and loaded in both backend servers. As we now host hundreds of sites this has become a problem. We may set up many resin backend servers but they will all end up loading all web apps over time and get out of memory.

The theory to get this work is a load balancer with the following logic:
1. A request for a certain DNS comes in. For example: www.siteA.com
2. Load balancer checks if this certain DNS has been redirected to a certain backend server before and if this server is alive
2.1. (If not redirected before): Redirect the request to the backend server with least load. Store the selected backend route based on the DNS name.
2.2. (If redirected before): Redirect the request to the assigned backend server for siteA.

3. If a backend server is down then all DNS requests to this server will be redirected to another backend server with least load. All requests to these DNS names will be assigned to this backend server instead.

Example of set up

Many DNS to one IP
192.168.1.1 www.siteA.com
192.168.1.1 www.siteB.com
192.168.1.1 www.siteC.com
...

Frontend load balancer
192.168.1.1 (load balancer)

Backend app servers
192.168.2.2 (App server 1)
192.168.2.3 (App server 2)
192.168.2.4 (App server 3)

Snapshot of servers during load

App server 1
www.siteA.com (Activated)
www.siteB.com (Lazy)
www.siteC.com (Lazy)

App server 2
www.siteA.com (Lazy)
www.siteB.com (Activated)
www.siteC.com (Lazy)

App server 3
www.siteA.com (Lazy)
www.siteB.com (Lazy)
www.siteC.com (Activated)

Steps To Reproduce

Additional Information

Attached Files

Relationships

Notes
(0005389) ferg 07-22-11 12:31	server/26o0

Issue History
Date Modified	Username	Field	Change
09-25-08 11:57	ferg	New Issue
07-22-11 12:31	ferg	Note Added: 0005389
07-22-11 12:31	ferg	Assigned To	=> ferg
07-22-11 12:31	ferg	Status	new => closed
07-22-11 12:31	ferg	Resolution	open => fixed
07-22-11 12:31	ferg	Fixed in Version	=> 4.0.21

Mantis 1.0.0rc3[^]

28 total queries executed.
25 unique queries executed.