Load Balancing for network elements

In this world of network communication, one of the common patterns of information exchange is where an information requester and an information server exist. In common parlance, this is known as the client and server architecture. (For curious minds, there is another common pattern: an information registrar on one end, and registrants for that information on the other end. This model is better known as the publisher and subscriber model.)When there is a large number of requesters and a relatively small number of servers, the system's efficiency and the end users' experience are directly affected by the way requests are processed among the serving entities. Here becomes the application of load(request) balancing techniques of paramount importance. A large body of literature already exists that explains various load-balancing algorithms. Consider distributing the load in a round-robin manner, or using a weighted average scheme, etc)  I won't deal with them through this article but instead, I will try to address various considerations that should be taken into account when choosing load balancing as a solution.

1. Load balancing function location: Should the load balancing be done directly at the client entity itself, at the server (where the server has multiple threads of execution) or there should be a third-party load balancing entity in between? This is to say where the load balancing function should exist. The answer should be dictated by the expected load at peak times as well as during normal operation. The cost is another factor. The ease of managing and distributing the load balancing-related configuration is also a major concern.

2. Security. Load balancing solutions are generally expected to work seamlessly between a client and server as if both are not aware of the load balancer's existence. If the load balancing function is outside of both the client and server, securing the communication has its challenges as most security protocols tend to secure the end-to-end communication. If there is an intercepting entity in between, the security apparatus at both ends needs to be aware of it. SSL-based load balancing is one option.

3. Communication organization:  The load balancer has a choice to either act as a proxy or a redirector of requests. If the load balancer is a proxy, both the request and response go through it affecting communications in at least two ways:     a. Comparatively low throughput due to proxy intercepting requests and response to edit and then route them in both directions.     b. The end server may not be able to identify the specific user unless the request has something to identify the client or the load balancer intercepts and enhances the request by adding the client-specific information.

    If the load balancer is a redirector, there is either an extra step where the client should resend the request to the server identified by the load balancer or the client should be prepared to get a response from an unknown server (could be a security concern for some applications)

4. Exchange the health and load information: There is a need to have a mechanism between the load balancer and servers to exchange the health as well as load information so that the load can be balanced efficiently between the live servers and appropriate actions can be taken during any untoward situation. 

Health and load information can be exchanged by sharing enhanced heartbeats at regular intervals with each other or sharing with a common entity. This common entity should be queriable equally by load balancers and servers.

Given the above considerations, it is important for a network planner to look at the service goals and desired throughput before choosing the components and techniques of load balancing. Also important is not to choose a solution based on just the vendor specifications but rather bench-marking different alternatives in the live or almost live setup before accepting it.

Please feel free to let me know of any more considerations while choosing and placing a Load Balancer in their network.