homedisk nfs performance

[elTigro]

Wij hebben hier in een voornamelijk Linux omgeving een centrale homedisk voor alle gebruikers.
Deze homedisk wordt geserveerd door een redelijk rap systeempje, maar top of the bill is het niet. (dual k8, 4 Gig , gigabit ethernet, dat soort werk)
Er staat in middels een vervanger voor klaar die weer wat nieuwere specs heeft, maar een earthsimulator is dit ook niet natuurlijk.

. Er hangen zo'n 200 clients aan, en via samba nog een stuk of 10 (jazeker ) windows computers. Een showmount geeft:

code:

root![server-~] # showmount | wc -l
225

Het probleem is alleen dat we de laatste tijd merken dat het ding het nfs serven niet meer zo goed aankan. Dit levert dus onwijs slechte respons op bij de clients. Af en toe duurt het openen van een shell gewoon een minuut. Nu is dit wel op slechte tijden - gewoonlijk is het systeem nog redelijk snel, maar echt fraai vind ik die tijden van traagheid niet. Het lijkt ook steeds vaker voor te komen.
Ik vermoed dat het vooral de disk IO is, want deze server is een backup omdat de vorige onlangs overleden is. De raid is dus een software mirror waar we normaal een nette hardware raid kaart gebruiken. De nieuwe server heeft ook weer zo'n kaart natuurlijk.

Ik ben alleen bang dat we over niet al te lange tijd weer tegen performance problemen aan gaan lopen (wij groeien als organisatie namelijk nog steeds), omdat alleen het vervangen van een server door een wat snellere nou niet het beste voorbeeld van schaalbaarheid is natuurlijk.
Ik ben dus eigenlijk benieuwd hoe anderen deze situatie hebben aangepakt, en ik wil mijn licht eens opsteken bij hun (leidende) voorbeelden.
Bij deze dus de oproep om eens wat voorbeelden van andere (groter dan soho) oplossingen te tonen.

[deadinspace]

Ik ben geen ervaring met NFS, zeker niet in dit soort settings, maar dat weerhoudt me niet van commentaar leveren

elTigro schreef op vrijdag 16 januari 2009 @ 12:12:
Ik vermoed dat het vooral de disk IO is

Nouja, prioriteit één is natuurlijk achterhalen wat de oorzaak is en waar de bottleneck ligt.

Is het zeker dat het NFS serven de traagheid veroorzaakt, of draaien er ook nog andere zaken op die machine?

Als het traag is, waar ligt dan de bottleneck? Wat is het CPU gebruik, geheugengebruik, netwerkgebruik, disk I/O?

De raid is dus een software mirror waar we normaal een nette hardware raid kaart gebruiken.

In mijn ervaring maakt dat niet zo gek veel uit qua snelheid, al hangt het natuurlijk van het type belasting af, je RAID level, de disk/bus topologie en dat soort dingen.

Ik ben alleen bang dat we over niet al te lange tijd weer tegen performance problemen aan gaan lopen (wij groeien als organisatie namelijk nog steeds), omdat alleen het vervangen van een server door een wat snellere nou niet het beste voorbeeld van schaalbaarheid is natuurlijk.
Ik ben dus eigenlijk benieuwd hoe anderen deze situatie hebben aangepakt, en ik wil mijn licht eens opsteken bij hun (leidende) voorbeelden.

Een manier om het beter te laten schalen is natuurlijk het over meerdere machines spreiden. Je zou dan kunnen denken aan een statische verdeling (users a-m op server 1, n-z op server 2), of wat dynamischer met bijvoorbeeld round-robin op DNS basis. In dat tweede geval moeten de servers wel onderling de data syncen (en mogelijk locken), maar het is wel netter en flexibeler ivm uitbreidingen, en geeft meteen een stukje fail-over.

Maar het is wel handig om te weten wat voor opties hiervoor standaard beschikbaar zijn (en dat weet ik niet), want zulk soort dingen zelf bouwen is vaak behoorlijk veel werk.

[gertvdijk]

Ik heb ook geen ervaring met NFS, maar voor het onderzoeken van de I/O bottleneck:
In geval van Debian:

aptitude install sysstat

waarna je iostat kan gebruiken om op alle schijven/volumes de I/O stats (await en %util zijn heel nuttig) te zien:

iostat -k -x -d 2

[ Voor 17% gewijzigd door gertvdijk op 17-01-2009 13:59 ]

[Rainmaker]

Of je laat top gewoon iedere minuut een bestandje wegschrijven.

Kun je ook mooi in zien of je "wa" (io wait) hebt.

code:

top -b -n 1 | head -n 20 > `date +%s`

[elTigro]

Tja, de bottleneck achterhalen zal nu niet meer lukken. Men heeft besloten het oude ding te vervangen door de nieuwe... We zullen helaas nooit meer weten wat het nu was op de oude server.
Ik heb me wel voorgenomen de huidige server wat beter te monitoren (via iostat ja).

Ik was zelf inderdaad wel nieuwsgierig naar specifieke multiserver installaties, en op welke manier mensen onderling alles in sync houden. Ik heb al wel wat fail-over systemen gezien, maar echt goed dynamische systemen ken ik helaas nog niet.
De statische verdeling zoals deadinspace suggereert had ik me ook bedacht, maar ik kan er niet echt enthousiast over worden. Maar het is altijd beter dan elke ochtend vastlopers.

Ik denk dat ik toch eens aan een soort SAN-achtige oplossing moet gaan denken en daaraan wellicht meerdere fileservers... Maar eigenlijk is dat een nog net een stapje te hoog voor mij/ons.

zo'n systeem heeft volgens mij een wat schaalbaarder opzet, of vergis ik me nu?