Joomla traag binnen Windows 2008 cluster

[Verwijderd]

Wij maken gebruik van een geclusterde Windows (2008) shared omgeving. Binnen deze geclusterde shared omgeving ervaren wij en onze klanten problemen (lees vertragingen) met pakketten als Joomla en Wordpres. We weten dat het probleem hem zit binnen het geclusterde netwerk. Dit n.a.v. een test die wij hebben uitgevoerd met één van onze Joomla klanten.

De Joomla website van die betreffende klant hadden wij tijdelijk lokaal op een van de nodes (servers) binnen het netwerk gezet. Normaliter staan de websites op een storage/data server. Lokaal op de node draaide de betreffende website letterlijk 2 keer zo snel. Hieruit kunnen we dus concluderen dat het probleem hem waarschijnlijk zit binnen de verbinding tussen de nodes en de storage server.

Wij zijn uiteraard bekend met het feit dat Joomla bestaat uit letterlijk duizenden kleine bestandjes. Ook hier ligt uiteraard een deel van het probleem waar wij echter, voor zover wij weten, aan server kant niks kunnen doen.

Wij lopen helaas een beetje stuk op dit probleem. Een oplossing zou kunnen zijn om de betreffende klanten met hun website op een stand-alone/dedicated server te zetten. Hiermee slaan wij echter de plank mis aangezien we juist meer kwaliteit en betrouwbaarheid willen bieden met een cluster. Daarnaast is dit uiteraard zonde van de investering die wij qua tijd en geld in het cluster hebben gestoken.

Zijn er mensen die hier ervaring mee hebben? Wellicht dat iemand dit zelfde probleem ook een keer heeft gehad. Zit de oplossing hem in de software, wij denken hierbij aan een plugin… of moeten we bijvoorbeeld investeren in een andere storage omgeving?

De storage omgeving is normaliter ook verdeeld over 2 servers. Momenteel draait deze echter op 1 storage server. Alle web nodes zijn uitgerust met de Windows 2008 web editie en zijn verbonden via een gigabit verbinding naar de storage server welke is uitgerust met de Windows server 2008 standaard editie. De storage server bestaat uit meerdere Western Digital SATA2 raid edition schijven. De raid kaart is een Adaptec 5405 256MB cache. Verder heeft de server 8 GB intern geheugen ( 1333 mhz), een intel xeon e5502 en draaien de schijven hardware raid 5.

ps. Andere sites die niet gebouwd in bijvoorbeeld Joomla of Wordpress en dus niet zijn opgebouwd uit duizenden bestanden, draaien en laden wel snel.

[Rolfie]

Je hebt dus een cluster van webservers neer gezet? of niet? Of heb je gewoon een webserver farm draaien?

Maar al je data staat op 1 server? Dus als je storage server uitvalt, dan vallen eingelijk al je webservers uit? Dus nog steeds een SPOF . Dus waarom dan een cluster webserver farm neer zetten

En tja, kleine files over het netwerk trekken is niet het meest efficiente wat je kunt doen.
Toevallig is je "storage" server ook niet de domain controller van het netwerk?
Daarbij RAID5 is nu net niet de snelte raid technologie die je kunt gebruiken.

[ Voor 7% gewijzigd door Rolfie op 05-01-2011 17:06 ]

[alt-92]

Nog steeds dezelfde opbouw als \[2008] Shares soms onbereikbaar ?

[Meekoh]

Gebruik je network teaming software? Zo ja hoe staat die ingesteld?
Gebruik je IPv6? Zo nee disable het dan VOLLEDIG(is nog een of andere registry key voor).klik
TCP Offloading kan ook nog weleens lastig doen, staat dit aan op je netwerk kaart(en)?

edit: @Rolfie
Het is een Storage server cluster, geen SPOF
Hij heeft dus meerdere webservers die voor hun storage naar een windows file server cluster gaan.

[ Voor 25% gewijzigd door Meekoh op 05-01-2011 18:16 ]

[Verwijderd]

@alt-92: ja, de setup is nog hetzelfde.
DFS wordt nog niet gebruikt, omdat dit de performance nog erger maakt.

@Rolfie: Het is inderdaad momenteel een SPOF, maar dat is het probleem nu niet.
We hebben een 2e storage server staan, deze draait een exacte kopie van alle sites.
We willen nu eerst de focus leggen op de snelheid.
En ja, hij is ook DC voor het interne domein.

@Meekoh: Network teaming wordt niet gebruikt, Offloading is ook disabled.
Zodra ik IPV6 uitschakel kom ik niet meer bij de share.

[Zwelgje]

filesharing op een een DC... ieuw writecache op de disk waar je ntds staat (in sommige gevallen hetzelfde volume als waar de overige files ook op staan... hallo 'beheerder' ) staat dan default uit en hij doet aan SMB signing wat de boel nog trager maakt..

kortom: gebruik een dedicated fileserver en geen DC voor filesharing taken

[_Arthur]

Powershell schreef op woensdag 05 januari 2011 @ 19:28:
kortom: gebruik een dedicated fileserver en geen DC voor filesharing taken

Goh. Was dat het antwoord in z'n vorige topic ook al niet

[Zwelgje]

raid5 is zoals gezegd geen 'toppertje' voor dit soort zaken, je hebt wel 256mb cache maar heb je er ook een BBWC opzitten anders heb je namelijk alleen maar 'read cache' een geen write cache.. en laat dat laatste nu erg belangrijk zijn in een raid5 setup waarbij de writes gewoon erg traaaaaag zijn

[MoBi]

Probeer eens deze module http://www.iis.net/download/WinCacheForPHP te installeren op je iis servers. Daarvan gaat de verwerking van php vele malen sneller in combinatie met FASTCGI

[Rolfie]

Het is een Storage server cluster, geen SPOF

Wat versta jij onder een cluster? Is het een Failover Clustering of een NLB cluster? Dit maat namelijk een heeel hoop uit. En is nog al zeer belangrijk om te melden in je TS.

Ik je vorige topic lees ik iets over NLB? Is dit nog actief?

Daarbij zoals al eerder gemeld, Gebruik geen domain controller voor file shareing, zeker niet met kleine klote files.

Probeer het eerst eens met een gewone file server. Das de eerste die ik eens zou proberen om je problemen te troubleshooten.

[Verwijderd]

Zo te zien is de hoofdgedachte dat we de DC van de fileserver af moeten halen...

Dan zullen we binnenkort de DC op een andere server plaatsen en daarna deïnstalleren van de fileserver.
We hebben niet zo heel veel ervaring met DC, ik had niet gedacht dat dit zo heel belastend is voor de server en dan met name de file-reads en writes, maar blijkbaar heb ik me daar aardig in vergist.

We gaan dit op korte termijn uitproberen, mocht iemand nog andere suggesties hebben dan horen we dat uiteraard heel graag!

writecache zet ik liever niet aan.
Snelheid is belangrijk, maar we kunnen het (kleine) risico op dataverlies bij stroomuitval niet riskeren...

[Zwelgje]

Verwijderd schreef op donderdag 06 januari 2011 @ 09:30:
Zo te zien is de hoofdgedachte dat we de DC van de fileserver af moeten halen...

Dan zullen we binnenkort de DC op een andere server plaatsen en daarna deïnstalleren van de fileserver.
We hebben niet zo heel veel ervaring met DC, ik had niet gedacht dat dit zo heel belastend is voor de server en dan met name de file-reads en writes, maar blijkbaar heb ik me daar aardig in vergist.

We gaan dit op korte termijn uitproberen, mocht iemand nog andere suggesties hebben dan horen we dat uiteraard heel graag!

writecache zet ik liever niet aan.
Snelheid is belangrijk, maar we kunnen het (kleine) risico op dataverlies bij stroomuitval niet riskeren...

voor writecache heb je juist die BBWC module op je raid kaart, bij stroomuitval ben je niks kwijt

EDIT: dit zijn de batterijen die je moet hebben http://www.adaptec.com/nr.../0/4520_battery_lc_17.pdf

[ Voor 7% gewijzigd door Zwelgje op 06-01-2011 10:06 ]

[raymondw]

Zoveel keuzes zoveel opties, jammer om dit te testen op een live klanten omgeving...

Maar zoals veel al aangeven zijn er een aantal dingen waar je rekening mee moet houden
- DC niet op je FS
- Writecache aan als je een BBU/BBWC hebt
- Controleer je SATA disken op de "advanced formatting", dat wil nog wel eens mis-allignen icm RAID
- TOE aan
- Teaming uit (kan aan als je weet wat je doet...)
- IP v4 gebruiken en 6 uitzetten (weinig die het nu nog nodig hebben op een interne LAN)
- zorgen dat het geen multi gateway env is
- ben een fan van gescheiden SAN structuur, 1 switch "intern" SAN verkeer, 1 extern "LAN" verkeer
- check firewall rules (wederom SAN/LAN indeling)
- doe eens een speedtest op je share, met een 1Gb lijn is 60/80MB/s normaal (ik red in een goeie omgeving 130/160MB/s, multipath Gb)

Genoeg om even mee bezig te zijn en zeker wat performance uit te halen.
Het is iig allemaal redelijk standaard en vrij easy als je de fundering goed hebt

[Verwijderd]

Ik hoor een hoop mensen over writecache...
Echter heeft dit toch alleen invloed op het schrijven naar de schijf?

Wij hebben hier juist last van het lezen van veel bestandjes tegelijk.

Zou writecache hier dan ook performance winst kunnen opleveren?

[raymondw]

Dat zou idd wel kunnen, Windows wil nog wel eens wat locken etc...
Maar het gaat om het hele plaatje van disk tot netwerk, kans is groot dat er hier en daar verbeteringen kan doen die de algehele snelheid omhoog halen.

Je kan je nu richten op 1 punt en straks de 5 anderen doen, maar waarom dan nu niet in 1x alles?

[Question Mark]

Verwijderd schreef op woensdag 05 januari 2011 @ 16:57:
De Joomla website van die betreffende klant hadden wij tijdelijk lokaal op een van de nodes (servers) binnen het netwerk gezet. Normaliter staan de websites op een storage/data server. Lokaal op de node draaide de betreffende website letterlijk 2 keer zo snel. Hieruit kunnen we dus concluderen dat het probleem hem waarschijnlijk zit binnen de verbinding tussen de nodes en de storage server.

Leuke test, maar waarom meet je niet gewoon even de disk queue lengths (read én write) van je disken. Dan weet je in één klap of je een bottleneck hebt op je disksubsystem of ergens anders.

Perfmon is your friend...