Load balancing

[baseh]

Beste Wht's,

Voor het bedrijf waarvoor ik werk moet ik het volgende uitzoeken.

Er is een applicatie die op piekmomenten wel door 1500 gebruikers tegelijk gebruikt gaat worden.
Nu word het systeem over het algemeen 1 x ingeladen, en haalt hij na het laden over het algemeen alleen nog maar data uit de database via een request. php/pgsql).

Nu is het de bedoeling dat er in ieder geval een san komt voor opslag, en een apparte server voor de database. Nu ben ik over het algemeen erg bekend met database servers, maar wil toch ook eens kijken wat jullie ervaring is.

Heb je aan 1 fatsoenlijke database server genoeg? (Uitgaand van tussen de 500 en 1000 queries tegelijk).

En is 1 server sterk genoeg voor het php gedeelte? Of kan je beter 2 servers met een loadbalancer? En mocht een loadbalancer een aanrader zijn, wat zijn goeie en waar ben je gemiddeld voor zoiets kwijt?

Ik dacht voor de pgsql aan een:
- quadcore met 12gb werkgeheugen
- opslag gewoon op de san

En voor het php framework
- quadcore met 8 gb werkgeheugen
- opslag gewoon op de san

Opslag is qua snelheid snel zat. Dus gaat echt om de specs van de server. Ben ik reëel of schat ik het te laag in?

Alvast bedankt

[wonko]

zonder de specifieke kennis van de applicatie (wat doet je php script, welke queries zijn het).

Even heel extreem: als het altijd exact dezelfde query is, dan gaat je DB-server die prima kunnen cachen, en zou je hoegenaamd geen probleem mogen hebben. Als je php die dataset neemt, en die gewoon doorstuurt, dan kan je het als het ware op een atom *kuch*server*kuch* draaien.

Ik raad je aan te testen. Neem je applicatie, genereer een representabele dataset, gooi die neer op een systeem die je ietwat kent, en gooi er maar eens een benchmarking suite tegenaan. Ga op zoek naar wat je applicatie traag maakt, en tune/rewrite dat. Eens dat gedaan is, kan je normaal vrij goed inschatten wat qua machine ongeveer nodig is.

Een SAN in per definitie niet "voldoende snel"; databases hou ik graag de storage zo dicht mogelijk bij m'n CPUs, op zo snel mogelijke disks.

[baseh]

zonder de specifieke kennis van de applicatie (wat doet je php script, welke queries zijn het).

Even heel extreem: als het altijd exact dezelfde query is, dan gaat je DB-server die prima kunnen cachen, en zou je hoegenaamd geen probleem mogen hebben. Als je php die dataset neemt, en die gewoon doorstuurt, dan kan je het als het ware op een atom *kuch*server*kuch* draaien.

Ik raad je aan te testen. Neem je applicatie, genereer een representabele dataset, gooi die neer op een systeem die je ietwat kent, en gooi er maar eens een benchmarking suite tegenaan. Ga op zoek naar wat je applicatie traag maakt, en tune/rewrite dat. Eens dat gedaan is, kan je normaal vrij goed inschatten wat qua machine ongeveer nodig is.

Een SAN in per definitie niet "voldoende snel"; databases hou ik graag de storage zo dicht mogelijk bij m'n CPUs, op zo snel mogelijke disks.

Bedankt voor je reactie. Het gaat hier over het algemeen om verschillende queries. Maar geen hele zware queries. Wel zal de database vermoedelijk over enkele miljoenen records gaan beschikken. Maar dat mag volgens mij niet echt het probleem zijn.

Ik zal het eens gaan benchmarken in ieder geval.

Jij raadt aan dus om interne schijven te gebruiken voor de database server?

Is het dan verstandig voor scsi of sas te gaan? Of raad je SSD's aan. (Ik begreep namelijk dat SSD's, niet zo geschikt waren voor databases ivm de vele read/write acties.

[Trans-IX B.V.]

De tegenwoordige SSD disks met technieken als wear leveling e.d. kunnen dat volgens de specificaties aan, maar zijn ook wel een stuk duurder.
Goede SAS disks in een RAID setup kunnen dit wel aan voor de database server.

Met veel bezoekers kun je misschien starten met 2 web frontend servers en 1 database server.
Zo kun je de load van de PHP applicatie verdelen, omdat PHP wel een aanslag kan zijn op de processoren.
Een load balancer kan, er zijn goede hardware load balancers die redelijk betaalbaar zijn, maar als je bijvoorbeeld Windows 2008 Web neemt voor je website zit naar Network Load Balancing in waar ik persoonlijk goede ervaringen mee heb. Linux kan ook prima met de standaard load balancing mogelijkheden.

[baseh]

De tegenwoordige SSD disks met technieken als wear leveling e.d. kunnen dat volgens de specificaties aan, maar zijn ook wel een stuk duurder.
Goede SAS disks in een RAID setup kunnen dit wel aan voor de database server.

Met veel bezoekers kun je misschien starten met 2 web frontend servers en 1 database server.
Zo kun je de load van de PHP applicatie verdelen, omdat PHP wel een aanslag kan zijn op de processoren.
Een load balancer kan, er zijn goede hardware load balancers die redelijk betaalbaar zijn, maar als je bijvoorbeeld Windows 2008 Web neemt voor je website zit naar Network Load Balancing in waar ik persoonlijk goede ervaringen mee heb. Linux kan ook prima met de standaard load balancing mogelijkheden.

Ook jij hartstikke bedankt voor je antwoord.

Stel dat ik ga loadbalancen aan de hand van een linux of windows bak. Ik neem aan dat ik 1 losse server als loadbalancer nodig hebt die de request dan weer verdeeld over de 2 webservers?

En is een linux of windows loadbalancer (veel?) minder goed dan een hardware matige oplossing voor dit formaat?

[vDong]

Ook jij hartstikke bedankt voor je antwoord.

Stel dat ik ga loadbalancen aan de hand van een linux of windows bak. Ik neem aan dat ik 1 losse server als loadbalancer nodig hebt die de request dan weer verdeeld over de 2 webservers?

En is een linux of windows loadbalancer (veel?) minder goed dan een hardware matige oplossing voor dit formaat?

Load balancing voor zo "weinig" kan al met 2 kleine linux machines ervoor. Ik zou als ik voor redundancy ga niet een extra SPOF maken door 1 load balancer te nemen.

Hardware loadbalancers zijn in verhouding veel te duur, omdat die berekend zijn op veel meer of veel grotere websites.

Ik heb erg slechte ervaring met de load balancing onder windows en ik zou ook zeker niet willen aanraden om je php frontend op windows te draaien voor alleen de load balancing functionaliteit.

[wonko]

Zet een eenvoudige haproxy op beide web-machines, en je bent al een eind ver. SSD's zal overdreven zijn, zorg gewoon dat je queries slim opgebouwd zijn en dat de goede indexen aanwezig zijn.

Opnieuw: benchmark, benchmark, benchmark (met REALISTISCHE data en load, je spreekt over miljoenen records, laad dan ook gewoon miljoenen records in je test-db bij het stress-testen, met goede data (niet allemaal gelijk)).

[vDong]

Opnieuw: benchmark, benchmark, benchmark (met REALISTISCHE data en load, je spreekt over miljoenen records, laad dan ook gewoon miljoenen records in je test-db bij het stress-testen, met goede data (niet allemaal gelijk)).

Als je dat zo doet dan zeker ook: indexen! indexen! indexen!

Goede queries is hele malen belangrijker dan je infra, tegen slecht opgebouwde databases en queries valt niet aan te schalen.

[Trans-IX B.V.]

Zelf heb ik wel goede ervaringen met Windows load balancing en dit doe je op de web frontend servers zelf dus je hebt geen extra hardware nodig.

Losse load balancers maakt het gelijk al weer een vrij grote omgeving omdat met 1 load balancer je een SPOF introduceer zoals vDong ook aangeeft.

[Yourwebhoster]

Zet een eenvoudige haproxy op beide web-machines, en je bent al een eind ver.

HAproxy kan je doen, maar mij lijkt het handiger om direct voor LVS (Linux Virtual Server project, http://www.linuxvirtualserver.org/) te gaan, omdat je hierbij gelijk doorgestuurd word naar de webserver en de webserver de gegevens direct naar de bezoeker stuurt ipv eerst naar de proxy server en dan pas naar de bezoeker.

Verder moet je met de database servers niet met SAN's willen werken, hoe klein deze factor ook is, het vertraagd. Als je snelle SAS disks hebt in mirror en een hot-spare in het geval er eentje uitvalt, dan kom je al heel ver.
Als het budget toelaat zou je kunnen gaan voor SSD's met SLC geheugen (dit zijn de duurdere disks). Vooral op het gebied van reactie snelheid, IOPS en stroomverbruik is dit niet te vergelijken met SAS schijven. Maar als de server onder de berekende hoeveelheid bezoekers zich normaal gedraagt en voldoende ruimte bied om meer aan te kunnen, dan zou ik bij SAS disks blijven.

Overigens is optimalisatie van de database server ook belangrijk naast de queries. Als je dit niet voldoende optimaliseert kan je alsnog te maken hebben met performance problemen. Daarnaast is het aan te raden om voldoende RAM in de server te stoppen, hoeveel voldoende is hangt van de omvang van je database af.

Zelf heb ik wel goede ervaringen met Windows load balancing en dit doe je op de web frontend servers zelf dus je hebt geen extra hardware nodig.

Losse load balancers maakt het gelijk al weer een vrij grote omgeving omdat met 1 load balancer je een SPOF introduceer zoals vDong ook aangeeft.

Als je meerdere webservers hebt dan kan je daar de load balancers op zetten. Als een load balancer uitvalt, dan heb je nog een andere load balancer die de taken kan overnemen. Natuurlijk kan je dit ook op meerdere servers doen.

[baseh]

Nu ben ik zelf benieuwd. Als je op beide servers ook een loadbalancing server zet. Hoe gaat het dan in zijn werk? Je kan een domeinnaam namelijk maar aan 1 ip koppelen toch? Dan pakt hij standaard altijd de eerste server als ik het goed begrijp?

Stel dat de eerste server dan down gaat, verliest hij ook de verbinding. Ik weet dat je met heartbeatje server kan monitoren en mocht de 1e server crashen dat hij ip omschakeld.

Echter ben ik benieuwd of daar een betere oplossing is.

Want beste is dus 2 webservers welke ieder ook al loadbalancer kan dienen? Hoe zorg je ervoor dat de 2e dus als fallback functioneerd wanneer er 1 down gaat.

[systemdeveloper]

Het lijkt bijna offtopic maar... als je gegevens maar 1 keer worden ingelezen en de rest readqueries zijn... waarom cache je het dan niet statisch? Blijft nog altijd het snelste.

Domein koppel je aan 1 ip (als je geen dns roundrobin gebruikt), maar je loadbalancer koppelt dat ip weer aan een 2de,3de... ip van je servers. Als een server down gaat dan stuurt de lb hem gewoon niet meer daar naar dat ipadres.

[baseh]

Het lijkt bijna offtopic maar... als je gegevens maar 1 keer worden ingelezen en de rest readqueries zijn... waarom cache je het dan niet statisch? Blijft nog altijd het snelste.

Domein koppel je aan 1 ip (als je geen dns roundrobin gebruikt), maar je loadbalancer koppelt dat ip weer aan een 2de,3de... ip van je servers. Als een server down gaat dan stuurt de lb hem gewoon niet meer daar naar dat ipadres.

Dit is mij inderdaad bekend. Maar wat als de 1e loadbalancer down gaat. Hoe zorg ik er dan voor dat de andere het automatische overneemt? Of zal ik dan toch iets als heartbeat moeten gebruiken?

Het gaat niet alleen om reads. Gaat om zowel veel reads als writes.

[systemdeveloper]

Dit is mij inderdaad bekend. Maar wat als de 1e loadbalancer down gaat. Hoe zorg ik er dan voor dat de andere het automatische overneemt? Of zal ik dan toch iets als heartbeat moeten gebruiken?

Het gaat niet alleen om reads. Gaat om zowel veel reads als writes.

Jammer, dan gaat het verhaal niet (helemaal) op. Vaak is 10 seconden cachen al erg zinvol bij 1500 pv's/sec, terwijl je toch een redelijk 'live' beeld presenteert.

Anyway, wat die lb betreft, hier staat een tekeningetje, al is de info als iets ouder. Pics zijn vaak wat duidelijker http://grumplicio.us/fbsd_lb.html

[wonko]

als je twee LBs hebt, ga je idd iets als keepalived of heartbeat of aanverwanten moeten hebben.

Maar begin maar eerst eens met je applicatie op een enkele eenvoudige machine te zetten, en zorg daar dat je een flink aantal pages per seconde kan serven. Loadbalancers en redundancy gaan je applicatie niet sneller maken... Indexen, optimalisatie, caching,... heel de boel.