GitHub Launches Open Source Software Load Balancer 'GLB Director'

GitHub has released the open source load balancer " GLB Director " which improved the problem which existed in the conventional virtual load balancer.

GLB: GitHub's open source load balancer | GitHub Engineering
https://githubengineering.com/glb-director-open-source-load-balancer/

GitHub looses load-balancing open-source code on netops world • The Register
https://www.theregister.co.uk/2018/08/09/github_load_balancing_director/

"Load balancer (load balancer)" distributes requests for servers to multiple servers. Although it is a name unfamiliar to those who have not experienced system development, in reality, many of the services including YouTube have multiple servers with the same function. This is because if service is performed on one server, the load increases as access increases, the system goes down, the response gets worse, and it may not be able to maintain comfortable service for users is. However, just by physically increasing the number of servers, load sharing can not be done because there is not evenly distributed access. Therefore, a load balancer (load balancer) that has the role of evenly distributing the load is necessary.

For example, assume that a common network router is used as a load balancer and the two proxy servers are load-balanced as shown in the image below. Here, if you configure the router to add the third proxy server (right end) to the load balancing target ... ...

Immediately the third server is added to the load balancing target. Once the router can communicate with the server, it recognizes that "the server is alive". For this reason, even if the third proxy server is not in a state where the service can be continued while being prepared, the router recognizes that "the third server is normal" and assigns the communication, and a part (Two communications in this case) will cause an error.

Routers can not handle application level load balancing well. The virtual load balancer like LVS (Linus Virtual Server) is used there. In the following, three LVSs are placed directly under the router, and the three LVSs under the router are placed, and the three proxy servers under it are load-balanced. According to GitHub, LVS is checking the state of the service of the backend server (server subject to load balancing), which means "It will work without problems in many cases". In the following cases, the third LVS at the right end of the three LVS and proxy servers and the proxy failed and it is stopped. At this point there are no problems as the service can be handled by two LVS and proxy servers.

Here, suppose that the third LVS and proxy server are activated at the same time as a response to disaster recovery. Normally, LVS checks the status of the backend server before assigning communications. However, if the third LVS does not cleanly process down before the failure occurs, it may have the state before the failure occurred at the time of restart. At this time, even if the third proxy server is in operation and can not be serviced, the third LVS immediately after the restoration will allocate communication from "the fact that the server was in operation before the failure" There is a problem that access to some users will be erroneous.

To solve this problem, GLB Director developed by GitHub adopts the method "Allocate primary and secondary backend servers for each communication assignment". Here, even if the same problem as above occurs, the communication is transferred to the server set as the secondary immediately, and connection errors can be avoided.

GLB Director can be downloaded from the following.

GitHub - github / glb - director: GitHub Load Balancer Director and supporting tooling.
https://github.com/github/glb-director