één volume van 40TB

[jaapbrandhof]

Hallo,

Ik zoek een mogelijkheid om een volume van 40TB te creeën.
Zelf heb ik er niet echt verstand hoe dit voor elkaar te krijgen. Ik weet dat je meerdere machines aan elkaar moet koppelen.

Heeft iemand enig idee hoe?

Alvast bedankt voor reacties.

[j-a-s-p-e-r]

Raid 0 of iets in die gooi wellicht. Heb je zelf al gezocht? En wat heb je toen gevonden?

[ Voor 19% gewijzigd door j-a-s-p-e-r op 22-08-2007 16:32 ]

[Kawaii]

Leuke dataserver aanschaffen? Zet maar vast een pak geld opzij.

[Verwijderd]

RocketRAID 2340 (16-poort SATA) met elk 16 schijfjes van 1TB (Samsung F1 bijv.)
dan 2 controllers (32TB dus) en op de onboard controller nog eens 8 ofzo (40TB).

Dan kun je een concat gebruiken om 1 volume te creeeren. Wil je RAID dan verlies je natuurlijk wel wat ruimte, en 40 schijven in RAID5 is wellicht niet super veilig meer. Maar je kunt de twee RocketRAID volumes ook RAID5 maken zodat je hebt:

16-disk RAID5 = 15TB
16-disk RAID5 = 15TB
8-disk RAID5 = 7TB

Die drie zet je dan in concat zodat je hebt:
15+15+7 = 37TB

Uiteindelijk mis je dan 3 schijven aan parity. Andere keuze zou zijn 24-poort controllers gebruiken.

Oh en 40-disks spin-up met 30W is 1200W piekbelasting, komt die 2 kilowatt voeding op de FP van een tijdje terug toch nog eens van pas.

[Verwijderd]

voorwat heb je 40T nodig ????

[EXX]

j-a-s-p-e-r schreef op woensdag 22 augustus 2007 @ 16:32:
Raid 0 of iets in die gooi wellicht. Heb je zelf al gezocht? En wat heb je toen gevonden?

JBOD lijkt me iets verstandiger

[soulrider]

JBOD, Raid 5, ....
een "gewone"-raid controller heeft meestal een 2TB grens per volume.
(zelfs de 24-poorts-controllers, maar met linux en de juiste drivers is dit mogelijk aanpasbaar, zo 2 controllers vol met 1TB-schijven, geeft je 40 TB opslag en 8 TB redundantie)

we mogen aannamen dat het hier vooral de ruimte is en niet de snelheid die telt?

en anders zijn er wrs genoeg cluster-varianten van linux waarmee je 1 groot volume mee kunt aanmaken. (google kan je wel wat verder helpen wrs)

maw: wat heb je zelf al gezocht (waar/welke zoektermen/...)
voor deze grootte is het al linux/solaris/dataserver windows-variant die je moet gaan bedenken

[ Voor 15% gewijzigd door soulrider op 22-08-2007 16:39 ]

[trixx]

Ik denk dat als je niet weet hoe dit moet je het ook niet moet proberen.....

[bakkerl]

Kijk eens naar een EMC^2 of een netApp. Die dingen zijn er voor bedoelt om dat soort volumes te hebben...

trixx schreef op woensdag 22 augustus 2007 @ 16:36:
Ik denk dat als je niet weet hoe dit moet je het ook niet moet proberen.....

Daar heb je geheel gelijk in.

[ Voor 51% gewijzigd door bakkerl op 22-08-2007 16:47 ]

[AtleX]

Ga eens praten met Dell/HP/IBM oid. Voor zo'n setup willen ze wel een leuk prijsje maken.

[Verwijderd]

soulrider schreef op woensdag 22 augustus 2007 @ 16:36:
JBOD, Raid 5, ....
een "gewone"-raid controller heeft meestal een 2TB grens per volume.

Zelfs een cheap-ass controller als Highpoint RocketRAID RR2340 heeft 64-bit LBA hoor.

RAID Controller met enkel 48-bit LBA moet zich schamen.

[sariel]

sannetje aanschaffen?

[BCC]

AtleX schreef op woensdag 22 augustus 2007 @ 16:37:
Ga eens praten met Dell/HP/IBM oid. Voor zo'n setup willen ze wel een leuk prijsje maken.

Inderdaad. Je moet meer aan NAS / SAN oplossingen gaan denken. Zeker omdat het vast geen 40 TB onbelangrijke data is.

[Verwijderd]

Komkom ICT student,

huiswerk moet je zelf oplossen

[soulrider]

Verwijderd schreef op woensdag 22 augustus 2007 @ 16:38:
[...]

Zelfs een cheap-ass controller als Highpoint RocketRAID RR2340 heeft 64-bit LBA hoor.

RAID Controller met enkel 48-bit LBA moet zich schamen.

Ja idd blijkt niet controller afh. maar OS afh.
(maar de zot die een standaard desktop OS hiervoor gebruikt gaan ze wrs ook nog moeten gaan maken)
voorbeeld van 3ware

Auto carving allows LUNs > 2TB to be divided into multiple units for legacy operating systems limited to 2TB max. per LUN.

Maar zoals hierboven al vermeld: je moet rekening houden met het starten van de schijven, en failover/hotswap/... de leveranciers zien je wrs liever komen voor een onderhoudscontractje enzo.
Dit is niet echt nog een huis-, tuin, en keuken- servertje.

[jaapbrandhof]

Een klant van ons wil 40TB hebben. Wat ze er precies mee gaan doen is mij niet duidelijk.

Waar we hier zelf aan zaten te denken is Open-E NAS als OS. Van Chenbro willen we een chassis gaan gebruiken. Zij hebben een 5U chassis waar 24 disken in kunnen, 24 x 1TB levert effectief 23TB op bij gebruik van een Areca 1180/1280 24 poorts controller en een RAID 5 array.

Hier mee kom je er dus nog niet.

Mijn specifieke vraag is nu hoe je 2 van zulke systemen aan elkaar kan koppelen.


Waarom ik deze informatie eerst nog niet gaf had meer de reden om te kijken wat voor een ideeën jullie hadden.

[bakkerl]

spoiler:

http://www1.euro.dell.com...l&cs=RC1078544&l=nl&s=pad

De kleinste doet max 38TB, de grootste tot 253TB. Daar moet toch wel iets tussen zitten als _mogelijke_ oplossing.

[BCC]

jaapbrandhof schreef op woensdag 22 augustus 2007 @ 16:49:
Een klant van ons wil 40TB hebben. Wat ze er precies mee gaan doen is mij niet duidelijk.

Misschien wil je dat dan eerst vragen

Mijn specifieke vraag is nu hoe je 2 van zulke systemen aan elkaar kan koppelen.

Via een SAN/NAS

[bakkerl]

jaapbrandhof schreef op woensdag 22 augustus 2007 @ 16:49:
Een klant van ons wil 40TB hebben. Wat ze er precies mee gaan doen is mij niet duidelijk.

Waar we hier zelf aan zaten te denken is Open-E NAS als OS. Van Chenbro willen we een chassis gaan gebruiken. Zij hebben een 5U chassis waar 24 disken in kunnen, 24 x 1TB levert effectief 23TB op bij gebruik van een Areca 1180/1280 24 poorts controller en een RAID 5 array.

En zolang je niet weet wat ze er mee gaan doen kun je ook niets voorstellen. Als jij met zo'n oplossing 40TB wil gaan maken, dan is de performance LAAG (ja, in hoofdletters).
Ik neem aan dat als ze 40TB willen, dat ze ook genoeg IO willen om dat leuk te kunnen vullen en gebruiken.

[BCC]

bakkerl schreef op woensdag 22 augustus 2007 @ 16:52:
En zolang je niet weet wat ze er mee gaan doen kun je ook niets voorstellen. Als jij met zo'n oplossing 40TB wil gaan maken, dan is de performance LAAG (ja, in hoofdletters).
Ik neem aan dat als ze 40TB willen, dat ze ook genoeg IO willen om dat leuk te kunnen vullen en gebruiken.

Behalve als het archivering is.. en dan willen ze raid 5

[bakkerl]

BCC schreef op woensdag 22 augustus 2007 @ 16:54:
[...]
Behalve als het archivering is.. en dan willen ze raid 5

Dat is dus uiteindelijk afhankelijk van het gebruikt.. en dat weet die dus net niet
Daarnaast zou ik bij dit soort aantallen van disken niet meer voor raid5, maar voor raid6 gaan.

[jaapbrandhof]

Raid 6 is inderdaad wel wat verstandiger. Meer redundantie is wel handig met dit soort oplossingen.

[BCC]

bakkerl schreef op woensdag 22 augustus 2007 @ 16:56:
Dat is dus uiteindelijk afhankelijk van het gebruikt.. en dat weet die dus net niet
Daarnaast zou ik bij dit soort aantallen van disken niet meer voor raid5, maar voor raid6 gaan.

Een taperobot is oneindig cooler http://www.gridpp.ac.uk/tier1a/tier1_tape.jpg

[Dukey]

bakkerl schreef op woensdag 22 augustus 2007 @ 16:56:
[...]


Dat is dus uiteindelijk afhankelijk van het gebruikt.. en dat weet die dus net niet
Daarnaast zou ik bij dit soort aantallen van disken niet meer voor raid5, maar voor raid6 gaan.

Precies, de kans dat er nog schijf kaduuk gaat terwijl je net je array aan repareren bent is natuurlijk groot bij een array van 24 disks en terabyte schijven.

[Verwijderd]

Bij het bedrijf waar ik werk leveren wij dit soort oplossing, interesse? neem maar contact met me op...
wij zorgen voor security en storage voor MKB en enterprise bedrijven.

[Mishmash]

Dit soort dingen moet je niet zelf in mekaar gaan knopen... Je doet er veel verstandiger aan dit uit te besteden naar Dell, Sun of HP. Ben je misschien wel iets meer kwijt, maar dan heb je iig een systeem waar alle componenten goed op elkaar afgestemd zijn!

[bakkerl]

BCC schreef op woensdag 22 augustus 2007 @ 17:00:
[...]

Een taperobot is oneindig cooler http://www.gridpp.ac.uk/tier1a/tier1_tape.jpg

Afhankelijk van het gebruik ja.
Ik heb hier een SANnetje staan welke voor videobewerking is gebruikt. Dat red je niet met tapes hoor.. wordt lang wachten voordat je videofragment beschikbaar heb. Maar deze 15k rpm disken SAN had dan ook een specifiek doel.

[FlorisB]

bakkerl schreef op woensdag 22 augustus 2007 @ 16:56:
[...]


Dat is dus uiteindelijk afhankelijk van het gebruikt.. en dat weet die dus net niet
Daarnaast zou ik bij dit soort aantallen van disken niet meer voor raid5, maar voor raid6 gaan.

Nou raid6 bij dit soort opstellingen wil je ook niet denk ik, als ze dr data écht wil bewaren moet je misschien raid51 overwegen, maar dan heb je wel een verdubbeling in kosten.

[bakkerl]

FlorisB schreef op woensdag 22 augustus 2007 @ 17:04:
[...]

Nou raid6 bij dit soort opstellingen wil je ook niet denk ik, als ze dr data écht wil bewaren moet je misschien raid51 overwegen, maar dan heb je wel een verdubbeling in kosten.

Waarom dan geen raid 61 he. Op de aantallen disken die net genoemt werden zou dat maar 6 disken extra zijn En als we dan toch doorgaan.. waarom dan geen 2e SAN welke in sync blijft op een remote locatie.

[Verwijderd]

soulrider schreef op woensdag 22 augustus 2007 @ 16:46:
Ja idd blijkt niet controller afh. maar OS afh.

Jawel het is controller afhankelijk. Behalve bij fake RAID dan. Maar je koopt geen RAID controller die zich tot 2TB limiteert, dan kom je bij 3 disks al tekort. Of het moet om een oude kaart gaan dan.

En misschien de beste oplossing:

Areca 24-poort in RAID6, effectief 22TB
Areca 16-poort in RAID6, effectief 14TB

22+14 = 36TB aan redelijk veilige storage. Moet je mee vooruit kunnen? Als het 1 volume moet zijn kun je er een concat van maken natuurlijk.

Leg je klant ook even het verschil uit tussen TB en TiB. Want straks ziet hij 32,7T staan terwijl hij 36TB aan storage heeft. Dat gaat geheid klachten opleveren.

[bakkerl]

Verwijderd schreef op woensdag 22 augustus 2007 @ 18:21:
[...]
En misschien de beste oplossing:

Beste? Naar mijn inzicht eens van de goedkopere.. Maar hoeft dus afhankelijk van (voor ons onbekende) eisen niet de beste te zijn!

Enlightenment schreef op woensdag 22 augustus 2007 @ 18:21
Areca 24-poort in RAID6, effectief 22TB
Areca 16-poort in RAID6, effectief 14TB

22+14 = 36TB aan redelijk veilige storage. Moet je mee vooruit kunnen? Als het 1 volume moet zijn kun je er een concat van maken natuurlijk.

Waarom dan niet 2x Areca 24-poort in RAID6, effectief 22TB.
Dat zit je op 44TB, voldoet meer aan de eisen van de TS, dan 36TB.

[JumpStart]

• Hoeveel mag het kosten?
• Moet er een service contract bij?
• Zo ja, wat voor eentje?
• Hoe hoog moet de betrouwbaarheid zijn?
• Hoe goed moet de uptime zijn? 3N? 4N? 5N?
• Hoeveel gebruikers moeten er tegelijkertijd bij kunnen?
• Enig idee wat voor data verkeer het slurpt?
• IS dit de backup, of moet de data ook nog op tape?
• Is er serverruimte / 19" Rack ruimte voor beschikbaar?
• Ook al nagedacht over beheer- en monitoring software?
• Moet het NAS zijn of SAN?

Oftewel, je moet véél meer informatie aandragen voordat je iets zinnigs kan zeggen hierover.

[fleppuhstein]

Ik moet de eerste klant nog tegen komen die alleen zegt we willen 40TB opslag.

Meestal als een klant zoiets vraagt weet hij vast wel meer te vertellen, doettie dat niet is het jouw taak als "verkoper" dat aan hem te vragen. 40TB ga je namelijk niet als 1 volume creeren over twee computertjes. bij 40TB zal ook doorvoer wel belangrijk zijn. En ik denk ook wel zn RAID levels. Vervelend als je 1 disk stuk is, ervolgens moet wachten tot de nieuwe er is, en dan je backup van 40 TB terug zetten. Owja, en dan heb ik het nog niet over de array synch, bij 40 disken (RAID 0 level) zal dat wel even (gokje: Twee weken). duren.

Pak het gewoon proffi aan, en zoek een goede SAN oplossing. Google maar eens naar HP EVA. Mooie SAN omgeving, met FibreChannel Disken. Kan met een redundant controller worden uitgevoerd, en doet al het werk voor je.

En bedenk ook dat Disk of San geen secure backup is, het is slechts Nearline Strorage. Dus misschien is een HP ESL een leuke extraatje voor de backup.

BCC schreef op woensdag 22 augustus 2007 @ 17:00:
[...]

Een taperobot is oneindig cooler http://www.gridpp.ac.uk/tier1a/tier1_tape.jpg

Lang niet zo groot als de oplossingen van StorageTech. Kan je ten minste een deur opentrekken, en naar binnen lopen.

[ Voor 20% gewijzigd door fleppuhstein op 22-08-2007 20:23 ]

[markje1]

Verwijderd schreef op woensdag 22 augustus 2007 @ 17:00:
Bij het bedrijf waar ik werk leveren wij dit soort oplossing, interesse? neem maar contact met me op...
wij zorgen voor security en storage voor MKB en enterprise bedrijven.

ik denk dat je dat het beste kan doen. ik denk niet dat ze het leuk vinden als het product dat je geleverd hebt binnen no-time problemen oplevert.... ik zou ze ook goed informeren over de risico's als er een HD opeens mee stopt

[Verwijderd]

bakkerl schreef op woensdag 22 augustus 2007 @ 19:56:
[...]

Beste? Naar mijn inzicht eens van de goedkopere.. Maar hoeft dus afhankelijk van (voor ons onbekende) eisen niet de beste te zijn!

Helemaal mee eens, je hebt gelijk.
Persoonlijk vind ik het een uitdaging om voor een bepaald eisenpakket (in dit geval dus enkel 40TB) de meest goedkope/efficiente oplossing te verzinnen. Maar andere mensen maakt het geen moer uit of het ding duizend euro meer kost of niet. Dus dat is inderdaad een verschil.

Waarom dan niet 2x Areca 24-poort in RAID6, effectief 22TB.
Dat zit je op 44TB, voldoet meer aan de eisen van de TS, dan 36TB.

Alweer gelijk.
Maar hij had het over 40TB, zonder te vermelden of dat bruto of netto (excl. RAID-overhead) moest zijn. (om mezelf er nog even uit te kunnen praten )

[ Voor 9% gewijzigd door Verwijderd op 22-08-2007 22:37 ]

[killercow]

hmm, klinkt misschien raar, maar waarom niet gewoon 10 kleine x86 machines met elk een tb of 8, en deze dan via lustre als een groot clustered filesystem aanbieden aan je users?
Heb je ook meteen redundancy, high performance, en high availability, en dat allemaal zonder perer dure raid controllers.

scale out, not up.

[ Voor 3% gewijzigd door killercow op 22-08-2007 22:43 ]

[jealma]

De Areca's kunnen idd 64bit LBA aan. Ik zou denk ik dan twee Areca ARC1280 24-poorts controllers in een systeem stoppen, 48 schijven van 1TB eraan hangen en dan meerdere raid sets van RAID5 maken, bijvoorbeeld 2 per controller. Per controller dan 2 global hotspares, 22 disken, waarvan 11 in een RAID5 array en nog eens 11 in een RAID5 array, dan kom je op 20TB, hetzelfde voor de andere controller. Deze vier array's van 10TB kun je dan met LVM aan elkaar knuppen en zo is het geheel behoorlijk redundant. Zorg wel voor een intel server board met PCI-e en onboard vga en een C2D ofzo.

Beste advies: is al gegeven, namelijk Dell/HP/Sun opbellen.

[Alfa Novanta]

Raid 5 is sowieso out-of-the-question .. Raid 6 komt eerder. Je moet minimaal 40 schijven hebben, dus de kans dat er gelijktijdig 2 kapot zijn/gaan is best aanwezig. Het zal niet tegelijkertijd zijn, maar tijdens het rebuilden van de defecte zal er uiteindelijk vast eens een keer een 2e ermee kappen en dan zit je.

Anyway, ik denk dat je hier een heel eind mee komt

http://h41131.www4.hp.com...ageWorks_EVA_8000_mid.jpg

edit: aansluitend op mijn onderbuurman, je zou zelfs een EVA <> EVA backup moeten gaan maken, anders red je het niet.

[ Voor 57% gewijzigd door Alfa Novanta op 22-08-2007 22:55 ]

[Pascal Saul]

Ik denk dat de vragen van JumpStart het beste beantwoord kunnen worden. Zelfs wij hebben geen volumes van 40TB , overigens werken wij door best practices met RAID10 over het algemeen. Uiteraard is het doel niet onbelangrijk in dit geval, laat staan backups van 40TB! Zelfs een LTO-4 gaat dat niet trekken denk ik zo In elk geval wil je volumes met deze grote van order middels een SAN verkrijgen.

[killercow]

je kunt ook 2 van deze bij sun kopen, zfs kun je vast wel mounten als 1 share.
http://www.sun.com/servers/x64/x4500/
24tb per stuk.

[JumpStart]

Maar euhh, praktisch gezien:

Minstens:

• Een kwart hoogte (12U) 19" Rack, danwel enclosure
• Twee stuks 4U 24 HD enclosure SCSI to SATA
• 1U (of 2U kan ook) fileserver met dual redundant SCSI U360 controllers

Eonstor van www.infortrend.com bijvoorbeeld: 4U enclosure, dual redundant PSU, dual redundant SCSI U320 naar SATA-II hardware RAID controller. Hier kunnen 24 schijven in.

Totaal: 48 schijven, 4 arrays van 12 schijven, iedere array in RAID 6, arrays samenvoegen en presto: effectief 40 TB, uitgaande van 1 TB schijven. Alleen wie komt er dan binnen 24 uur aanzetten als er een schijf ploft en een array in degraded mode draait ?

Zelf zou ik nog wat conservatiever doen. 24 schijven per enclosure: 2 global hot spares, en dan 22 schijven over, voor 2 arrays van 11 in RAID 6. Dan heb je 18 TB per enclosure, voor 36 TB totaal.

[DrBOB101]

jaapbrandhof schreef op woensdag 22 augustus 2007 @ 16:49:
Waarom ik deze informatie eerst nog niet gaf had meer de reden om te kijken wat voor een ideeën jullie hadden.

De policy op GoT is dat je zelf zo veel mogelijk (uit)zoekt.
Als je geen idee hebt waar je moet beginnen zou ik zo'n opdracht van een klant niet aannemen.

[bakkerl]

killercow schreef op woensdag 22 augustus 2007 @ 22:43:
hmm, klinkt misschien raar, maar waarom niet gewoon 10 kleine x86 machines met elk een tb of 8, en deze dan via lustre als een groot clustered filesystem aanbieden aan je users?
Heb je ook meteen redundancy, high performance, en high availability, en dat allemaal zonder perer dure raid controllers.

scale out, not up.

Omdat Lustre nog beperkt is met 'raid' mogelijkheden over zijn eigen nodes heen. Als bij lustre, in dit geval 1 van de 10 nodes uit zou vallen, dan is (tijdelijk) de gehele 40TB niet beschikbaar. Natuurlijk heb je bij een SAN ook een mogelijkheid dat een node uitvalt, alleen zijn deze er meestal voor gemaakt om de 5N te kunnen halen. 10 kleine x86 machines zou ik max willen inzetten met 3N.

Zelfs al zou je de nodes bij lustre redunant willen maken, dan heb je spontaan 20 kleine x86 nodes (+2 als NDS). Je beheer kosten zijn dan al snel hoger dan een nette SAN.


Maar goed, laat de TS eerst maar eens met antwoorden komen op de vragen, voordat we allerlei exotische oplossingen gaan bedenken, die straks niet eens wenselijk zijn of binnen enig budget vallen.

[ Voor 9% gewijzigd door bakkerl op 23-08-2007 09:00 ]

[Alfa Novanta]

bakkerl schreef op donderdag 23 augustus 2007 @ 08:59:
.. de 5N te kunnen halen. 10 kleine x86 machines zou ik max willen inzetten met 3N.

call me stupid, maar 5N, 3N?! nodes bedoel je

Maar goed, laat de TS eerst maar eens met antwoorden komen op de vragen, voordat we allerlei exotische oplossingen gaan bedenken, die straks niet eens wenselijk zijn of binnen enig budget vallen.

idd

we worden zo aardig aan het lijntje gehouden, de spanning stijgt ten top .. wat is nu eigenlijk de bedoeling?? Welke top-cliënt wil zomaar ffies 40 TB hebben?! tell us

[JumpStart]

ing._Buttje schreef op donderdag 23 augustus 2007 @ 09:09:
[...]

call me stupid, maar 5N, 3N?! nodes bedoel je

Okay, you're stupid!



Maar 3N, of 4N, of 6N (enz.) staat op het aantal negens.

3N = 99,9%
5N = 99,999%
enzovoort.

5N zuiver koper is volgens audiofielen echt een must voor goede geluidsbelevenis. Dan hebben ze het dus over koper dat 99,999% puur is. In dit geval gaat het over uptime. Een 6N uptime is vrij fors, dan mag slechts 0,0001% van de tijd het systeem niet beschikbaar zijn. Minder dan een uur per jaar.

[Alfa Novanta]

heej koel, die kende ik nog niet. Thanks

[leuk_he]

Alleen al het feit dat je het over een volume hebt en niet of een disk geeft al aan dat je een OS hebt dat meerdere Disken bij alkaar kan schuiven tot een volume.

Maar pas als je een OS, Beschikbaarheid, performance en backup (!) mogelijkheiden weet kun je oplossingen gaan zoeken.

(maar aangezien goedkoopste HD van 500 MB Gigabyte iets van 100 euro kost en je hebt er daar al 100 (raid5) van nodig geef aan dat je nooit onder de 10.000 euro gaat komen, reken op een veelvoud hiervan (eerder 10x dan 2x) )

[soulrider]

leuk_he schreef op donderdag 23 augustus 2007 @ 11:41:
Alleen al het feit dat je het over een volume hebt en niet of een disk geeft al aan dat je een OS hebt dat meerdere Disken bij alkaar kan schuiven tot een volume.

Maar pas als je een OS, Beschikbaarheid, performance en backup (!) mogelijkheiden weet kun je oplossingen gaan zoeken.

(maar aangezien goedkoopste HD van 500 MB iets van 100 euro kost en je hebt er daar al 100 (raid5) van nodig geef aan dat je nooit onder de 10.000 euro gaat komen, reken op een veelvoud hiervan (eerder 10x dan 2x) )

wrs bedoel je GB hierboven

en zowat elke OS kan dat, omdat het de controller is meestal die alle disc's samen voegt in een Raid-set en als 1 schijf presenteerd naar de OS.
Die OS kan met die "ene zeer grote schijf" er verschillende volumes/partitie's van maken.

(goedkoop raid-controllertje waarop je 4 schijven hangt in raid 10 van 250 GB is volgens je pc 1 schijf van 500 GB al de rest regelt die controller en/of zijn drivers wel.... mbv de ev. bijgeleverde software kan je dan de aparte schijven bekijken en de opbouw van de raidset bekijken/wijzigen/...)

[Kokkers]

DrBOB101 schreef op woensdag 22 augustus 2007 @ 22:59:
De policy op GoT is dat je zelf zo veel mogelijk (uit)zoekt.
Als je geen idee hebt waar je moet beginnen zou ik zo'n opdracht van een klant niet aannemen.

JumpStart schreef op woensdag 22 augustus 2007 @ 20:09:

• Hoeveel mag het kosten?
• Moet er een service contract bij?
• Zo ja, wat voor eentje?
• Hoe hoog moet de betrouwbaarheid zijn?
• Hoe goed moet de uptime zijn? 3N? 4N? 5N?
• Hoeveel gebruikers moeten er tegelijkertijd bij kunnen?
• Enig idee wat voor data verkeer het slurpt?
• IS dit de backup, of moet de data ook nog op tape?
• Is er serverruimte / 19" Rack ruimte voor beschikbaar?
• Ook al nagedacht over beheer- en monitoring software?
• Moet het NAS zijn of SAN?

Oftewel, je moet véél meer informatie aandragen voordat je iets zinnigs kan zeggen hierover.

Ik ben het hier mee eens.

Zolang de topicstarter geen randvoorwaarden en eisen aan zijn 'illustere 40TB' stelt zal elke extra reply in dit topic de hoeveelheid oeverloos gezwets alleen maar doen vergroten...

Iedereen roept maar wat, zwaar irritant.
Kan een moderator hier geen punt (slot) achter zetten?

[u_nix_we_all]

Heb je ook al bedacht wat voor FileSystem je op dat 40TB volume los gaat laten ?

[soulrider]

ivm die FS-vraag hierboven:
daarvoor moet ie eerst weten waarvoor het moet dienen.
snelle vaak wijzigende opslag, of is het voor datawarehousing.
(40 TB die continu op "the move" is, of 40 TB die wordt volgepompt en nadien niet meer gewijzigd, en slechts enkel gelezen)

bij die eerste is een 'snel' FS handig dat niet fragmenteerd, bij die andere een secure FS.
(liefst ook geen fragmentatie, maar dat is hier zelfs niet zo belangrijk)

@hieronder: voor jou mss niet, ik zelf zou er wel aan denken. Maar bij "write once, read many"-data heb je zowiezo al geen fragmentatie dus dan boeit het niet wat je gebruikt, bij iets wat continu wijzigd is het in het achterhoofd te houden dat je een FS gebruikt waar zoiets niet optreed (zekers met Windows-varianten als OS), en door het slechte begin van de TS (slechte analyse wegens niet genoeg doorgevraagd bij zijn klant) wil ik hem daar ook op wijzen.
Dat is ook zo met de vraag tot welk FS de TS wilt gebruiken als ie nog niet weet waarvoor het moet dienen, of welke server-OS ie gaat (moeten) draaien...
dus ja het is mss een non-issue, maar als het design even slecht is als de start-analyse dan gaat ie er wel last van hebben.

[ Voor 50% gewijzigd door soulrider op 25-08-2007 11:23 ]

[bakkerl]

soulrider schreef op zaterdag 25 augustus 2007 @ 10:29:
bij die eerste is een 'snel' FS handig dat niet fragmenteerd, bij die andere een secure FS.
(liefst ook geen fragmentatie, maar dat is hier zelfs niet zo belangrijk)

Fragmentatie opmerkingen bij dit soort systemen zijn een gehele non-issues.

[smeerbartje]

bakkerl schreef op zaterdag 25 augustus 2007 @ 10:51:
[...]


Fragmentatie opmerkingen bij dit soort systemen zijn een gehele non-issues.

Waarom eigenlijk? (gewoon benieuwd)

[Verwijderd]

Kokkers schreef op vrijdag 24 augustus 2007 @ 14:54:
[...]

Ik ben het hier mee eens.

Zolang de topicstarter geen randvoorwaarden en eisen aan zijn 'illustere 40TB' stelt zal elke extra reply in dit topic de hoeveelheid oeverloos gezwets alleen maar doen vergroten...

Iedereen roept maar wat, zwaar irritant.
Kan een moderator hier geen punt (slot) achter zetten?

Met zo'n opgave van details gok ik dat de klant 40 GB bedoelde en gewoon een USB diskje wil voor wat heen-en-weer gesleep met files. Meer kan ik ook niet uit de TS en de verdere onderbouwing halen.

[bakkerl]

smeerbartje schreef op zaterdag 25 augustus 2007 @ 12:01:
Waarom eigenlijk? (gewoon benieuwd)

In raid0, raid5 en/of raid6 configs wordt de data toch al over meerdere disken verdeelt. Dus als het eerste blok van disk1 gelezen is, zal blok2 van de data niet op de zelfde disk staan. Fragmentatie waarbij de kop verplaatst moet worden om blok2 van een zelfde disk te lezen zal dus niet van toepassing zijn.

Tegen de tijd dat disk1 weer een stukje moet lezen voor het zelfde bestand, is er al eerder gelezen van andere disken. Er is zelf een grote kans dat disk1 eerst bloken heeft moeten lezen welke bij andere data(streams) horen.

[bakkerl]

soulrider schreef op zaterdag 25 augustus 2007 @ 10:29:
@hieronder: voor jou mss niet, ik zelf zou er wel aan denken. Maar bij "write once, read many"-data heb je zowiezo al geen fragmentatie dus dan boeit het niet wat je gebruikt, bij iets wat continu wijzigd is het in het achterhoofd te houden dat je een FS gebruikt waar zoiets niet optreed (zekers met Windows-varianten als OS), en door het slechte begin van de TS (slechte analyse wegens niet genoeg doorgevraagd bij zijn klant) wil ik hem daar ook op wijzen.
Dat is ook zo met de vraag tot welk FS de TS wilt gebruiken als ie nog niet weet waarvoor het moet dienen, of welke server-OS ie gaat (moeten) draaien...
dus ja het is mss een non-issue, maar als het design even slecht is als de start-analyse dan gaat ie er wel last van hebben.

je data wordt bij RAID systemen (op uitzondering van raid1) wortd ALTIJD al gefragmenteerd. Gefragmenteerd over meerdere disken.

Fragmentatie is alleen irritant als je data op 1 disk staat, waardoor je kop zoveel moet seeken, voordat die data kan leveren. Bij Raid systemen komt de data altijd al van meerdere disken vandaan.

[ Voor 11% gewijzigd door bakkerl op 25-08-2007 15:57 ]

[Verwijderd]

bakkerl schreef op zaterdag 25 augustus 2007 @ 15:55:
je data wordt bij RAID systemen (op uitzondering van raid1) wortd ALTIJD al gefragmenteerd. Gefragmenteerd over meerdere disken.

Striping is iets anders dan fragmentatie. Het feit dat een stripe meer I/O kan verwerken en daardoor in absolute zin minder last heeft van fragmentatie weerhoudt niet dat fragementatie de I/Ops van je array doet verminderen.

RAID gaat om parallellisatie, hoe meer I/O door fragmentatie des te minder snelheid.

[bakkerl]

Verwijderd schreef op zaterdag 25 augustus 2007 @ 16:08:
Striping is iets anders dan fragmentatie. Het feit dat een stripe meer I/O kan verwerken en daardoor in absolute zin minder last heeft van fragmentatie weerhoudt niet dat fragementatie de I/Ops van je array doet verminderen.

RAID gaat om parallellisatie, hoe meer I/O door fragmentatie des te minder snelheid.

En daarom kun jij bij alle SAN's natuurlijk ook standaard de data laten defragmenteren.
De eerste SAN met deze optie (in de hardware of in de software) moet ik nog tegen komen. Dit zit er niet in omdat het een non-issue is geworden door de striping.

[Verwijderd]

Ik zit enigzins met hetzelfde probleem. Microsoft zegt dat hun ntfs systeem volumes tot 32TB ondersteunt, onder 32 bit. Maar de kaarten van areca en highpoint blijven dus die 2TB restrictie houden?

[mad_max234]

soulrider schreef op woensdag 22 augustus 2007 @ 16:46:
[...]

Ja idd blijkt niet controller afh. maar OS afh.
(maar de zot die een standaard desktop OS hiervoor gebruikt gaan ze wrs ook nog moeten gaan maken)
voorbeeld van 3ware

Je bedoeld 2tb limit van NTFS? Die kan je ook makkelijk omzeilen, is echt geen probleem met juist hardware en software trucs.

[ Voor 4% gewijzigd door mad_max234 op 19-09-2007 00:47 ]

[appie1981]

Je zou ook kunnen denken aan een DFS structuur met meerdere fileservers.
Maar ik kan eigenlijk nog steeds geen goede reden vinden waarom je 1 volume van 40TB zou moeten hebben.

[Alfa Novanta]

Sjah en gezien TS's tempo met posten kon het nog wel eens even gaan duren


.. sinds 2004 nu weer een post of 3

[ Voor 22% gewijzigd door Alfa Novanta op 20-09-2007 08:40 ]

[PcDealer]

Verwijderd schreef op dinsdag 18 september 2007 @ 23:37:
Ik zit enigzins met hetzelfde probleem. Microsoft zegt dat hun ntfs systeem volumes tot 32TB ondersteunt, onder 32 bit. Maar de kaarten van areca en highpoint blijven dus die 2TB restrictie houden?

Je kunt toch een volume als een dir mounten?

[JumpStart]

Topicstarter is met de noorderzon vertrokken lijkt het, maar aangezien dit ineens langskwam leek het me wel aardig om dit even hier neer te plempen:

http://www.tomshardware.com/newsletter/vol3/16/70tb.html

Vergeet even niet dat het hier om een 70 TB storage oplossing gaat anno 2003. Near-line storage gebaseerd op standaard componenten, voor een backup systeem van de Universiteit van Tübingen, Duitsland.

Iedere node (dual Athlon MP 1500+ met 1 GB ram) heeft 3x8 schijven op 3 stuks 8-poorts IDE RAID controllers van 3Ware. Iedere array heeft 1 hot spare en draait RAID 5 dus gebruikt effectief 6 schijven. En los daarvan staat het node OS op een apparte RAID 1 array. 18 schijven per node dus, en dat bewuste systeem heeft 24 nodes. De grootste schijf in 2003 was 160 GB, dus 18x24x160 = 69.120 GB

Bij gebruik van huidige SATA schijven van, zeg, 750 GB, heb je aan 3 nodes genoeg om 40 TB te halen.