Load-Balanced SSL Farm

SSL Farm

in the above tutorial, we have overlooked one thing, that is, the L7 load Balancing server for SSL support. In the L7 load balancing server, we often need to read and write requests and cookies in response. However, if the communication uses an SSL connection, the L7 load balancing server will not be able to read and write the contents of the request and response. One solution that the

has used to resolve this problem is to use a load-balanced server in reverse proxy mode. In this scenario, the load-balancing server owns the service's certificate and can decrypt the request through the key in the certificate. When decryption is complete, the load-balancing server can begin to attempt to read the contents of the cookie and determine the service instance to be distributed to the request based on the information it records. When the request is distributed, the load-balancing server can no longer use the SSL connection, which makes it unnecessary for each service instance to decrypt the request again and improve the operational efficiency of the service instance.

After the request has been processed, the service instance returns a response through the service instance and the non-SSL connection to the load-balanced server. After the load-balancing server receives the response, it encrypts the response and emits it over an SSL connection:

But the problem is that if all the processing of SSL is concentrated on the L7 load balancing server, it will become a bottleneck for the system. The way to bypass this problem is to use a series of reverse proxies to handle the codec operation of SSL before L7 the load balancing server.

At this point the architecture of the entire system renders the following hierarchy:

As you can see, the entire solution is divided into four tiers. When a user's request arrives at the first tier of a load-balanced server, it forwards the request to a second-tier reverse proxy that is specifically responsible for the SSL codec work, based on its own load-balancing algorithm. The agent will send incoming requests transmitted by the SSL connection by a non-SSL connection. When a request reaches the third tier, the L7 load balancing server can directly access the cookie contained in the request and determine the service instance that needs to process the request, based on the content in the cookie.

There are many benefits to doing so. The first is that these reverse proxies are very inexpensive, and even about 1/20 of the price of a common load-balancing server, they have almost the same efficiency in handling SSL connections. In addition, these reverse proxies provide very good scalability and high availability. Once the load-balancing system is struggling with the ability to handle SSL connections, we can add new reverse proxies to the system at any time. And once one of the reverse proxies fails, the other reverse proxies can guarantee the safe operation of the system by assuming more load.

Load-balanced SSL Farm