Onderwerp: Website clusteren over meerdere servers

Ik doe veel troubleshooting en installaties op enkele servers, echter tot zo ver heb ik nooit een loadbalanced omgeving opgezet, dus jullie tips, kennis en ervaring is meer dan welkom.

De opdrachtgever is zelf niet heel erg into techniek, maar doet wel alsof, dus de eisen zijn er, maar ze zijn niet geheel duidelijk of niet goed omschreven. Hier ga ik sowieso nog achteraan.

Hardware:
6x servers, allen 32GB geheugen waarvan er één 64GB heeft.

De klant heeft (op het moment) 1 website draaien, welke er meer kunnen worden in de toekomst. Vanwege de hoge bezoekersaantallen is een enkele server niet snel genoeg, waardoor de klant wilt clusteren/loadbalancen.

Klant wilt:
1x MySQL server
1x Video server
4x Webservers

Zoals je ziet is er geen fileserver of een server welke de loadbalancing regelt. Dat laatste is wel te regelen als dat echt een must is.

Hoe zouden jullie het in dit geval opzetten?

Ik dacht zelf aan:
MySQL server:
- MySQL Database
- Shared fileserver voor sessies en de PHP scripts

Webservers:
- Webserver, meer niet, web/PHP scripts mounten vanaf de MySQL server (Vraag: met welke protocol mount je de bestanden, NFS?)

Video:
- Bevat de video bestanden

En om het loadbalancing te regelen een 7e server regelen. Echter welk software/applicaties draai je hierop?

Je moet eerst goed kijken wat je echt nodig hebt en waarom die keuze van 4-1-1 zo gemaakt is.
Als je namelijk een beetje verstandig gebruikt maakt van php caching, eventueel varnish/offloading images/video's dan kun je al snel meer traffic uit een webserver trekken dan je uplink aankan. Het eerste dat in zo'n geval de bottleneck wordt is dan de database. Is die even traag dan zijn al je webserver dat ook.

Ook kan het handig zijn om de database te splitsen over meerdere servers (niet redundant, maar echt splitsen).

Wat je ook kunt doen is een vps cluster maken van alle 6 de servers. Daarop definieer je dan een loadbalancer (varnish), 2 mysql vpssen in master/master, 4 webservers, 2 storage servers(drbd) en een video server.
Dan heb je weliswaar 11 logisch servers, maar je kunt de benodigde resources hiervoor redelijk flexibel indelen zodat je betere redundantie hebt en gemakkelijker kunt uitbreiden.

Even snel mee gedacht:

4x Webserver -> DRBD met Quad Lan kaartjes er tussen? Met Round Robin aanspreken als loadbalancing geen optie is? Indien storing op 1 van de 4, IP erbij hangen op 1 van de andere, kan geautomatiseerd (zou ik niet doen), en IP uit DNS laten schieten. Maakt fysiek onderhoud snel mogelijk.

Shared file server zou ik niet doen (SPOF), sessie -> Mysql.

1x Mysql -> Deze 2x uitvoeren? Master/Master waarvan 50% wordt gebruikt door 1e 2 webservers, en de andere 50% door de andere 2 (config bestanden kunnen doormiddel van IP server kijken waar ze naar toe moeten connecten)

Ik zou 2 van de webservers in ieder geval gebruiken om virtuele servers op te maken, met op beide een load balancer en een web frontend. Voordeel is dat de load balancers in geval van uitval en/of onderhoud vanzelf alle verkeer omleid.
1 load balancer zou ik in ieder geval nooit doen.

Zonder centrale storage kan wel, als de site slim gebouwd is en alle dynamische data in mysql zit.

Op zich wil ik je best verder helpen (irc?) maar dan heb ik veel meer informatie nodig.

Mag ik vragen om hoeveel bezoekers het gaat? Ik vind ruim 200G aan geheugen voor 1 website erg veel.

Zoals hierboven al beschreven is, zou ik zelf een virtualisatie cluster maken, of gebruik gaan maken van een private cloud omgeving.

In deze omgeving minimaal 2x MySQL op basis van master-master. 2 of meerdere webservers. Inderdaad ook 2 caching servers op basis van varnish of squid als het niet anders kan. En natuurlijk nog één of meerdere video servers op basis van nginx.
Qua shared storage kun je denken aan een clustered filesystem als Ceph of OCFS.

Bij een master-master configuratie zou ik zelf ervoor zorgen dat er maar 1 master tegelijkertijd gebruik wordt, anders kun je rare dingen krijgen met betrekking tot duplicate keys enzo. Je kunt dit oplossen door 1 shared ip te gebruiken.

Persoonlijk zou ik gaan voor 2 loadbalancers (mag gevirtualiseerd op verschillende hosts), 2 MySQL servers en minimaal 2 (liever 4 webservers). Tot slot zou ik sterk overwegen om toch een centrale storage server neer te zetten of de plaatjes op een andere manier (rsync?) te distribueren over de verschillende servers. Op zich wil ik je best verder helpen, maar dan is meer informatie wel gewenst (irc?).

Hoe wij een shared omgeving opgezet hebben in een cluster staat wel op het forum, lees dat eventueel nog een keer door.

Je moet eerst goed kijken wat je echt nodig hebt en waarom die keuze van 4-1-1 zo gemaakt is.

De klant denkt dat de webservers de bottleneck zijn, misschien is dat ook zo, geen idee. Ik heb nog geen inzicht gekregen in de huidige setup.

Wat je ook kunt doen is een vps cluster maken van alle 6 de servers.

Dit is wel een leuk idee, maar er is bijvoorbeeld geen file/storage server. Wat het minder leuk maakt. Heeft virtualizatie geen overhead (vast wel, maar is die te overzien?)?

4x Webserver -> DRBD met Quad Lan kaartjes er tussen? Met Round Robin aanspreken als loadbalancing geen optie is? Indien storing op 1 van de 4, IP erbij hangen op 1 van de andere, kan geautomatiseerd (zou ik niet doen), en IP uit DNS laten schieten. Maakt fysiek onderhoud snel mogelijk.

Ook aan gedacht, maar waarom IP uit DNS laten schieten als je het IP toch laat overnemen. Om een server niet extra te belasten?

Ik zou 2 van de webservers in ieder geval gebruiken om virtuele servers op te maken, met op beide een load balancer en een web frontend. Voordeel is dat de load balancers in geval van uitval en/of onderhoud vanzelf alle verkeer omleid.

Wat raad je aan om als loadbalancer te gebruiken? Software dus.

Mag ik vragen om hoeveel bezoekers het gaat? Ik vind ruim 200G aan geheugen voor 1 website erg veel.

Ze zijn nog groeiende, 200GB is ook overkill, maar ze verwachten over een tijdje constant 8.000-10.000 bezoekers te hebben. Ik persoonlijk denk dat ze die aantallen nooit zullen halen, maar goed.

Bedankt voor alle reacties en tips. Maar ik zie weinig terug over hoe je het probleem wilt oplossen met php sessies, deze moeten toch ergens centraal staan lijkt mij.

Oorspronkelijk geplaatst door xaban

D
Wat raad je aan om als loadbalancer te gebruiken? Software dus.

HAproxy met wat zijtooltjes, of een van de concurrende pakketten, beetje afhankelijk van wat je precies gaat doen.

Ze zijn nog groeiende, 200GB is ook overkill, maar ze verwachten over een tijdje constant 8.000-10.000 bezoekers te hebben. Ik persoonlijk denk dat ze die aantallen nooit zullen halen, maar goed.

Bedankt voor alle reacties en tips. Maar ik zie weinig terug over hoe je het probleem wilt oplossen met php sessies, deze moeten toch ergens centraal staan lijkt mij.

Ik zou de sessies sticky maken naar 1 webserver en in geval van failover gewoon opnieuw laten inloggen.

10k concurrend users op één db server? Als je een gem. io patroon hebt met 25%w/75%r dan heb je ca. 2000-2500 schrijfacties op je db. Zelfs met ssd's kan dat nog zwaar worden, zeker als je ook nog de sessies in een db gaat gooien. Bij de eerste de beste dump (als bv. een tabel gelocked wordt) heb je kans dat je xxk qeuries in de queue hebt staan. Puur voor backupdoeleinden kun je er wellicht nog een snelle sql slave bij stoppen.

De overhead van een virtueel platform is niet iets waar je je zorgen over moet maken. Als dat wel zo zou zijn, dan heb je met de setup ook geen power genoeg over om backups te maken of om een index op je db aan te maken

Ik zou de sessies sticky maken naar 1 webserver en in geval van failover gewoon opnieuw laten inloggen.

Hoezo op die manier? Gewoon omdat je dat gewend bent of? Want de sessies shared lijkt mij juist ideaal?

Ik zou in 2 servers zorgen dat er een ssd aanwezig is en daar de sessies op zetten. Vervolgens kunnen de overige systemen die via NFS benaderen (of als alternatief voor ssd een ramdisk gebruiken).

Waarom op 2 servers? Als de eerste server uitvalt moet wel iedereen opnieuw inloggen, maar kun je verder automatisch verder draaien op server 2. Sessies in een database lijkt mij geen voordeel/geen handige optie. Tot slot zou ik niet zorgen dat een bepaalde bezoeker altijd bij een bepaalde webserver uitkomt, wel zou ik kijken wat er met cachen te doen is (cache = snel).

Virtualisatie maakt het makkelijk maar centrale storage is dan wel aan te raden, zeker omdat je daardoor wat meer mogelijkheden krijgt. Je wilt zoveel mogelijk spof's uit de weg gaan maar als je werkt met een budget kun je vaak niet anders. Je kunt sessies of in je database (al dan niet een cluster) opslaan of bijvoorbeeld via memcached. Een caching server voor nginx of Apache is zeker aan te raden maar je applicatie moet hier wel mee om kunnen gaan. Wij gebruiken Varnish, waar je overigens ook je load balancer mee kunt inregelen, maar andere pakketten werken ook natuurlijk. Varnish kun je ook laten draaien vanuit het geheugen als je wilt zodat je cache totaal geen effect heeft op je disks. Een opcode cacher op je web servers voor de hits die wel door komen kan ook nooit kwaad.

Zorg voor een backup scenario: stel de database server valt om. Zorg voor een failover scenario bijvoorbeeld door te redirecten naar een statische pagina. HaProxy kan dat voor je doen bijvoorbeeld maar je moet er wel iets voor inrichten en deze failover moet ook dezelfde aantallen bezoekers aan kunnen. Hou er rekening mee dat het restoren van de database even kan duren afhankelijk van het probleem, de benodigde redundantie wordt ook hier door bepaald. Als je klant geen hoger budget heeft dan heb je geen keus. Let ook op dat je SSL sessies niet zo snel zijn als je normale sessies. Mijn advies is om HaProxy voor SSL in tcp mode te draaien en de SSL af te vangen op de web servers. Geeft wat meer overhead bij het beheer: je moet SSL op alle servers configureren maar bij ons was de snelheidswinst zeker merkbaar. Als alternatief kun je stunnel + haproxy gebruiken. Net hoeveel SSL verkeer je hebt en of het een bottleneck is.

Plaats zoveel mogelijk statische content of op een CDN of op een server met bijvoorbeeld lighttpd zonder PHP en allemaal andere modules of zorg dat ze in je caching server belanden.

En hoe dan ook: zorg voor goede indexes op je tabellen! Misschien een open deur maar het wordt nog wel eens gemist. Een van onze klanten deed een load test en alles viel om met minder dan 1k concurrent bezoekers. Met de index draaide alles met gemak tot 10k concurrent bezoekers. Dat was een oplossing die lijkt op wat je nu beschrijft trouwens.

Oorspronkelijk geplaatst door xaban

Hoezo op die manier? Gewoon omdat je dat gewend bent of? Want de sessies shared lijkt mij juist ideaal?

Omdat ervaring mij geleerd heeft dat dat eenvoudiger is dan de al bestaande software (of software development methodes) aan te passen. Wellicht is dat iets te veel tegen dezelfde muur aan lopen geweest, wie weet.
In een ideale wereld waar beheer bij ontwerp en achitectuur betrokken is heb je inderdaad gelijk

En zorg voor een testomgeving. Als je een site draait op 7-8 servers dan wil je meestal niet live gaan ontwikkelen of even wat database aanpassingen doen

Hoe je het ook opbouwt, hoe rekening met de toekomst en de mogelijkheid om later makkelijk nodes te kunnen toevoegen. Het zou te zot zijn voor woorden om tijd en geld in de ontwikkeling van het cluster te steken om achteraf tot de conclusie te komen dat het niet makkelijk op te schalen is. Dus voorzie bvb al de mogelijk om met meerdere mysql servers te gaan werken zelf al begin je maar met 1 mysql server.