Load Balancer voor webservers

[djlinsen]

Ik wil voor een webapplicatie een high availability en high performance opstelling maken.
Het idee is dat de load over de IIS webservers verdeelt gaat worden en als 1 server uitvalt de andere server de boel draainde houdt. De load wil ik het liefst dynamisch over de servers verdelen, dus de server die de laagste responstijden, laagste cpu belasting, laagste disk belasting etc heeft, krijgt extra load toegewezen. Verder moet het relatief eenvoudig te installeren en te onderhouden zijn.

Een methode lijkt me om dit te doen met een redundant uitgevoerde load balancer. Er zijn verschillende totaal oplossingen te koop zoals van baracuda en Zeus. Verder heb ik wat opensource oplossingen gevonden zoals LVS en ultra monkey. Ik heb met Zeus ZXTM desktop edition al wat gespeeld, dat zag er allemaal wel redelijk eenvoudig uit. Verder heb ik de howto's van LVS en ultra monkey doorgebladerd, maar dat was wel erg linux commandline georienteerd, daar heb ik helaas erg weinig kennis van.

De webservers zijn microsoft georienteerd (IIS) asp.net webapplicatie. Vandaar uit ben ik ook nog tegen ARR in combinatie met nlb tegen gekomen. http://learn.iis.net/page...calability---arr-and-nlb/

Met welke load balancers hebben jullie goede ervaring? Hebben jullie al ervaring met ARR en NLB?

Uiteindelijk wil ik gaan voor een loadbalancer met een scherpe prijs kwaliteit verhouding. Dus het liefs zo goedkoop mogelijk, maar zeker niet tenkoste van betrouwbaarheid en kwaliteit.

[Verwijderd]

Varnish is een makkelijke loadbalancer/reverse proxy cache. Tweakers gebruikt deze ook ergens voor (zoek even in de .plans). Ik gebruik varnish ook en het werkt echt top. In varnish kan je een weight aan bepaalde backend webservers geven.

De .vcl maken moet geen probleem vormen en zoveel kennis van *nix heb je niet nodig. Je kan overigens het beste de IIS headers (Server:) eruit laten halen door varnish, zodat je een minder groot target wordt voor hackers.

Alternatieve loadbalancers: nginx en lighttpd.

[DiedX]

zeer goede ervaringen met ha-proxy.

[CyBeR]

Overigens zijn varnish en ha-proxy geen load balancers maar reverse proxies. lighttpd en nginx zijn zelfs full-featured web servers met reverse proxy functionaliteit. Afhankelijk van wat je uit gaat spoken kan dat een probleem zijn. Bijvoorbeeld, omdat een reverse proxy altijd zowel de request als het antwoord ziet*, gaat dat dus beide over één netwerklink heen. Als je veel met downloads doet kan dat dus een beste bottleneck worden. Een echte load balancer kun je zo inregelen dat alleen de requests erlangs gaan en de antwoorden direct teruggestuurd worden.

Verder gebruik ik zelf varnish als caching proxy, niet zozeer omwille van 't load balancen. Daar heb ik een load balancer voor. ha-proxy heb ik ook wel 's gebruikt, maar dat was toch gelimiteerder dan varnish (en het doet geen caching). Het mooie aan varnish is dat VCL feitelijk een programmeertaal is-- het wordt ook vertaald naar C en dat wordt gecompileerd. Dat is heel krachtig. Maar voor simpelheid is ha-proxy dan weer beter.

*) Ik meen dat ha-proxy met wat extra moeite geconfigureerd kan worden om dat niet het geval te laten zijn.

[ Voor 5% gewijzigd door CyBeR op 31-01-2010 16:17 ]

[djlinsen]

CyBeR schreef op zondag 31 januari 2010 @ 16:16:
Overigens zijn varnish en ha-proxy geen load balancers maar reverse proxies. lighttpd en nginx zijn zelfs full-featured web servers met reverse proxy functionaliteit. Afhankelijk van wat je uit gaat spoken kan dat een probleem zijn. Bijvoorbeeld, omdat een reverse proxy altijd zowel de request als het antwoord ziet*, gaat dat dus beide over één netwerklink heen. Als je veel met downloads doet kan dat dus een beste bottleneck worden. Een echte load balancer kun je zo inregelen dat alleen de requests erlangs gaan en de antwoorden direct teruggestuurd worden.

Verder gebruik ik zelf varnish als caching proxy, niet zozeer omwille van 't load balancen. Daar heb ik een load balancer voor. ha-proxy heb ik ook wel 's gebruikt, maar dat was toch gelimiteerder dan varnish (en het doet geen caching). Het mooie aan varnish is dat VCL feitelijk een programmeertaal is-- het wordt ook vertaald naar C en dat wordt gecompileerd. Dat is heel krachtig. Maar voor simpelheid is ha-proxy dan weer beter.

*) Ik meen dat ha-proxy met wat extra moeite geconfigureerd kan worden om dat niet het geval te laten zijn.

Welke Load balancer gebruik jij? en wat is jou ervaring hier mee?

[Zwelgje]

zelf gebruik ik altijd de NLB functionaliteit in windows. zeker als het 'alleen' maar gaat om simpele IIS load balancing is dat een prima oplossing

http://technet.microsoft....rary/cc779570(WS.10).aspx

[CyBeR]

djlinsen schreef op zondag 31 januari 2010 @ 16:44:
[...]


Welke Load balancer gebruik jij? en wat is jou ervaring hier mee?

Ik heb een Alteon 180. Die is al wat ouder maar is rock-solid. Maar ik denk dat we op een gegeven moment ook wel overstappen op een varnish frontend, aangezien dat wel wat flexibeler is.

[Bl@ckbird]

Naast Baracuda en Zeus heb je bijvoorbeeld F5 Big-IP en Cisco ACE appliances.

Of je standaard NLB van Windows gebruikt of dedicated load-balance appliances wil gebruiken ligt aan de performance die je wil halen, het aantal webservers en andere features die je belangrijk vindt. ( Zoals inspectie van XML verkeer, SSL offloading voor HTTPS verkeer, virtual context zodat klanten in een hosted omgeving hun eigen virtuele load balancer kunnen beheren, enz. )

[axis]

djlinsen schreef op zondag 31 januari 2010 @ 15:11:
Ik wil voor een webapplicatie een high availability en high performance opstelling maken.
Het idee is dat de load over de IIS webservers verdeelt gaat worden en als 1 server uitvalt de andere server de boel draainde houdt.

Windows NLB doet dit, en heb je binnen 10 minuten geconfigureerd op je IIS servers zonder extra hardware. Nadeel van NLB is dat het osi model layer 3/4 balancing is, niet layer 7. Je NLB balanced gewoon TCP poorten die je aangeeft, onafhankelijk van of je website actief is, fouten geeft, etc.. Pas als je machine onderuit gaat (of je dit handmatig aangeeft) beslist de balancer pas dat er geen verkeer meer naar de foute node moet. En da's jammer als de helft van je gebruikers een foutmelding te zien krijgt omdat 1 van je sites plat ligt.

Ik gebruik haproxy voor loadbalancing, en squid of varnish om te cachen en connecties naar end-users af te handelen (en dus de performance te verhogen). Een van mijn clusters doet nu 3000 req/sec met 150Mbps, en ik hoop dat dit nog een veelvoud wordt hiervan. Ik vind squid fijner, maar varnish performed veel beter onder zware load. In haproxy doe ik health checking per site, en alleen 'healthy' sites krijgen requests. Als alle instanties van een site eruit liggen, toon ik een mooie foutmelding met logo van de klant dat de site momenteel niet beschikaar is, en ik doe meer van dat soort truukjes.

De load wil ik het liefst dynamisch over de servers verdelen, dus de server die de laagste responstijden, laagste cpu belasting, laagste disk belasting etc heeft, krijgt extra load toegewezen. Verder moet het relatief eenvoudig te installeren en te onderhouden zijn.

Alle balancers die ik ken (haproxy en pound) en reverse proxies (squid/varnish) ondersteunen weighed backends. Dynamisch aanpassen van weight echter gebeurt bijna nergens out-of-the box, omdat het te complex is. Er is recentlijk wel een boel over te doen geweest op de haproxy mailing list. Volgens mij ondersteunt pound wel dynamisch aanpassen van backend weights out-of-the-box, maar het is lang geleden dat ik daar naar heb gekeken. Het kan met alle balancers, maar dan moet je wel zelf willen scripten.

Eenvouding te installeren en onderhouden, dan kies ik voor haproxy.

Ik gebruik een aantal clusters van simpele freebsd machines (minstens 2) met CARP voor high availability. Ik gebruik bijvoorbeeld Dell R300's met 8GB RAM, voor 2 stuks met remote access cards en dergelijke ben je onder de 3000 euro kwijt, en linux of freebsd is gratis.

De webservers zijn microsoft georienteerd (IIS) asp.net webapplicatie. Vandaar uit ben ik ook nog tegen ARR in combinatie met nlb tegen gekomen. http://learn.iis.net/page...calability---arr-and-nlb/

Ik gebruik NLB al wel een jaar of 5, maar ik heb nog geen ervaring met ARR. Ziet er opzich wel goed uit (tijdje geleden een presentatie bekeken), maar ik zou nog niet vertrouwen op zo'n 'jong' project. Community support is wel heel erg handig als je met dit soort dingen bezig bent, en er zijn gewoon 'established' projecten zoals Squid, Haproxy, Varnish, met developer support op de mailinglist. Goud waard.

[machielse]

CyBeR schreef op zondag 31 januari 2010 @ 16:16:
Overigens zijn varnish en ha-proxy geen load balancers maar reverse proxies. lighttpd en nginx zijn zelfs full-featured web servers met reverse proxy functionaliteit. Afhankelijk van wat je uit gaat spoken kan dat een probleem zijn. Bijvoorbeeld, omdat een reverse proxy altijd zowel de request als het antwoord ziet*, gaat dat dus beide over één netwerklink heen. Als je veel met downloads doet kan dat dus een beste bottleneck worden. Een echte load balancer kun je zo inregelen dat alleen de requests erlangs gaan en de antwoorden direct teruggestuurd worden.

Verder gebruik ik zelf varnish als caching proxy, niet zozeer omwille van 't load balancen. Daar heb ik een load balancer voor. ha-proxy heb ik ook wel 's gebruikt, maar dat was toch gelimiteerder dan varnish (en het doet geen caching). Het mooie aan varnish is dat VCL feitelijk een programmeertaal is-- het wordt ook vertaald naar C en dat wordt gecompileerd. Dat is heel krachtig. Maar voor simpelheid is ha-proxy dan weer beter.

*) Ik meen dat ha-proxy met wat extra moeite geconfigureerd kan worden om dat niet het geval te laten zijn.

Reverse proxy is in de praktijk hetzelfde als een loadbalancer. Het is meer kwestie van wat voor naam geef je het. Bij hardwareloadbalancers is het misschien wat anders maar die zijn zo gigantisch duur dat het waarschijnlijk beetje overkill voor je is.
Als je puur redudantie wil kun je het beste gewoon de reverse proxy/loadbalancer nemen die je het makkelijkst te configureren en beheren vindt. Als je niet gigantische traffic hebt (laten we zeggen <10/20 duizend pageviews op een dag), dan is de performance eigenlijk altijd wel goed. Ik heb HAproxy tijdje gebruikt in setup met ongeveer 700 connecties tegelijk (ongeveer 200 requests per seconde) en dat liep perfect op core2quad.
Voordeel van HAproxy vond ik oorspronkelijk dat de load op basis van queue-size verdeeld kan worden; dat is beter dan pure round-robin. Bij pure round-robin balancing kun je krijgen dat als 1 server trager is dan de andere server, hij nog wel evenveel requests toegewezen krijgt, terwijl natuurlijk de machine die het minst te doen heeft het werkt toebedeeld moet krijgen.
Daarnaast heeft HAproxy een overzichtelijke statuspagina en meer heb je eigenlijk niet nodig meestal.
Meer stats op http://haproxy.1wt.eu/10g.html

[axis]

machielse schreef op vrijdag 26 februari 2010 @ 14:39:
[...]
Reverse proxy is in de praktijk hetzelfde als een loadbalancer. Het is meer kwestie van wat voor naam geef je het. [...]

Niet altijd, reverse proxies werken altijd op layer 3 van het OSI model, waar sommige balancers zoals LVS op layer 2 van het OSI model werken.

Soms maakt het niet uit, soms wel. Bijvoorbeeld bij de meeste reverse proxies krijg je een ander source ip-adres op je backend applicatie. Als je in je applicatie iets doet met source addressen (loggen, bannen, etc), dan moet je dus je applicatie aanpassen dat ie bijvoorbeeld naar de x-forwarded-for header kijkt of iets dergelijks. Daarnaast kan het zijn dat niet alle apparatuur in je netwerk om kan gaan met al dat layer 2 gedoe (denk aan balancer nodes die hun netwerkkaart in promiscuous mode moeten hebben, etc)

[ Voor 7% gewijzigd door axis op 26-02-2010 15:20 ]

[lordgandalf]

het bannen en loggen doe je toch op je reverse proxy dan. dan kan de gebruiker nooit op je site en dan hoeven je webservers niet alles meer te loggen

[Kees]

machielse schreef op vrijdag 26 februari 2010 @ 14:39:
[...]


Reverse proxy is in de praktijk hetzelfde als een loadbalancer. Het is meer kwestie van wat voor naam geef je het. Bij hardwareloadbalancers is het misschien wat anders maar die zijn zo gigantisch duur dat het waarschijnlijk beetje overkill voor je is.

Dat is nu niet echt een uitspraak waar ik het mee eens ben. Voor tweakers gebruiken wij een combinatie van lichte en zware webservers, reverse proxies en loadbalancers. Daar zit wel degelijk verschil in. Zo zou 1 reverse proxy lang niet onze website kunnen serveren (te dynamisch), en zou het dan ook niet HA zijn. Daar heb je dan twee reverse proxies voor nodig die dmv bijvoorbeeld heartbeat/pacemaker communiceren. Maar dan heb je nog steeds maar twee frontend servers, welke niet op load gebalanced zijn, maar eerder op bv round robin. Om op load te balancen heb je een systeem nodig die de load van de backends kent, en vervolgens nieuwe requests naar de server stuurt met de laagste load.

Een loadbalancer is toch echt fundamenteel anders dan een reverse proxy.

Wij gebruiken zelf twee hele simpele Dell 1u bakken, uitgerust met een quad core (was goedkoper dan een single of dual core ) 2G geheugen, een disk en 4 netwerkpoorten. Hierop draait een standaard Debian install, uitgerust met de http://www.linuxvirtualserver.org/ software. Redelijk basic, en daar hebben we dan zelf wat omheen gescript. Je kan ook een appliance kopen, maar in 9 vd 10 gevallen draait er (zeker op de goedkopere appliances) gewoon ook LVS op, alleen hoef je dan er niet omheen te scripten

[gertvdijk]

Vreemd genoeg heb ik Apache nog niet voorbij zien komen in dit topic. Ik heb laatst zelf een reverse proxy opgezet met wat spannende trucendozen om oude URLs (soms transparant) te supporten middels rewrites+proxy. Daarbij liep ik onvermijdelijk tegen de mogelijkheden van Apache als load balancer. Vooralsnog beschouw ik het als leuke toekomstige uitbreiding op de huidige setup, maar als hier Apache niet eens wordt genoemd vraag ik me toch af wat er dan eventueel mee mis is.

[ Voor 19% gewijzigd door gertvdijk op 26-02-2010 17:25 ]

[Kees]

gertvdijk schreef op vrijdag 26 februari 2010 @ 17:21:
Vreemd genoeg heb ik Apache nog niet voorbij zien komen in dit topic. Ik heb laatst zelf een reverse proxy opgezet met wat spannende trucendozen om oude URLs (soms transparant) te supporten middels rewrites+proxy. Daarbij liep ik tegen onvermijdelijk tegen de mogelijkheden van Apache als load balancer.

Dat komt omdat apache redelijk zwaar is voor de simpele taak van reverse proxy. Hij kan het wel, en het werkt ook wel, maar het blijft overkill. Het is een beetje als een HD5970 kopen voor simpele desktop applicaties; het werk wel, maar het is ook overkill

[Rainmaker]

Je zou eventueel er ook nog een LVS (http://www.linuxvirtualserver.org/) voor zetten.

Lekker simpel, en werkt prima. "Wij" gebruiken het hier vrij veel, ook voor IIS servers.

[Verwijderd]

Hoi

Kijk hier eens

http://www.kemptechnologies.com/emea/

LM-2500 kost rond de 5000.
Twee van die dingen en je hebt HA

Je kunt er zowat alles mee aanbieden. En die dingen ondersteunen stickyness/persistence.
Heb hier ervaring mee, relatief goedkoop en werkt.

[djlinsen]

Rainmaker schreef op vrijdag 26 februari 2010 @ 17:49:
Je zou eventueel er ook nog een LVS (http://www.linuxvirtualserver.org/) voor zetten.

Lekker simpel, en werkt prima. "Wij" gebruiken het hier vrij veel, ook voor IIS servers.

Initieel gaan we starten met NLB, met het huidige aantal users en load is dat voldoende.

Ik ga hier binnenkort eens mee spelen, maar met de minimale kennis die ik van linux heb hoop ik maar dat het ook echt een beetje "Lekker simpel" is. In de how-to's zie ik erg veel scripts en config files langs komen tot nu toe.

Welke linux distributie is eenvoudig te installeren/configureren en geschikt om als platform voor LVS te dienen?

[ Voor 6% gewijzigd door djlinsen op 05-03-2010 07:36 ]

[djlinsen]

LVS gaat hem niet worden hier, in onze organisatie is niemand met gedegen linux kennis. Het installeren en configureren aan de hand van de verschillende how-to's gaat al erg moeizaam, maar troubleshooten in geval van problemen zal nog veel en veel meer tijd kosten zonder de juiste kennis. Dan is een totaal oplossing zoals kemp al snel voordeliger in de aanschaf.