En lagringsfråga, raid0 vs raid10 vs raid6

Permalänk
Avstängd

En lagringsfråga, raid0 vs raid10 vs raid6

Hejsan

För att klargöra en sak, jag har hållt på med det här ett bra tag och kunskaperna finns - men jag kan inte besluta mig för vad som är bättre eller bäst i det här fallet.

Förutsättningarna är att det finns ett kontrollerkort med åtta sata-diskar och en teoretisk kapacitet på 32TB i det här fallet. Kortet kan köra raid6 vilket ger ca 23TB effektiv lagring.

Om jag tänker rätt nu så slutar raid5 fungera vid ca 12TB på grund av i stort sett garanterade bitfel, blir Raid6 lika verkningslöst vid det dubbla?
Rebuild-tiden för denna storlek i Raid6 motsvarar vadå, tio dagar?

Vid ett diskras så är man alltså sårbar i upp till denna tiden, risken är hög att ytterligare en disk fallerar eller att ett bitfel uppstår och kontrollern hänger sig. Så då börjar jag fundera på Raid0, möjligen Raid10, istället.

Dör en disk, vilket den kommer att göra, så är det bara att ersätta disken och börja skyffla över data från backupen. Vi pratar om åtminstone 360GB per timme över ett gigabitnätverk, låt oss säga 1TB var tredje timme för att räkna lågt - det skulle motsvara knappt tre dygn om alla 23TB utnyttjas. Att jämföras med kanske tio dygn istället och dessutom ha två diskar över.

Alternativt en Raid10 med dryga 15TB effektiv diskutrymme. Dör en disk här så ersätter man den men den enda synkningen borde vara från den andra speglade disken, dvs max 4TB vilket i tid blir drygt tre timmar. Mycket mer effektivt, men åtta terabyte mindre utrymme.

Eller tänker jag helt fel nu?

Permalänk

Nackdelen med raid 10 fick jag erfara på jobbet för några dagar sedan. Den hade 4 diskar i raid 10 en disk dog så vi byte den, under rebuilden som tog 2 dagar fick den speglade disken skrivfel. Raiden höll på att dö men som tur va gick andra rebuilden bra. Om två av fel diskar dör kan de slå ut hela din raid 10 med raid 6 kan alltid två diskar gå sönder oavsett vilken det är. Jag säger så här, raid är ingen backup! Backa dina filer som är viktiga annanstans också!

Visa signatur

Gaming:[Asus Crosshair Extreme X670e]-[AMD R9 7950X3D]-[G.Skill TridentZ 6000Mhz 32GB]-[MSI Suprimx RTX 4090]-[Samsung 980PRO 2TB]-[Lian Li O11]:.
Server:[Asrock Rack X570d4u-2l2t]-[AMD R5 5600X]-[64GB ECC]-[nVidia P2000]-[40TB WD Re + 500GB Curcial MX100]:.

Permalänk
Medlem

RAID10 kör man helst för prestandans skull, typ databaser och liknande som man kontunuerligt tar backup på och kan återställa snabbt.
Rasar en RAID10 för mig så tar jag bort den, byter trasig disk och skapar en ny RAID10 och kör en restore från backupen, rebuild tar för lång tid samtidigt som man oftast får urusel prestanda under den tid som rebuilden tar.
Då är det oftast runt 500GB disk vi kör RAID10 på, sällan större.
För lagring på stora volymer så är det oftast speglade RAID5 eller RAID6 arrayer (20 till 40x1TB SAS-diskar) där man kan koppla ur ett SAN och fixa den under tiden dom andra SANen fortsätter jobba.
Vi undviker iallafall större diskar än 1TB i våra miljöer.

Visa signatur

Medlem #14

Permalänk
Avstängd
Skrivet av AquaRelliux:

Nackdelen med raid 10 fick jag erfara på jobbet för några dagar sedan. Den hade 4 diskar i raid 10 en disk dog så vi byte den, under rebuilden som tog 2 dagar fick den speglade disken skrivfel. Raiden höll på att dö men som tur va gick andra rebuilden bra. Om två av fel diskar dör kan de slå ut hela din raid 10 med raid 6 kan alltid två diskar gå sönder oavsett vilken det är. Jag säger så här, raid är ingen backup! Backa dina filer som är viktiga annanstans också!

Tack, det är en evig påminnelse det där, som jag själv skrev ovanför
"Dör en disk, vilket den kommer att göra, så är det bara att ersätta disken och börja skyffla över data från backupen"
Men att det tog så lång tid att återställa en Raid10 trodde jag inte!

Skrivet av JenzA:

RAID10 kör man helst för prestandans skull, typ databaser och liknande som man kontunuerligt tar backup på och kan återställa snabbt.
Rasar en RAID10 för mig så tar jag bort den, byter trasig disk och skapar en ny RAID10 och kör en restore från backupen, rebuild tar för lång tid samtidigt som man oftast får urusel prestanda under den tid som rebuilden tar.
Då är det oftast runt 500GB disk vi kör RAID10 på, sällan större.
För lagring på stora volymer så är det oftast speglade RAID5 eller RAID6 arrayer (20 till 40x1TB SAS-diskar) där man kan koppla ur ett SAN och fixa den under tiden dom andra SANen fortsätter jobba.
Vi undviker iallafall större diskar än 1TB i våra miljöer.

Ni verkar säga samma sak här, så då känns det ganska så bekräftat.
Då stryker vi Raid10
Däremot dök ett annat förslag upp, nämligen SnapRaid, som om jag förstår det rätt motsvarar Raid4 men med fördelen att datan är tillgänglig även vid diskfel och att man kan ha flera diskar som paritetsdiskar. Dock gör inte mitt kontrollerkort någon nytta i det här fallet.

Permalänk
Medlem
Skrivet av Damodred:

Om jag tänker rätt nu så slutar raid5 fungera vid ca 12TB på grund av i stort sett garanterade bitfel, blir Raid6 lika verkningslöst vid det dubbla?
Rebuild-tiden för denna storlek i Raid6 motsvarar vadå, tio dagar?

Det där var det dummaste jag hört, vad baserar du det på? Har en hel del raidar i storlek om 60TB+ i produktion som rullar på utan något som helst problem med både raid5 och raid6 nivå.

Visa signatur

Networking geek, #28735

Permalänk
Avstängd
Skrivet av thadizzy:

Det där var det dummaste jag hört, vad baserar du det på? Har en hel del raidar i storlek om 60TB+ i produktion som rullar på utan något som helst problem med både raid5 och raid6 nivå.

Det där är modigt gjort

Citat:

Reads fail SATA drives are commonly specified with an unrecoverable read error rate (URE) of 10^14. Which means that once every 100,000,000,000,000 bits, the disk will very politely tell you that, so sorry, but I really, truly can't read that sector back to you.

One hundred trillion bits is about 12 terabytes

http://www.zdnet.com/blog/storage/why-raid-5-stops-working-in...

Hur lång tid tar det inte att göra en resync på de storlekarna.
Det är här felet uppstår och kontrollern kan säga ifrån.

Permalänk
Medlem

Om det skulle vara som du säger skulle arrayer rasa överallt. Det gör dom inte. Det är även samma diskar i större SAN system som hanterar gigantiska mängder med data.. och vet du vad, dom fungerar också.

En snabb titt på diskarna visar att det finns "Raw_Read_Error_Rate" fel på vissa av diskarna, men detta hanteras utan att raiden tappar disken så ser inte vad problemet är.

Vi har haft denna diskution tidigare på forumet (där HW RAID ifrågasattes till förmån för ZFS), känns meningslöst att ha en till.

Visa signatur

Networking geek, #28735

Permalänk
Avstängd

Nej, då har du missförstått poängen.
Poängen är att när en disk dör och du ersätter den så utsätter du dig för risken att få ett bitfel, vilket en kontroller kan stoppa på då den anser att pariteten inte stämmer överens med vad som faktiskt finns.

Det har inget med att en array skulle rasa bara för att den är i en viss storlek.
Om disktillverkaren inte kan garantera något så hade jag nog inte valt att köra på det, ej heller anlitat någon som heller inte följer deras rekommendationer.

Jag byter själv från ZFS till förmån för detta

Permalänk
Medlem
Skrivet av Damodred:

Nej, då har du missförstått poängen.
Poängen är att när en disk dör och du ersätter den så utsätter du dig för risken att få ett bitfel, vilket en kontroller kan stoppa på då den anser att pariteten inte stämmer överens med vad som faktiskt finns.

Det har inget med att en array skulle rasa bara för att den är i en viss storlek.
Om disktillverkaren inte kan garantera något så hade jag nog inte valt att köra på det, ej heller anlitat någon som heller inte följer deras rekommendationer.

Jag byter själv från ZFS till förmån för detta

Så din poäng är att när den oundvikliga rebuilden kommer så är det statistiskt troligt att en disk får ett bitfel om den totala diskytan överstiger en viss mängd. Då checksumman blir fel borde detta block skrivas på nytt, och är sektorn trasig borde inte den bli automagiskt omflyttad då. Känns som simpel logik för raid-programvaran att hantera snarare än att raid som teknologi är dödsdömd. Vet inte hur det fungerar i detalj och exakt hur logiken fungerar. Kan tänka mig att det skiljer sig ganska markant.

Visa signatur

Networking geek, #28735

Permalänk
Avstängd

Ja jag vet inte heller hur det fungerar rent tekniskt men som jag ser det kan inte checksumman bli fel och sedan ersättas, då raid5 endast klarar en disks frånvaro. Där av skulle raid6 fortfarande fungera bättre vid URE- fel. Sedan är det väl så att bara för att statistik eller tillverkaren hävdar något så behöver det inte ske. Men säg att det skulle ske, då är enda lösningen att återställa från backupen - och det jag tänker är att vid ett diskhaveri så är det kanske bättre att bara bryta upp alltihopa och göra om det med en ny disk och återställa på en gång, istället för att spendera tid på en resync som kanske tar lika lång tid eller till och med längre.

Permalänk
Medlem

Jag känner att du börjar lite i fel ända gällande vilken RAID du skall använda.
Vad är syftet med systemet, VMware, fileserver? Vad har du för upptidskrav? Vad har du för SLA gällande RPO?
Vad har du för prestandakrav?
Vad är det för diskystem?

Och när det gäller RAID 5 och 6 så är det standard att köra RAID 5 eller 6 på SAS-NL diskar alt SAS diskar. Har kunder som kör detta på PB stora SAN och NAS.

Permalänk
Avstängd

Är tyvärr inte så bekant med dina förkortningar.
Syftet är att i grunden ha två (nämnde aldrig det tidigare då de är identiska) filservrar med möjlighet till att göra mer, så som webbserver och andra relaterade lösningar (owncloud, ftp, wordpress osv), men även transcoding för Plex.

I dagsläget rullar en ZFS- baserad lösning som jag tycker är lite stelbent men som efter att det här är löst blir backupserver istället. Upptidskrav, sedan 2003 har filservern enbart varit nere för underhåll och/eller semestertider. Så snarlikt det. Prestanda är egentligen inte så viktigt, det kommer oavsett bli högre än vad gigabitnätverket klarar av.

Så det är i högsta grad mer på en seriös hemmasnickarnivå än yrkesmässig.

Permalänk
Entusiast
Skrivet av thadizzy:

Så din poäng är att när den oundvikliga rebuilden kommer så är det statistiskt troligt att en disk får ett bitfel om den totala diskytan överstiger en viss mängd. Då checksumman blir fel borde detta block skrivas på nytt, och är sektorn trasig borde inte den bli automagiskt omflyttad då. Känns som simpel logik för raid-programvaran att hantera snarare än att raid som teknologi är dödsdömd. Vet inte hur det fungerar i detalj och exakt hur logiken fungerar. Kan tänka mig att det skiljer sig ganska markant.

Ja en bra implementation av RAID kommer analysera all data för att leta efter fel och rätta till dem med hjälp av paritet under tiden den är igång. Fast det hjälper ju inte så mycket i fallet när en disk saknas för då har du ingen aning om vad just den sektorn skulle vara. URE är inte bara att den läser fel en gång utan informationen kan vara förlorad för alltid. Vanliga hårddiskar är specade till ett fel på 10^14 bitar. Om det stämmer så betyder det i snitt ett fel på 12,5 TB data. Har du då en RAID5 som är så stor är risken stor att en bit inte kommer kunna läsas när den bygger om. Då är det som sagt för sent för att kunna återställa den eftersom det per definition inte finns något att återställa från. Nu bygger detta helt på antagandet att hårddisktillverkarnas specifikation stämmer. Jag skulle gissa att den är rätt konservativt satt. Ungefär som specad skrivtålighet på SSD som kan vara en tiopotens lägre än det faktiska värdet för att de vill vara på den säkra sidan. Fast faktum kvarstår, det finns en risk att en RAID5 inte kan byggas upp igen och den beror på storleken.

Fast det är i praktiken inte ett så stort problem om man tittar på hur stora RAID5 används i verkligheten. RAID är till för att säkra driftstid och inte för att säkra data.

Tänk dig följande scenario. En filserver på 20 TB för ett företag tappar en hårddisk en morgon. Har du ingen RAID kan ingen jobba på ett par timmar medan du slänger ut den trasiga disken och återställer från en backup. Har du däremot RAID5 så kommer de som använder filservern knappt märka något. Möjligtvis blir den lite långsammare. Då kan du i lugn och ro vänta på att folk går hem. Sen slänger du den trasiga disken, ersätter den med en ny och sen kan den stå och tugga över natten. Antingen bygger den om sig eller så skrotar man den och bygger en ny från backup vilket kan gå fortare när vi börjar prata stora mängder data. Nyckelordet här är backup. RAID är inte designat för att klara bitfel, det är designat för att du ska kunna fortsätta jobba tills det är lämpligt att fixa en trasig disk istället för att tvingas göra det direkt. Murphys lag säger att en disk kommer rasa när det är som minst lägligt.

Visa signatur

Q9450, HD4850, 8 GB DDR2 800 MHz, 3x750 GB, Antec 300, Dell 2408WFP, U2410, Qnap TS-419p+ 4x2 TB Samsung F4, Asus UL30A-QX056V, Logitech Z-680, Sennheiser HD380pro, M-Audio FastTrack Pro, Ibanez sa160qm, Ibanez TB 15R, Zoom 505II, Ibanez GSR 200, Ibanez SW 35, Cort AC-15, Squier SD-3 BBL, Yamaha PSR 270, Røde NT1-A, Nikon D200, Nikkor 18-70/3,5-4,5, 70-300VR, 50/1,8, 28/2,8, Tamron 17-50/2,8, 90/2,8, Sigma 30/1,4, SB-800, SB-25, SB-24

Permalänk
Skrivet av Zotamedu:

Ja en bra implementation av RAID kommer analysera all data för att leta efter fel och rätta till dem med hjälp av paritet under tiden den är igång. Fast det hjälper ju inte så mycket i fallet när en disk saknas för då har du ingen aning om vad just den sektorn skulle vara. URE är inte bara att den läser fel en gång utan informationen kan vara förlorad för alltid. Vanliga hårddiskar är specade till ett fel på 10^14 bitar. Om det stämmer så betyder det i snitt ett fel på 12,5 TB data. Har du då en RAID5 som är så stor är risken stor att en bit inte kommer kunna läsas när den bygger om. Då är det som sagt för sent för att kunna återställa den eftersom det per definition inte finns något att återställa från. Nu bygger detta helt på antagandet att hårddisktillverkarnas specifikation stämmer. Jag skulle gissa att den är rätt konservativt satt. Ungefär som specad skrivtålighet på SSD som kan vara en tiopotens lägre än det faktiska värdet för att de vill vara på den säkra sidan. Fast faktum kvarstår, det finns en risk att en RAID5 inte kan byggas upp igen och den beror på storleken.

Fast det är i praktiken inte ett så stort problem om man tittar på hur stora RAID5 används i verkligheten. RAID är till för att säkra driftstid och inte för att säkra data.

Tänk dig följande scenario. En filserver på 20 TB för ett företag tappar en hårddisk en morgon. Har du ingen RAID kan ingen jobba på ett par timmar medan du slänger ut den trasiga disken och återställer från en backup. Har du däremot RAID5 så kommer de som använder filservern knappt märka något. Möjligtvis blir den lite långsammare. Då kan du i lugn och ro vänta på att folk går hem. Sen slänger du den trasiga disken, ersätter den med en ny och sen kan den stå och tugga över natten. Antingen bygger den om sig eller så skrotar man den och bygger en ny från backup vilket kan gå fortare när vi börjar prata stora mängder data. Nyckelordet här är backup. RAID är inte designat för att klara bitfel, det är designat för att du ska kunna fortsätta jobba tills det är lämpligt att fixa en trasig disk istället för att tvingas göra det direkt. Murphys lag säger att en disk kommer rasa när det är som minst lägligt.

Mycket klokt sagt där! Kör själv raid5 på min server. Det jag finner raid5 bra till är att även om man tappar en disk kan man med reduserad prestanda ladda ner all information från raid arrayen innan man slänger in den nya disken och bygger upp den. Det tillåter än att komma åt det som ligger där.

Och det är väldigt sant att raid är inte någon ersättning för backups. Utan backups skall hållas på informationen. Väldigt viktigt. Där många gör fel.

Exempelvis på min htpc kör jag raid 0 bara för skoj skull på 3st 250gb diskar. Har en likadan kontroller där som i servern. Bra att lära sig där utifall de rasar.

På servern kör jag raid 5 med fyra stycken 3TB WD Red diskar. Fungerar perfekt. Lustigt nog gå raid5 på servern snabbare än raid0 på htpcn. Men de är nog slumpen.

Visa signatur

Coolermaster Stacker 810. Asus rampage II Extreme x58. Core i7 990x 3.46ghz. 24GB Corsair XMS3. 2st Nvidia 295 Q-Sli. 2x120gb ssd, 1.5tb wd green, 640gb wd blue. (6x500gb raid6, 2x1tb raid0 på adaptec 5805) Corsair AX1200 psu. Lexicon Lambda Usb ljudkort. 2st skärmar + tv.

Permalänk
Avstängd
Skrivet av Zotamedu:

. Sen slänger du den trasiga disken, ersätter den med en ny och sen kan den stå och tugga över natten. Antingen bygger den om sig eller så skrotar man den och bygger en ny från backup vilket kan gå fortare när vi börjar prata stora mängder data.

Yes, och där av min lilla fundering om Raid0 eller Raid10 vs Raid6
Eller Snapraid som också dök som ett alternativ när jag ställde samma frågeställning på ett internationellt forum. En återställning av exempelvis 10+ TB på en Raid5 eller Raid6 tar kanske längre tid än att göra det mot en Raid0.

Skrivet av Svchost.exe:

Exempelvis på min htpc kör jag raid 0 bara för skoj skull på 3st 250gb diskar. Har en likadan kontroller där som i servern. Bra att lära sig där utifall de rasar.

På servern kör jag raid 5 med fyra stycken 3TB WD Red diskar. Fungerar perfekt. Lustigt nog gå raid5 på servern snabbare än raid0 på htpcn. Men de är nog slumpen.

Raid5 kan nog vara snabbare på läsning än Raid0, däremot skrivning borde det vara tvärtom. Har du prövat att rycka en disk under drift än?

Permalänk
Avstängd

Det blev till slut Raid6.
Har nu kopierat drygt 25TB och det tog vackert sin lilla tid...
Synktiden blev ungefär 36 timmar. Inget kul när strömmen går med andra ord. Men en UPS är beställd. Kan väl utan ansträngning påstå att synkning tar mindre tid än kopieringen
Har testat att rycka diskar under drift och kontrollerkortet verkar sköta det där smidigt.