Er zijn meerdere manieren om loadbalancing te implementeren, deze sectie beschrijft hoe wij dit het liefste doen, nl met twee gestapelde loadbalancers. De gedachte is dat we aan de buitenkant een paartje loadbalancers hebben, welke in master/slave configuratie draaien. Deze loadbalancers gebruiken keepalived met direct routing. Dat betekent dat de loadbalancers puur op IP niveau kijken en losse IP pakketjes doorsturen naar de te loadbalancen instanties.

Normaal zouden die te loadbalancen instanties een farm van webservers zijn die het eigenlijke werk doen, maar hier zit er een extra laag tussen, nl er wordt geloadbalanced over een farm(pje) van http proxies. En die proxies op hun beurt loadbalancen (mod-proxy-balancer igv apache) dan over de farm van (php enabled) webservers die het echte werk doen. In ascii art ziet dat er als volgt uit

          Interweb
           |
         web1a....web1b         Load balancers
         /   \
        /     \
   xxx1afp  xxx1bfp             static, loadbalancing http proxies
       |\    /|
       | \  / |
       |  \/  |
       |  /\  |
       | /  \ |
       |/    \|
   xxx2afp  xxx2bfp		php nodes

Er is voor deze getrapte setup gekozen om de volgende redenen:

• Aan webserving zitten twee kanten: enerzijds het spoonfeeden

(bitje voor bitje uitserveren, over een tergend traag internet lijntje) van data naar je kijkers, anderzijds het uitrekenen (denk php) van hoe een webpagina eruit moet zien. Voor het uitrekenen (php) heb je hele “dure” webserver slots nodig; bij apache is dat single threaded, ze hebben veel geheugen nodig etc. Het spoonfeeden echter is een simpele taak, die heel goed threaded kan. Normaal bij een php webserver zit je dus 90% van de tijd dure php slots te gebruiken om data naar je kijkers te spoonfeeden. Rescources die beter anders gebruikt zouden kunnen worden. Door er een http proxy tussen te zetten ontkoppel je het rekenen van het spoonfeeden. Het spoonfeeden gebeurt nu door de proxy, die daartoe geoptimaliseerd is (threaded webserver, veel slots e.d.) Het rekenen gebeurt door de geproxiede server. Omdat er tussen de proxy en de reken-server een snelle connectie ligt, is daar geen sprake van spoonfeeding en zijn de dure php slots alleen in gebruik op het moment dat ze ook echt nodig zijn. In apache termen betekent dit dat je op de php servers kan volstaan met>MaxClients 8, wat in normale mensentermen betekent dat je heel veel apache instanties naast elkaar zou kunnen gaan draaien zonder dat het geheugen volloopt.

• Een aardige bijkomstigheid van het gebruik van apache als proxy is

dat deze ook alvast het domme werk kan doen, nl zelf de statische data uitserveren, zonder daar de php server mee te belasten.

• Deze setup kan gebruikt worden voor het high-volume uitserveren

van statische websites. In dit geval zijn de proxies gewoon de eindpunten (ze proxyen zelf niks, omdat alles statische data is). Het schalen gaat hier door maar genoeg http proxies bij te schakelen. Stel dat er gekozen zou zijn voor een ongetrapt, simpeler alternatief, waarbij je de keepalived / DR loadbalancing gewoon niet zou doen (dwz direct aan de voorkant 1 proxy instantie, welke mbv keepalived in een master/slave config gedraaid wordt), dan zou dat prima werken voor groots php hosten, maar uiteindelijk zou je ene proxy server dan een choke point kunnen worden. Andersom, als de buitenkant een keepalived/DR loadbalancer zou zijn, die direct balanced over een aantal php nodes, dan heb je dus last van alle spoonfeeding issues zoals boven beschreven