The Epic Storage Part 1

Om du menar att spela upp 1080p och 4k material så är svaret ja, särskilt som att du kommer att använda de(m) i en NAS (Raid).

När du skriver "Chaina" så menar du att expandera med ett av de expansions-chassi som finns.
Det är som du skriver att dessa kan kopplas till vissa av modellerna. Du ska dock _aldrig_ utöka en volym över en sådan utökning (du ökar din risk för fel på ett oacceptabelt sätt)

Mest prisvärt i längden är att köpa en NAS med så många bays som möjligt, särskilt med ditt mål att ha mycket lagring.

Den disken du länkar till verkar inte vara så snabb, sätter du den i Raid så kommer den volymen att kunna dra nytta av att flera diskar ingår i samma filsystem för snabbare överförings hastighet (Raid0, 5, 6 ...)

När en disk i en Raid 5 eller 6 går sönder så används paritets information som finns på de andra diskarna för att återskapa den data som fanns på den trasiga disken. När du ersätter den med en fungerande så används samma paritetsdata för att återskapa datat på den disken.
Under tiden så är Raiden i degraded-mode och är långsammare (i alla konsument / pro-sumer lösningar).

Raid är önskvärt för att skydda sig mot mekansika fel på sina diskar - dvs att de går sönder.

Eftersom du funderar på 8TB diskar så bör (ska) du köra Raid-6 eller SHR-2.
Du behöver två diskars paritet pga att under tiden en disk har gått sönder och du stoppar i en ny för att bygga upp din Raid - så är sannolikheten stor att ytterligare en disk går sönder. I Raid5/SHR1 så förlorar du din data, medan med Raid6/SHR2 så har du ytterligare en disk att falla tillbaka på (som kan gå sönder).

Vill minnas att det var någon som gjorde en fin uträkning och graf på detta. Att köra en array på mer än 5 diskar i Raid5 ansågs vara hasardspel.

Sedan dess så har diskarna blivit dubbelt så stora vilket innebär att årterskapande tiden i ett sådan scenario ökar (och risken).

Startbudgeten är lite liten med det målet.
Jag förutsätter att du på något sätt är mån om din data, dvs att du inte vill förlora den eller behöva ladda hem den igen.
Att då köra något mindre än Raid6 borde inte vara ett alternativ för dig.

Om du köper en 12-bay nas så kommer du att med 12 st 8 TB diskar i Raid6 ha 80 TB disk användbart för filsystemet, sedan blir det lite mindre när du formaterar.

Efter det så får du köpa en expansionsbox och fortsätta där.

Med Raid6 så behöver du börja med minst 4 diskar.
Med varje disk du lägger till så måste NASen utöka Raid-settet vilket tar lång tid. När du börjar komma upp i volym så kan det ta dagar eller längre än en vecka (berorende på hur "långsam" NAS:ens CPU är, samt vilka diskar du har, med de diskarna du länkat kommer det att ta ca dubbelt så lång tid som med WD Red diskar (om Seagate snittar i 30 MB/s så har jag med mina WD Red diskar haft >60 MB/s vid Raidskapande och utökning)).

Om ditt mål är att ha väldigt mycket lagringsutrymme så ska du nog börja med en 12 bay NAS från början.
Du slipper då att börja med behöva hantera två logiska volymer iom utöknings boxen.

Sitter själv på en DS3612xs som jag köpte begagnad för 15tkr - hur nöjd som helst (har 8 diskar i Raid6).

Finns säkert mer att tillägga. Du får värdera vad som är viktigast för dig. Storlek, pris, snabbhet eller något annat - och sedan väga de svar du får mot det.

Men om målet är 100TB så behöver budgeten öka, alternativ om du har tid och ork att bygga och installera något själv så kommer du ner i pris.

Jag föredrar dock att få allt serverat av Synology med säkerhets patchar och uppdateringar.
Hade först långtgående planer och research gjord för att sätta upp FreeNAS på egenbyggd NAS-server, la säkert närmare 100 timmar under några månader att läsa om de olika NAS-distrona, kolla deras supportforum (bra för att se vilka problem användarna har) och sedan kontrollera om delarna "jag" ville ha gick att få tag på i europa.
Till slut så insåg jag att jag inte ville ha ZFS då det inte blir snabbare än den långsammaste disken och att poolerna inte gick att utöka.

Länkar:
http://www.zdnet.com/article/why-raid-5-stops-working-in-2009...
http://www.zdnet.com/article/has-raid5-stopped-working/

Skulle inte våga köra raid5 på 8TB diskar och ha 100TB som mål.

BluRay har en dataströmsstorlek på upp till 54Mbit/s, vilket blir just under 7 Mbyte/s. Med en disk med en blockstorlek på 4KB motsvarar detta ca 1700 IOPS. Försök med marksänd 4K har gjorts med bitrates som "ryms" på BluRay. Motsvarande försök med 8K (H.264-komprimering, 7680 x 4320p@59.94fps) har gjorts med en bitrate på 91 Mbit/s.

Så länge läsningar kan göras någotsånär sekventiellt (inte oerhört fragmenterade filsystem, inte många samtidiga dataströmmar) och spridas över flera hårddiskar kommer inte diskens läshastighet att vara något problem. Andra saker som strömsparfunktioner och transkodning kan dock ställa till det.

415play har bara USB-anslutningar, så Synologys expansionslådor kan inte anslutas till den. Det verkar som om USB-ansluten lagring bara kan användas för backup samt att servera filer från -- USB-ansluten lagring kan inte ingå i ett RAID-set. I Synologys konsumentproduktserie vill du nog ha en NAS med eSATA-anslutning och en eller flera expansionslådor. "Chaina" vet jag inte vad det betyder, men Synologys NASar verkar ha stöd för replikering mellan två enheter. Notera att detta dock inte ökar mångden användbart lagringsutrymme utan enbart skyddar mot dataförlust vid mer omfattande hårdvarufel.

Tillverkarens hemsida har troligtvis den korrektaste informationen. Med RAID 5 krävs en extra disk för paritetsinformation. Med SHR (Synologys egna raidlösning) uppnås ungefär samma skydd som med RAID5/6, med den skillnaden att diskar av olika storlekar kan användas.

Ja, det går att stoppa i en extra disk och välja att denna disk ska agera hot spare. När enheten markerar en disk som fallerad påbörjas automatiskt migrering/rebuild av data till hot spare-disken.

RAID med redundans är mest användbart för att minska nedtid, men det ger också ett bra skydd mot dataförlust som en följd av fel på enskilda diskar. Med Backblaze' tillförlitlighetsdata så verkar diskarna vara de mest felbenägna komponenterna i lagringslösningar. Ordentlig backup (offsite, flera generationer) skyddar mot en massa saker som RAID inte skyddar mot - oavsiktlig radering, brand, stöld osv.

Vi kan ju räkna lite på det.

Om vi antar att vi fått tag på en hårddiskmodell med 5% AFR (årlig felprocent) och vill ha lagringsutrymme motsvarande 12 diskar så kommer en lösning utan redundans att med (RAID0 eller JBOD) med 1-(1-0,05)¹² = 46% sannolikhet drabbas av dataförlust.
Med en disks redundans (sammanlagt 13 diskar, således) blir felsannolikheten (1-(1-0,05)¹³)*(1-(1-0,05)¹²) = 22%, även om fallerade diskar inte byts ut. Om NASen tittas till med någon veckas mellanrum och diskar med upptäckta fel byts ut så krymper sannolikheten för fel som innebär dataförlust dramatiskt.

Om kravet på Synology står kvar finns, tillsammans med ovanstående förutsättningar, inte så mycket att välja på. 100 TB användbar kapacitet uppnås med 14 hårddiskar på 8 TB i en raidfemma. I den här tillämpningen kommer nog inte RAID att ge ett skydd mot nedtid och dataförlust som är i närheten av heltäckande, men kombinerat med någon form av övervakning och tillgång till reservdelar borde sannolikheten för dataförlust inte bli högre än några procent/år.

Föga förvånande tas expansion av raidset upp i tillverkarens dokumentation. Det finns säkert yttre faktorer som kan mula ett raidset som håller på att expandera (strömavbrott, fel på den nya hårddisken etc).

Så med disk (8 TB med ett snittpris på 2500 kr/disk fram till jul) blir det ca 36 kkr för 80 TB oraidad kapacitet. 0,45 kr/gig. Låter väldigt rimligt.

Det låter väldigt osmidigt att ha en stor volym på 80/100 TB. Bara för att man har RAID betyder det inte att man är skyddad mot tex korrupta partitionstabeller osv. Tänk på vad du ska göra om du av någon anledning behöver migrera bort all data för att göra någon större förändring i alla dina diskar, byta från RAID5 till RAID 1 eller minska antalet diskar i arrayen osv.

Att utöka arrayen vart eftersom är i sig en bra idé om man tänker pengar. Men att utöka en array från 72TB till 80TB kommer ta riktigt lång tid. Bara att bygga den första arrayen när du börjar med ett mindre antal diskar kommer ta en avsevärd tidsrymd.

Dela dina 100TB i 3 eller 4 mindre delar. Mina 2 dinarer

Jag tycker du börjar i fel ände om du är ute efter den bästa lösningen. Att bestämma sig för en specifik produkt och sedan börja ställa krav på dessa produkter gör att du riskerar att missa många andra alternativ. Jag tycker du ska börja med att ställa krav på vad du vill ha och därefter sålla bland produkterna.

Har aldrig varit med om att en hårddisk är begränsningen vid mediauppspelning.

Ingen aning.

SnapRAID är enligt mig bättre än både RAID 5/6 och Synologys RAID om du vill ha redundans ifall en hårddisk krashar, speciellt med de stora mängder data som du verkar ha tänkt spara. Problemet är att det inte finns implementerat automatiskt utan du måste konfigurera en egen server själv. Vill du ha en hyfsat autonom och enkel installation så skulle jag föreslå att du tar dig en titt på OpenMediaVault. Där finns det tillägg för SnapRAID och i princip för alla andra tänkbara scenarier man kan tänkas använda en NAS till, t.ex. Plex och torrentklienter. Dessutom är du inte bunden till specifik hårdvara utan du kan bygga en helt ny dator som kommer vara mer prisvärd än en färdig lösning.

Billigaste alternativet är såklart att sätta upp en server helt själv. Se föregående svar.

Vet inte hur det är med Synologys RAID, men med RAID 5 och 6 så måste du skriva om allt såvitt jag vet. SnapRAID struntar i storleken eller om det redan finns data på hårddisken vilket gör att det går att lägga till en hårddisk i arrayen direkt bara genom att skriva in några extra rader i en konfigurationsfil. Se jämförelsen på SnapRAIDs hemsida för lite..., ja, jämförelser.

Som sagt så tycker jag du börjar i fel ände. Se svar på fråga 3.

Beroende på hur man läser detta så kan det bli så att man får fel för sig.

Ifall man lägger till en disk i Raid5/6 så skrivs inte alla diskar över i den mening att datan försvinner och att man behöver börja om.
Disken läggs till i array:en och sedan flyttas/fördelas datan ut över den nya disken också, inklusive paritetsdata.
Detta ta en stund, längre ju större array man har.

Du kan använda din NAS under tiden både för att läsa och skriva, men det går långsammare.

Jag tror vi menar samma sak, ville bara tydliggöra.

Japps så går också att resonera.

Tänk dock på att du då kommer att ha 8 stycken "enheter". Dvs du kan inte slå ihop diskarna i JBOD eller RAID0, om en disk går sönder så förlorar du allt i volymen (alternativt sitter och sliter för att försöka rädda det som räddas kan).

Alternativet att du tänker om kring målet med 100 TB.
Som jag förtår så är anledningen att du vill vara framtidsäker att när Ultra HD blir vanligt att du då har ett system som kan lagra dessa volymer i din NAS.

Jag tror inte att Ultra HD kommer att vara vanligt på 2-3 år.
Tänk tillbaka 2-3 år istället för att se vilka diskar vi hade då. De var betydligt mindre än de vi har idag.

Det betyder att när behovet verkligen kommer att finnas för dig i framtiden så kommer diskarna ha hunnit att bli större, 15 eller tom 20 TB i en disk till ett rimligt pris.

För egen del så har jag kommit fram till att jag ska sluta med att köpa pryla som är "framtidssäkra", dvs den snabbaste CPU:n, eller största mängden minne. Anledningen är att när jag "i framtiden" kommer att behöva denna extra CPU kraft eller minne så har tekniken hunnit utvecklas och bli billigare att jag får mer för mina pengar att köpa det jag behöver idag och låta framtiden sköta sig själv med uppgraderinger eller nyköp.
Med detta menar jag inte att vara dumsnål, bara att jag inte är beredd att lägga dubbelt så mycket på något för att det ska vara framtidskert om jag kan få något som funkar i 3+ år för halva priset.

Att få en färdig lösning med hård- och mjukvara som funkar ihop, hotswapfunktion och enkla verktyg för att managera lösningen är i mina ögon värt en del pengar.

Well, då försvinner mycket av vitsen med Synologys volymhantering ocht du får antingen sitta och sortera om lagrat material så att det matchar de fysiska diskarna eller lagra materialet osorterat och lägga tiden på att hitta det.

I värsta fall krypterar någon form av malware hela klabbet. Förväntad dataförlust per år som en följd av diskfel blir AFR * diskstorlek * antal diskar, eller ungefär 4,8 TB/år. Utöver denna risk tillkommer alla andra risker för dataförlust: stöld, brand, översvämning, buggar i mjukvara, användarmisstag, malware.

Jag vet inte hur du värderar din egen tid, men att behöva leta fram originalskivor och rippa om i genomsnitt 4,8 TB av dessa varje år känns som något jag gärna skulle betala en del för att slippa.

Det enda jag direkt reagerar på är en att tala om RAID 5 på 100TB. Det är som att lägga backupen på 1000 floppy disketter och tycka allt är frid och fröjd.

Hårddiskar idag är så stora att de börjar komma ikapp sina egna fel toleranser. 1 bit fel per 10^14 är inte ovanligt, och 10^12 är 1TB. Så på 100TB har du garanterat ett fel i snitt, varje gång du läser den arrayn.

Mao, när en disk havererar, och du ska "åter bygga den" som kommer du statistiskt sett, garanterat ha minst ett fel, som du kommer spara, och få bit korruption. Mao, det är 100% dömt redan från början.

RAID 5 blev uråldrigt redan när vi började nå 1TB diskar, och idag är nästan RAID 6 för lite.
Ska vi upp i 100TB skulle jag nästan satt flera mindre kluster med RAID 6 vardera. Så 25TB med RAID 6, och 4 st av dem. Absolut min 50TB med Raid6 x 2.

Du kan använda denna till att få en uppskattning:
http://www.seagate.com/www-content/product-content/hdd-fam/se... (står 1 per 10E14)
De är inte 100% felfria iaf, så du måste räkna med haveri:
#15301765
http://www.servethehome.com/raid-calculator/raid-reliability-...

Baserat på "Conservativ Estimate 145k" timmar, 10^14 (enligt spec ovan), 8TB disk, 4k sector, 12 diskar, 1 volym, 25MB/s rebuild (dessa diskar skriver inte så bra om intill liggande spår ska skrivas)
Failure Rate, RAID5: 1år 9,2%, 2år 17,6%, 3år 25%. Mao du har ca 25% chans på 3 år att minsta allt... rubbet av data.
Failure Rate, RAID6: 1år 0,53%, 2år 1,04%, 3år 1,56%. Inte perfekt men betydligt bättre.

Lägger vi till 2 diskar, kör 4 volymer och RAID 6: 1år 0,08%, 2år 0,16%, 3år 0,24%

Du bör oavsett köra med ett filsystem som har skydd mot bitröta, som jag tvivlar på att denna NAS kan/har (rätta mig gärna). Men där finns bara 3 filsystem jag känner till och bara 2 är "i drift". ZFS, btrfs och Microsofts ReFS som fortfarande är under utveckling men kan gå att använda.

Njae, riktigt så funkar inte sannolikhet. Om du slår en tärning fem gånger utan att få en sexa är du ju inte garanterad en sexa den sjätte gången, även om tärningen i genomsnitt levererar sexor 1/6 av gångerna.

Om sannolikheten för fel motsvarar tillverkarens spec* på 10^-14 (0,00000000000001) per läst bit blir sannolikheten att läsa en korrekt bit 1-10^-14) (0,99999999999999). Sannolikheten att läsa två bitar korrekt blir (1-10^-14)² (0,99999999999998).

Och sannolikheten att korrekt läsa 100 TB (800 * 10¹² bitar) blir då
(1-10^-14)^{800 * 1012} ≈ 0,033%. Ouch.

Dessutom är jag ganska övertygad om att en hårddisk som i övrigt inte uppvisar några konstigheter levererar betydligt färre läsfel än vad specifikationen säger.

Inte i filsystemet, men Synologys fräsigare modeller har data scrubbing, som kontrollerar data mot paritet. Det måste dock köras manuellt (men jag antar att det går att hax0risera NASens OS så att det körs som ett schemalagt jobb) och fular nog upp NASens prestanda under tiden scrubbingen körs.

Jag håller med dig i din slutsats. Även om den faktiska felsannolikheten hos hårddiskarna skulle vara hundra eller tusen gånger högre än spec hade jag varit skeptisk till att bara ha en extra disk för paritetsinformation på ett raidset med 100 användbara TB.
Dock tror jag att premisserna är felaktiga. Skulle inte andra typer av användning också drabbas av de fel som kan uppstå vid rebuild av ett raidset? Normen för RAID 5- och 6-implementationer verkar vara att prioritera prestanda och bara läsa paritetsinformation när raidsetet är degraderat och under rebuild. (ZFS och andra ballare raidtyper som NetApps WAFL kan göra integritetskontroll mot paritet vid varje läsning.) Backup av motsvarande datamängder, t ex, borde vara lika utsatt för läsfel.

Ja, jo. Den feltyp som diskuteras kallas Uncorrectable Read Error eftersom disken själv inte kan korrigera det...

De har inte en bättre spec än sina mindre föregångare, men deras faktiska tillförlitlighet är nog betydligt bättre än specen. Det lilla empiriska underlag som finns pekar på att läsfel är mindre frekventa än vad specarna säger och att felen inte är oberoende av varandra; de uppträder dessutom i flock. Ett intressantare värde än felsannolikhet per läst bit vore något slags "genomsnittligt antal korrekt lästa bitar i följd".

Det är inte riktigt min erfarenhet.

Om man följer referensspåret för ovanstående tillbaka till någon slags källa så hittar man artikeln "Why RAID 5 stops working in 2009" av Robin Harris. Även denna artikel baserar förutsägelsen på av hårddisktillverkare uppgivna specar. Samtidigt fortsätter leverantörer av lagringslösningar glatt att riskera sina kunders data (och sina egna intäkter) genom att tillhandahålla och rekommendera RAID 5.

Jag tror att en leverantör av lagringslösningar har bättre underlag för riskanalys avseende felfrekvens hos hårddiskar (och större intresse av att göra ekonomiskt sunda avvägningar) än vad en journalist har.

Absolut. Andra lösningar är RAID 50 eller 60, som i utbyte mot utrymmeseffektivitet kan konfigureras så att full redundans kan återfås med en rebuild av en begränsad del av raidsetet.