Differences

This shows you the differences between two versions of the page.

Link to this comparison view

schaalbare-website_loadbalancing [2019/04/26 10:34] (current)
Line 1: Line 1:
 +===== Http Loadbalancing =====
 +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
 +<​code>​
 +          Interweb
 +           |
 +         ​web1a....web1b ​        Load balancers
 +         / ​  \
 +        /     \
 +   ​xxx1afp ​ xxx1bfp ​            ​static,​ loadbalancing http proxies
 +       ​|\ ​   /|
 +       | \  / |
 +       ​| ​ \/  |
 +       ​| ​ /\  |
 +       | /  \ |
 +       ​|/ ​   \|
 +   ​xxx2afp ​ xxx2bfp php nodes
 +</​code>​
 +
 +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
 +
 +
  
  • schaalbare-website_loadbalancing.txt
  • Last modified: 2019/04/26 10:34
  • (external edit)