HTTP¶
Schéma de base¶
Description¶
The HTTP service is of primary importance for the day-to-day operations of the computing system (updates, boot process, …). We therefore suggest to set up the HTTP service in such a way that its only limiting factor is the network bandwith.
To do so, we combine HAProxy, keepalived and apache. Thus, the clients communicate with an unique URL pointing towards 2 PI addresses (DNS round robin). This set up offers a first level of load balancing.
The two IP addresses used are attributed to the 2 HAProxy machines. These are virtual IP addresses which are taken care of by a keepalived service, which is it running on both machines. Please note that these machines should be located on different hypervisors. The proxy service will be provided by HAProxy, allowing for finer grained load balancing towards the final HTTPS servers.
For the http clients that support transparent http redirections, the HAProxy will not serve as proxy for the requests, but redirect the requests to the most appropriate server (identified by the load balancing algorithm). The other clients (iPXE`+ `curl mainly at this point in time) will see the HAProxy as a transparent proxy.
The final servers will run on the machines dedicated to the island management (with higher network throughput) and on the workers. It will be the role of the load balancer to maximize the available bandwith onto the different available HTTP servers.
In oder to reduce the risk of cascading failures, we suggest to limit the number of requests sent to the workers. Thus, the service will be composed of:
N HTTPS serves, with N being the total number of hypervisors (TOP+WORKERS+2xISLET). Note that the data of the HTTP Server is stored in gluster file system, and not cached by apache.
2 machines with HAProxy servers paired via keepalived.
There will be a single and unique URL for all clients. This service will host the package repository, the bmgr service and the services needed for deployment of the compute nodes (kickstart, diskless, …)