SCSI of SATA Windows 2003 Terminal Server

[appie1981]

Momenteel ben ik bezig met het inrichten van een Terminal server omgeving.
De huidige server is een Sun Sunfire X2100. De specificaties van de server zijn de volgende:

Processor: AMD Opteron 175
Geheugen: 4GB
Harde schijven: 2x 80GB SATA 7200RPM (mirror)
RAID Controller Nvidia Nforce4


Op de server zitten meestal zo'n 25 mensen te werken. De processor wordt nauwelijks belast en het geheugen wordt ook niet optimaal gebruikt (meestal zo'n 2.5GB). Toch loop ik tegen performane problemen aan. Vooral het browsen in mappen (zowel lokale als netwerk shares) gaat niet goed. Soms gaat het browsen goed maar de andere keer dan ben je bezig en dan hangt ineens de hele sessie.

Nu heb ik met mijn manager de discussie gehad over de hardware. Ik twijfel aan de geschiktheid van SATA schijven (met een niet al te goede raid controller). Hij zegt dat je op een terminal server weinig data verkeer hebt.

Op internet kan ik vrij weinig vinden over dit onderwerp. Zijn er mensen die meer weten over Terminal servers en de schijfbelasting?

[elevator]

Je disk systeem is in zoverre belangrijk dat er veel 'piek belasting' is op een standaard terminal server, dit heeft voornamelijk te maken met het client-side mappen van printers en de registry waarin dit gebeurt, dit probleem staat hier beschreven: Performance problem because of contention on CmpRegistryLock.

De kans dat je daar tegen aan loopt is niet zo heel groot met 25 users, maar het zou wel degelijk kunnen, in dat artikel staat geloof ik ook uitgelegd hoe je kan controleren dat je hier last van hebt dus begin daar anders eens mee?

[McMiGHtY]

Ele, je KB Article heeft het alleen over Windows 2000 (in diverse soorten) en niet over 2003. Persoonlijk zou ik zelf ook SCSI schijven adviseren.

[alt-92]

McMiGHtY schreef op vrijdag 14 september 2007 @ 16:25:
Ele, je KB Article heeft het alleen over Windows 2000 (in diverse soorten) en niet over 2003.

Verandert niks aan het principe hoor

Terminal Services is an "enabler" for this performance problem, because of the total size of the registry hives that are associated with all of the Terminal Services sessions that are in progress.
[...]
This performance problem may be caused by a slowdown that is caused by the number of input/outputs on the system disk during the registry-flush operation.

[ Voor 42% gewijzigd door alt-92 op 14-09-2007 16:32 ]

[appie1981]

Sorry ik was vergeten te melden dat het om een Windows 2003 Enterprise Terminal server is.
Ik moet er wel bij vermelden dat het om zo'n 25 active gebruikers zijn maar dat er ook nog wel eens tot 15 disconnected users zijn.

[elevator]

Klopt - voor zover ik weet geld dit nog steeds voor Windows 2003, als ik het goed heb is dit in Windows 2008 wel verholpen

[Zwelgje]

elevator schreef op vrijdag 14 september 2007 @ 19:42:
Klopt - voor zover ik weet geld dit nog steeds voor Windows 2003, als ik het goed heb is dit in Windows 2008 wel verholpen

het is in windows 2003 prima te verhelpen door gewoon snelle disken te nemen (15k) en, en dat is het belangrijkste.... een Battery Backed Cache Enabler... dat leverd je pas echt performance op

ide/sata op terminalserver...brrrr... pain, horror

[elevator]

Och, het is gewoon een design probleem dat een multi-user omgeving dusdanige contention heeft op de globale registry dat je voor de rest overbodige hardware er tegen aan moet smijten imho.

Een rustige en kleine TS heeft nergens 'dure' disken voor nodig, behalve voor 1 file

[Zwelgje]

ben ik met je eens elevator.

maar goed, zelfs in kleine terminalservers stop ik 15k disken. waarom? zodat niemand hier al te snel kan komen klagen over performance.

en ide en sata disken gebruik 'by design' al helmaal niet

[Microkid]

Alhoewel SATA schijven steeds sneller worden zijn SATA schijven imho (nog) niet geschikt voor enterprise toepassingen zoals Terminal Server farms. Daar zit je tenslotte met meerdere gebruikers op 1 server. In jouw geval 25, maar ik ken ook gevallen van 150 gebruikers per server. Die vechten met z'n allen om disk toegang. Daar wint SCSI het nog steeds, doordat het beter met command queing kan omgaan en een hogere rotatiesnelheid heeft. Daarbij komt dat SCSI drives een aparte processor hebben voor de dataafhandeling en een aparte processor voor het positioneren van de kop. SATA drives doen dat met 1 processor. Bij opvraag van veel data moet die ene processor dus beide taken uitvoeren waardoor de performance in gevaar kan komen.
Dus SATA is niet per definitie slecht, je zal alleen een goed overwogen keuze moeten maken. Ik zet nog altijd 15krpm SCSI schijven in Terminal Servers.

[appie1981]

Microkid schreef op zaterdag 15 september 2007 @ 10:20:
Alhoewel SATA schijven steeds sneller worden zijn SATA schijven imho (nog) niet geschikt voor enterprise toepassingen zoals Terminal Server farms. Daar zit je tenslotte met meerdere gebruikers op 1 server. In jouw geval 25, maar ik ken ook gevallen van 150 gebruikers per server. Die vechten met z'n allen om disk toegang. Daar wint SCSI het nog steeds, doordat het beter met command queing kan omgaan en een hogere rotatiesnelheid heeft. Daarbij komt dat SCSI drives een aparte processor hebben voor de dataafhandeling en een aparte processor voor het positioneren van de kop. SATA drives doen dat met 1 processor. Bij opvraag van veel data moet die ene processor dus beide taken uitvoeren waardoor de performance in gevaar kan komen.
Dus SATA is niet per definitie slecht, je zal alleen een goed overwogen keuze moeten maken. Ik zet nog altijd 15krpm SCSI schijven in Terminal Servers.

Kijk wat jij zegt vermoedde ik al. Mijn manager heeft het er de hele tijd over dat er niet veel data geschreven en gelezen wordt. En dat is natuurlijk ook zo. Maar het aantal requests dat zo'n schijf simultaan te verwerken krijgt lijkt mij aanzienlijk.

Ik ga woensdag een network load balancing cluster maken met 2 Sunfire X2100 servers. Hierdoor zal het aantal users over de 2 servers verdeeld worden. Hopelijk ben ik dan van de "vage" performance problemen af. Maar ik zal ook eens nagaan of het niet mogelijk is om een server met SCSI schijven aan te schaffen. Aangezien zo'n beetje het halve bedrijf via Sunray terminals werkt is het toch wel handig dat alles een beetje performt

[Jazzy]

Kijk anders eens met perfomn wat de avarage disk queue leght zo'n beetje is, die zou eigenlijk niet boven de 5 uit mogen komen. Als dat wel zo is dan staat de server op het opslagsysteem (disks en controller) te wachten.