Website voorbereiden op multiserver environment.

[kramer65]

Hallo,

Aan het werk aan een nieuwe site kwam ik tot een vraagstuk. Ik wil de site zo maken zodat als hij inderdaad de groei gaat doormaken die wij willen, hij ook voorbereid is voor een cluster van servers met een reverse-proxy ervoor.

Nou ben ik er inmiddels achter dat je een probleem krijgt met sessies op verschillende servers. Als je de sessies nou opslaat in de DB (zoals hier) kan straks makkelijker naar een multiserver environment toe gegaan worden.

Zijn er nog meer dingen die jullie weten waar je aan moet denken terwijl je de site programmeert?

[Kettrick]

Sessie info los je inderdaad op door het in een DB te zetten, of door bijv. een gezamelijke NFS mount aan te maken. Voor eventuele file uploads geldt natuurlijk hetzelfde, deze zal je ook in je db moeten zetten, of via NFS moeten delen.

[kramer65]

Ah! Dat is handige info! Dus een upload moet ook onmiddellijk in de DB gezet worden?

Zijn er nog meer dingen waar ik aan moet denken?

[Kettrick]

kramer65 schreef op dinsdag 18 maart 2008 @ 15:48:
Ah! Dat is handige info! Dus een upload moet ook onmiddellijk in de DB gezet worden?

Is wel logisch he, als de upload of server1 staat, en de volgende request komt op server2 voor dag plaatje ?

Zijn er nog meer dingen waar ik aan moet denken?

versiebeheer voor je webapp, php , os etc. om te voorkomen dat je onvoorspelbaar gedrag krijgt op een bepaalde server

[Rob]

Denk er wel aan dat bij een grote hoeveelheid bezoekers tegelijkertijd voor elke bezoeker een DB request gedaan moet worden, dat kan nog wel eens zwaar worden.
Maak een tabel aan in het geheugen of gebruik memcached (let wel op dat je bij een servercrash alles uit het geheugen kwijt ben, dus stop geen informatie in de sessies die bewaard moeten blijven).

NFS is ook niet al te snel, dus een lokale cache van de NFS map doet ook wonderen.

[Kettrick]

Lokaal cachen is nou juist iets wat je niet wil, dan bestaat de kans dat je sessies uit sync. raken

[Rob]

Je moet de sessies ook niet lokaal cachen, maar de files wel zoveel mogelijk.

[kramer65]

RoeLz schreef op dinsdag 18 maart 2008 @ 15:54:
Is wel logisch he, als de upload of server1 staat, en de volgende request komt op server2 voor dag plaatje ?

Dat klopt. maar wat nou als je bijvoorbeeld een storage server hebt en een database server. Dan word toch alles van die storage server gehaald en is die upload er dus wel meteen en overal. Het probleem komt er inderdaad wanneer je meerdere storage servers gaat krijgen. Moet je die dan automatisch laten spiegelen ofzo? Hoe gaat dat dan?

versiebeheer voor je webapp, php , os etc. om te voorkomen dat je onvoorspelbaar gedrag krijgt op een bepaalde server

Versiebeheer. Bedoel je dan dat alles hetzelfde is, of dat alles onmiddelijk geupdate moet zijn naar de laatste versie?

[Kettrick]

Als het dedicated servers zijn voor een site zet je je webcontent toch gewoon op de servers neer?
nfs is alleen voor sessie en uploads, de laatste kan je uiteraard wel cachen.

[Rob]

RoeLz schreef op dinsdag 18 maart 2008 @ 16:00:
Als het dedicated servers zijn voor een site zet je je webcontent toch gewoon op de servers neer?
nfs is alleen voor sessie en uploads, de laatste kan je uiteraard wel cachen.

En dan op elke server apart de webcontent uploaden bij een aanpassing. Lijkt mij niet handig.
De webcontent mag wel op een centrale storage, maar zorg ervoor dat niet elke aanvraag bij de centrale storage terecht komt.

[Kettrick]

kramer65 schreef op dinsdag 18 maart 2008 @ 15:59:
[...]

Dat klopt. maar wat nou als je bijvoorbeeld een storage server hebt en een database server. Dan word toch alles van die storage server gehaald en is die upload er dus wel meteen en overal. Het probleem komt er inderdaad wanneer je meerdere storage servers gaat krijgen. Moet je die dan automatisch laten spiegelen ofzo? Hoe gaat dat dan?

Als je een storage server hebt dan is het klaar, zolang je het maar niet lokaal op we webdoos neer zet. Het mirroren van die content is meer een beheer ding, daar zou ik me als ontwikkelaar niet te druk om maken ( en niet aan beginnen, is een vak apart )

[...]

Versiebeheer. Bedoel je dan dat alles hetzelfde is, of dat alles onmiddelijk geupdate moet zijn naar de laatste versie?

Dat alles het zelfde is, dan sluit je eventuele problemen door bijv. een php versie met een bug uit.

Rob schreef op dinsdag 18 maart 2008 @ 16:02:
[...]


En dan op elke server apart de webcontent uploaden bij een aanpassing. Lijkt mij niet handig.
De webcontent mag wel op een centrale storage, maar zorg ervoor dat niet elke aanvraag bij de centrale storage terecht komt.

Het hangt van je applicatie af, als je wekelijks een release doet bijvoorbeeld zou dat wat mij betreft geen probleem zijn. Je kan het ook meteen vanuit je versiebeheer naar meerdere servers pushen.

dan heb je het onder controle, met caching is het altijd maar de vraag welke versie nou echt gebruikt wordt

[ Voor 25% gewijzigd door Kettrick op 18-03-2008 16:04 ]

[kramer65]

Ok. Dus om het even in 1 bericht te krijgen. In de code van de website moet je dus uploads en sessies in de database opslaan zoals hier beschreven.


Als je dan eenmaal inderdaad die multiserver structuur met meerdere storage servers/database servers krijgt, dan moet je die spiegelen zoals bijvoorbeeld hier, en je moet aan versiebheer doen.

Deze laatste zijn echter voornamelijk beheer dingen en ik moet er nu alleen maar voor zorgen dat in de code van de site de uploads en de sessies in de database gedaan moeten worden. Niet meer toch?

Heeft er iemand nog een link waar het hebben van uploads in de database nog duidelijk wordt uitgelegd met eventuele haken en ogen?

[CubicQ]

Je kan naast het opslaan van je sessie in een database (wat echt niet lekker is voor je performance... en je moet al je objecten in de sessie serializeerbaar maken) ook denken aan het gebruik maken van een loadbalancer die session affinity aankan (sticky sessions).

[kramer65]

Dus ik kan kiezen om of mijn sessies in de DB op te slaan, of dat niet te doen en straks gewoon een server met session affinity te gebruiken. Waarom zou ik voor de een of de ander gaan? Wat zou het voordeel van de een over de ander zijn?

Voordeel van session affinity is natuurlijk dat ik er nu dan niets aan hoef te doen (toch) en je zegt ook dat het sneller is dan de boel in de DB op te slaan?

[djluc]

Wellicht leuk om eens door te lezen, zitten best inhoudelijk interessante discussies tussen: http://technologie.hyves.nl/ bijvoorbeeld in deze discussie: http://technologie.hyves....es_database_statistieken/