RAID for dummies og viderekommende

[j--]

Kjapt spørsmål:

Ved hardware-RAID så er det kontrollerens ansvar å ta seg av en del av feilhåndteringen istedenfor disken (ref https://www.diskusjon.no/index.php?showtopic=1435554&view=findpost&p=19288763).

 

Hva med software-RAID? Tar f.eks mdadm seg av denne feilhåndteringen, eller er det opp til disken igjen å ta seg av dette?

[tho_kva2]

Har lett litt i disse postene, men hvordan settes egentlig et raid opp? Software raid er pretty straight forward, men hardware? HK idag skal vel støtte en basic form for slikt? men hvordan sette det opp er et annet spørsmål. tok et søk på google, men kom lange og tunge ting opp, om det er noen enkel forklaring så hadde det vært fint. Software blir det vel ikke siden da må jeg vel har os på en annen disk enn jeg skal ha raidet på.

Endret 7. juni 2012 av tho_kva2

[siDDis]

Feilretting på hardware raid kontrollere og dei fleste filsystemer idag er bullshit og ein skandale.

 

For å kunne rett feil og unngå kollisjoner så må ein ha ein sterk kryptografisk checksum. Ingen hardware raid kontrollere har checksum støtte og så og si nesten ingen filsystemer har det heller.

 

Dei filsystemene som har checksum støtte bruker ein SVAK checksum, som oftast CRC-32C(btrfs, hammer, wafl)

ZFS derimot har SHA-256 checksum for kvar datablokk. ZFS har også end to end checksumming som også passer på data som kjem inn og går ut av filsystemet(ergo den vil oppdage feil på nettverkskortet om du sender data mellom to ZFS filsystemer). Kvar gong ZFS leser data så generer den ein SHA-256 checksum og samanlikner med metadata'en til datablokka om alt er som det skal. Kvar checksum blir også checksumma igjen opptil ein supernode som blir massereplikert.

 

For dei som aldri har brukt ZFS så veit dei eigentleg ikkje kor alvorleg situasjon dei er i. Datakorrupsjon skjer heile tida og når du ikkje har verktøy som kan oppdage dette så kan det bli katastrofalt. Skal du ha feilhandtering av din data så er ZFS per dags dato det einaste alternativet.

 

CRC32 er såpass svak at ord som

codding kolliderer med gnu

exhibiters kolliderer schlager

 

python eksempel

import binascii
print binascii.crc32("codding")
print binascii.crc32("gnu")

[ATWindsor]

Det er jo allikevel snakk om sannsynlighet, hva eer sannsynligheten for at bit flippes så man får akkurat samme checksum med "svak" checksummuing? Andre systemer har feilbahndling de også, men dog ikke like god som ZFS. Og situasjonen er ikke helt god, men samtidig ikke mer alvorlig enn at katastrofale ting svært sjeldent skjer.

 

AtW

[siDDis]

Fordi med svak checksumming og mange TB med data kan forårsake at du reparerer feil data med feil data. Risikoen er liten, men den auker jo meir data du har. Til petabyte systemar så byrje det verkeleg å bli farleg.

Andre fordelar er at det er enklare å ta i bruk deduplisering.

 

Men feilhåntering i dei fleste systemar idag gjelder bare når ein finner feil!!!! Og det er så vanvittig forskjell når feil skjer i dei fleste tilfeller i all stillheit. Når har eg brukt ZFS på ca 10TB med data i 2 år. Eg har hatt fleire disker som har kræsja, hatt dårleg sata kabel eller rett og slett trengt ein pause. Igjennom disse åra så har eg hatt 50mb som har måtte blitt reddet via redundans. 49.9MB av disse var pågrunn av ein dårleg sata kabel i ein ny server, resten skyldes små bits som har forandra seg i stillheit.

 

På ein testserver så har eg til og med knerta eit raid såpass at nokre filer var ubrukelege sånn at eg måtte hente dei frå backup. ZFS køyrte ellers heilt fint, så eg lagde bare ein liste, sletta filene og la dei til på nytt. Same greia med mdadm enda med at heile raidet var nede og ubrukeleg.

 

Eg har så stor tillit til ZFS at eg prøver å få alt til å køyre på det. Inkl Windows oppå eit iSCSI volum frå ZFS.

 

ZFS har sine minus, som mangel på block pointer rewrite og skalering(iops må auke likt med datamengde).

[ATWindsor]

Fordi med svak checksumming og mange TB med data kan forårsake at du reparerer feil data med feil data. Risikoen er liten, men den auker jo meir data du har. Til petabyte systemar så byrje det verkeleg å bli farleg.

Andre fordelar er at det er enklare å ta i bruk deduplisering.

 

Men feilhåntering i dei fleste systemar idag gjelder bare når ein finner feil!!!! Og det er så vanvittig forskjell når feil skjer i dei fleste tilfeller i all stillheit. Når har eg brukt ZFS på ca 10TB med data i 2 år. Eg har hatt fleire disker som har kræsja, hatt dårleg sata kabel eller rett og slett trengt ein pause. Igjennom disse åra så har eg hatt 50mb som har måtte blitt reddet via redundans. 49.9MB av disse var pågrunn av ein dårleg sata kabel i ein ny server, resten skyldes små bits som har forandra seg i stillheit.

 

På ein testserver så har eg til og med knerta eit raid såpass at nokre filer var ubrukelege sånn at eg måtte hente dei frå backup. ZFS køyrte ellers heilt fint, så eg lagde bare ein liste, sletta filene og la dei til på nytt. Same greia med mdadm enda med at heile raidet var nede og ubrukeleg.

 

Eg har så stor tillit til ZFS at eg prøver å få alt til å køyre på det. Inkl Windows oppå eit iSCSI volum frå ZFS.

 

ZFS har sine minus, som mangel på block pointer rewrite og skalering(iops må auke likt med datamengde).

 

Det er alltid en teoretisk mulighet, uansett hvor kraftig checksummingen er. jeg spurte dog om hvor sannsynlig det er, hvor sannsynlig er det at 1. Det oppstår en feil på dataene 2. Reperasjonen faktisk feiler pga "feil" checksum. Hvor mye data har man før man ødelegger en bit med dette, rent sannsynlighetsmessig? Jeg tipper det er snakk om tusenvis av terrabyte.

 

Selvfølgelig er det forskjell, og ZFS er ett kaon filsystem, men situasjonen på testserveren din var ikke "katastrofal", uhelidg, ja. Katastrofal, nei.

 

AtW

[siDDis]

Høhø, betegnelsen katastrofal kjem du nok til å høyre frå sjefen din når han får rapporter med feil data

 

Kollisjoner med SHA er mange mange mange ganger mindre enn CRC, og det er ingen kjente tilfeller av kollisjon med SHA1 - 80 rounds

Samanlikning av hash algoritmer og kollisjoner -> http://programmers.s...eness-and-speed

[ATWindsor]

Høhø, betegnelsen katastrofal kjem du nok til å høyre frå sjefen din når han får rapporter med feil data

 

Kollisjoner med SHA er mange mange mange ganger mindre enn CRC, og det er ingen kjente tilfeller av kollisjon med SHA1 - 80 rounds

Samanlikning av hash algoritmer og kollisjoner -> http://programmers.s...eness-and-speed

 

Dette er jo ikke en tråd der folk ber om råd til sitt bedriftsoppsett.

 

Det er færre kollisjoner, men hvor ofte er det ett reelt problem med CRC? hvor mange ganger skjer det at man får bitfeil, og crcen retter opp feil per terrabyte?

 

AtW

[siDDis]

Bitfeil vil eg påstå skjer på 1 byte i året per TB, hos nokon oftare, hos andre skjeldnare. Det skal igjen veldig mykje til at ein får feil med CRC, men nokon vil oppleve eit katastrofalt problem med CRC ein dag. Ville du ha køyrt ein bil utan airbag idag? Sannsynlegheita for at det skal gå verkeleg galt er jo forsvinnande liten...

[ATWindsor]

Bitfeil vil eg påstå skjer på 1 byte i året per TB, hos nokon oftare, hos andre skjeldnare. Det skal igjen veldig mykje til at ein får feil med CRC, men nokon vil oppleve eit katastrofalt problem med CRC ein dag. Ville du ha køyrt ein bil utan airbag idag? Sannsynlegheita for at det skal gå verkeleg galt er jo forsvinnande liten...

 

Nei, det er det ikke, biluykker er blant det som dreper mest av unge folk. Risikoen er langt fra neglisjerbar. Tvert imot er bilulykker en illustrasjon av det motsatte, nemlig at folk askepterer en viss risiko om noe er praktisk.

 

AtW

[jonny]

...

Dei filsystemene som har checksum støtte bruker ein SVAK checksum, som oftast CRC-32C(btrfs, hammer, wafl)

ZFS derimot har SHA-256 checksum for kvar datablokk. ZFS har også end to end checksumming som også passer på data som kjem inn og går ut av filsystemet(ergo den vil oppdage feil på nettverkskortet om du sender data mellom to ZFS filsystemer). Kvar gong ZFS leser data så generer den ein SHA-256 checksum og samanlikner med metadata'en til datablokka om alt er som det skal. Kvar checksum blir også checksumma igjen opptil ein supernode som blir massereplikert.

...

 

Jeg kjører ZFS på Ubuntu server, og der er default checksum algoritme Fletcher2. Hvordan stiller denne seg sammenlignet med CRC og SHA256? Bør jeg endre til en annen algoritme (mulighetene er fletcher2, fletcher4 og sha256)?

[siDDis]

Fletcher2 er litt svakare enn CRC32C, men igjen litt kjappare.

[jonny]

Kjørte noen kjappe tester nå med hver av de tre algoritmene. Selve testen gjorde jeg slik:

 

dd bs=1M count=20K if=/dev/zero out=/tank1/video/dd_test

 

tank1 er en ZFS zpool med et RAIDZ1 vdev (5x2TB), OS er Ubuntu 64-bit server (kjører virtuelt på en Windows 7 maskin).

 

For fletcher2 (default): ca. 275 MB/s

fletcher4: ca. 250 MB/S

sha256: ca. 110 MB/s

 

Tror jeg holder med til fletcher2, jeg...

[tho_kva2]

Slettet

Endret 7. juni 2012 av tho_kva2

[tho_kva2]

Når jeg følger guiden i manualen og settet bios settings til:

OnChip SATA Controller - Enabled

OnChip Sata Type - Raid

OnChip Sata port 4/5 Type - As SATA Type

Så finner ikke windows noen filer på dvd, men tar jeg alt tilbake til normalt så finner den alt som normalt

Hva er problemet? Noen som kan hjelpe?

[zotbar1234]

Bitfeil vil eg påstå skjer på 1 byte i året per TB, hos nokon oftare, hos andre skjeldnare.

 

Kilde?

 

Ved siden av saken, finnes det en open source kryptoløsning for ZFS for Linux?

[siDDis]

Det er bare å google, er nok med eksempler.

 

http://golem.ph.utex...ves/001305.html

http://sosc-dr.sun.c...ed/data_rot.jsp

 

Til kryptering av ZFS så bruker eg GELI som er ein modul til FreeBSD, til Linux kan du sikkert bruke encfs.

[ATWindsor]

Det er bare å google, er nok med eksempler.

 

http://golem.ph.utex...ves/001305.html

http://sosc-dr.sun.c...ed/data_rot.jsp

 

Til kryptering av ZFS så bruker eg GELI som er ein modul til FreeBSD, til Linux kan du sikkert bruke encfs.

 

Ingen av disse underbygger en byte per år per TB, man ville fått ødelagt, eller i det minste skadet tusenvis av filer i året om det var vanlig. Det er ikke min erfaring.

 

AtW

[GullLars]

Du har BER (Bit Error Rate) og UBER (Uncorrectable BER) på harddisker. Om filsystemet bruker CRC kan det oppdage silent errors og UBER som ikke disken tar/oppdager selv. Med en eller annen ECC form eller paritet i filsystemet kan man rette UBER fra harddisker, eller feil som oppstår under transport.

BER for forbrukerharddisker ligger rundt 10^-14, mens UBER ligger rundt 10^-15 til 10^-16. Noen SSDer oppgir UBER til 10^-18 til 10^-19 innenfor en viss skrivemengde (typisk 50-200TiB).

 

En TB er 8*10^12 bits, så du kan ha litt trafikk til og fra en TB disk i løpet av et år for å sansynligvis få en sektorfeil. Om du fyller en 1TB harddisk èn gang er det ca 1% sjangs (10^-5) for at en sektor er korrupt i følge fabrikantenes oppgitte UBER. Om man stoler på denne er en annen sak.

[zotbar1234]

Det er bare å google, er nok med eksempler.

 

Nei, jeg har ikke tenkt å google etter dine påstander. Siden du kom med dem, antok jeg at det var en begrunnelse du støttet deg på. Og denne begrunnelsen er ... ?

 

http://golem.ph.utex...ves/001305.html

 

Underbygger overhodet ikke tesen (de har ikke engang fastslått hva feilen skyldtes).

 

http://sosc-dr.sun.c...ed/data_rot.jsp

 

Dette er litt bedre, men heller ikke deres undersøkelse gir belegg, såvidt jeg ser, til å hevde "Bitfeil (...) skjer på 1 byte i året per TB".

 

Så jeg spør igjen, har du en kilde for påstanden din?

 

(...) til Linux kan du sikkert bruke encfs.

 

Nei, det kan jeg ikke, siden encfs har en rekke begrensninger. Jeg vil essensielt ha funksjonaliteten til iallfall RAID5+cryptsetup (det er vel RAIDZ på zfs-sk) over hele diskbestanden (med unntaket av /boot). encfs kommer til kort der. sha1 over alle blokkene er veldig kjekt, men hvilke realistiske valg har man i dag under linux?