Perfomance van 'n share-server.
Posted: 10 Nov 2003, 21:46
Op dit moment heb ik dus een servertje waarmee ik m'n spulletjes aanbiedt aan de rest van de LAN party gangers. Twee dingen aan dit PC'tje waar ik graag wat verbetering in zou willen zien.
Hou even in het hoofd dat 't wel van een krap budget gedaan moet worden. Dus dat wordt geen SCSI en ook geen Raptor schijven.
1. De perfomance:
de 4 IDE schijven die gestriped zijn (RAID 0 dus), hebben een flinke doorvoer. Daarom heb ik toendertijd er een gigabit kaartje bij aangeschaft omdat ik dacht dat 100Mbit wel een hele grote bottleneck zou worden.
Na wat praktijkervaring ben ik er achter gekomen dat de acces-time van de harde schijven een *zware* bottleneck vormen. De hoogste snelheid ooit gemeten is 23 MB/sec (waar ik best tevreden mee zou kunnen zijn). MAAR: dit was terwijl er 3 connecties met 100Mbit aan het leechen waren.
De doorsnee praktijk is heel anders: 20 tot 50 connecties die allemaal verschillende bestanden gelijktijdig van mijn server zuigen. Resultaat: Zwaar ratelende harde schijven en een totale doorvoor van nog geen 4MB/sec. Zwaar frustrerend. 't is alsof je achter een oud PC'tje zit die wegens hevig tekort aan fysiek geheugen zo ongeveer alles naar HD zit te swappen.
2. De betrouwbaarheid.
Uiteraard is een striped(RAID 0) nou niet echt bevordelijk voor veilige gegevensopslag. Is ook niet van vreselijk groot belang, want alles wat ik erop heb staan kan ik wel weer bij elkaar leechen. Maar 't zou wel vreselijk zonde zijn. En omdat ik een RAID 0 heb van 4 schijven, is de kans op dataverlies 4 keer zo groot als dat ik maar 1 schijf zou gebruiken.
Ik heb eens nagedacht over een oplossing voor i.i.g punt 1, maar bij voorkeur beide punten. Hierbij heb ik al wat mogelijke oplossingen bedacht.
Eerste oplossing: Verander de configuratie van die striped(RAID0) volume in een spanned(JBOD)volume.
Hiermee verhoog je in sommige gevallen de doorvoersnelheid bij veel connecties. Waarom? Omdat diverse bestanden verdeeld zijn over verschillende harde schijven. Stel nou dat 1 gebruiker bestanden aan het leechen is die toevallig op schijf 1 staan. Een andere gebruiker leecht vanaf schijf 2. HD koppen hoeven nu nauwelijks heen en weer. Had je deze actie gedaan met de striped volume, dan hadden alle kopppen op alle schijven al heen en weer staan te ratelen.
Conclusie: Met JBOD wordt je *gemiddelde* acces-time verlaagd. Gewoon omdat er een gedegen kans bestaat dat voor het lezen van verschillende bestanden een HD kop niet of nauwelijks verplaatst hoeft te worden.
Punt 1 wordt hierbij verbeterd. Punt 2 niet, maar ik ga daarbij ook niet achteruit in opslagcapaciteit.
Tweede oplossing: RAID1
Zet de schijven in een RAID1 (mirror) Data wordt op beide schijven weggeschreven, en als er twee bestanden simultaan gelezen moeten worden kan het ene bestand van de ene schijf gelezen worden en de andere van de tweede harde schijf.
Mits natuurlijk de RAID controller dit ondersteund. En mijn RAID controller is windows 2000. Weet iemand of die software RAID van Windows 2000 zo intelligent is?
Punt 1: Misschien opgelost, Punt 2: Heel goed opgelost, maar ik ga wel fors in opslagcapaciteit achteruit.
Derde oplossing: RAID 5
Moet ik natuurlijk wel eerst W2K server installeren of die ene hack zien te vinden voor W2K pro (Staat ergens op GoT, alleen ff zoeken waar)
Punt 1: RAID 5 is traag in het schrijven omdat er een parity berekend moet worden. (Nee, ik heb dus geen hardware RAID). Dit is voor mijn situatie niet echt een probleem. Schrijven gebeurt meestal als ik weer thuis ben van de LAN party. Tijd zat dus om die meuk uit te sorteren en van mijn werkstation naar de server te pleuren.
Maar zit er eigenlijk voor mijn situatie snelheidswinst in RAID5? Iemand?
Punt 2 is wel opgelost, en ik wordt niet gehalveerd in mijn dataopslag. Zou een redelijke oplossing zijn.
Nou, wie roept?
Hou even in het hoofd dat 't wel van een krap budget gedaan moet worden. Dus dat wordt geen SCSI en ook geen Raptor schijven.
1. De perfomance:
de 4 IDE schijven die gestriped zijn (RAID 0 dus), hebben een flinke doorvoer. Daarom heb ik toendertijd er een gigabit kaartje bij aangeschaft omdat ik dacht dat 100Mbit wel een hele grote bottleneck zou worden.
Na wat praktijkervaring ben ik er achter gekomen dat de acces-time van de harde schijven een *zware* bottleneck vormen. De hoogste snelheid ooit gemeten is 23 MB/sec (waar ik best tevreden mee zou kunnen zijn). MAAR: dit was terwijl er 3 connecties met 100Mbit aan het leechen waren.
De doorsnee praktijk is heel anders: 20 tot 50 connecties die allemaal verschillende bestanden gelijktijdig van mijn server zuigen. Resultaat: Zwaar ratelende harde schijven en een totale doorvoor van nog geen 4MB/sec. Zwaar frustrerend. 't is alsof je achter een oud PC'tje zit die wegens hevig tekort aan fysiek geheugen zo ongeveer alles naar HD zit te swappen.
2. De betrouwbaarheid.
Uiteraard is een striped(RAID 0) nou niet echt bevordelijk voor veilige gegevensopslag. Is ook niet van vreselijk groot belang, want alles wat ik erop heb staan kan ik wel weer bij elkaar leechen. Maar 't zou wel vreselijk zonde zijn. En omdat ik een RAID 0 heb van 4 schijven, is de kans op dataverlies 4 keer zo groot als dat ik maar 1 schijf zou gebruiken.
Ik heb eens nagedacht over een oplossing voor i.i.g punt 1, maar bij voorkeur beide punten. Hierbij heb ik al wat mogelijke oplossingen bedacht.
Eerste oplossing: Verander de configuratie van die striped(RAID0) volume in een spanned(JBOD)volume.
Hiermee verhoog je in sommige gevallen de doorvoersnelheid bij veel connecties. Waarom? Omdat diverse bestanden verdeeld zijn over verschillende harde schijven. Stel nou dat 1 gebruiker bestanden aan het leechen is die toevallig op schijf 1 staan. Een andere gebruiker leecht vanaf schijf 2. HD koppen hoeven nu nauwelijks heen en weer. Had je deze actie gedaan met de striped volume, dan hadden alle kopppen op alle schijven al heen en weer staan te ratelen.
Conclusie: Met JBOD wordt je *gemiddelde* acces-time verlaagd. Gewoon omdat er een gedegen kans bestaat dat voor het lezen van verschillende bestanden een HD kop niet of nauwelijks verplaatst hoeft te worden.
Punt 1 wordt hierbij verbeterd. Punt 2 niet, maar ik ga daarbij ook niet achteruit in opslagcapaciteit.
Tweede oplossing: RAID1
Zet de schijven in een RAID1 (mirror) Data wordt op beide schijven weggeschreven, en als er twee bestanden simultaan gelezen moeten worden kan het ene bestand van de ene schijf gelezen worden en de andere van de tweede harde schijf.
Mits natuurlijk de RAID controller dit ondersteund. En mijn RAID controller is windows 2000. Weet iemand of die software RAID van Windows 2000 zo intelligent is?
Punt 1: Misschien opgelost, Punt 2: Heel goed opgelost, maar ik ga wel fors in opslagcapaciteit achteruit.
Derde oplossing: RAID 5
Moet ik natuurlijk wel eerst W2K server installeren of die ene hack zien te vinden voor W2K pro (Staat ergens op GoT, alleen ff zoeken waar)
Punt 1: RAID 5 is traag in het schrijven omdat er een parity berekend moet worden. (Nee, ik heb dus geen hardware RAID). Dit is voor mijn situatie niet echt een probleem. Schrijven gebeurt meestal als ik weer thuis ben van de LAN party. Tijd zat dus om die meuk uit te sorteren en van mijn werkstation naar de server te pleuren.
Maar zit er eigenlijk voor mijn situatie snelheidswinst in RAID5? Iemand?
Punt 2 is wel opgelost, en ik wordt niet gehalveerd in mijn dataopslag. Zou een redelijke oplossing zijn.
Nou, wie roept?
)