Purpose
Build a scalable architecture for news website using below components:
- Load balancer with content switching capability
- Cache server
- Application server
Definition
- Content switching: the ability to route traffic based on the content of the HTTP request: URI, parameters, headers, etc…
HAProxy is a good example of OpenSource reverse proxy load-balancer with content switching capability. - cache server: a server able to quickly deliver static content.
Squid, Varnish and Apache Traffic Server are OpenSource cache reverse proxy. - application server: the server which build the pages for your news website.
This can be either Apache+PHP, Tomcat+Java, IIS+asp .net, etc…
Target Network Diagram
Context
All the traffic pass through the ALOHA load-balancer.
HAProxy, the layer 7 load-balancer included in ALOHA, will do the content switching to route request either to cache servers or to application servers.
If cache server misses an object, it will get it from the application servers.
HAProxy configuration
Service configuration:
frontend public bind :80 acl DYN path_beg /user acl DYN path_beg /profile acl DYN method POST use_backend APPLICATION if DYN default_backend CACHE
The content switching is achieved by the few lines beginning with the keyword acl.
If a URI starts with /user or /profile or if the method is a POSTthen, the traffic will be redirected to the APPLICATION server pool, otherwise the CACHE pool will be used.
Application pool configuration:
backend APPLICATION balance roundrobin cookie PHPSESSID prefix option httpchk /health http-check expect string GOOD server APP1 1.1.1.1:80 cookie app1 check server APP2 1.1.1.2:80 cookie app2 check
We maintain backend server persistence using the cookie sent by the application server, named PHPSESSID in this example. You can change this cookie name to the cookie provided by your application, like JSESSIONID, ASP.NET_SessionId or anything else.
Note the health check URL: /health. The script executed on the backend will check server health (database availability, CPU usage, memory usage, etc…) and will return a GOOD if everything looks fine and a WRONG if not. With this, HAproxy will consider the server as ready only if the server returns a GOOD.
Cache pool configuration
backend CACHE balance url hash-type consistent option httpchk / http-check expect KEYWORD reqidel ^Accept-Encoding unless { hdr_sub(Accept-Encoding) gzip } reqirep ^Accept-Encoding: .*gzip.* Accept-Encoding: gzip server CACHE1 1.1.1.3:80 check server CACHE2 1.1.1.4:80 check
Here, we balance requests according to the URL. The purpose of this metric is to “force” a single URL to always be retrieved from the same server.
Main benefits are :
- less objects in caches memory
- less requests to the application server for static and pseudo-static content
In order to lower the impact of the Vary: header on Content Encoding, we added the two lines reqidel / reqirep to normalize a bit the Accept-Encoding header.
whoah this blog is excellent i love reading your articles. Keep up the great work! You know, a lot of people are searching around for this information, you could aid them greatly.
Thx! A small addition which may be obvious for most of the people but took me some time to figure out: For content switching both the frontend and backend need to be in the same mode. It worked for me after adding “mode http” to the frontend and backend definition.