2x RAID-5 of 1x RAID-6?

[Fauna]

Misschien een wat vage topictitel, maar ik zal het zo goed mogelijk proberen uit te leggen.

Momenteel heb ik een Areca ARC-1160 met 1GB cache. Hierop heb ik 2 RAID-5 array's; 1 set van 6x 1,5TB Seagate 7200.11 disks, en 1 set van 10x 750GB Seagate 7200.11 disks. Die laatste array wordt komende week vervangen door 10x 1,5TB Seagate 7200.11 disks, waardoor ik straks dus 16 (min of meer) identieke schijven zal hebben.

In principe was ik van plan om alles te backuppen en vanaf scratch een nieuwe RAID-5 op te bouwen met de 10 nieuwe disks. Hier heb ik een systeem voor, maar vanwege de complexiteit zal ik jullie dat besparen. Zodoende zou ik dus 2 afzonderlijke array's naast elkaar houden op dezelfde controller.

Mijn server moet voornamelijk zijn diensten bewijzen op LAN's, en met een applicatie genaamd HDDLed indicator kan ik inzien hoe snel de data geleeched wordt. Belangrijker is echter het aantal requests per seconde en het aantal uitstaande queues. Uit ervaring weet ik dat als die laatste boven de 1 komt, de algehele performance inzakt. Zolang er niet teveel threads zijn stamp ik er zo 200MB/s uit via het netwerk (Broadcom adapter-teaming ftw), maar komt de queue op een array boven de 1, gaat het rap langzamer. Op afgelopen The Party kon ik dit ook goed merken, want de array met de meest populaire bestanden trok het gewoon niet. Om het in beeld te brengen: Array 1 (6x1,5TB) had een stuk of 20 threads met een queue 2<5 en deed 50MB/s read, maar array 2 (10x750GB) had er slechts een stuk of 5 met een queue van <1,5, en deed 120MB/s read.

Nu kan ik zodirect wel de data een beetje balancen, zodat straks de loads op de twee array's ongeveer gelijk wordt, maar verschillen houd je altijd. Mijn concrete vraag is dan ook, wat zal straks sneller werken; 1 grote array of 2 wat kleinere? Ik weet dat mijn Areca bij ongeveer 400MB/s ophoudt, dus dat zou met een dual gigabit lijn geen probleem moeten zijn.

Er zijn mijns inziens 2 mogelijke uitkomsten:

• De uiteindelijke snelheid wordt hoger. De controller kan zorgen voor load-balancing, waardoor altijd de optimale snelheid wordt gehaald.
• De uiteindelijke snelheid wordt langzamer. Als ik bij het voorbeeld blijf, zou deze array 25 threads te verwerken krijgen. De IOP op de controller kan het niet bijhouden en de disk queue loopt op.

Graag jullie input

De specs van de server vind je via de link in mijn sig, maar even kort opgesomd:
Intel E8400, 4GB DDR2, Asus P5BV, ARC-1160 1GB, 2x WD Raptor 36GB (RAID-0, boot), 16x 1.5TB Seagate 7200.11 (data), Tagan 900W

[ Voor 4% gewijzigd door Fauna op 04-06-2009 00:50 ]

[kalizec]

Gezien het data volume lijkt het mij dat het redelijk sequentiele data 'hoort' te zijn en dat dit normaliter ook met 'grotere' queues nog redelijke snelheden zou moeten kunnen halen. Het lijkt mij dan ook eerder een software probleem dan een hardware probleem. Waarschijnlijk 'snijdt' de software de HD-requests in te kleine stukjes (met seek-time als gevolg) of is er een te kleine cache (en dus hetzelfde probleem).

Kortom, ik denk dat je eerder moet kijken naar je software dan je hardware.

Ik kan me eigenlijk niet voorstellen dat een array met 10 spindels in dergelijke omstandigheden niet meer dan 200MB/s uit kan leveren (mits de data maar sequentieel is).

[Fauna]

Ik denk dat alles juist behoorlijk random is. Met ca. 20 gelijktijdige users die hun data via DC en FTP proberen binnen te hengelen, lijkt het me dat die al voor genoeg randomness zorgen. Overigens: in het verleden heb ik een DC++ versie gebruikt die chunks van 2MB uitstuurde. Dat had een drastisch effect op de performance, want toen haalde ik max 60-70MB/s, iig met dezelfde hardware (wellicht een wat andere schijfconfig).

Trouwens, meer dan 200MB/s op een LAN-party hoef ik voorlopig ook niet te halen, totdat er over 5 jaar een 10Gb netwerkadapter in hangt Continuïteit en zo min mogelijk performanceverlies (dips naar 100MB/s bij extreme drukte bijv) bij veel gebruikers is mijn doel.

Voor de duidelijkheid: de meeste files die gerequest worden zijn vrij groot. Ik praat dan over files van 350MB tot 12GB groot. Laat het gemiddelde op 1GB liggen, dat past in het optimale geval net in de cache, maar met zoveel gelijktijdige users zal dat never nooit niet lukken.

[ Voor 16% gewijzigd door Fauna op 04-06-2009 00:59 ]

[Desolation Angel]

Puur door het aantal Unrecoverable Read Errors zou je al geen RAID-5 meer mogen draaien op zulk formaat schijven.
1 Grote Raid-6 kan op zich nog wel, maar voor alle zekerheid en om absurde rebuild times te beperken zou ik gaan voor 2 even grote Raid-6 arrays van 8 schijven
zeker met consumer grade disks van 1.5TB is de kans er wel dat als er een disk failt, er kort achter ook een tweede zal failen, zelfs zo'n hiclass areca controller kan een 16 disk array van 1.5TB schijven niet op afzienbare tijd rebuilden, hotspare of niet, dus die tijd sterk inkorten door 2 kleinere arrays te gebruiken lijkt me wijselijk als je data je lief is

Wikipedia: Standard RAID levels
http://blogs.zdnet.com/storage/?p=162

[gertvdijk]

Ik klink misschien aanvankelijk heel dom, maar waarom gebruik je überhaupt RAID als je zoveel random read performance wil? Volgens mij kan je alle disks beter los (eventueel in één LVM gooien) inzetten, waardoor je van nature de verdeling van de reads hebt. Juist bij veel gelijktijdige random reads wil je niet dat al je disks moeten mee seeken - dat kost ontzettend veel tijd. Nadeel is dat een single sequentiële read dan wel mindere performance heeft, ten gunste van de hogere performance bij meerdere requests.

Volgens mij krijg je met 1xRAID6 helemaal problemen. Je moet je voorstellen dat dan *al* je disks gelijktijdig moeten gaan seeken continu... niet echt efficiënt.

[ Voor 13% gewijzigd door gertvdijk op 04-06-2009 01:58 ]

[kalizec]

Fauna schreef op donderdag 04 juni 2009 @ 00:55:
Ik denk dat alles juist behoorlijk random is.

Dat hangt dus sterk af van de grootte van de blokken zoals ze van de HDD gehaald worden.

Een rekenvoorbeeldje:

Aannames
- Perfecte raidcontroller
- 8 schijven
- RAID 6
- gemiddelde seektime van 12,5ms
- sequentiele throughput van 80MB/s per schijf
- stripesize 64kb (zolang we reads doen van minstens ±512kB doen alle acht de schijven mee tijdens het lezen, zes lezen data, twee parity).

Chunksize 1MB
- seektime 12,5 ms.
- readtime 2,1 ms (1MB / 6 / 80MB/s = 2,1 ms)
- request time 14,6 ms
- requests per seconde = 68 (1000/14,6 = 68)
- array-snelheid = 68MB/s (68 * 1MB)

Chunksize 5MB
- seektime 12,5 ms.
- readtime 10,4 ms (5MB / 6 / 80MB/s = 10,4 ms)
- request time 22,9 ms
- requests per seconde = 43 (1000/22,9 = 43)
- array-snelheid = 215MB/s (43 * 5MB)

Chunksize 25MB
- seektime 12,5 ms.
- readtime 52,1 ms (25MB / 6 / 80MB/s = 52,1 ms)
- request time 64,6 ms
- requests per seconde = 15 (1000/64,6 = 15)
- array-snelheid = 375MB/s (15 * 25MB)


Dit laatste gaat je controller waarschijnlijk niet halen, maar het idee is duidelijk. Als jij je software / raidsoftware kunt vertellen dat de data in grotere blokken opgehaald moet worden raak je relatief minder tijd kwijt aan het seeken en dan moet het prima mogelijk zijn dit soort snelheid te halen.

[Matis]

Daarbij moet je ook nog eens jezelf de vraag stellen. Wat is belangrijker:

data dichtheid, data zekerheid, lees/schrijf snelheid enz.

Als je wilt gaan voor data dichtheid dan sws geen RAID nemen. Wil je absoluut zekerheid tegen zo min mogelijk rekenkracht dan ga je voor 1. Wil je iets in de midden dan ga je voor 5, maar met 6 heb je net iets meer zekerheid dan dichtheid enz. Nja het is jou feestje.

Ik heb mijn 4 x 250 GB gewoon netjes als losse disks in mn systeem zitten zonder RAID. Ik wil gewoon veel opslag en als er 1tje stuk gaat; dikke pech. Gebruik eigenlijk 1 schijf gewoon als buffer tussen het inlezen en bewerken en het uiteindelijke afmixen, renderen en wegschrijven op schijf 3. Van de laatste heb ik mn OS staan.
De gemuxte sequences gaan naar een andere server met wel data garantie, maar ik weet niet hoe dat in elkaar steekt!

[Fauna]

Werken met losse disks is voor mij in ieder geval geen optie. Als ik wel iets haat is dat ik mijn data moet gaan zoeken over schijven gelabeld films 1t/m10 (bijv). Anders is het voor mij en de users totaal niet overzichtelijk. Aangezien ik met Windows Server werk gaat LVM ook niet lukken. Als ik het goed lees is het een soort van software-JBOD. Dat zou dan opzich nog een uitweg zijn, maar je hebt totaal geen vorm van redundancy.

Daarover gesproken, de redundancy heb ik vooral om het falen van een enkele (straks dus twee) disk(s) op te vangen. Het verhaal van URE's is erg interessant, maar mocht er een bitje/block omvallen is het jammer, maar dan moet ik die betreffende file maar als verloren beschouwen, als ik er al überhaupt achter kom. Trouwens, het probleem zal ik altijd tegen gaan komen in de toekomst, welke manier ik ook gebruik. Mits die rate meegroeit met de capaciteit dus, zoals ook in een van de artikelen wordt genoemd. De ideologie dat RAID heilig is heb ik allang achter me gelaten, en heb ook meer dan genoeg keren dataverlies gehad in al zijn vormen. De kans bij meerdere schijven is in ieder geval wel aanwezig dat er een schijf omvalt, dus vandaar RAID-5. Maar dan heb ik dus niet direct een probleem. Het rebuilden gaat best snel; zelfs met de 10-disk array ben ik binnen 24h klaar; afhankelijk van de load kan het zelfs binnen 12h. Daarnaast voer ik ook 2-wekelijks een parity-check uit.

Over de software: ik weet dat DC++ (StrongDC in mijn geval) een verre van ideaal programma/protocol is. In ieder geval veel overhead en CPU-load. Ik ben bang dat ik de request-size niet kan aanpassen, als ik al kan zien hoe groot dat die zijn. Mijn persoonlijke vermoeden is echter dat door de vele gebruikers een file niet meer efficiënt in een paar grotere blokken is uit te lezen. Meer cache op de controller gaat helaas niet.

[gertvdijk]

Fauna schreef op donderdag 04 juni 2009 @ 09:57:
Aangezien ik met Windows Server werk gaat LVM ook niet lukken.

Windows heeft dat ook, alleen heet dat dan anders. Als ik het me goed herinner iets met dynamische volumes ofzo.
En LVM is veel meer dan software-JBOD

Fauna schreef op donderdag 04 juni 2009 @ 09:57:
Daarover gesproken, de redundancy heb ik vooral om het falen van een enkele (straks dus twee) disk(s) op te vangen.

Je redundancy ben je dan kwijt inderdaad, maar mij was niet duidelijk in hoeverre de data critical is. Als je redundancy nodig hebt, dan snap ik niet waarom je allemaal dezelfde schijven pakt. De kans dat dezelfde fouten optreden bij schijven binnen dezelfde serie is aanzienlijk hoger dan wanneer je die kansen verspreid door het kiezen van verschillende schijven.

Met software RAID in Linux zou ik je wellicht kunnen helpen met het tunen van de array en het configureren van grote 'readahead' blocksize. Ben het namelijk helemaal eens met Matis en kalizec als zijnde een workaround voor de 'verticale' opstelling van RAID arrays i.c.m. jouw gebruik.

Kern van het probleem is dat jij paralelle reads hebt terwijl je je disks in serie zet.

[ Voor 8% gewijzigd door gertvdijk op 04-06-2009 11:56 ]

[Fauna]

Ok, eens met jullie motivatie over paralelle reads. De mogelijke oplossing zou zijn om met dynamische disks of JBOD te gaan werken. Voor 1 file wordt dan (als het goed is) ook 1 disk aangesproken.

Hoe los ik dan op als er zeg 5 users iets van die disk proberen te halen? 1 user zal prima gaan (zeg de eerder genoemde 80MB/s), maar bij 2 users zullen beide users geen 40MB/s meer halen, om nog maar te zwijgen over 5 concurrent users. Of zou de cache van de controller dit netjes kunnen oplossen? Ik zie op LAN's namelijk meerdere servers die losse disks gebruiken, en de populaire zooi krijg je nog niet eens met 2MB/s binnen, terwijl een andere disk van die server met gemak over de 50MB/s gaat. Ik heb dus nog steeds mijn ernstige twijfels

Mijn gedachte was namelijk dat je door RAID de load over de verschillende disks kan balancen. Echter lijkt het er dus op dat dit niet opweegt tegen het sterk groeiende requests over alle betrokken disks?

[Femme]

Load balancing over losse disks werkt natuurlijk ook alleen goed als de bestanden die over de disks zijn verdeeld even populair zijn. Het voordeel van raid is dat je hier geen omkijken naar hebt. Vanuit het oogpunt van beheersbaarheid en redundancy zijn losse disks een hel.

Met twee raid 5-arrays van acht disks zal beter presteren dan een enkele array van zestien drives mits beide arrays evenwichtig belast worden. De performance van een raid-array schaalt in de praktijk zelden optimaal. Voorbeeldje:

Fileserver - Large filesize
#	RAID	Controller	Score (IOps)
14	RAID 5	Areca ARC-1160 1GB	********* 2.041
12	RAID 5	Areca ARC-1160 1GB	******** 1.923
8	RAID 5	Areca ARC-1160 512MB	****** 1.493
6	RAID 5	Areca ARC-1160 512MB	***** 1.235

In de praktijk zal het verschil wat minder zijn om dat de processor dubbel werk heeft te verrichten maar het geeft een idee.

gertvdijk schreef op donderdag 04 juni 2009 @ 11:44:
[...]

Je redundancy ben je dan kwijt inderdaad, maar mij was niet duidelijk in hoeverre de data critical is. Als je redundancy nodig hebt, dan snap ik niet waarom je allemaal dezelfde schijven pakt. De kans dat dezelfde fouten optreden bij schijven binnen dezelfde serie is aanzienlijk hoger dan wanneer je die kansen verspreid door het kiezen van verschillende schijven.

Het is onwaarschijnlijk dat schijven van hetzelfde type binnen een tijdsbestek van 24 uur defect raken. Ik heb nog nooit gehoord dat serverfabrikanten harde schijven van verschillende fabrikanten in een systeem mixen om gelijktijdige defecten te voorkomen. Voor de prestaties is het in ieder geval niet ideaal dat de drives in een array afwijkend ten opzichte van elkaar presteren.

[kalizec]

Fauna schreef op donderdag 04 juni 2009 @ 09:57:
Over de software: ik weet dat DC++ (StrongDC in mijn geval) een verre van ideaal programma/protocol is. In ieder geval veel overhead en CPU-load. Ik ben bang dat ik de request-size niet kan aanpassen, als ik al kan zien hoe groot dat die zijn. Mijn persoonlijke vermoeden is echter dat door de vele gebruikers een file niet meer efficiënt in een paar grotere blokken is uit te lezen. Meer cache op de controller gaat helaas niet.

Tenzij ik me vergis (en de kans is redelijk aanwezig, daar ik er zelf geen heb liggen) hebben Areca controllers ook gewoon de mogelijkheid een Chunksize op te geven. Het OS kan dan piepen wat het wil, maar blokken zullen minimaal ter grootte van de Chunksize gelezen worden.

[gertvdijk]

Fauna schreef op donderdag 04 juni 2009 @ 12:42:
Ok, eens met jullie motivatie over paralelle reads. De mogelijke oplossing zou zijn om met dynamische disks of JBOD te gaan werken. Voor 1 file wordt dan (als het goed is) ook 1 disk aangesproken.

Met JBOD wordt je hele controller overbodig, aangezien elk fatsoenlijk OS dit in de software kan en je veel meer DIMM reepjes kan kopen met de besparing daarvan.

Fauna schreef op donderdag 04 juni 2009 @ 12:42:
Hoe los ik dan op als er zeg 5 users iets van die disk proberen te halen? 1 user zal prima gaan (zeg de eerder genoemde 80MB/s), maar bij 2 users zullen beide users geen 40MB/s meer halen, om nog maar te zwijgen over 5 concurrent users. Of zou de cache van de controller dit netjes kunnen oplossen? Ik zie op LAN's namelijk meerdere servers die losse disks gebruiken, en de populaire zooi krijg je nog niet eens met 2MB/s binnen, terwijl een andere disk van die server met gemak over de 50MB/s gaat. Ik heb dus nog steeds mijn ernstige twijfels

Concurrent transfers vanaf 1 schijf is altijd al problematisch geweest. Dat is inherent aan het model harddisk: platters en koppen. Veelal wordt dit opgelost met grote hoeveelheden werkgeheugen in de servers voor filesystem cache i.c.m. veel readahead. Het is aan jou om de data zo goed mogelijk te verdelen over de schijven, om zo een verdeling te krijgen van de load over de disks. Ik ken hiervoor geen methodiek om dit te automatiseren, naast het gebruik van RAID1 waarbij je die kan afregelen zodat concurrent reads efficienter gaan. (default Linux mdadm t.o.v. dubbele leessnelheden bij hardware-RAID)

Fauna schreef op donderdag 04 juni 2009 @ 12:42:
Mijn gedachte was namelijk dat je door RAID de load over de verschillende disks kan balancen.

Dat is een verkeerde gedachte. Je balanct niks, je laat ze alleen altijd samenwerken voor een zo hoog mogelijke doorvoersnelheid.

Femme schreef op donderdag 04 juni 2009 @ 13:25:
Het is onwaarschijnlijk dat schijven van hetzelfde type binnen een tijdsbestek van 24 uur defect raken. Ik heb nog nooit gehoord dat serverfabrikanten harde schijven van verschillende fabrikanten in een systeem mixen om gelijktijdige defecten te voorkomen. Voor de prestaties is het in ieder geval niet ideaal dat de drives in een array afwijkend ten opzichte van elkaar presteren.

Binnen 24 uur is natuurlijk onwaarschijnlijk, maar uit ervaring weet ik dat schijven uit dezelfde serie venijnig snel dezelfde fouten kunnen geven! Als je favo webshop het laat afweten of je bent op vakantie en je geraakt in de situatie dat je array aan een zijden draadje hangt, dan ben ik veel geruster als het allemaal andere soorten schijven zijn. Voor performance doeleinden (lees: sequentiele transfersnelheid) waarbij data non-critical is zou je wel dezelfde moeten nemen...

[Fauna]

kalizec schreef op donderdag 04 juni 2009 @ 18:58:
Tenzij ik me vergis (en de kans is redelijk aanwezig, daar ik er zelf geen heb liggen) hebben Areca controllers ook gewoon de mogelijkheid een Chunksize op te geven. Het OS kan dan piepen wat het wil, maar blokken zullen minimaal ter grootte van de Chunksize gelezen worden.

De arrays die ik momenteel heb, hebben een block size van 512B en een stripe size van 128kB. Dit zijn de hoogst mogelijke waardes.

gertvdijk schreef op donderdag 04 juni 2009 @ 19:31:
Met JBOD wordt je hele controller overbodig, aangezien elk fatsoenlijk OS dit in de software kan en je veel meer DIMM reepjes kan kopen met de besparing daarvan.

Dat lijkt me bij LVM en Dynamische disks ook het geval... Hoe dan ook, de controller is er, en ik was niet van plan deze reeds af te schrijven.

gertvdijk schreef op donderdag 04 juni 2009 @ 19:31:
Concurrent transfers vanaf 1 schijf is altijd al problematisch geweest. Dat is inherent aan het model harddisk: platters en koppen. Veelal wordt dit opgelost met grote hoeveelheden werkgeheugen in de servers voor filesystem cache i.c.m. veel readahead. Het is aan jou om de data zo goed mogelijk te verdelen over de schijven, om zo een verdeling te krijgen van de load over de disks. Ik ken hiervoor geen methodiek om dit te automatiseren, naast het gebruik van RAID1 waarbij je die kan afregelen zodat concurrent reads efficienter gaan. (default Linux mdadm t.o.v. dubbele leessnelheden bij hardware-RAID)

Het is dus een goede optie, maar alleen in het geval dat alles goed geoptimaliseerd is en ik er een paar honderd euro voor DDR tegenaan smijt. In theorie mooi, maar in de praktijk gaat het dus niet werken vrees ik. Ik heb al moeite om de data over 2 array's te verdelen, laat staan 16 disks. Bovendien heb ik er niet echt controle op als ik gebruik zou maken van een software spanning oplossing. De performance is dan ook nog eens hoogst onvoorspelbaar.

gertvdijk schreef op donderdag 04 juni 2009 @ 19:31:
Dat is een verkeerde gedachte. Je balanct niks, je laat ze alleen altijd samenwerken voor een zo hoog mogelijke doorvoersnelheid.

Natuurlijk wel, alle schijven in de betreffende array hebben precies dezelfde load. De hogere doorvoer bij het gebruik van een grote RAID-array zorgt ervoor dat de request-time ook omlaag gaat. Nu gaat die toch wel omhoog bij veel requests, maar de totale doorvoer zal bij een grotere array wel stijgen (zie de benches van Femme).

gertvdijk schreef op donderdag 04 juni 2009 @ 19:31:
Binnen 24 uur is natuurlijk onwaarschijnlijk, maar uit ervaring weet ik dat schijven uit dezelfde serie venijnig snel dezelfde fouten kunnen geven! Als je favo webshop het laat afweten of je bent op vakantie en je geraakt in de situatie dat je array aan een zijden draadje hangt, dan ben ik veel geruster als het allemaal andere soorten schijven zijn. Voor performance doeleinden (lees: sequentiele transfersnelheid) waarbij data non-critical is zou je wel dezelfde moeten nemen...

Dezelfde disks verwerken de data op dezelfde manier, en zeker bij meerdere samenwerkende disks is het van belang dat de ene disk niet op de andere hoeft te wachten. Al is het maar door andere optimalisaties. Ik zou alleen bang worden als een bepaalde soort schijven structurele problemen heeft. Voor de rest is het pure statistiek, en is de kans op het uitvallen van 2 schijven uit eenzelfde serie marginaal groter dan 2 compleet verschillende disks.

Hoe dan ook, we dwalen af. Een non-RAID oplossing gaat voor mij niet werken. Het is totaal onbeheersbaar om de load handmatig te balancen. En als ik dat verschil zou willen compenseren, gooi ik het hele principe van de server om met bijbehorende kosten.
De benchmarks die Femme laat zien geven eigenlijk een perfect antwoord op mijn vraag (en had ik zelf goed op kunnen zoeken). Sequentieel schalen RAID-array's prima, maar zodra er randomness in het spel is en meerdere threads, schaalt het een stukje minder. In die theorie zijn 2 kleinere arrays bij elkaar opgeteld dus sneller.

[kalizec]

Chunksize is iets anders dan block size en stripe size.

RAID FAQ

[Fauna]

kalizec schreef op donderdag 04 juni 2009 @ 22:26:
Chunksize is iets anders dan block size en stripe size.

RAID FAQ

Dat kan ik nergens instellen helaas.

[gertvdijk]

Fauna schreef op donderdag 04 juni 2009 @ 22:14:
Natuurlijk wel, alle schijven in de betreffende array hebben precies dezelfde load. De hogere doorvoer bij het gebruik van een grote RAID-array zorgt ervoor dat de request-time ook omlaag gaat. Nu gaat die toch wel omhoog bij veel requests, maar de totale doorvoer zal bij een grotere array wel stijgen (zie de benches van Femme).

Wat heb je aan #disks × ~80MB/s? Je schaalt op in totale doorvoer met een grotere array terwijl daarmee de seektime een steeds grotere factor gaat spelen t.o.v. de readtime in de request time. Gezien geen enkele leecher sustained reads van dergelijke hoge snelheden hoeft te hebben is deze opschaling mijns insziens niet nuttig danwel zwaar overschat. Maar inmiddels heb je dat zelf ook wel door.

Fauna schreef op donderdag 04 juni 2009 @ 22:14:
Dezelfde disks verwerken de data op dezelfde manier, en zeker bij meerdere samenwerkende disks is het van belang dat de ene disk niet op de andere hoeft te wachten. Al is het maar door andere optimalisaties.

Weer optimaliseer je dan voor de symptomen die dus bijwerkingen zijn van je hele setup: RAID. Volgens mij is de enige reden waarom je RAID gebruikt de redundancy. En daarvoor bestaat niet een veel beter alternatief.

Fauna schreef op donderdag 04 juni 2009 @ 22:14:
Ik zou alleen bang worden als een bepaalde soort schijven structurele problemen heeft. Voor de rest is het pure statistiek, en is de kans op het uitvallen van 2 schijven uit eenzelfde serie marginaal groter dan 2 compleet verschillende disks.

Tuurlijk is het statistiek en is het allemaal normaal verdeeld, maar toch spreid ik mijn risico's het liefst. Het woord 'marginaal' waag ik toch wel te betwijfelen. Heb het zelf iets te vaak in de praktijk zien gebeuren...

Fauna schreef op donderdag 04 juni 2009 @ 22:14:
In die theorie zijn 2 kleinere arrays bij elkaar opgeteld dus sneller.

Ja.

[Femme]

gertvdijk schreef op donderdag 04 juni 2009 @ 19:31:
[...]

Concurrent transfers vanaf 1 schijf is altijd al problematisch geweest. Dat is inherent aan het model harddisk: platters en koppen. Veelal wordt dit opgelost met grote hoeveelheden werkgeheugen in de servers voor filesystem cache i.c.m. veel readahead. Het is aan jou om de data zo goed mogelijk te verdelen over de schijven, om zo een verdeling te krijgen van de load over de disks. Ik ken hiervoor geen methodiek om dit te automatiseren, naast het gebruik van RAID1 waarbij je die kan afregelen zodat concurrent reads efficienter gaan. (default Linux mdadm t.o.v. dubbele leessnelheden bij hardware-RAID)

De oplossing om data automatisch goed te verdelen over harde schijven heet raid. Natuurlijk zijn er situaties te verzinnen waarin handmatige optimalisaties beter presteren, maar die optimalisaties zullen al snel onbeheersbaar worden.

Dat is een verkeerde gedachte. Je balanct niks, je laat ze alleen altijd samenwerken voor een zo hoog mogelijke doorvoersnelheid.

Natuurlijk kan de load op een raid-array wel gebalanced worden. De effectiviteit hangt af van de implementatie en optimalisaties in het besturingssysteem. Een raid-array biedt hogere sequentiële transferrates en de mogelijkheid om gelijktijdig transfers kleiner dan de stripe size uit te voeren vanaf verschillende disks. Gelijktijdige sequentiële streams zijn wat moeilijker te optimaliseren maar de Areca's lijken dit goed onder de knie te hebben. Een raid-array die intern 400MB/s haalt en per client 80MB/s over het netwerk moet pompen kan in theorie vijf clients met die snelheid bedienen. Het probleem zit 'm in het schakelen tussen de verschillende sequentiële streams. Als dit vaak gebeurd wordt de doorvoer omlaag getrokken door veel seeks. Ik kan me voorstellen dat er tussen besturingsysstemen en bestandssystemen ook nog significante wel verschillen zijn door pre-fetching optimalisaties. Pre-fetching is in deze situaties de key voor hoge prestaties. Een raid-array moet data eerder inlezen dan deze naar de client wordt verstuurd.

Binnen 24 uur is natuurlijk onwaarschijnlijk, maar uit ervaring weet ik dat schijven uit dezelfde serie venijnig snel dezelfde fouten kunnen geven! Als je favo webshop het laat afweten of je bent op vakantie en je geraakt in de situatie dat je array aan een zijden draadje hangt, dan ben ik veel geruster als het allemaal andere soorten schijven zijn.

Als je je goed wilt indekken moet je een hotspare paraat hebben staan.

Fauna schreef op donderdag 04 juni 2009 @ 22:14:
[...]

De benchmarks die Femme laat zien geven eigenlijk een perfect antwoord op mijn vraag (en had ik zelf goed op kunnen zoeken). Sequentieel schalen RAID-array's prima, maar zodra er randomness in het spel is en meerdere threads, schaalt het een stukje minder. In die theorie zijn 2 kleinere arrays bij elkaar opgeteld dus sneller.

De prestaties van raid-arrays schalen prima als er puur willekeurige I/O wordt uitgevoerd die een zeer hoge concurrency heeft. Hoe willekeuriger de I/O en hoger de concurrency, des te groter de kans dat alle schijven in een array aan het werk gehouden kunnen worden. In IOMeter kun je dit goed demonstreren. In de praktijk is de concurrency vaak niet hoog genoeg en kunnen de I/O's niet evenwichtig over de schijven verdeeld worden, waardoor de disks niet optimaal belast kunnen worden.

[AlexanderB]

en 4 arrays van 4 disks? dan ben je wel 4x 1.5 tb kwijt aan redundancy, maar dan heb je 4x zo veel random doorvoer als 1 grote array..

[heuveltje]

AlexanderB schreef op donderdag 04 juni 2009 @ 23:43:
en 4 arrays van 4 disks? dan ben je wel 4x 1.5 tb kwijt aan redundancy, maar dan heb je 4x zo veel random doorvoer als 1 grote array..

-Hoezo heb je 4 x zoveel doorvoer ?
-Je bent die 4 disken die parity opslaan ook kwijt, dus daar verlies je performance aan
-Je zit met 4 partities te klooien, wat de TS specifiek niet wil
-ALs van je 10 leechers er 8 data van 1 array willen, stort je performance helemaal in, en staat de helft van je hd's uit zijn neus te vreten.

Ik draai ook een File server op Lanparties, zij het met idd allemaal losse schijven(bewuste keuze) en wat minder budget
en uit ervaring kan ik je zeggen dat er van min 13 disken, het altijd dezelfde 2 zijn waar continu op gehamerd word, en dat zijn :
-De schijf waar je net op geleechte nieuwe films staan.
-De schijf waar je pr0n op staat

* Anoniem: 58354 zwaait naar fauna

[ Voor 7% gewijzigd door heuveltje op 05-06-2009 11:04 ]

[gertvdijk]

Femme schreef op donderdag 04 juni 2009 @ 23:26:
De oplossing om data automatisch goed te verdelen over harde schijven heet raid. Natuurlijk zijn er situaties te verzinnen waarin handmatige optimalisaties beter presteren, maar die optimalisaties zullen al snel onbeheersbaar worden.

In geval van kleine files (<blocksizeArray) op de RAID volumes zou ik ook nooit durven beweren dat RAID een slechte methodiek toepast van verdelen van data over schijven. Dan werkt dit zelfs in het bijzonder bij concurrency en willekeur heel goed, inderdaad. Wanneer de situatie zo is dat er grote (> 10 × aantalSchijven × blocksizeArray) files sequentieel en cuncurrent worden gelezen heeft dit nogal nare bijverschijnselen, wat TS terugziet in de performance.

Femme schreef op donderdag 04 juni 2009 @ 23:26:
Ik kan me voorstellen dat er tussen besturingsysstemen en bestandssystemen ook nog significante wel verschillen zijn door pre-fetching optimalisaties. Pre-fetching is in deze situaties de key voor hoge prestaties. Een raid-array moet data eerder inlezen dan deze naar de client wordt verstuurd.

manpage hdparm:

       -a     Get/set  sector  count  for  filesystem (software) read-ahead.
              This is used to improve performance  in  sequential  reads  of
              large  files, by prefetching additional blocks in anticipation
              of them being needed by the running  task.   Many  IDE  drives
              also  have a separate built-in read-ahead function, which aug‐
              ments this filesystem (software) read-ahead function.

       -A     Get/set the IDE drive´s read-lookahead feature (usually ON  by
              default).  Usage: -A0 (disable) or -A1 (enable).

Ik zeg hdparm -a [sector-count] /dev/mapper/mijnontzettendeRAIDvolumevoorgrotefiles
maar in geval van Windows kan ik niet vertellen hoe je dit kan instellen.

Femme schreef op donderdag 04 juni 2009 @ 23:26:
Als je je goed wilt indekken moet je een hotspare paraat hebben staan.

Kan ik het alleen maar mee eens zijn.

Femme schreef op donderdag 04 juni 2009 @ 23:26:
De prestaties van raid-arrays schalen prima als er puur willekeurige I/O wordt uitgevoerd die een zeer hoge concurrency heeft. [...]

Eens, indien requestSize <= blocksizeArray.

[Q]

Met het verhaal van Femme in het achterhoofd: 2x een raid 5 van 8 disks geeft meer io dan 1x 16 in raid5/6 zou je dit kunnen doen: maak 2x raid5 en gooi die samen in een raid 0 tot een raid 50 (?). Heb je 1 array en volgens mij ook nog wat meer performance door te stripen.

Maar met 16 van deze grote disks is raid 5 met 8 disks al een beetje op het randje denk ik. Met 1.5 TB heb je met 8 disks al een 9 TB RAID 6. Dus 2x9 = 18! TB RAID 6. RAID 5 was totaal 21 TB geweest, maar voor die 15% verlies aan capaciteit en de winst aan betrouwbaarheid lijkt me 2x RAID 6 niet eens zo gestoord.

Zeker met het idee om veel parallel files te gaan serveren = random io -> geen grote RAID 6 array maken denk ik.

[ Voor 8% gewijzigd door Q op 05-06-2009 22:25 ]

[Desolation Angel]

[b][message=32044540,noline]
Daarover gesproken, de redundancy heb ik vooral om het falen van een enkele (straks dus twee) disk(s) op te vangen. Het verhaal van URE's is erg interessant, maar mocht er een bitje/block omvallen is het jammer, maar dan moet ik die betreffende file maar als verloren beschouwen, als ik er al überhaupt achter kom. Trouwens, het probleem zal ik altijd tegen gaan komen in de toekomst, welke manier ik ook gebruik. Mits die rate meegroeit met de capaciteit dus, zoals ook in een van de artikelen wordt genoemd. De ideologie dat RAID heilig is heb ik allang achter me gelaten, en heb ook meer dan genoeg keren dataverlies gehad in al zijn vormen. De kans bij meerdere schijven is in ieder geval wel aanwezig dat er een schijf omvalt, dus vandaar RAID-5. Maar dan heb ik dus niet direct een probleem. Het rebuilden gaat best snel; zelfs met de 10-disk array ben ik binnen 24h klaar; afhankelijk van de load kan het zelfs binnen 12h. Daarnaast voer ik ook 2-wekelijks een parity-check uit.

Het probleem met de URE's is vooral een probleem tijdens disk failures. Met raid-5 is de kans zeer groot dat je tijdens een rebuild een URE tegenkomt, en dan spreken we niet over "die file als verloren", neen, dan is je hele array rijp voor het stort want dan is deze totaal corrupt en unrebuildable

[Q]

Desolation Angel schreef op zaterdag 06 juni 2009 @ 00:27:
[...]


Het probleem met de URE's is vooral een probleem tijdens disk failures. Met raid-5 is de kans zeer groot dat je tijdens een rebuild een URE tegenkomt, en dan spreken we niet over "die file als verloren", neen, dan is je hele array rijp voor het stort want dan is deze totaal corrupt en unrebuildable

Bij grote arrays is RAID6 dus eigenlijk noodzakelijk. Eigenlijk is het zo dat RAID6 je dan beschermt tegen slechts 1 diskfaillure omdat bij een tweede het risico op een URE dermate groot is dat het Russische roulette wordt of de array het overleeft.

Althans, dat is het idee. Maar hoe groot is de kans op een URE werkelijk? Een URE is dat een harddisk data niet meer goed kan lezen van disk. Is die kans, met grote arrays echt zo groot.

EDIT:

Is het nu echt zo dat bij een URE je hele disk corrupt raakt? Parrity word toch per stripe berekent? Dat zou hooguit een kapotte file betekenen. Of is dit implementatie-afhankelijk. Ik vraag het me toch af.

Omdat de RAID logica geen weet heeft van het bovenliggende file-system kan niet worden doorgegeven aan het filesystem wat er precies stuk is. Zodoende kun je wel gaan rebuilden, maar je filesystem loopt denk ik in de soep. Volgens mij is dit de reden waarom rebuilden dan geen zin meer heeft.

[ Voor 22% gewijzigd door Q op 06-06-2009 11:27 ]

[Desolation Angel]

als tijdens een rebuild er een read error voorkomt van een werkende disk én er is een kapotte disk, dan is er niet genoeg data meer om ofwel parity ofwel data te berekenen. met als het gevold dat er natuurlijk incosistentie in de array zit. ik ga het het nu niet gaan testen met men eigen data, maar het lijkt me toch wel aannemelijk dat hij je array gewoon als corrupt bestempelt, vermits hij die nooit meer tot 100% integriteit krijgt

[Q]

Desolation Angel schreef op zaterdag 06 juni 2009 @ 13:01:
als tijdens een rebuild er een read error voorkomt van een werkende disk én er is een kapotte disk, dan is er niet genoeg data meer om ofwel parity ofwel data te berekenen. met als het gevold dat er natuurlijk incosistentie in de array zit. ik ga het het nu niet gaan testen met men eigen data, maar het lijkt me toch wel aannemelijk dat hij je array gewoon als corrupt bestempelt, vermits hij die nooit meer tot 100% integriteit krijgt

Maar je zou verwachten dat het hooguit een paar stripes corrupt raken en strikt genomen zou dat niet moeten uitmaken. De meeste filesystems moeten daar wel tegen kunnen, hooguit dat je wat files kwijt raakt. Maar beter iets terug dan niets. Echter: als corruptie alleen plaatsvind binnen een file kom je daar niet achter tot het moment dat je 'm opent.

[ Voor 6% gewijzigd door Q op 06-06-2009 13:14 ]

[Desolation Angel]

Maar een array is geen filesystem he, die vergelijking gaat absoluut niet op. We spreken over corruption op volume level, daar komt zelfs geen filesystem aan te pas

[Q]

Nevermind.

Wat gaat Fauna doen?

[CaptJackSparrow]

Ik zit me ook nog af te vragen of je als aanvullende methodiek om overall distributie throughput te vergroten niet ook gebruik zou kunnen maken van torrents. Desnoods alleen de grootste en meest gevraagde bestanden. Ook hier zal het 80/20 principe waarschijnlijk op gaan (80% van het dataverkeer wordt gegenereerd door 20% van de bestanden).

Dat hoeft de server het niet allemaal in zijn eentje te doen.

Verder zat ik ook te denken aan de ondertussen al genoemde RAID 50 optie als je controller dat aan kan.

[Fauna]

Neen, geen RAID-50 mogelijkheden hier helaas, tenzij ik ze met dynamische disks ga spannen. En eigenlijk wil ik dat vermijden om flexibiliteit te houden mbt evt recoveren van data. Ik betwijfel overigens of het veel verschil uitmaakt tov RAID-6 mbt performance. Ik begin namelijk het idee te krijgen dat de IOP op zijn tenen begint te lopen in extreme situaties. Ik merkte het vandaag met het overpompen van de data; ik had 4 transfers naar de nieuwe array, 3 pass-through disks op de Areca, en 1 op de ICHR. De schijf op de ICHR was dubbel zo snel klaar als de 3 andere disks. Nu had de Areca het ook wel druk met de 3 andere disks en de 10-disk RAID-5, maar als het aan een limitatie van de array zou liggen, zou de data van de 4 disks ongeveer tegelijk op de array moeten staan.

Torrents zijn geen gemeengoed op LAN's, en helaas raakt zelfs FTP uit de gratie. Ik heb nu op de nieuwe array echter wel een NTFS clustersize van 64k gepakt. Dit was de grootst mogelijke optie, en zou met grote bestanden toch iets moeten schelen dunkt me.

Ik heb de situatie dan ook gelaten zoals het is; 1 RAID-5 van 6 disks en 1 RAID-5 van 10 disks. Redundancy gebruik ik alleen voor het mogelijke uitvallen van 1 disk. Mocht er een URE voorkomen op het moment dat de array critical is denk ik niet dat heel het FS op zijn gat gaat. Bij een single disk kunnen er immers ook bits omvallen en valt veel van de data gewoon te recoveren. Vaak is een simpele chkdsk zelfs al voldoende om het FS gewoon weer de oude te laten zijn, muv die ene file dan. Als één bestand de geest geeft is het jammer maar helaas. Bij 12TB verliezen geldt hetzelfde verhaal, maar dan is wel al mijn sorteer- en tagwerk naar de knoppen. De data is dus expendable, maar tot op zekere hoogte wil ik me wel indekken.


Nu ik het topic nog eens doorlees; volgens mij heb ik ooit een situatie meegemaakt die hier op lijkt. Ik had namelijk een disk met bad sectors die af en toe een read error gaf, wat ook in het log van de controller verscheen. Ik heb dat (met m'n domme kop) even zo gelaten, en op een LAN viel er een andere disk weg. Toen ik inlogde, waren er dus 2 disks van een RAID-5 kwijt. De schijf met bad sectors kreeg ik nog wel aan de praat, maar de andere disk was helemaal vastgeslagen. 2 nieuwe disks besteld, en gerebuild met de defecte schijf in de array. Ik weet het niet meer zeker, maar het lijkt me waarschijnlijk dat die disk toen ook read errors heeft gegeven. Deze schijf is er toen iig gelijk uitgegaan en om met de nieuwe schijf te rebuilden om zo weer een stabiele array te krijgen. Ik weet ook niet meer of ik een chkdsk heb uit moeten voeren, maar dat moet haast wel.

Nogmaals, ik kan het me niet meer precies herinneren, maar ik weet wel zeker dat nog zeker 99% van de data intact is. Als dit een analogie is voor de problemen die je evt bij een critical array + URE zou krijgen, stelt mij dit gerust.

/me Fauna zwaait naar Q en heuveltje

[Q]

Fauna schreef op zondag 07 juni 2009 @ 00:58:


Ik heb de situatie dan ook gelaten zoals het is; 1 RAID-5 van 6 disks en 1 RAID-5 van 10 disks. Redundancy gebruik ik alleen voor het mogelijke uitvallen van 1 disk. Mocht er een URE voorkomen op het moment dat de array critical is denk ik niet dat heel het FS op zijn gat gaat. Bij een single disk kunnen er immers ook bits omvallen en valt veel van de data gewoon te recoveren. Vaak is een simpele chkdsk zelfs al voldoende om het FS gewoon weer de oude te laten zijn, muv die ene file dan. Als één bestand de geest geeft is het jammer maar helaas. Bij 12TB verliezen geldt hetzelfde verhaal, maar dan is wel al mijn sorteer- en tagwerk naar de knoppen. De data is dus expendable, maar tot op zekere hoogte wil ik me wel indekken.

Check! Lijkt me helder.

Nu ik het topic nog eens doorlees; volgens mij heb ik ooit een situatie meegemaakt die hier op lijkt. Ik had namelijk een disk met bad sectors die af en toe een read error gaf, wat ook in het log van de controller verscheen. Ik heb dat (met m'n domme kop) even zo gelaten, en op een LAN viel er een andere disk weg. Toen ik inlogde, waren er dus 2 disks van een RAID-5 kwijt. De schijf met bad sectors kreeg ik nog wel aan de praat, maar de andere disk was helemaal vastgeslagen. 2 nieuwe disks besteld, en gerebuild met de defecte schijf in de array. Ik weet het niet meer zeker, maar het lijkt me waarschijnlijk dat die disk toen ook read errors heeft gegeven. Deze schijf is er toen iig gelijk uitgegaan en om met de nieuwe schijf te rebuilden om zo weer een stabiele array te krijgen. Ik weet ook niet meer of ik een chkdsk heb uit moeten voeren, maar dat moet haast wel.

Nogmaals, ik kan het me niet meer precies herinneren, maar ik weet wel zeker dat nog zeker 99% van de data intact is. Als dit een analogie is voor de problemen die je evt bij een critical array + URE zou krijgen, stelt mij dit gerust.

/me Fauna zwaait naar Q en heuveltje

Tnx voor de update. Ik heb zoiets nog nooit meegemaakt maar wat je beschrijft is wat ik zelf zou verwachten. Het is alleen lastig om zoiets te testen, behalve als je een disk hebt met bad sectors oid.

Dus straks 16-2=14x1.5= 21 TB aan storage

[CaptJackSparrow]

Ik kende dat (Strong)DC++ dat je noemde niet en zocht dat uit nieuwsgierigheid nog even op. Ik begrijp dat dit in principe ook een P2P file sharing client is dus je gebruikt dergelijke methodieken al. Je zegt wel dat het geen efficiënt protocol is. Weet niet of het torrent protocol beter zou presteren.

Ik kreeg nl. niet de indruk dat je dergelijke technieken gebruikte omdat je dacht ik beschreef dat bij toenemend aantal file requests de downloadsnelheid per user inzakte. Bij P2P zou de downloadsnelheid van gesharede files juist moeten toenemen bij een groter aantal mensen die het downloaden/sharen, tenzij mensen die het bestand binnen hebben het onmiddellijk verwijderen uit de gesharede pool en niet meer voor uploads ter beschikking stellen.

Waarom werkt dat sharen bij jouw situatie niet?

[Fauna]

Ik had het puur over de efficiëntie op de server zelf, want FTP gaat zonder morren flink wat sneller bij meerdere users. Daarnaast heb ik bij DC meer CPU-load.

Op een DC hub (andere server als ik) heb je meestal een flink aantal gebruikers. Afhankelijk van de instellingen op de client gaat deze ook zoeken naar andere bronnen op die hub, maar de standaardinstelling is dat je handmatig een 'match queue' moet uitvoeren. Mochten er meerdere bronnen gevonden worden voor de files in je queue, gaat de client ook van die user(s) downloaden. Echter is dat meteen een andere file, want meerdere gelijktijdige downloads van 1 file heb ik nog niet in de praktijk gezien.

Naast het feit dat de users deze 'match queue' functie niet altijd weten te vinden, gaan ze altijd het eerst naar de server met de grootste share. Die krijgt verhoudingsgewijs dus meer te verduren. Daar komt ook nog eens bij dat sommige users bijna niets sharen, waaronder dus hun net gedownloadde files.

[kalizec]

Als FTP een stuk sneller is, dan is het 100% een software probleem. Want kennelijk wordt FTP in jouw geval wel geoptimaliseerd door het OS en de drivers tot enkele grote reads en gebeurt dat bij DC niet.

[Fauna]

FTP is gewoon een stuk simpeler, daar komt het op neer. Zowel op DC als FTP krijg ik users die met 80MB/s of meer downloaden, maar bij DC zie je vaker dat de client bij de user het niet meer trekt door downloaden van teveel sources en/of op de achtergrond hashen van files. Met dat hashen heeft DC als hét grote voordeel op een LAN dat je op servers kan zoeken naar de door jou gewenste file. Als dat met bijv. FTP ook kon bood ik niks anders aan, maar de vraag naar DC is gewoon groot en je zou stom zijn om je files daar niet te serveren.

Inmiddels raken we behoorlijk offtopic. De keuze voor de array's is gemaakt, en ik ben niet in de keuze om iets anders te doen m.b.t. software. Hoogstens een andere DC client, maar ik heb al een andere (betere) dan de standaard DC++ client.

[Demo]

Fauna schreef op donderdag 04 juni 2009 @ 09:57:
Over de software: ik weet dat DC++ (StrongDC in mijn geval) een verre van ideaal programma/protocol is. In ieder geval veel overhead en CPU-load. Ik ben bang dat ik de request-size niet kan aanpassen, als ik al kan zien hoe groot dat die zijn. Mijn persoonlijke vermoeden is echter dat door de vele gebruikers een file niet meer efficiënt in een paar grotere blokken is uit te lezen. Meer cache op de controller gaat helaas niet.

Heb je 'compressed and encrypted transfers' oid uit staan? Dat staat standaard aan en je hoeft geen raketgeleerde te zijn om te bedenken dat 100 MB/s compressen en encrypten behoorlijk wat cpu-kracht vraagt (ik verwacht niet dat dit het geval is aangezien jij redelijk bekend bent met het fenomeen DC++)
Ik kan me namelijk niet herinneren dat mijn DC-client echt veel CPU gebruikte nadat ik dat had uitgezet en die had ook enkele TB's op een Areca geshared en gigabit-verbinding.

[ Voor 9% gewijzigd door Demo op 08-06-2009 17:14 ]

[Fauna]

Joah, da's het eerste wat ik uitzet naast wat andere optimalisaties.

[AlexanderB]

heuveltje schreef op vrijdag 05 juni 2009 @ 11:02:
[...]


-Hoezo heb je 4 x zoveel doorvoer ?
-Je bent die 4 disken die parity opslaan ook kwijt, dus daar verlies je performance aan
-Je zit met 4 partities te klooien, wat de TS specifiek niet wil
-ALs van je 10 leechers er 8 data van 1 array willen, stort je performance helemaal in, en staat de helft van je hd's uit zijn neus te vreten.

Ik draai ook een File server op Lanparties, zij het met idd allemaal losse schijven(bewuste keuze) en wat minder budget
en uit ervaring kan ik je zeggen dat er van min 13 disken, het altijd dezelfde 2 zijn waar continu op gehamerd word, en dat zijn :
-De schijf waar je net op geleechte nieuwe films staan.
-De schijf waar je pr0n op staat

* Anoniem: 58354 zwaait naar fauna

daarom moet je je pr0n en je nieuwste meuk ook verdelen over die 4 arrays, dat zie je in DC++ toch niet terug.
Daar gaat dit topic *eigenlijk* over, hoe verdeel je effectief en efficient je data, op zo'n manier dat er zo veel mogelijk over je disks gespreid wordt..

[Fauna]

AlexanderB schreef op maandag 08 juni 2009 @ 18:18:
[...]

daarom moet je je pr0n en je nieuwste meuk ook verdelen over die 4 arrays, dat zie je in DC++ toch niet terug.

Daar ben ik het niet mee eens, want iedere map die je shared op DC wordt ook een andere map in de share. Je kan wel gaan nesten enzo, maar dat is dus precies wat ik niet wil. Ik haat het echt als ik servers tegen kom waar ik alle 23 disks moet doorzoeken om te kijken of er iets interessants tussen zit. Nu zal dat met 4 array's/partities wel meevallen opzich, maar je blijft aan het schuiven, en je ontkomt er bij de grootste mappen (films en series, ieder zo'n 5TB inmiddels) niet aan om ze dan te verdelen over meerdere array's. De meest gevraagde data heb ik inmiddels al anders verdeeld over de 2 array's, en komend weekend zal blijken of het succes heeft.

[heuveltje]

AlexanderB schreef op maandag 08 juni 2009 @ 18:18:
[...]

daarom moet je je pr0n en je nieuwste meuk ook verdelen over die 4 arrays, dat zie je in DC++ toch niet terug.
Daar gaat dit topic *eigenlijk* over, hoe verdeel je effectief en efficient je data, op zo'n manier dat er zo veel mogelijk over je disks gespreid wordt..

Dan zou je dat elke keer opnieuw moeten bijwerken. sowieso moet je dan al iets als " films" en "films nieuw" gaan maken. en dat zijn alle 2 dingen die ik (en fauna) allebei willen voorkomen !

Fauna schreef op maandag 08 juni 2009 @ 19:49:
[...]


Daar ben ik het niet mee eens, want iedere map die je shared op DC wordt ook een andere map in de share. Je kan wel gaan nesten enzo, maar dat is dus precies wat ik niet wil. Ik haat het echt als ik servers tegen kom waar ik alle 23 disks moet doorzoeken om te kijken of er iets interessants tussen zit. Nu zal dat met 4 array's/partities wel meevallen opzich, maar je blijft aan het schuiven, en je ontkomt er bij de grootste mappen (films en series, ieder zo'n 5TB inmiddels) niet aan om ze dan te verdelen over meerdere array's. De meest gevraagde data heb ik inmiddels al anders verdeeld over de 2 array's, en komend weekend zal blijken of het succes heeft.

Sauna dat klopt maar half. Het is idd iritant voor jezelf. Maar je gebruikers hoeven het niet te merken ...
Als je map A shared als "Pr0n" en dan opgeeft dat je map B ook als "pr0n" wil sharen. dan zal DC++ die 2 mappen virtueel samenvoegen. hebben ze in 1 van de laatste versies toegevoegd

als ik nou ook een manier wist om dat in Windows File Sharing werkend te krijgen......................
Want voor de rest blijven verschillende schijven gewoon iritant, en veels te snel vol raken
Maar dat vind ik wel weer opwegen tegen de voordelen

[ Voor 22% gewijzigd door heuveltje op 08-06-2009 20:21 ]

[CaptJackSparrow]

Het zou natuurlijk helemaal handig zijn als er automatisch gebaseerd op in te stellen criteria van populaire bestanden een kopie op de tweede array gezet zou kunnen worden en ook de load automatisch over beide arrays verdeeld zou worden. Is zoiets niet al ontwikkeld?

[Fauna]

heuveltje schreef op maandag 08 juni 2009 @ 20:15:
Sauna dat klopt maar half. Het is idd iritant voor jezelf. Maar je gebruikers hoeven het niet te merken ...
Als je map A shared als "Pr0n" en dan opgeeft dat je map B ook als "pr0n" wil sharen. dan zal DC++ die 2 mappen virtueel samenvoegen. hebben ze in 1 van de laatste versies toegevoegd

als ik nou ook een manier wist om dat in Windows File Sharing werkend te krijgen......................
Want voor de rest blijven verschillende schijven gewoon iritant, en veels te snel vol raken
Maar dat vind ik wel weer opwegen tegen de voordelen

Hm cool, dat wist ik niet. Goed om in het achterhoofd te houden voor het geval dat. Nu nog idd een manier om het op de server zelf of desnoods via een share op een of andere manier te koppelen. Dan heb je wel zelf de controle over op welke schijf dat het staat, maar is het toch als 1 virtual folder te zien.

[ Voor 32% gewijzigd door Fauna op 08-06-2009 21:58 ]

[Milmoor]

heuveltje schreef op maandag 08 juni 2009 @ 20:15:
Als je map A shared als "Pr0n" en dan opgeeft dat je map B ook als "pr0n" wil sharen. dan zal DC++ die 2 mappen virtueel samenvoegen. hebben ze in 1 van de laatste versies toegevoegd
als ik nou ook een manier wist om dat in Windows File Sharing werkend te krijgen......................

Die zijn er wel, hoewel het iets meer werk is:
De eenvoudigste: je kan een partitie als folder onder de root van een andere schijf mounten. Je moet de bestanden dan wel zelf over de partities verdelen (bijv. op alphabet), maar de gebruiker merkt daar niets van.
Je kan ook in Windows met hard/soft links werken, dan ben je zo flexibel als je het jezelf moeilijk wil maken. Zie bijv. hier voor wat uitleg.
Beide mogelijkheden zijn voor mij puur theorie, ik weet niet hoe dit samenwerkt met Windows shares of met programma's die erg diep in het OS geworteld zijn. Ik verwacht echter dat dit goed gaat.

[ Voor 5% gewijzigd door Milmoor op 09-06-2009 18:02 . Reden: Betere link naar informatie over links ;) ]

[Matis]

Milmoor schreef op dinsdag 09 juni 2009 @ 07:59:
[...]

Die zijn er wel, hoewel het iets meer werk is:
De eenvoudigste: je kan een partitie als folder onder de root van een andere schijf mounten. Je moet de bestanden dan wel zelf over de partities verdelen (bijv. op alphabet), maar de gebruiker merkt daar niets van.
Je kan ook in Windows met hard/soft links werken, dan ben je zo flexibel als je het jezelf moeilijk wil maken. Zie bijv. hier voor wat uitleg.
Beide mogelijkheden zijn voor mij puur theorie, ik weet niet hoe dit samenwerkt met Windows shares of met programma's die erg diep in het OS geworteld zijn. Ik verwacht echter dat dit goed gaat.

Ja, dat is een goede. Zo heb ik mijn Video-map (externe usb-schijf) ook onder mijn eigen C: dir gemount met een softlink. Dit omdat Media Player Classic geen DVD's kan spelen als hij niet op de interne hardeschijf staat Met zo'n softlink denkt het systeem dat de map (wel beide NTFS natuurlijk) gewoon bij de C: schijf hoort. Problem solved
Ik weet niet welk OS je wilt graan draaien, maar symbolische links werken AFAIK pas echt lekker vanaf Vista en Server 2k8 voor Windows, Linux weet ik niet

[kalizec]

Matis schreef op dinsdag 09 juni 2009 @ 08:11:
maar symbolische links werken AFAIK pas echt lekker vanaf Vista en Server 2k8 voor Windows, Linux weet ik niet

Symbolische links voor Linux en Unix werken al langer goed dan Windows bestaat.

[Matis]

kalizec schreef op dinsdag 09 juni 2009 @ 09:00:
Symbolische links voor Linux en Unix werken al langer goed dan Windows bestaat.

Ik vroeg daarom ook aan de TS wat voor OS hij wilde gebruiken

[Fauna]

Ik werk momenteel met Windows Server 2003. Ik heb op een andere partitie wel nog een trial van 2008 staan, zou even moeten kijken of die nog zin heeft om op te starten. Dan eens gaan uitzoeken hoe dat zit met die symbolische links.

[Milmoor]

Het mounten kan meen ik al vanaf NT (eigenlijk vanaf NTFS), de flexibeler hard/soft links inderdaad pas later.

[muppet99]

Even nog over het sequetieel downloaden van dezelfde file van meerdere users. Er was vroeger (Ik heb een Ynhub gehad op DC) een client die dit wel kan. Zion heette deze. Hij was ten strengste verboden op de meeste hubs, maar je kunt die wel gebruiken op lan party's. Aangezien je de hub owner kent kun je aanvragen of hij zion door de client check wil laten gaan.

link gebruik de green client. De Blue client is voor hub-ops en owners. Geel is de chatclient en heeft geen share mogelijkheden.

Hopelijk kom je hiermee weer een stappie verder

[heuveltje]

muppet99 schreef op dinsdag 09 juni 2009 @ 10:27:
Even nog over het sequetieel downloaden van dezelfde file van meerdere users. Er was vroeger (Ik heb een Ynhub gehad op DC) een client die dit wel kan. Zion heette deze. Hij was ten strengste verboden op de meeste hubs, maar je kunt die wel gebruiken op lan party's. Aangezien je de hub owner kent kun je aanvragen of hij zion door de client check wil laten gaan.

link gebruik de green client. De Blue client is voor hub-ops en owners. Geel is de chatclient en heeft geen share mogelijkheden.

Hopelijk kom je hiermee weer een stappie verder

dc++ kan dat ook. alleen staat het standaart uit
is voor lanparties ook vaak een niet nuttige toevoeging. download in 9 van de 10 blokken van mensen met 10MB/s en vervolgens wacht je een hald uur op dat ene blok dat met 400Kb/s binnenkomt.

[quote]Milmoor schreef op dinsdag 09 juni 2009 @ 07:59:
De eenvoudigste: je kan een partitie als folder onder de root van een andere schijf mounten. Je moet de bestanden dan wel zelf over de partities verdelen (bijv. op alphabet), maar de gebruiker merkt daar niets van. Hmm daar had ik zelf ook al aan gedacht.
maar nu heb ik gewoon 3 shares. Films 1, Films 2,Films 3
Dan zou ik dus een share Films hebben met daarin submappen Films 1,Films 2,Films 3
Vind ik persoonlijk eerder een stap naar achteren dan voorruit


Je kan ook in Windows met hard/soft links werken. bijv. hier voor wat uitleg.
Beide mogelijkheden zijn voor mij puur theorie, ik weet niet hoe dit samenwerkt met Windows shares of met programma's die erg diep in het OS geworteld zijn. Ik verwacht echter dat dit goed gaat.
Kijk dat is interesant, binnen linux kende ik het wel. maar binnen Windows Server(wat ik draai) is het nieuw voor me.
Helaas vallen hard-links per direct af (you cannot create a hard link on a different drive)
Dat soft link gebeuren moet ik eens even goed voor gaan zitten

[Fauna]

Ik ben al wat aan het uitzoeken geweest, en ff getest met het Sysinternals 'Junction' commando. Waar ik echter op stuit is dat de naam van de junction uniek moet zijn. Anders gezegd, feitelijk kan je 2 mappen nog niet mergen naar 1. Het tooltje geeft dan aan dat de map al bestaat. Ook 2 junctions aanmaken met dezelfde linkdir en een andere target werkt niet; de ene overschrijft de andere.

Hoe het in vista/2008 werkt met softlinks zal ik nog moeten uitzoeken, maar ik verwacht dat het op hetzelfde neerkomt.

Edit: vista doet hetzelfde

Overigens werkt het mergen van folders wel prima in DC en ook mijn FTP server ondersteunt het. De manier om het zelf overzichtelijk te krijgen in explorer is blijkbaar lastiger....

[ Voor 18% gewijzigd door Fauna op 09-06-2009 11:56 ]

[Milmoor]

Dat ze niet hetzelfde mogen zijn is ook logisch. Vanuit het OS lijkt het een gewoon bestand/folder, die moeten altijd een unieke naam hebben. Het is geen mergetool, het is een alternatieve manier van bestanden en folders in een boom hangen. Het voordeel van links t.o.v. mounten is dat je in allerlei kruisverbanden kan maken en ook in subfolders kan werken. Maar het \\pc\films\films2\filmnaam effect blijf je houden.
In theorie zou je trouwens elk individueel bestand met een softlink kunnen koppelen, maar dat wil je alleen doen als het of weinig bestanden zijn of je er een tool voor hebt. Dan heb je precies wat je zoekt, maar mooi is anders.
Zie hier voor meer informatie over links, deze is beter geschikt dan degene die ik eerder noemde. Die heb ik dan ook aangepast.

[ Voor 38% gewijzigd door Milmoor op 09-06-2009 18:03 . Reden: Verduidelijking. ]