High availability en high-performace LAMP oplossing

[Skaah]

Voor het bedrijf waar ik werk zijn we op zoek naar een nieuw webservercluster. We hosten zo'n 80 - 100 domeinen, varierend van simpele CMS'en tot ingewikkelde applicaties. Al deze websites zijn PHP met MySQL en leunen zwaar op hun database. De huidige oplossing, met een aantal losse webservers voldoet niet qua performance, availability en beheermogelijkheden.

We zijn daarom op zoek naar een nieuwe webserver oplossing. We zaten te denken aan een combinatie van loadbalancers, webservers en database- annex fileservers. De opzet zou ongeveer iets als volgt moeten worden:

Een dikke server bevat alle databases en bestanden voor alle domeinen. Deze is redundant uitgevoerd. Door middel van NFS hebben webservers toegang tot alle bestanden en handelen ze alle verzoeken af. De webservers hebben dus geen eigen data en config, alles gaat via NFS (config, websites, uploads, alles).

code:

[loadbalancer] <--> [loadbalancer]
     |
[webserver][webserver][...]
     |
[fileserver/mysqlserver] <--> [fileserver/mysqlserver]

Het voordeel van deze oplossing is dat het transparant is voor alle websites. Het is niet nodig om websites aan te passen, omdat alle storage toch op een plek blijft. Het is eenvoudig om meer rekenkracht aan de webserverpool toe te voegen. Door middel van rsync en MySQL-replicatie kunnen de fileservers in sync blijven.

Voor de webservers zaten we te denken aan een aantal Dell PE 850's, voor de database/fileservers aan twee nieuwe PE 1950 met RAID 5 over 4 SAS schijven. Dit in verband met de grote verwachtte I/O.

Is dit een wijze setup? Zijn er valkuilen waar we op moeten letten?

[bakkerl]

Hoe ga je zorgen dat als er een fileserver/mysqlserver uitvalt dat de anders het gaat overnemen?
Dit is een van de problemen die je gaat tegen komen.

Tevens kun je verlies van data hebben indien een fileserver die uitvalt. Dit dan ter maximaal de interval van rsync job.

Tevens verwacht je dat de fileserver/mysql databases het het zwaarst zullen krijgen (aantal IO). Het zal dan eerder in de verwachting liggen dat je niet de webservers moet gaan uitbreiden maar de fileserver/mysql omgeving. In deze setup kan dit niet.

Even zo mijn snelle gedachten erover..

[moto-moi]

Skaah schreef op vrijdag 15 december 2006 @ 12:39:
Een dikke server bevat alle databases en bestanden voor alle domeinen. Deze is redundant uitgevoerd. Door middel van NFS hebben webservers toegang tot alle bestanden en handelen ze alle verzoeken af. De webservers hebben dus geen eigen data en config, alles gaat via NFS (config, websites, uploads, alles).

Zodra je fileserver wegvalt zal -alles- plat gaan, en de load op je webservers door het dak heenvliegen, je zult i.i.g. je errorcode lokaal moeten hebben zodat je een toffe foutmelding kunt geven zodra je nfs-server down is.

Door middel van rsync en MySQL-replicatie kunnen de fileservers in sync blijven.

Voor fileserver replicatie lijkt het me niet handig om op rsync te vertrouwen, dat moet je tenslotte met de hand aanroepen of in een cronjob waarvan de granulariteit niet echt helemaal is wat je wilt.

Je zou beter naar iets als drb kunnen kijken.

voor de database/fileservers aan twee nieuwe PE 1950 met RAID 5 over 4 SAS schijven. Dit in verband met de grote verwachtte I/O.
Is dit een wijze setup? Zijn er valkuilen waar we op moeten letten?

Ik zou in ieder geval even plan: Forum in verwachting van nieuwe database-server en reviews: Databasetest: Apollo 5 goed doorlezen voor die PE 1950's die je wil kopen

Verder weet ik niet hoe de actuele stand van mysql replicatie is, het laatste waar ik me in verdiept heb is het in-memory systeem van ze, en dat wil je echt niet op een beetje dynamische site.

[bakkerl]

moto-moi schreef op vrijdag 15 december 2006 @ 13:12:
Verder weet ik niet hoe de actuele stand van mysql replicatie is, het laatste waar ik me in verdiept heb is het in-memory systeem van ze, en dat wil je echt niet op een beetje dynamische site.

Dat is als je HA mysql wil hebben. Voor alleen replicatie kun je de standaard mysql database types gebruiken.

Dat in-memory wil je in veel gevallen niet. Het doet geen referenties ondersteunen (voordeel InnoDB) en ook geen Full-Text-Search velden (voordeel MyISAM).

[Skaah]

moto-moi schreef op vrijdag 15 december 2006 @ 13:12:
[...]

Zodra je fileserver wegvalt zal -alles- plat gaan, en de load op je webservers door het dak heenvliegen, je zult i.i.g. je errorcode lokaal moeten hebben zodat je een toffe foutmelding kunt geven zodra je nfs-server down is.

[...]

Voor fileserver replicatie lijkt het me niet handig om op rsync te vertrouwen, dat moet je tenslotte met de hand aanroepen of in een cronjob waarvan de granulariteit niet echt helemaal is wat je wilt.

Je zou beter naar iets als drb kunnen kijken.

Dit zijn goede tips, dank je. Wat bedoel je precies met DRB? Het enige wat ik kan vinden is Distributed Ruby, maar dat is niet wat je bedoelt.

[zeroxcool]

Skaah schreef op zondag 17 december 2006 @ 12:05:
[...]

Dit zijn goede tips, dank je. Wat bedoel je precies met DRB? Het enige wat ik kan vinden is Distributed Ruby, maar dat is niet wat je bedoelt.

Kijk hier eens:
http://www.drbd.org/

[Guru Evi]

Ik zou in ieder geval de laatste versie van MySQL gebruiken en 2 of MEER database servers in een failover (niet load-balancing) situatie. Gebruik een lokaal storage array voor je databases (RAID5).

Dan kun je x-aantal Apache servers in loadbalancing/failover zetten met een proxy of loadbalancer ervoor ook redundant uitgevoerd. Lokale configuratie en boot-systeem die gesynchroniseerd wordt via rsync vanaf een 'master'.

Voor je klanten kun je dan een NFS-systeem of FibreChannel of iets gelijkaardigs gebruiken. Maak wel dat je een redundant array hebt (RAID 5 + 1) of een snelle D2D2T oplossing, zeker als je een degelijk webhoster bent.

En denk eraan: Two is company, three is an orgy.