The Load Balancing CAT provides a structure for the distribution of workload over multiple computing resources. It is facilitated by a load balancer component that spreads the incoming requests to the duplicated components running on different resources. The distribution of requestes depends on the current server utilization and other predefined performance criteria, like response time.
Also Known As
Service Load Balancing, Static Load Balancer
In the example, the architecture of a book shop is shown. It consists of a requester, in this case it is the book shop frontend, which sends requests to the book shop management. As there are two instances of the book shop management component available, a load balancer is connected in between the book shop frontend and the book shop management. It distributes incoming requests from the book shop frontend to the book shop management component. How the requests are spreaded to the available components should be specified by the architect. The roles‘ constraints assure the characteristics of the Load Balancing architecture:
- The load balancer component is in between the requester and provider component, i.e. the requester has a connector to the load balancer component and the load balancer component has a connector to the provider component.
- A connector from the requester to the provider and the other way round is not allowed.
- The provider components should be stateless.
A system, consisting of multiple component instances, that requires distribution of incoming requests to them.
Assume a system with multiple component instances running on distributed resources without a load balancer, e.g. requests are sent randomly to one of the components. This could lead to unpredictable and ineffcient behavior. For example, in the worst case the requests are sent to only one of the components and, at a certain point in time, the server is not able to handle all of the requests and they have to be aborted. In a system that is dynamical horizontal scalable, a load balancer is mandatory as it is not only used to distribute the workload but also to gain utilization information by it and thereby to deduce the number of required components.
Introduce a load balancer component that distributes incoming requests among multiple component instances. By spreading the requests depending on the server utilization, the load balancer enhances responsiveness, availability and it serves as a basis for elasticity. Furthermore, criteria and an related threshold can be predefined and evaluated values can be compared to the threshold to enhance the distribution of requests.
In the following figure, we provide the CAT type for Load Balancing:
Assume a system with multiple component instances of one type and a number of requests sent to this component type, so that only a subset of them is utilized. Suddenly, a high amount of requests arrives that would lead to high response times or rejection of requests when still the same number of components is used because the server would be overloaded. Hence, the load balancer transfers the requests to the components that are not used at the moment. When the load decreases, the load balancer can adapt the distribution of requests, e.g. it can initiate the deallocation of a server.
The load balancer component can be implemented as an external component or as a built-in component that is deployed on one of the severs allowing them to balance the workload on their own. This means, the load balancer component can communicate with the other servers to distribute the workload.
Amazons Elastic Compute Cloud (EC2), OnApp Cloud
We identified the following benefits for Load Balancing:
- The system is scalable and better utilized. It provides a better availability and smaller response times.
- It reduces the problem of single points of failures.
- Extendable to dynamic horizontal scaling architecture.
We are aware of the following liabilities for Load Balancing:
- The components of the provider should be stateless. Keeping information over several requests needs more sophisticated techniques to preserve the state while spreading the requests over multiple resources.
- Erl, T., Puttini, R., Mahmood, Z. "Cloud Computing: Concepts, Technology & Architecture". Prentice Hall Press, 2013.
- Fehling, C., Leymann, F., Retter, R., Schupeck, W., Arbitter, P. "Cloud Computing Patterns. Fundamentals to Design, Build, and Manage Cloud Applications". Springer, 2014.
- Furht, B., Escalante, A. "Handbook of Cloud Computing". Springer, 2010.