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?
Perfomance van 'n share-server.
Ten eerste is er natuurlijk je software raid: ide kost cpu kracht, en als je daar ook nog eens een software raid bij gebruikt kan je de rest natuurlijk wel invullen. Ik zou kiezen voor een hardware raid: dit ontlast je CPU aanzienlijk!
Dan zou ik het zo doen dat je je raid verdeelt: maak er 2 raid 0 configuraties van! Hier tussen zou je JBOD kunnen draaien...
Als die server alleen voor het leechen gebruikt en niet zozeer als fileserver dan hoeft het behoud van date niet je belangrijkste punt te zijn.. Je zou bijv copieen op cd's/dvd's kunnen bewaren, mocht een schijf crashen en je je raid op nieuw moet opbouwen...
Ik hoop dat je hier wat aan hebt..
oh ja als je raid 5 neemt zou ik zeker een hardware raid kaart halen, die dingen zijn er voor gemaakt om parity uit te rekenen
Dan zou ik het zo doen dat je je raid verdeelt: maak er 2 raid 0 configuraties van! Hier tussen zou je JBOD kunnen draaien...
Als die server alleen voor het leechen gebruikt en niet zozeer als fileserver dan hoeft het behoud van date niet je belangrijkste punt te zijn.. Je zou bijv copieen op cd's/dvd's kunnen bewaren, mocht een schijf crashen en je je raid op nieuw moet opbouwen...
Ik hoop dat je hier wat aan hebt..
oh ja als je raid 5 neemt zou ik zeker een hardware raid kaart halen, die dingen zijn er voor gemaakt om parity uit te rekenen
Kheb een IDE PCI kaartje van Promise. RAID maak ik met W2K. En met W2K server kun je ook software RAID 5 maken.HitmanWVU wrote:RAID 5 kan volgens mij niet via die onboard raid-controller
Nu met RAID0 is mijn TB800 nog steeds snel genoeg om die IDE bij te kunnen benen. Kheb nog nooit strak tegen de 100% CPU belasting aan gezeten.madman wrote:ide kost cpu kracht, en als je daar ook nog eens een software raid bij gebruikt
EN RAID5 heeft ie alleen CPU kracht nodig voor de parity als tie naar die schijven moet schrijven. Is dus geen zwaar punt. Schrijven doe ik thuis wel.
Maar idd. Een hardware RAID is wel een hele verbetering.
Da's natuurlijk ook nog een oplossing. Zo creatief was ik nog niet.madman wrote:maak er 2 raid 0 configuraties van! Hier tussen zou je JBOD kunnen draaien
Maar is RAID5 dan ook zoveel sneller? Onthou dat de maximale doorvoersnelheid toch niet gehaald wordt, omdat die access tijden van die harde schijven de boel afremmen.dsmarty wrote:Je kan beter een budget verantwoorde RAID-5 IDE controller met cache kopen, voor 250 euro heb je er eentje ongeveer.
Dan heb je en je redundantie en je snelheid.
Na deze reacties zie ik de oplossing van Madman RAID0+JBOD toch als een goeie oplossing. Maar ik blijf nog met een vraag zitten.
Iemand die dit weet?WhoCares wrote:...en als er twee bestanden simultaan gelezen moeten worden ...Weet iemand of die software RAID van Windows 2000 zo intelligent is?
Dit is geen eigenschap van raid. Ik denkt niet dat dat soort foejes bij win2k in zitten. Misschien met speciale software...WhoCares wrote: Maar ik blijf nog met een vraag zitten.Iemand die dit weet?WhoCares wrote:...en als er twee bestanden simultaan gelezen moeten worden ...Weet iemand of die software RAID van Windows 2000 zo intelligent is?
Laatst al eens gekeken naar die promise SX4000 (pdf, gerarred). Zou dat wat zijn met een 256MB PC133 dimmetje erin?
Zag 'm bij de Pricewatch voor 200 euro bij Salland Automatisering (De buren op m'n werk, dat scheelt verzendkosten
)
Zag 'm bij de Pricewatch voor 200 euro bij Salland Automatisering (De buren op m'n werk, dat scheelt verzendkosten
)Zover ik weet zijn er (en vraag me niet waar) harddisk op de markt die speciaal ontworpen zien voor firewire, dus geen extern lomp bakje. En die kunnen makelijk 150 tot 200mb per sec halen. Dit wel onder linux. Een half jaar terug heb ik daar een reviewtje op gelezen. Als ik nog eens zoiets tegen kom, laat ik er meer over weten!
cn=Blacktux,dc=EMS2CREW,dc=NL
** This File Should Not Be World Readable **
The open cow project pwd = "admin"
[url]HTTP://WWW.EMS2CREW.TK[/url]
** This File Should Not Be World Readable **
The open cow project pwd = "admin"
[url]HTTP://WWW.EMS2CREW.TK[/url]
Ben nu al wat bezig geweest met heen en weer kopieren. En de snelheid is degelijk merkbaar. De volgende dingen zijn *fors* sneller geworden.
* Defragmenteren: In het verleden was de doorvoer rond de 3 a 5 MB/sec. Toen ik vandaag defragmentatie aanzette schoot deze naar een constante 21MB/sec
* FTP uploads: ik heb twee 100mbit clients met ieders 16 threads laten downloaden van dit systeem. In de oude situatie sloeg de doorvoer volledig dicht (lees: 2MB/sec) Nu schommelt ie tussen de 8 a 10MB/Sec.
Wat mij verder opvalt is dat 't geheugen veel minder snel volloopt als onder de softwareRAID situatie. Mag ook wel, want de 512MB werkgeheugen is ingekrompen tot 256MB (Die andere 256MB zit nu op die RAID5 controller
)
Ik heb dus goeie hoop. Ik wacht op een vuurdoop (Aha, vandaar die reminder voor lanz4all )
En ik kon 't niet laten. Nu heb ik nog een backup. Ik heb ff een voedingsstekkertje losgetrokken van 1 harde schijf. Rebuilden duurt dus anderhalf uur. Gelukkig kun je gewoon doorwerken al wordt 't dan wel een heel stukje trager.
* Defragmenteren: In het verleden was de doorvoer rond de 3 a 5 MB/sec. Toen ik vandaag defragmentatie aanzette schoot deze naar een constante 21MB/sec
* FTP uploads: ik heb twee 100mbit clients met ieders 16 threads laten downloaden van dit systeem. In de oude situatie sloeg de doorvoer volledig dicht (lees: 2MB/sec) Nu schommelt ie tussen de 8 a 10MB/Sec.
Wat mij verder opvalt is dat 't geheugen veel minder snel volloopt als onder de softwareRAID situatie. Mag ook wel, want de 512MB werkgeheugen is ingekrompen tot 256MB (Die andere 256MB zit nu op die RAID5 controller
)Ik heb dus goeie hoop. Ik wacht op een vuurdoop (Aha, vandaar die reminder voor lanz4all
)En ik kon 't niet laten. Nu heb ik nog een backup. Ik heb ff een voedingsstekkertje losgetrokken van 1 harde schijf. Rebuilden duurt dus anderhalf uur. Gelukkig kun je gewoon doorwerken al wordt 't dan wel een heel stukje trager.