Gå til innhold

RAID 5/6 fullstendig ubrukelig til filserver anno 2010?


HåkonN

Anbefalte innlegg

Dukket opp en link til en artikkel (fra 2007) på et annet forum.

 

http://www.zdnet.com...ing-in-2009/162

 

Er RAID 5/6 virkelig *så* ubrukelig i dagens filservere (i artikkelen tas det også utgangspunkt 1TB disker, mens nå er vi oppe i 2TB)?

 

Følger man resoneringen, virker det som stor (og snart teoretisk 100% sannsynlighet) sjangs for "havari" selv under rebuild av RAID-6 der man har 2 spares.

Endret av HåkonN
Lenke til kommentar
Videoannonse
Annonse

De overdriver helt klart en god del, det er ingen grunn til krisemaksimering.

 

Men bitråte er helt klart et reelt problem, og for privatmarkedet er det best løst av ZFS.

 

I bedriftsmarkedet er det løst av ekstra checksums og jevnlige verifiseringsjobber.

 

Når det gjelder diskfeil under rebuild, så ja, det er en risiko, og en av de mange grunnene til at man har backup.

Endret av Varj
Lenke til kommentar

Stusser litt på en ting her.

 

Må neste ta et eksempel. La oss nummerere diskene i et raid5 sett med 7 disker som disk1, disk2, ... disk7. Vi sier at disk7 er paritetsdisk. Dersom disk1 får totalhavari og det er noen få kb på disk2 som ikke lar seg lese, er det da nødvendigvis slik at ALT data går tapt.

Skulle tro det kun var de få kb som ikke lot seg lese som gikk tapt? Er ikke normalt sett raid kontrollere i stand til å håndtere blokker på disken som ikke lar seg lese, og evt bare fortsette?

Lenke til kommentar

problemet med bitråte er ikke at deler av disken brått slutter å fungere, men derimot at de får feil verdi.

om det oppdages kan du finne fram til de orginale dataene via paritetsdisken, men det forutsetter at du vet om det er data-stripa eller paritets-stripa det er feil på.

 

men prinsippmessig har du helt rett, dataråte tar ikke livet av hele raidet ditt, men det er også noe av grunnen til at det er så skummelt, feil kan ligge lenge nok til at korrekt backup er skrevet over, før man merker det. hvis man i det hele tatt merker det.

Lenke til kommentar

Og det er derfor me har nestegenerasjonsfilsystemer som har innebygd checksumming og self healing. ZFS løyser dei problema enkelt og greit! Skal du vere sikker på at dataen ikkje råtner vekk så er ZFS det einaste alternativet. Faktisk så er det mange dyre propritære filsystemer som ikkje har checksum og self healing funksjonaliteten til ZFS.

 

Dei einaste filsystema som har denne funksjonaliteten per dags dato er

File systems with built in fault-tolerance

 

These file systems have built in checksumming and either mirroring or parity for extra redundancy on one or several block devices.

 

* Btrfs - A filesystem based on B-Trees, created by Oracle Corporation.

* Reliance – A transactional file system with CRCs, created by Datalight.

* Reliance Nitro – A tree-based transactional file system with CRCs, developed for high performance and reliability in embedded systems, from Datalight.

* ZFS – Created by Sun Microsystems for use on Solaris 10 and OpenSolaris, ported to FreeBSD 7.0, NetBSD (as of 08/2009) and to FUSE (not to be confused with the two zFSes from IBM). Apple had announced inclusion of ZFS in their Mac OS X 10.6 (Snow Leopard) update, but later quietly removed support for it prior to release.

 

Sjølv den superdyre WAFL kan ikkje tilby den type datasikkerheit. BTRFS er enda veldig nytt, samtidig som det mangler massevis av anna funksjonalitet ZFS tilbyr.

 

Og forresten, Oracle-databasen har også end to end checksumming ;)

Endret av siDDIs
Lenke til kommentar

Dessverre når det gjelder Windows er det ikke så enkelt heller å få inn annen filsystemstøtte enn NTFS og FAT32.

Det finnes drivere for å la de LESE andre systemer men straks du toucher skrivedelen ser du at de fleste flagger ut med "Ekesperimentellt" og litt hips og haps støtte.

Lenke til kommentar

Så finnes det folk som har kjørt flere år med raid 5, 6 og raid-0 uten å mistet en eneste fil eller fått en korrupt fil. Dette tilogmed med overklokket raidkontroller Og cpu  :p

 

For meg er windows stabilt, samme som ubuntu som jeg også bruker. I de fleste tilfellene så er brukerene ustabile, ikkje operativsystemet  laugh.gif

 

 

Lenke til kommentar

Ok korleis veit du det? Har du utført checksumming manuelt på filene over tid? Det handler ikkje bare om filer som blir korrupte, men også filer som inneheld feil data. F.eks 1 bit på harddisken skifter frå 1 til 0

 

CERN har utført ein test som påviste feil i 1 av 1500 filer i snitt.

Lenke til kommentar

Ang. checksum og selfhealing. Kom nettopp over dette som en nyhet på kommende Windows Home Server "Vail". 

 

To protect against silent storage errors (bit flips, misdirected writes, torn writes), additional information is appended to each 512-byte sector stored on drive. In particular, each sector is protected by a CRC checksum, which enables Drive Extender to detect data read errors, perform realtime error correction and self-healing (up to 2 bit errors per sector if duplication is disabled, and any number of bit errors if duplication is enabled) and report the errors back to the user and application. The overhead for this additional data is roughly 12% of drive space.

 

Virket jo lovende. Vil dette gjøre samme nytten som ZFS?

 

 

Lenke til kommentar

Ang. checksum og selfhealing. Kom nettopp over dette som en nyhet på kommende Windows Home Server "Vail". 

 

To protect against silent storage errors (bit flips, misdirected writes, torn writes), additional information is appended to each 512-byte sector stored on drive. In particular, each sector is protected by a CRC checksum, which enables Drive Extender to detect data read errors, perform realtime error correction and self-healing (up to 2 bit errors per sector if duplication is disabled, and any number of bit errors if duplication is enabled) and report the errors back to the user and application. The overhead for this additional data is roughly 12% of drive space.

 

Virket jo lovende. Vil dette gjøre samme nytten som ZFS?

 

Det høyres veldig likt ut WAFL sin implementasjon, forskjellen med ZFS er at den lagrer checksum i parent block. Forskjellen med det er at om det skjer ein feil mellom ein checksum block og data block så er checksum blokka allereie validert av dens parent block. Det sies ingenting om dette i implementasjonen til NTFS. Er godt mogleg om det er feil mellom checksum og datablock så kopierer den det dupliserte blocken over den som feilet og lager ny checksum. Dete vil jo fungere så lenge ikkje den dupliserte datablokka også inneheld feil. Ikkje veit eg i detalj, men synes det er rart at det blir sagt så lite.

 

Framleis mangler også end to end checksums, ergo ZFS passer på dataen din når det går rundt i andre deler av systemet som kontroller/minne/nettverk.

Endret av siDDIs
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...