Köpa NAS?

[xxargs]

Vetetusan, en OS som läser en nibbel fel data från en fallerande rambank krachar ganska fort, en kontroller som inte själv använder samma ram som den cache:ar datat i - kan köra med detta i evighet innan det upptäcks och hela raiden är körd.

(detta har jag nämligen åkt på en gång i tiden - förvisso RAM-minnet i en MFM-kontroller, men jäkla vad det ställde till, och sådan kan hända också i en RAID-kontroller)

Även om det använder ECC-minne - det är paritet och checksumma i transfern mellan hårddisk och controllern, så finns det ändå en rad gränssnitt där data går över gränser utan kontroll och kan korruptas obemärkt trots ecc-minne etc. HW-åtgärder.

Det är därför modernare filsystem som btrfs och zfs börjar med checksumma i filsystemet även på datadelen så att man får en 'ax till limpa'-kontroll att datat som till slut hamnar på disken är verkligen är det som skrevs och likaså när det läses tillbaka igen.

alla moderna HD - vare sig flash eller snurr, har ganska hög nivå av ECC och felrättning i sig medans sk. ECC-minne ofta bara ligger på Hamming-kodnivå då mer avancerade metoder ger längre accesstider och mer måste läsas in innan man kan avgöra om fel föreligger eller inte.

Sedan finns begränsning i hur många fel kan upptäckas - paritet indikerar för ett bitfel men ger grönt ljus för 2 fel samtidigt och alla jämna antal fel utöver detta - därför kan en nibbel-fel (4 bitar) passera obemärkt i en överföring med paritetskontroll.

Hammingkod förbättra detta en hel del som dels kan indikera felet om det är 1 eller 2 fel och kan peka ut vilket som är felet om det är 1 fel och kan rätta det och också kan avgöra om felet är i datadelen eller paritetsdelen. Skall man ha högre felrättningsförmåga så kostar det fler bitar parallellt i bussen på minnet.

Felrättning som Reed-Solomo kräver att en ganska stor ström av bitar och läsas in i större block innan det kan rätta, och är det 'interleave' (flätning) så krävs ännu större inlästa block - passar inte för ramminne men fungerar för sekventiella strömmar som från hårddisk, tape, och CD/DVD/BR-media och via trådlösa gränssnitt.

---

Skall man ha en köpe snik-NAS med filsystem med checksumma även på datadelen (och inbyggd kompression samt kryptering av filsystemet om man vill) så är så vitt jag vet bara Netgear Ready-nas, som har det med btrfs som filsystem.

annars får man ge sig på egenbyggd dator med freeNAS och liknande där man kan köra zfs/btrfs som disklagringsmodell.

tyvärr är licensförhållandet så att zfs aldrig kan komma in på de stora linux-distributionerna (dessutom är zfs lite minneshungrig) utan kräver egen manuell laddning och installation medans btrfs är allt närmare till att bli en standard filsystem som ersätter ext4 i distributionerna i linuxvärlden - för har man väl provat på att göra snapshot som generationsbackup och COW som medger deduplikation på annan (både fil och block) nivå än att använda hårda länkar, så är det jäkligt svårt att backa till ext4 igen...


Btrfs som jag provat ett tag, har än så länge varit stabilt (dvs inga oplanerade dataförluster) och förutom ovanstående så finns ingen begränsning på antalet inoder, vilket ext4 har (inte för att jag har kört slut på inoder hittills ännu) och sådant blir allt viktigare ju större diskarna är.

Idag är största diskarna på 6 och 8 TB i konsumentprisnivå (Hitachi har en 10 TB men kräver specielle drivrutiner på lågnivå för att hanteras och siktet är på datacenter-lagring) och inom 5 år förmodligen fördubblats, och många filsystem och speciellt i RAID-konfiguration börja knaka i sömmarna numera. Till detta när man skall hantera shingled-diskar, kanske i kombination med SSD-cache så är både ZFS och Btrfs förmodligen närmast att optimera för detta iom aktiv utveckling medans ntfs,ext4 och liknande är ganska frusna i formen och att något överväldigande händer där är inte att förvänta sig på lång tid framöver.

[Nerre]

Idag är väl egentligen all RAID SW-raid, skillnaden är bara om koden ligger i operativets kernel eller om det ligger i flash-minne på ett controllerkort?

Det finns väl knappast nån RAID-controller som jobbar enbart med hårdkodad logik?

[AndersG]

Det finns väl knappast nån RAID-controller som jobbar enbart med hårdkodad logik?

De gjorde inte Compaqs första SMART controllers på 80 talet heller Minns att jag pratade med en av ingenjörerna som konstruerat den och han sade att han gillade att konstruera raidkontrollers för att han slapp (programmera för) Intel.

Som sagt var. Jag är säkert färgad av mina egna och goda erfarenheter av hårdvaru raid. Har även satt upp åtskilliga servers med speglade diskar oxå. Har egentligen aldrig kört mjukvaru-RAID. Få se hur jag gör med min TV server. Moderkortet jag funderar på (ASUS Z97-P) har uppenbarligen stöd för någonsorts hw raid, dock knappast batteribackat.

[sodjan]

> Det finns väl knappast nån RAID-controller som jobbar enbart med hårdkodad logik?

Det har det nog i princip aldrig funnits.

HW-RAID har alltid betytt att det inte ligger i host OS'et.
D.v.s att host OS'et enbart ser RAID volymen och inte de individuella diskarna.

HBVS (Host Based Volume Shadowing) på VMS är ett exempel på SW-RAID som
körs i host-OS. DKAxxx är individuella diskar och DSAxxx är RAID/shadow set:

Kod: Markera allt

$ show device d

Device                  Device           Error    Volume         Free  Trans Mnt
 Name                   Status           Count     Label         Space Count Cnt
DSA10:                  Mounted              0  ALPHASYS       57.53GB   588   1
DSA100:                 Mounted              0  DISK3          33.94GB    61   1
DSA200:                 Mounted              0  BCK_DISK       50.47GB     3   1
$1$DKA0:      (xxxxxx)  ShadowSetMember      0  (member of DSA10:)
$1$DKA100:    (xxxxxx)  ShadowSetMember      1  (member of DSA10:)
$1$DKA200:    (xxxxxx)  ShadowSetMember      0  (member of DSA100:)
$1$DKA300:    (xxxxxx)  ShadowSetMember      0  (member of DSA100:)
$1$DKA400:    (xxxxxx)  ShadowSetMember      0  (member of DSA200:)

Det är disk drivern och shadow drivern i VMS som ser till att både diskarna uppdateras.
Notera att DSA200: är ett shadow-set med enbart en member, DKA400: (just nu).
"DKA" betyder lokalt anslutna SCSI diskar.
"DSA" betyder "Shadowset".

Varje DSA Shadowset kan ha upp till 6 underliggande diskar volymer.

Om man har t.ex FibreChannel anslutna diskar från ett SAN så är det i princip
HW-RAID eftersom host-OS inte ser hur volymerna är realiserade fysiskt.
Det sköts av supporten för SAN'et

Kod: Markera allt

$ show device/mounted d

Device                  Device           Error    Volume         Free  Trans Mnt
 Name                   Status           Count     Label         Space Count Cnt
$1$DGA1400:     (xxxx)  Mounted              3  ALPHASYS        8.18GB   430   1
$1$DGA1410:     (xxxx)  Mounted              2  DATA2           8.52GB    16   1
$1$DGA1420:     (xxxx)  Mounted              0  DATA3          20.32GB     3   1
$

I detta fall är volymerna allokerade på ett centralt IBM DS8000 system.
"DGA" betyder "FibreChannel ansluten disk".

Sen kan så klart flera DGA diskar från olika SAN monteras som
ett DSA shadowset, ifall man vill skugga lagringen mellan flera SAN.

Se en SW-RAID kan vara uppbyggt av flera HW-RAID volymer...

Just nu vill man faktiskt byta SAN system, och då hade det varit en fördel
om vi hade varje disk monterad som en DSA disk, även om det enbart var
en DGA disk i varje "shadowset". Då skulle vi bara kunna montera den nya
DGA disken från det nya SAN systemet i varje shadowset, låta "shadow copy"
gå klart, och sedan demontera den gamla DGA disken och alltså ha flyttat
driften från ett SAN till ett annat helt transparent under drift.

[säter]

Jag har kollat runt lite efter begagnat, men det verkar vara så små diskar i de som finns till salu.
Jag måste ha minimum 2x3TB.

Är det bättre att köpa diskar separat i efterhand?

[swapper]

Diskar är "färskvara" så det är aldrig fel att köpa nytt.
Hårdvara i övrigt håller betydligt längre än diskarna.
Kontrollera bara så att diskarna du köper stödjs av hårdvaran (storlek/märke)
Just nas kan vara petiga.

[xxargs]

Speciellt HW-NAS kan vara griniga medans mjukvaru-NAS är ofta mer flexibla.

Sedan att tänka på om man letar beg NAS med mer än 2 diskplatser till runt 4-5 diskplatser och är ARM-processor baserat, att det finns ofta en gräns vid 16 TB på filsystemet om det baseras på 32-bitars ARM etc. Intelbaserade maskiner (för dom större NAS med > 4 diskar) kör på 64-bit processor och då har man ingen 16 TB-gräns på filsystemet.

Då bara för några år sedan så var 16 TB nästan ouppnålig gräns, medans idag korsas när man stoppar in den tredje eller fjärde 8TB-disken (i JBOD eller RAID-5)


Och att också tänka på är att Ready-NAS, buffalo, Synology mfl. att om en av dessa har problem så har oftast de andra tillverkarna det samtidigt eftersom de delar stor delar av linux-källkoden. tex. ARM-versionerna av NAS hade för ett par år sedan stora bekymmer med ext4:an journalföring att man får verkan att disken blir extremt slö med exponentiellt ökad tid för varje skriven fil när man når 75-80% diskfyllnad och det tog lång tid (uppemot 1 år) innan det fixades något så när och av någon anledning nära på samtidigt hos de största tillverkarna av NAS.

Man kunde nästa ana paniken på resp. tillverkare bakom resp. forum att de egentligen inte hade någon kernelhackare att slänga in för att lösa problemet och alla väntade på varandra att någon skulle lösa dilemmat åt dem och resten följa efter.

Det var en situation att folk/kunder blev skitsura i resp tillverkares forum och returnerade NAS och pengarna tillbaka och köpte någon annan fabrikat, för att upptäcka att problemet var precis lika där, ja, om man inte bytte från ARM-baserad NAS till tex. Intelbaserad dito (som kostar dubbla till 3 ggr så mycket)...

Skall man vara ärlig, så skulle jag inte köpa någon begagnad NAS och kanske få ovanstående problem för att man inte skött uppdateringen - sedan är de äldre versionerna också primitivare på olika sätt även i gränssnittet.

[skalman23]

Köp en Syology. De är enkla att använda och fungerar även till Mac.

[swapper]

För de som inte vill vara helt låsta i ett "köpe nas" med de för/nackdelar det har finns http://www.openmediavault.org/ (finns massor andra såklart)
Kör själv det på en HP gen8 microserver fungerar riktigt bra.
Inte lika mycket funktioner som synology mfl. men man är flexibel att köra lite vad man önskar på hårdvaran.
Att hårdvaran sen är gjord av HP som definitivt har bra erfarenhet av hållbar design av serverprodukter skadar inte.
Får även ILO med som gör att man kan fjärrstarta och administrera systemet utan att skärm/kb.

[xxargs]

Själv har jag insett vad deduplikation på filnivå (under btrfs) kan göra när det gäller att minska upptagen volym på disken - ja under förutsättning att filerna är av typen en massa backupper, samma foton som förekommer på flera ställen i tex projekt etc., generations-backupper ala rdiff-backup mfl. som inte förstår om filer bara har flyttats i filsystemet, utan istället lagrar filen som togs bort som generationsbackup och en ny fil dyker upp på andra ställen som också måste backuppas - lite jobbigt om det är 32 GB bilder som bytte directory...

Har dock varit lite försiktig med detta och aldrig gjort det på orginal - men hittills verkar det inte missa något eller tappa eller korrumpera filer i dom experimenten jag gjort hittills och besparingen har legat runt 50% på HD - betydligt mer än vad tex. påslagen filkomprimering kan ge då dagens filer är extremt mycket mer komprimerade (media och bildfiler) och stora samt många program komprimerar internt eller krypterar det och gör filen okomprimerbart innan det hamnar på disken.

Av läxa sedan lång tidigare (det började med excel som inte kunde hantera mer än 65535 rader och jag ville hantera >300000 poster från mätprogram...) att det som fungerar bra med kanske några hundra till kanske några tusen filer/poster men barkar riktigt åt pipan när man pratar om tiotusentals till flera miljoner filer/poster så har mina experiment alltid skett på minst 1 TB stora filsamlingar (på egna HD) och ca 3-4 miljoner filer

Förr räknade man med ca 50% komprimering när man kör med filsystembaserad komprimering (som tex NTFS stöder och även btrfs gör) - men idag skulle jag säga att det ger 10, kanske 20% komprimering om man komprimerar hela innehållet på en väl inkörd 'C:' - Hur eller hur så blir man ganska besviken 'gav det inte mer!!??' när det gäller återvunnen diskplats mha. komprimering på filsystemnivå.


Programmet som deduplikerar på filnivå och som jag provat under btrfs bryr sig inte om filnamnet utan jämför hasch-summor av filinnehållet efter sortering av filstorlek först och innan deduplikation-momentet gör byte för byte-komparering. Då varje filnamn har sin egen I-nod så ändras inte datum och andra parametrar relaterat till filen fast inoden efter deduplikeringen pekar så samma sektorer som andra inoder med samma filinnehåll också gör (reflink).

För att detta skall fungera utan problem så måste filsystemet (läs btrfs och zfs) stödja COW - copy on write - vilket innebär att om filen senare ändras av något program så skrivs ändringarna på nya sektorer unikt kopplad till filen och inte på sektorerna som delas av flera andra inoder.

(denna del går dock att stänga av om det tex. handlar om databasfiler eller VM-filer för tex. vmware som vid tung användning annars kan bli väldigt fragmenterat om varenda skrivning med ny data alltid görs på nya sektorer mha. COW)

Det finns också block-deduplikation vilket kan innebära att om man har diskimage från tex jobbdatorn tagna vid olika tillfällen - så kommer inte fildeduplikation att se filerna som lika och inte göra deduplikation - medans blockdeduplikation jämför innehållet i tex 1 MB-block på filerna och lägger alla lika block så inoderna på båda filerna pekar på samma sektorer för dom delar som är gemensamt lika för båda filerna och frigör diskutrymme den vägen. sådant kan vara intressant om man som jag gör en imagefil av hela disken på 250 GB styck en gång i halvåret då det i praktiken har visat sig att bara 15- 20 GB har ändrats mellan versionerna och resten är lika...

(varför image av disken - jo för att få igång datorn snabbt med inte all för mycket backupper att mata in om det blir diskhaveri eller datorn stulen, har lärt mig att det är inte det man tror är viktig och som man tar backup på, som är det viktiga - utan det är den delen som man _inte_ tar backup på som är det viktiga och utan dem kan vara tuvan som välter lasset... - tex java ver 7 för gamla klientprogram som vägrar något nyare pga säkerhetsfunktioner då denna inte går att ladda ner längre från Oracle utan betalsupport hos dem... - en driftklar imagekopia som inte är för lastgammal är guld värd i dom lägena...)

Rekommendationen i dagsläget är att använda btrfs för dessa övningar då ZFS kräver väldigt mycket mer minne för deduplikation (ca 1 GB ram per 1 TB hårddiskutrymme) då det är stödd i själva filsystemets mekanismer som används när en fil skrivs och läses i realtid medans i btrfs så är det separata program som går i sin egen lilla (lågprioriterad) takt och städar i efterhand som en garbage collector ungefär och kan lägga metadatat som filer/databas istället för att låsa upp en massa RAM-minne online som i ZFS.

Nu skall också sägas att deduplikeringsprogrammen under btrfs inte är helt färdigpolerade, 'bedup' som fildeduplikeringsprogrammet kallas fungerar hyffsat och lagrar metadatat i sqlite-databas. Medans blockdeduplikationsprogrammet 'duperemove' i nuvarande läget har klara och allvarliga skalningsproblem med kvadratisk ökande tid med antal filer/minskad blockstorlek och databas-sökningen är helt klart flaskhalsen rent prestandamässigt. det börjar kanske med 10-tal deduplikationer/sekunden för småfiler men efter några timmar körning tar 3 minuter per event och kanske bara något hundratal GB genomgången så gav jag upp...

och så har man denna enkla script (fungerar bara under btrfs i linux och möjligen under zfs)

Kod: Markera allt

#!/bin/bash
# usage: dedup.sh path_to_files_with_many_expected_dupes
mkdir sums
find $@ -type f -print0 | while read -d $'\0' -r F
			  do
			      echo -n "$F : "
			      FHASH=$(sha256sum "$F" | cut -d" " -f1);
			     # If hashed, it's probably a dupe, compare bytewise 
              # and create a reflink (so cow)
			      if [[ -f "sums/$FHASH" ]] && cmp -s "sums/$FHASH" "$F";
			      then
				  echo "Dup." ;
				  rm "$F" ;
 				  cp --reflink --preserve=all "sums/$FHASH" "$F" ;

               # It's a new file, create a hash entry.
			      else
				  echo "New." ;
				  cp --reflink --preserve=all "$F" "sums/$FHASH" ;
			      fi
			  done
rm sums/*
rmdir sums 

Och det verkar inte vara någon skillnad i sökhastighet för matchande checksumma om direktoryt 'sum' innehåller 10 filer eller en miljon filer - det går snorsnabbt trots att det är genom en bash-script och medstadelen av tiden går åt att läsa data från disk och generera sha256-summor eller byte för byte-jämföra filer innan reflink-kopiering i fallen med match.

Denna script är hittills absolut den snabbaste lösningen för deduplikation på filnivå jag sett hittills då de mer avancerade programmen med databasuppslagning eller metadata i ramminne är långsammare (fast ambitionen är det motsatta - att göra det snabbt) - faktiskt mycket långsammare - dock det finns en (och kanske avgörande nackdel) med denna script - alla deduplikerade filer (med samma innehåll) behåller förvisso sitt unika namn men får samma tidsstämpel och filstatus och rättigheter som den först hittade filen med samma innehåll i sökningen!!.

Vet inte om detta går att lösa så att tid och status kan behållas för resp fil. i en enkel script och standardkommandon - de mer avancerade programmen tidigare nämnt använder ioctrl-funktioner (och fillåsning innan kopiering) för denna kopiering eller snarare reflink-funktion och därför påverkas inte filens metadata (tid, rättigheter etc.) .

[AndersG]

Litet "espirit de escalier", men en annan fördel med HW raid är att man kan boota från den även om en disk är nere. Hur löser man det med SW raid?

[Nerre]

När en PC bootar linux så är ju sekvensen så här:

BIOS läser bootsektorn och exekverar bootladdaren som ligger där.

Bootladdaren läser in kerneln från disk till RAM och exekverar sen kerneln.

Kerneln har stödet för mjukvaru-RAID och detekterar RAID-volymen.

Eftersom boot-laddaren knappast har stöd för RAID så måste den läsa kerneln från nån fysisk disk (jag tror boot-laddaren läser en specifik sektor, inte en specifik fil?). Så det borde då alltså fungera om boot-sektor och kernel finns på alla diskarna i arrayen.

[AndersG]

OK. Har viss erfarenhet av hur det funkade med spegling, för länge sedan.. Det ver inte så alldeles enkelt att hålla bootsektorerna synkade. I det fallet är en HW raid mycket enklare.

[Larsson90]

Bygg själv, installera openmediavault (debian), freeNAS (freebsd) eller något liknande och konfigurera där.

[Nerre]

OK. Har viss erfarenhet av hur det funkade med spegling, för länge sedan.. Det ver inte så alldeles enkelt att hålla bootsektorerna synkade. I det fallet är en HW raid mycket enklare.

Idag så tror jag inte man behöver pilla automatiskt. De senaste gångerna jag har installerat Debian så har det funnits med i installatonsprogrammet att installera på en RAID-volym och jag antar att då håller de medföljande scripten koll på att det blir rätt.

Här finns en beskrivning
https://wiki.debian.org/DebianInstaller ... reRaidRoot
(De demonstrerar på en virtuell maskin, bläddra ner en sida för att skippa installationen av den virtuella maskinen.)