[Utbrutet stickspår från en annan tråd — Här diskuteras ZFS, bit rot och annat - mod]

Trädvy Permalänk
Forumledare
Registrerad
Okt 2002

[Utbrutet stickspår från en annan tråd — Här diskuteras ZFS, bit rot och annat - mod]

*Meddelanden utbrutna*

...från Vilken typ av Raid5 el Raid6 lösning. Tips?. Detta långa stickspår anser jag inte hjälpte trådskaparen, men gör ett försök med att ge det en egen tråd om det finns mer att diskutera.

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Trädvy Permalänk
Avstängd
Plats
Sthlm
Registrerad
Nov 2008

[Utbrutet stickspår från en annan tråd — Här diskuteras ZFS, bit rot och annat - mod]

Moderator informerar om denna tråd

*Meddelanden utbrutna* från Vilken typ av Raid5 el Raid6 lösning. Tips?. Detta långa stickspår anser jag inte hjälpte trådskaparen, men gör ett försök med att ge det en egen tråd om det finns mer att diskutera.

/phz

----------------------------------

Skrivet av Micke O:

Det enda som hjälper mot oavsiktlig radering etc är ju just backup, så oavsett vilken RAID-typ du väljer så är du inte idiotsäker.

ZFS hjälper mot oavsiktlig radering. Du måste använda "snapshots", det funkar som Apple Time Machine.

ZFS är gratis och du behöver inget extra raidkort. Istället använder du bara vanliga SATA diskar. ZFS är ett mjukvaruraidsystem som är mycket säkrare än raid kort.

Med tiden så ruttnar data sakta bort. Det börjar bli bitfel här och där, helt spontant. Mina gamla Amiga disketter funkar inte idag, de har för många fel. Datat har ruttnat bort. Detta händer även på hårddiskar, men i långsammare takt. Så om du upptäkcer att du inte kan öppna en rar fil längre, så går du till din backup, dvs din extra hårddisk i byrån. Men, tänk om de filer du backuppade redan var ruttna? Tänk om även din backup har samma ruttna fil? Eller tänk om när du kopierade filen, så blev det något knas i kopian. Har du kontrollerat att din backup funkar korrekt och inte har några trasiga filer?

Du borde göra en MD5 (eller SHA256) checksum på alla filer på din hårddisk, och sen göra en MD5 (SHA256) checksum på din backuphårddisk och jämföra resultatet. Först då kan du vara säker på att din backup funkar som avsett och att det inte är några fel eller ruttna data. Så med jämna mellanrum (kanske en gång i månaden) så bör du göra MD5 checksummor på alla dina filer och jämföra dem för att se att inget har ändrats (t.ex. data ruttnar, eller virus har ändrat exe filer, etc). Och om nån fil har ändrat sig, så måste du ta fram en korrekt fil från din backup och kopiera tillbaka. Tänk om många filer har ändrat sig, då måste du kopiera många filer.

Och sen om du ska vara säker, så borde du förvara din MD5 checksumme fil på en annan hårddisk. Tänk om din MD5 fil råkar raderas?? Så du har din MD5 fil på olika hårddiskar. Och när du uppdaterat en fil så måste du uppdatera MD5 checksumme filen på alla dina hårddiskar. Och eftersom du har flera hårddiskar, så måste du göra detta för alla diskar. Det blir många MD5 checksumme filer det.

Självklart måste du göra även detta för raid. Om du köper ett raid kort så måste du se efter att dina data inte ruttnar bort på raidet. Du måste köra MD5 checksummor på alla filer med jämna mellanrum och se att alla data är korrekta. Och förvara MD5 checksumme filen på en annan disk. Och uppdatera den filen så fort du kopierat nya filer. etc etc Ett jävla jobb.

Eller, så använder du ZFS som gör allt detta ovanstående helt automatiskt åt dig. Du har ett mjukvarurraid, och ZFS gör SHA256 checksummor på alla filer och jämför och om någon minsta bit har ändrat sig, så tar ZFS fram en kopia och reparerar allting och informerar dig. Dessuotm kan du använda "snapshots" som skyddar mot t.ex. oavsitklig radering och mot virus.

ZFS är mycket säkrare än hårdvaru raid kort., och det är gratis. Stora lagringsservrar som lagrar PetaByte och kostar miljoner använder ZFS. Testa att ladda ned FreeNAS eller FreeBSD eller Solaris och labba lite i VirtualBox så slipper du installera dessa OS. Det går att köra ZFS på Linux också.

Trädvy Permalänk
Medlem
Registrerad
Nov 2009
Skrivet av Micke O:

Har provat ZFS på FreeNAS men det var en del strul att få igång det (skit bakom spakarna) med rättigheter hit och volymer dit etc. Har dessutom problem att få drägliga prestanda på VMar (ESXi) som kör FreeNAS. 30MB/s över nätet duger inte när jag under W2k8 på samma host och disk maxar gigethernet. Kanske för att jag saknar VMware Tools eller valt fel vNIC?

Allt är lätt när man kan det. FreeBSD är väl inte direkt känt för sin användarvänlighet... Garanterat sk*tbra när man kan det men vägen dit är ju ganska lång och det är bra svårt att sitta och pilla utan grafiskt gränssnitt (kan vara lurigt ändå) om man inte vet exakt vad man letar efter.

En misstanke:
Har ZFS direkt åtkomst till diskarna eller ligger det nån virtualiseringsmjukvara emellan? ZFS funkar bäst om det har direkt kontroll över diskarna, dvs dyra raidkort eller nån slags virtualiserad diskkontroller emellan sabbar bara. Windows och NTFS som du kör har inte samma funktioner som ZFS vilket gör att det funkar bättre i din miljö. Den här guiden använder inte FreeNAS utan Nexenta men principerna är desamma. Det viktiga här är att du har en CPU och mobo/chipset som klarar VT-d (om du har intel) så du kan ge den virtuella maskinen med ZFS direkt åtkomst till diskkontrollern. Sen måste du kanske kolla upp hur FreeBSD och FreeNAS sköter sig som en VM. Det kan mycket väl va det som gör att det går segt.

Vill man inte virtualisera filservern får man antingen ha två fysiska servrar, en filserver och en virtualiseringsserver, eller en virtualiseringsserver där host-OS även sköter filhanteringen, t.ex FreeBSD med Virtualbox eller Linux med KVM eller Xen. Eller Microsofts nya server 2012 med Hyper-V. Mer specifikt än så kan jag inte svara tyvärr för jag har knappt hållt på med virtualisering annat än virtualbox, resten har jag bara läst.

Inga av problemen du räkna upp ovan har nämligen med ZFS att göra förutom ovanstående möjliga scenario. När det gäller nätverkshastigheten måste du konfa samba eller nfs. Det kan vara smart att göra tester först för att få reda på var flaskhalsen ligger, om det är ZFS eller nätverket.

Om du inte orkar med FreeNAS så föreslår jag att du stannar med Windows. Vill du inte pröjsa kan du ju testa Ubuntu med ZFS men jag tvivlar på att det är lättare än FreeNAS. Tänk på att virtualiseringen lägger till extra komplexitet som även den måste förstås av användaren ifall problem uppstår.

Trädvy Permalänk
Medlem
Registrerad
Aug 2002
Skrivet av usilusken:

En misstanke:
Har ZFS direkt åtkomst till diskarna eller ligger det nån virtualiseringsmjukvara emellan? ZFS funkar bäst om det har direkt kontroll över diskarna, dvs dyra raidkort eller nån slags virtualiserad diskkontroller emellan sabbar bara. Windows och NTFS som du kör har inte samma funktioner som ZFS vilket gör att det funkar bättre i din miljö. Den här guiden använder inte FreeNAS utan Nexenta men principerna är desamma. Det viktiga här är att du har en CPU och mobo/chipset som klarar VT-d (om du har intel) så du kan ge den virtuella maskinen med ZFS direkt åtkomst till diskkontrollern. Sen måste du kanske kolla upp hur FreeBSD och FreeNAS sköter sig som en VM. Det kan mycket väl va det som gör att det går segt.

Vill man inte virtualisera filservern får man antingen ha två fysiska servrar, en filserver och en virtualiseringsserver, eller en virtualiseringsserver där host-OS även sköter filhanteringen, t.ex FreeBSD med Virtualbox eller Linux med KVM eller Xen. Eller Microsofts nya server 2012 med Hyper-V. Mer specifikt än så kan jag inte svara tyvärr för jag har knappt hållt på med virtualisering annat än virtualbox, resten har jag bara läst.

Inga av problemen du räkna upp ovan har nämligen med ZFS att göra förutom ovanstående möjliga scenario. När det gäller nätverkshastigheten måste du konfa samba eller nfs. Det kan vara smart att göra tester först för att få reda på var flaskhalsen ligger, om det är ZFS eller nätverket.

Om du inte orkar med FreeNAS så föreslår jag att du stannar med Windows. Vill du inte pröjsa kan du ju testa Ubuntu med ZFS men jag tvivlar på att det är lättare än FreeNAS. Tänk på att virtualiseringen lägger till extra komplexitet som även den måste förstås av användaren ifall problem uppstår.

Burken jag har som labbserver har tyvärr inte stöd för IOMMU så direktåtkomst blir det inte tal om därför

Problemen har iofs inget med ZFS i sig att göra men eftersom det är svårt att få ZFS att funka på Windows så blir det ett problem som hänger ihop så att säga

Jag drar slutsatsen att det verkar minst sagt meckigt att få att fungera ens med drägliga prestanda - och då är de frågor jag sett här i forumet ändå ställda av folk som verkar ha bra koll så det känns verkligen inte som någon Svensson-lösning.

Känns som att tråden spårade ur någonstans i höjd med att jag menade att RAID inte ersätter backup, och det vidhåller jag, men jag skulle ha skrivit offsite-backup som jag egentligen menade

i5-2500k @ 4.2GHz | ASUS P8Z68V/GEN3 | 4x4GB Kingston DDR3-1333 | ASUS GeForce GTX 1070 Dual OC | Intel 520 480GB | WD Black 3TB | Noctua NH-U12P SE2 | Fractal Design ARC | Be-Quiet Straight Power BQT E9 CM 680W | LG BH08LS20 | ASUS Xonar Essence STX

Trädvy Permalänk
Medlem
Registrerad
Nov 2009
Skrivet av Micke O:

Burken jag har som labbserver har tyvärr inte stöd för IOMMU så direktåtkomst blir det inte tal om därför

Problemen har iofs inget med ZFS i sig att göra men eftersom det är svårt att få ZFS att funka på Windows så blir det ett problem som hänger ihop så att säga

Jag drar slutsatsen att det verkar minst sagt meckigt att få att fungera ens med drägliga prestanda - och då är de frågor jag sett här i forumet ändå ställda av folk som verkar ha bra koll så det känns verkligen inte som någon Svensson-lösning.

Känns som att tråden spårade ur någonstans i höjd med att jag menade att RAID inte ersätter backup, och det vidhåller jag, men jag skulle ha skrivit offsite-backup som jag egentligen menade

Jag tycker inte tråden spårade ur mer än att trådskaparen övergav tråden. Jag tror inte han gillade svaret att gå in på dyra raidkort osv.

FreeNAS är Svensson-lösningen, men inte virtualiserat. Bygger man en egen NAS (dvs en burk med intel atom eller liknande) och installerar FreeNAS på den får man en skitbra lösning som slår de flesta färdiga NAS både när det gäller prestanda och funktioner. Hårdvaran blir kanske lite dyrare men du slipper pröjsa för mjukvara. Nu tänkte kanske trådskaparen satsa på en QNAP istället och det funkar ju det med om man inte orkar bygga själv.

Trädvy Permalänk
Medlem
Plats
Närmaste router
Registrerad
Jul 2001
Skrivet av Micke O:

Burken jag har som labbserver har tyvärr inte stöd för IOMMU så direktåtkomst blir det inte tal om därför

Problemen har iofs inget med ZFS i sig att göra men eftersom det är svårt att få ZFS att funka på Windows så blir det ett problem som hänger ihop så att säga

Jag drar slutsatsen att det verkar minst sagt meckigt att få att fungera ens med drägliga prestanda - och då är de frågor jag sett här i forumet ändå ställda av folk som verkar ha bra koll så det känns verkligen inte som någon Svensson-lösning.

ZFS är en barnlek, jag har kört FreeNAS på en ESXi server med full fräs över gigabit. Inga konstigheter, inte haft några prestandaproblem även fast jag kört diskarna som vmdk istället för RDM.

ZFS på linux är absolut inte komplicerat, jag tycker det är enklare att sätta upp det på ubuntu än på freenas. Men det är väl mest för att jag tycker att gui't är rörigt.
4 rader i terminalen är allt som behövs i ubuntu.
add-apt-repository ppa:zfs-native/stable
apt-get update
apt-get install ubuntu-zfs
zpool create warezdump raidz1 sdb sdc sdd sde

så har du skapat en motsvarande raid5, inget mer trixande behövs om man inte vill.
Poolen monteras automagiskt vid boot i /warezdump

Själv kör jag en raidz2 på 7st 2tb diskar utan att gjort mer än jag skrev ovan.
Har en i3-2100T (slöaste i3 proppen) med 8gb minne.

root@NASDISK:~# dd if=/dev/zero of=/nasdisk/zerofile.000 bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 36.046 s, 291 MB/s

root@NASDISK:~# dd if=/nasdisk/zerofile.000 of=/dev/null bs=1M
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 32.6235 s, 321 MB/s

"Datorn har ju fan mer dragningskraft än jorden. Skulle jag ramla skulle jag hamna i datorstolen & inte på golvet."

Trädvy Permalänk
Medlem
Plats
-
Registrerad
Jul 2002
Skrivet av JZ0NiC:

ZFS är en barnlek, jag har kört FreeNAS på en ESXi server med full fräs över gigabit. Inga konstigheter, inte haft några prestandaproblem även fast jag kört diskarna som vmdk istället för RDM.

ZFS på linux är absolut inte komplicerat, jag tycker det är enklare att sätta upp det på ubuntu än på freenas. Men det är väl mest för att jag tycker att gui't är rörigt.
4 rader i terminalen är allt som behövs i ubuntu.
add-apt-repository ppa:zfs-native/stable
apt-get update
apt-get install ubuntu-zfs
zpool create warezdump raidz1 sdb sdc sdd sde

så har du skapat en motsvarande raid5, inget mer trixande behövs om man inte vill.
Poolen monteras automagiskt vid boot i /warezdump

Själv kör jag en raidz2 på 7st 2tb diskar utan att gjort mer än jag skrev ovan.
Har en i3-2100T (slöaste i3 proppen) med 8gb minne.

root@NASDISK:~# dd if=/dev/zero of=/nasdisk/zerofile.000 bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 36.046 s, 291 MB/s

root@NASDISK:~# dd if=/nasdisk/zerofile.000 of=/dev/null bs=1M
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 32.6235 s, 321 MB/s

adderar du inte bara ytterligare ett lager som kan ställa till problem?
hypervisor med filsystem + vm med filsystem och där ligger filerna.

.:Wks: Cooler Master Silencio 650|Core i5 3570 3.4 GHz|Asus P8Z77-V|8 GB| GT 465|1xDell U2311H, 2xAlienware AW2210 2xEizo 19|OCZ Revo 3 Drive 120 + Raptor 150:.
.:Server: Har ett gäng :) :.
-Learn the system, Play the system, Break the system-

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Nov 2001

Inget problem med extra lager om man kör passthrough till SAS/SATA-kontrollern.

Argaste

Trädvy Permalänk
Medlem
Plats
Närmaste router
Registrerad
Jul 2001
Skrivet av Mr_Lazy:

adderar du inte bara ytterligare ett lager som kan ställa till problem?
hypervisor med filsystem + vm med filsystem och där ligger filerna.

Jo det blir ett extra lager och det var just anledningen till att jag testade det för jag villle se hur mycket sämre prestanda det var.
Men det var bara marginell skillnad när de låg i en VMDK, så det är absolut inget problem att ha det liggandes så.

Notetera att jag inte kör det i ESXi hemma, där rullar det på Ubuntu och även där min stats. kommer ifrån.

"Datorn har ju fan mer dragningskraft än jorden. Skulle jag ramla skulle jag hamna i datorstolen & inte på golvet."

Trädvy Permalänk
Medlem
Plats
-
Registrerad
Jul 2002
Skrivet av TommyToad:

Inget problem med extra lager om man kör passthrough till SAS/SATA-kontrollern.

Jo fast det var ju just det han inte gjorde i detta fallet.

Skrivet av JZ0NiC:

Jo det blir ett extra lager och det var just anledningen till att jag testade det för jag villle se hur mycket sämre prestanda det var.
Men det var bara marginell skillnad när de låg i en VMDK, så det är absolut inget problem att ha det liggandes så.

Notetera att jag inte kör det i ESXi hemma, där rullar det på Ubuntu och även där min stats. kommer ifrån.

Tänkte inte bara prestandaförlust utan också att om man adderar ett extra lager (oavsett vad) så adderar man ev. en till felkälla som kan strula...

.:Wks: Cooler Master Silencio 650|Core i5 3570 3.4 GHz|Asus P8Z77-V|8 GB| GT 465|1xDell U2311H, 2xAlienware AW2210 2xEizo 19|OCZ Revo 3 Drive 120 + Raptor 150:.
.:Server: Har ett gäng :) :.
-Learn the system, Play the system, Break the system-

Trädvy Permalänk
Medlem
Plats
Närmaste router
Registrerad
Jul 2001
Skrivet av Mr_Lazy:

Jo fast det var ju just det han inte gjorde i detta fallet.
Tänkte inte bara prestandaförlust utan också att om man adderar ett extra lager (oavsett vad) så adderar man ev. en till felkälla som kan strula...

Jo visst är VMFS ett tilll lager, jag skulle aldrig köra zfs i en vmdk, men det var ju bara för att jag ville testa prestandan.

"Datorn har ju fan mer dragningskraft än jorden. Skulle jag ramla skulle jag hamna i datorstolen & inte på golvet."

Trädvy Permalänk
Medlem
Plats
::1
Registrerad
Okt 2001
Skrivet av saddam:

ZFS hjälper mot oavsiktlig radering. Du måste använda "snapshots", det funkar som Apple Time Machine.

ZFS är gratis och du behöver inget extra raidkort. Istället använder du bara vanliga SATA diskar. ZFS är ett mjukvaruraidsystem som är mycket säkrare än raid kort.

Med tiden så ruttnar data sakta bort. Det börjar bli bitfel här och där, helt spontant. Mina gamla Amiga disketter funkar inte idag, de har för många fel. Datat har ruttnat bort. Detta händer även på hårddiskar, men i långsammare takt. Så om du upptäkcer att du inte kan öppna en rar fil längre, så går du till din backup, dvs din extra hårddisk i byrån. Men, tänk om de filer du backuppade redan var ruttna? Tänk om även din backup har samma ruttna fil? Eller tänk om när du kopierade filen, så blev det något knas i kopian. Har du kontrollerat att din backup funkar korrekt och inte har några trasiga filer?

Du borde göra en MD5 (eller SHA256) checksum på alla filer på din hårddisk, och sen göra en MD5 (SHA256) checksum på din backuphårddisk och jämföra resultatet. Först då kan du vara säker på att din backup funkar som avsett och att det inte är några fel eller ruttna data. Så med jämna mellanrum (kanske en gång i månaden) så bör du göra MD5 checksummor på alla dina filer och jämföra dem för att se att inget har ändrats (t.ex. data ruttnar, eller virus har ändrat exe filer, etc). Och om nån fil har ändrat sig, så måste du ta fram en korrekt fil från din backup och kopiera tillbaka. Tänk om många filer har ändrat sig, då måste du kopiera många filer.

Och sen om du ska vara säker, så borde du förvara din MD5 checksumme fil på en annan hårddisk. Tänk om din MD5 fil råkar raderas?? Så du har din MD5 fil på olika hårddiskar. Och när du uppdaterat en fil så måste du uppdatera MD5 checksumme filen på alla dina hårddiskar. Och eftersom du har flera hårddiskar, så måste du göra detta för alla diskar. Det blir många MD5 checksumme filer det.

Självklart måste du göra även detta för raid. Om du köper ett raid kort så måste du se efter att dina data inte ruttnar bort på raidet. Du måste köra MD5 checksummor på alla filer med jämna mellanrum och se att alla data är korrekta. Och förvara MD5 checksumme filen på en annan disk. Och uppdatera den filen så fort du kopierat nya filer. etc etc Ett jävla jobb.

Eller, så använder du ZFS som gör allt detta ovanstående helt automatiskt åt dig. Du har ett mjukvarurraid, och ZFS gör SHA256 checksummor på alla filer och jämför och om någon minsta bit har ändrat sig, så tar ZFS fram en kopia och reparerar allting och informerar dig. Dessuotm kan du använda "snapshots" som skyddar mot t.ex. oavsitklig radering och mot virus.

ZFS är mycket säkrare än hårdvaru raid kort., och det är gratis. Stora lagringsservrar som lagrar PetaByte och kostar miljoner använder ZFS. Testa att ladda ned FreeNAS eller FreeBSD eller Solaris och labba lite i VirtualBox så slipper du installera dessa OS. Det går att köra ZFS på Linux också.

Snälla, bit rot är inte ett reellt problem för de flesta, det är inte farligt att lagra data på andra filsystem eller att använda hårdvaruraid. Jag och många andra gör det dagligen, i stora produktionsmiljöer med många TB data. ZFS fungerar säkert jättebra för dig, men du beter dig lite som kyrkan förr i tiden och försöker skrämma till dig anhängare. Sluta med det, du framstår bara som en fåne som inte har någon som helst aning om vad han pratar om.

Trädvy Permalänk
Avstängd
Plats
Sthlm
Registrerad
Nov 2008
Skrivet av bamsefar:

Snälla, bit rot är inte ett reellt problem för de flesta, det är inte farligt att lagra data på andra filsystem eller att använda hårdvaruraid. Jag och många andra gör det dagligen, i stora produktionsmiljöer med många TB data.

Bit rot är inte ett problem med lite data, när du har några TB data så får du inte så ofta bit rot. I snitt 4 sektorer på en 2TB disk har bit rot. Men när du har mycket data, så blir bit rot ett reellt problem.

T.ex. Amazon skriver att de ser data corruption precis hela tiden.
http://www.zdnet.com/blog/storage/data-corruption-at-massive-...
-Hardware, software and firmware all introduce errors. ". . . absolutely nobody and nothing can be trusted."
-More error detection is always better. Every time he's added more he's been ". . . amazed at the frequency the error correction code fired."
-Corruption is everywhere. In one case he found latent data corruption on customer disks that was so bad that customers thought the software was buggy while the real problem was on-disk.
-You absolutely need ECC on servers. And, he concludes ". . . ECC memory should be part of all client systems."
Another example. In this case, a fleet of tens of thousands of servers was instrumented to monitor how frequently the DRAM ECC was correcting. Over the course of several months, the result was somewhere between amazing and frightening. ECC is firing constantly.

Så visst, när du administrerar små servrar så får du garanterat bit rot. Men de sektorerna är få. Med mycket data så har du alltid bitrot och behöver checksummor på allt för att fånga bit rot. Det är bara att läsa på senaste forskningen och vad folk som driftar stora system säger, t.ex. CERN. CERN lagrar så mycket data att bitröta är ett seriöst problem för dem, och de går nu över till ZFS. IBMs nya superdator SEQUIOA som ska lagra 55 PetaByte data kör Lustre ovanpå ZFS numera, istället för ext3.

Citat:

ZFS fungerar säkert jättebra för dig, men du beter dig lite som kyrkan förr i tiden och försöker skrämma till dig anhängare. Sluta med det, du framstår bara som en fåne som inte har någon som helst aning om vad han pratar om.

Om du också skulle läsa på senaste forskningen och vad folk som lagrar MYCKET data berättar, så skulle du också ta dig en funderare. Du kanske borde googla runt lite på "data corruption"? Du kanske ändrar inställning på kuppen.

Har du någonsin märkt att ECC RAM i dina servrar rapporterar att de råkat ut för bitfel i RAM? Sånt händer hela tiden i RAM. Om du inte märkt det, så betyder det inte att du haft tur - det betyder bara att du inte förstått det. T.ex. en server som beter sig märkligt, ett program som kraschar, en fil som blir korrupt etc - mycket sånt kan elimineras om man skyddar sig mot bitröta. MS samlar data efter Windows krascher, och upptäckte att 30% av alla Windows krascher beror på bitfel i RAM - så man skulle kunna få mycket färre Windows krascher om man har ECC RAM.

Framförallt, hårdvaruraid är notoriskt opålitiliga när det gäller data corruption och bör undvikas om man tycker att ens data är viktiga.

Om ens data är viktiga, så SKA man använda ECC RAM, och ett filsystem som gör MD5 checksummor på precis allting, vid varje läsning. ZFS gör detta (SHA256 checksummor). Om man tror att ECC RAM inte är viktigt, eller att MD5 checksummor inte är viktigt, så borde man läsa på lite. Börja med att läsa på om Big Data och Data corruption. Och framförallt, undvik hårdvaruraid.

Trädvy Permalänk
Medlem
Plats
::1
Registrerad
Okt 2001
Skrivet av saddam:

Bit rot är inte ett problem med lite data, när du har några TB data så får du inte så ofta bit rot. I snitt 4 sektorer på en 2TB disk har bit rot. Men när du har mycket data, så blir bit rot ett reellt problem.

T.ex. Amazon skriver att de ser data corruption precis hela tiden.
http://www.zdnet.com/blog/storage/data-corruption-at-massive-...
-Hardware, software and firmware all introduce errors. ". . . absolutely nobody and nothing can be trusted."
-More error detection is always better. Every time he's added more he's been ". . . amazed at the frequency the error correction code fired."
-Corruption is everywhere. In one case he found latent data corruption on customer disks that was so bad that customers thought the software was buggy while the real problem was on-disk.
-You absolutely need ECC on servers. And, he concludes ". . . ECC memory should be part of all client systems."
Another example. In this case, a fleet of tens of thousands of servers was instrumented to monitor how frequently the DRAM ECC was correcting. Over the course of several months, the result was somewhere between amazing and frightening. ECC is firing constantly.

Så visst, när du administrerar små servrar så får du garanterat bit rot. Men de sektorerna är få. Med mycket data så har du alltid bitrot och behöver checksummor på allt för att fånga bit rot. Det är bara att läsa på senaste forskningen och vad folk som driftar stora system säger, t.ex. CERN. CERN lagrar så mycket data att bitröta är ett seriöst problem för dem, och de går nu över till ZFS. IBMs nya superdator SEQUIOA som ska lagra 55 PetaByte data kör Lustre ovanpå ZFS numera, istället för ext3.

Om du också skulle läsa på senaste forskningen och vad folk som lagrar MYCKET data berättar, så skulle du också ta dig en funderare. Du kanske borde googla runt lite på "data corruption"? Du kanske ändrar inställning på kuppen.

Har du någonsin märkt att ECC RAM i dina servrar rapporterar att de råkat ut för bitfel i RAM? Sånt händer hela tiden i RAM. Om du inte märkt det, så betyder det inte att du haft tur - det betyder bara att du inte förstått det. T.ex. en server som beter sig märkligt, ett program som kraschar, en fil som blir korrupt etc - mycket sånt kan elimineras om man skyddar sig mot bitröta. MS samlar data efter Windows krascher, och upptäckte att 30% av alla Windows krascher beror på bitfel i RAM - så man skulle kunna få mycket färre Windows krascher om man har ECC RAM.

Framförallt, hårdvaruraid är notoriskt opålitiliga när det gäller data corruption och bör undvikas om man tycker att ens data är viktiga.

Om ens data är viktiga, så SKA man använda ECC RAM, och ett filsystem som gör MD5 checksummor på precis allting, vid varje läsning. ZFS gör detta (SHA256 checksummor). Om man tror att ECC RAM inte är viktigt, eller att MD5 checksummor inte är viktigt, så borde man läsa på lite. Börja med att läsa på om Big Data och Data corruption. Och framförallt, undvik hårdvaruraid.

Att ta upp ECC-minnen i diskussionen är ju bara fånigt, det är ett faktum att bitfel i minnet händer och att det händer ofta. Vad du däremot inte lyckas precisera är hur vanligt det är med bitröta på lagringssystem som inte är Amazon, CERN eller liknande. Hur är detta relevant i samanhanget?

På vilket sätt är hårdvaruraid notoriskt opålitliga när det gäller datakorruption, och varför bör de undvikas om man tycker att ens data är viktiga?

Trädvy Permalänk
Medlem
Plats
Borås
Registrerad
Okt 2002

Om man nu använder sig av ECC-minnen - kan man då se hur ofta de gör felkorrigeringar på något enkelt sätt? Lite offtopic kanske men min filserver som kör ZFS rapporterar 0 checksummefel trots avsaknaden av ECC, vilket känns helt osannolikt med tanke på att bitfel sker väldigt ofta enligt vad ni nyss har skrivit i tråden. Bitfel sker troligtvis inte särskilt sannolikt utan att checksumman borde detektera det när man kör en scrub.

Javisst kan det vara så att felen redan skett innan filen sparas ner på disk men då gäller det väl att alla datorer i nätverket som använder filservern också köra ECC och ZFS, annars är ju den felfria kedjan ändå förstörd? Visst jag kör ZFS för att snabbt detektera fel i lagringsystemet men ibland känns det som att det hela går lite till överdrift med att man måste ha ECC-minnen. Men jag har säkert fel som vanligt...

Men man kanske kan använda ECC ungefär som ZFS, att man får upp varningar när minnena börjar gå sönder? För oftast är de väl ändå hela antar jag.

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Jan 2003

Den grundläggande frågan avseende bitröta är väl vilka konsekvenser det får i praktiken för hemanvändare. Bitfelet kan drabba olika. De flesta hemanvändare med hyfsat stora multimedialager torde inte märka ett bitfel i sina filer då multimediaspelaren är "förlåtande".

Får du bitfel i en .exe eller annan vital komponent för OS lär du säkerligen märka detta med BSOD eller appkrasch. Finns statistik som visar hur många av dessa som beror på bitröta?

Det allra största datasäkerhetsproblemet för hemanvändare är inte bitfel utan avsaknaden av backup. Även vissa zfs/raidz gurus kör (o)säkert utan backup. Titanicsyndrom, man litar blint på tekniken och glömmer att det sitter en Homo Sapiens vid spakarna.

En annan analogi kan göras till humlan som flyger ändå trots att ingen ingenjörer fram till för nåt år sedan begrep hur/varför.

I kommersiella system, typ banker, har man säkert teknik för antibitröta i sina centrala datalager, men hur många klienter kör PC med ECC ute i organisationen. Inga bland de jag jobbat hos. Där tycks man acceptera bitröta, en siffra inmatad i klienten blir en annan i datalagret och vips har kunden vunnit/tappat nån mille. Nu har man säkert rutiner för uppföljning och rimlighetsbedömning vid datavalidering men bitröta tycks inte vara i fokus.

Trädvy Permalänk
Medlem
Plats
Borås
Registrerad
Okt 2002
Skrivet av jookeer:

Den grundläggande frågan avseende bitröta är väl vilka konsekvenser det får i praktiken för hemanvändare. Bitfelet kan drabba olika. De flesta hemanvändare med hyfsat stora multimedialager torde inte märka ett bitfel i sina filer då multimediaspelaren är "förlåtande".

Får du bitfel i en .exe eller annan vital komponent för OS lär du säkerligen märka detta med BSOD eller appkrasch. Finns statistik som visar hur många av dessa som beror på bitröta?

Det allra största datasäkerhetsproblemet för hemanvändare är inte bitfel utan avsaknaden av backup. Även vissa zfs/raidz gurus kör (o)säkert utan backup. Titanicsyndrom, man litar blint på tekniken och glömmer att det sitter en Homo Sapiens vid spakarna.

En annan analogi kan göras till humlan som flyger ändå trots att ingen ingenjörer fram till för nåt år sedan begrep hur/varför.

I kommersiella system, typ banker, har man säkert teknik för antibitröta i sina centrala datalager, men hur många klienter kör PC med ECC ute i organisationen. Inga bland de jag jobbat hos. Där tycks man acceptera bitröta, en siffra inmatad i klienten blir en annan i datalagret och vips har kunden vunnit/tappat nån mille. Nu har man säkert rutiner för uppföljning och rimlighetsbedömning vid datavalidering men bitröta tycks inte vara i fokus.

Ja backup är helt klart viktigare. Och nej, jag har inte backup på allting - anser att inte världen går under om jag slarvar bort några filmer jag spelat in från TV. Anser heller inte att världen går under om systemdisken kraschar, inte ens på servern. Däremot försöker jag att backupa mina viktiga filer. Kanske också därför jag inte ser så allvarligt på ECC och ZFS ser jag mer som ett verktyg än att varenda liten bit ska förbli rätt. Förhoppningsvis är filen OK på backupen om den skulle blivit korrupt på diskarna. Men nu är jag i serverforumet och inte i lagringsforumet så andra här har säkert större behov av driftsäkerhet än jag.

Men precis som du skriver - serverfolket kan vara jättenoga men klientmaskinerna kan fortfarande göra filerna korrupta. Förhoppningsvis har serverkillarna gjort backup/snapshots på filerna innan klienterna sabbar dem totalt så det finns väl möjlighet att backa bakåt och återställa en version som verkar rimligt OK. Men då filerna ofta skapas av klienterna från början kan ju originalen i princip vara hur korrupta som helst utan att det upptäcks av ECC och ZFS.

Edit: Jag tror det är ganska vanligt att krånglande minnen orsakar kraschande datorer med trasiga filer. Förhoppningsvis märker man det när man sitter vid sin dator...

EDIT: http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf

Citat:

About a third of machines and over 8% of DIMMs in
our fleet saw at least one correctable error per year.

Så man kan räkna med minnesfel varannat/vart tredje år ungefär som kan korrigeras av ECC?
Två tredjedelar av maskinerna och 92% av alla DIMM har inga korrigerbara fel alls per år. Låter inte som ECC gör nytta särskilt ofta tycker jag.

Trädvy Permalänk
Medlem
Plats
127.0.0.1
Registrerad
Jun 2004

Jag kan bara instämma med Bamsefar om att bitröta itne är ett reellt problem i en seriös företagsmiljö.
Men bara för skojs skull så tog jag en titt i en kundmiljö.

Miljön i fråga har runt 500 installationservrar. Med förändringar så blir det ca 800 paket per server och år.
om vi utgår från en snittstorlek på 100Mb så rör det sig alltså om 40TB data per år.
När ett paket skapas så får det en checksumma. Den används sen för att garantera att paketet blir rätt repliikerat till installationsservrarna. Där ligger paketen sen på en vanlig Raid-5. Vid installation på en klient så kopierar klienten sitt paket från servern till sin lokala disk och verifierar sen checksumman som skapades när paketet skapades. Är det samma checksumma så är ju paketet ok. Är det fel så loggas detta och systemet frågar näst närmaste instalaltionsserver efter paket osv tills den i värsta fall når den centrala servern eller ger upp.

Skulle bitröta vara ett reellt problem så skulle jag alltså få in loggar/larm på att paket är korrupta.
Under 2012 har det inte inträffat en enda gång.

Däremot har vi flera tusen begärans på att återläsa filer från backuperna där användarna har raderat sina egna filer av misstag.

Arbetsdator: HFX Mini. Core-i5 2405S, Radeon 6570, Asus P8P67-M . Skärm: Dell 2407
HTPC: HFX Classic, E8500, Radeon 3450, P5K/EPU, Floppydtv-s2
Hyper-V Server: E6750 8GB minne 2X3TB Raid1 samt 2X1TB raid 1

Trädvy Permalänk
Avstängd
Plats
Sthlm
Registrerad
Nov 2008
Skrivet av bamsefar:

Att ta upp ECC-minnen i diskussionen är ju bara fånigt, det är ett faktum att bitfel i minnet händer och att det händer ofta. Vad du däremot inte lyckas precisera är hur vanligt det är med bitröta på lagringssystem som inte är Amazon, CERN eller liknande. Hur är detta relevant i samanhanget?

Man ser bitröta lättast på stora datamängder. Skälet till det är att diskar har genom decennierna blivit snabbare och större, men de har inte blivit säkrare.

En typisk högkvalitets server Enterprise SAS säger i sina spec sheet från tillverkaren att för varje 10^16 bitar man läser, så får man i snitt ett fel som diskens felkorrigeringskoder inte kan korrigera:
http://www.komplett.se/k/ki.aspx?sku=759326#extra
"Oåterkalleligt fel 1 per 10^16"

Men ett fel per 10^16 bitar är inte så farligt, om det vore så väl. Problemet är att det finns massa andra felkällor än disken själv. T.ex. höga ljud stör disken, det räcker att du skriker högt bredvid disken så skakar den till och får problem att läsa/skriva:
http://www.youtube.com/watch?v=tDacjrSCeq4

Kosmisk strålning, solutbrott är ett STORT problem. Faktum är att Intel ville bygga in detektorer i cpun och när det blir kosmisk strålning så ska cpun spela om alla uträkningar, etc.

Poängen är att alla felkällor ger massa datakorruption, mycket mer än 1 per 10^16. T.ex. NetApp som gör stora lagringsservrar för många miljoner kr, har gjort en undersökning i praktiken. Bland 1.5 miljoner hårddiskar från kunder så:
http://en.wikipedia.org/wiki/ZFS#Data_Integrity
"A real life study of 1.5 million HDDs in the NetApp database found that on average 1 in 90 SATA drives will have silent corruption which is not caught by hardware RAID verification process; for a RAID-5 system that works out to one undetected error for every 67 TB of data read.[27]"

En annan källa säger att på varje 2TB disk så finns i snitt fyra sektorer med datakorruption, men denna har jag inga källor för, så denna uppgift är inte tillförlitlig.

Sammanfattning; det är liten chans att få datakorruption, typ som att vinna på lotto. Men om du köper tillräckligt många biljetter så kommer du garanterat vinna. Och om du har enorma mängder data, så kommer du se datakorruption hela tiden. Vilket CERN och Amazon och NetApp rapporterar - de har alla stora mängder data. Det är bara att läsa länkarna om du tror att jag hittar på.

Om du har några små servrar med kanske 10TB data så är risken för datakorruption liten. Om du köper 10,000 lottobiljetter så är chansen liten att du vinner. Men om du köper 1000.000.000.000 stycken lotter, så kommer du vinna flera gånger.

Citat:

På vilket sätt är hårdvaruraid notoriskt opålitliga när det gäller datakorruption, och varför bör de undvikas om man tycker att ens data är viktiga?

Därför att hårdvaruraid inte är designade att fånga upp datakorruption. De gör parity beräkningar, dvs XOR beräkningar för att man splittat data mellan olika diskar och ska sammanställa alla data igen. Men de gör inte checksummeberäkningar i syfte att fånga datakorruption. Du bör göra en typ MD5 checksumma på allt du läser och skriver hela tiden - då är du säker. Hårdvaruraid gör inte det. Sen finns det andra problem med hårdvaruraid som du säkert känner till, t.ex write-hole error som alla hårdvaruraid lider av (ZFS är immun mot detta problem).
http://en.wikipedia.org/wiki/RAID#Problems_with_RAID

Men ZFS gör checksummeberäkningar, det gör SHA256 checksummor på allt, precis hela tiden. Därför kräver ZFS mer cpukraft än vanliga filsystem, som aldrig gör MD5 checksummor. Att göra MD5 checksummor tar ju massa tid, och då blir allt långsammare. Tänk själv, om du gjorde MD5 på precis alla filer hela tiden, skulle det inte gå långsamt då? Då uppnår man iofs stor säkerhet, men tappar prestanda. Vad är viktigast? Att det går snabbt och lite datakorruption då och då, eller långsamt och säkrade data?

Sen finns det även forskning som visar att ZFS är säkert, medan NTFS är inte säkert. Forskaren pratar om NTFS, ext3, XFS, JFS, etc:
http://www.zdnet.com/blog/storage/how-microsoft-puts-your-dat...

Så om du hanterar mycket viktiga företagsdata, så bör du köra MD5 checksummor på precis alla filer, en gång om dagen i alla fall. Och sen bör du jämföra alla checksummor för att se om de har ändrats. Så du måste spara alla checksummorna i en fil och uppdatera filen hela tiden när något ändrats. Och om en fil korruptas, så måste du ersätta med en frisk kopia. Eller så använder du ZFS, som gör allt detta helt automatiskt åt dig.

Microsoft gjorde en studie, de samlar ju alla kraschdata från Windows. MS kom fram till att 20-30% av alla krascher berodde på bitröta i RAM. Mao, om man hade ECC RAM så skulle man sluppit 20-30% av alla krascher. Det är väldigt ofta, detta.

Skrivet av ronnylov:

Om man nu använder sig av ECC-minnen - kan man då se hur ofta de gör felkorrigeringar på något enkelt sätt? Lite offtopic kanske men min filserver som kör ZFS rapporterar 0 checksummefel trots avsaknaden av ECC, vilket känns helt osannolikt med tanke på att bitfel sker väldigt ofta enligt vad ni nyss har skrivit i tråden. Bitfel sker troligtvis inte särskilt sannolikt utan att checksumman borde detektera det när man kör en scrub.

Javisst kan det vara så att felen redan skett innan filen sparas ner på disk men då gäller det väl att alla datorer i nätverket som använder filservern också köra ECC och ZFS, annars är ju den felfria kedjan ändå förstörd?

Bra hjärna du har! Det är exakt det som forskarna kom fram till när de undersökte olika filsystem. De injicerade olika artificiella fel i olika filsystem och såg hur väl filsystemen hanterade problemen: inte alls. Men ZFS ensamt klarade av att hantera alla problemen:
http://research.cs.wisc.edu/wind/Publications/zfs-corruption-...

Dock, kom fram forskarna fram till att om de injicerade fel i RAM så klarade inte ZFS av att märka felen längre. ZFS sparar ned korrekt på disk, vad den får. Om den får skit (pga fel i RAM) så sparar den skit. Visst blir skiten korrekt sparad (vilket man inte kan säga om andra filsystemen som flippar bitar randomly och datakorruption) men för att det ska vara någon poäng med ZFS, så rekommenderade forskarna att man ska köra ECC RAM och ZFS. Precis din slutsats, utan att lägga ned månader av forskning.

Skrivet av mats42:

Jag kan bara instämma med Bamsefar om att bitröta itne är ett reellt problem i en seriös företagsmiljö.
Men bara för skojs skull så tog jag en titt i en kundmiljö.

Miljön i fråga har runt 500 installationservrar. Med förändringar så blir det ca 800 paket per server och år.
om vi utgår från en snittstorlek på 100Mb så rör det sig alltså om 40TB data per år.
När ett paket skapas så får det en checksumma. Den används sen för att garantera att paketet blir rätt repliikerat till installationsservrarna. Där ligger paketen sen på en vanlig Raid-5. Vid installation på en klient så kopierar klienten sitt paket från servern till sin lokala disk och verifierar sen checksumman som skapades när paketet skapades. Är det samma checksumma så är ju paketet ok. Är det fel så loggas detta och systemet frågar näst närmaste instalaltionsserver efter paket osv tills den i värsta fall når den centrala servern eller ger upp.

Skulle bitröta vara ett reellt problem så skulle jag alltså få in loggar/larm på att paket är korrupta.
Under 2012 har det inte inträffat en enda gång.

Jag håller inte med ditt resonemang.

Antag att du har ETT enda paket, en Windows uppgradering på 100MB som ska skickas ut till alla datorer på företaget. Nu säger du att eftersom den skickas ut så många gånger, så blir det totalt 40TB data som skickas ut. Och om du kör checksummor på 40TB data så borde du se ett fel, men det ser du inte. Alltså är inte bitröta på diskar ett problem! Eller?

Men jag håller inte med om detta resonemang. Därför att:
Du har ett enda paket, som tar upp 100MB. Det ligger på disken. Hur stor är risken att du får bitröta på just dessa 100MB? Mycket liten. Sen skickas detta paket ut till alla servrar som sparar ned filen på disk och direkt installerar och sen kastas paketet. Hur stor är risken att du får bitröta på servrarna under den korta tiden? Mycket liten. Hur stor är risken att du får bitröta på just era paket? Mycket liten. Hur många paket har ni? 800st, och varje tar 100MB, så det blir totalt 80 GB data. Det är inte mycket data det. Det är inte ens en tiondels TB.

Återigen, om man har lite data så är inte risken så stor för bitröta. Men när man lagrar STORA mängder data, så är bitröta och annan datakorruption ett mycket stort problem.

Men det är helt korrekt att göra checksummor på paketen som ni gör. Helst bör man ju göra checksummor på ALLA filer. Ha ett program som ligger och kör MD5 checksummor i bakgrunden hela tiden (som t.ex. ZFS gör).

Trädvy Permalänk
Avstängd
Plats
Sthlm
Registrerad
Nov 2008
Skrivet av Fnorken:

Valfri NAS och skicka över den viktigaste datan till en polare eller någon molntjänst. Kryptera datan som lämnar din kontroll om du känner att det behövs.

Och glöm inte att göra MD5 checksummor på originalfilen och kopian i molnet. Ibland när jag laddar ned ISO filer så funkar inte den, så får jag ladda ned ISO filen igen. Dvs, data korruption. Nånstans.

MD5 checksummor är viktiga om man är noga med sina data.

Trädvy Permalänk
Medlem
Plats
Göteborg
Registrerad
Dec 2008
Skrivet av saddam:

MD5 checksummor är viktiga om man är noga med sina data.

Nej, använd en algoritm som fungerar istället. MD5 är dokumenterat trasig sedan åtminstone 2005. Är man riktigt paranoid eller extremt trygghetsberoende skulle man antagligen hävda att MD5 blev persona-non-grata från 1996.

Trädvy Permalänk
Medlem
Plats
127.0.0.1
Registrerad
Jun 2004
Skrivet av saddam:

Jag håller inte med ditt resonemang.

Antag att du har ETT enda paket, en Windows uppgradering på 100MB som ska skickas ut till alla datorer på företaget. Nu säger du att eftersom den skickas ut så många gånger, så blir det totalt 40TB data som skickas ut. Och om du kör checksummor på 40TB data så borde du se ett fel, men det ser du inte. Alltså är inte bitröta på diskar ett problem! Eller?

Men jag håller inte med om detta resonemang. Därför att:
Du har ett enda paket, som tar upp 100MB. Det ligger på disken. Hur stor är risken att du får bitröta på just dessa 100MB? Mycket liten. Sen skickas detta paket ut till alla servrar som sparar ned filen på disk och direkt installerar och sen kastas paketet. Hur stor är risken att du får bitröta på servrarna under den korta tiden? Mycket liten. Hur stor är risken att du får bitröta på just era paket? Mycket liten. Hur många paket har ni? 800st, och varje tar 100MB, så det blir totalt 80 GB data. Det är inte mycket data det. Det är inte ens en tiondels TB.

Återigen, om man har lite data så är inte risken så stor för bitröta. Men när man lagrar STORA mängder data, så är bitröta och annan datakorruption ett mycket stort problem.

Men det är helt korrekt att göra checksummor på paketen som ni gör. Helst bör man ju göra checksummor på ALLA filer. Ha ett program som ligger och kör MD5 checksummor i bakgrunden hela tiden (som t.ex. ZFS gör).

Nja nu har du missuppfattat ganska ordentligt här alltså.

Första felet var mitt. 100 MB är för lite. 200-250 är nog mer rätt om jag tittar på diskförbrukningen istället för att gissa.
andra felet är att det inte rör sig om 800 paket totalt utan miljön växer med 800 paket per år.
tredje felet är att du totalt har missförstått vad installationsservrarna gör. De installerar ingenting utan de är paketlager. Paket skickas ut till installationsservrarna och sen ligger de på installationserverns disk tills det att det paketet avvecklas vilket brukar vara 5-10 år bort.
Med andra ord så lagras det 160-200GB nytt data per installtionsserver gånger 500 burk vilket ger en 80-100TB/år i utökning av datalagret

När en dator ska installera något så får den order om det och sen ropar den på närmaste installtionserver för att kopiera paketet från installationserven. Klienten sparar sen paketet i sin cache och installerar därifrån. Faktum är att inte ens klienten kastar paketet direkt utan det sker först när det blir fullt i cachen. Fram tills det ligger det kvar ifall man vill förändra/avinstallera (spar bandbrdd om man slipper tanka om)

Chansen för fel är ju linjär mot mängden lagrad data och därmed spelar det ingen roll om man har många servrar med lite data eller en enda med massor utan det är lagrad mängd som ska ge utslag och är risken för fel lika med noll på ca 200 TB så räcker det för mig. (2011 och 2012:s paketmängd).

Arbetsdator: HFX Mini. Core-i5 2405S, Radeon 6570, Asus P8P67-M . Skärm: Dell 2407
HTPC: HFX Classic, E8500, Radeon 3450, P5K/EPU, Floppydtv-s2
Hyper-V Server: E6750 8GB minne 2X3TB Raid1 samt 2X1TB raid 1

Trädvy Permalänk
Medlem
Plats
127.0.0.1
Registrerad
Jun 2004
Skrivet av saddam:

Och glöm inte att göra MD5 checksummor på originalfilen och kopian i molnet. Ibland när jag laddar ned ISO filer så funkar inte den, så får jag ladda ned ISO filen igen. Dvs, data korruption. Nånstans.

MD5 checksummor är viktiga om man är noga med sina data.

Oftast nån korkad wanaccelerator någonstans som är i farten.
Enterprise klassade replikeringsssytem har det som standard just pga att man inte kan lita på internettrafik. (inte interna wan helelr för den delen)

Arbetsdator: HFX Mini. Core-i5 2405S, Radeon 6570, Asus P8P67-M . Skärm: Dell 2407
HTPC: HFX Classic, E8500, Radeon 3450, P5K/EPU, Floppydtv-s2
Hyper-V Server: E6750 8GB minne 2X3TB Raid1 samt 2X1TB raid 1

Trädvy Permalänk
Avstängd
Plats
Sthlm
Registrerad
Nov 2008
Skrivet av Fnorken:

Nej, använd en algoritm som fungerar istället. MD5 är dokumenterat trasig sedan åtminstone 2005. Är man riktigt paranoid eller extremt trygghetsberoende skulle man antagligen hävda att MD5 blev persona-non-grata från 1996.

Ok tack för informationen! Vet du om SHA256 oxå har brister? ZFS har ju flera olika checksummealgoritmer förutom SHA256, men SHA256 är ju bäst av dem. Själv kör jag inte SHA256 checksummealgoritmen på min ZFS burk, eftersom jag inte ens har ECC RAM. Men när jag skaffar supermicro moderkort + Xeon + ECC + ZFS så får jag en mycket säker lösning. Då ska jag även slå på SHA256.

Skrivet av mats42:

Nja nu har du missuppfattat ganska ordentligt här alltså.

Första felet var mitt. 100 MB är för lite. 200-250 är nog mer rätt om jag tittar på diskförbrukningen istället för att gissa.
andra felet är att det inte rör sig om 800 paket totalt utan miljön växer med 800 paket per år.
tredje felet är att du totalt har missförstått vad installationsservrarna gör. De installerar ingenting utan de är paketlager. Paket skickas ut till installationsservrarna och sen ligger de på installationserverns disk tills det att det paketet avvecklas vilket brukar vara 5-10 år bort.
Med andra ord så lagras det 160-200GB nytt data per installtionsserver gånger 500 burk vilket ger en 80-100TB/år i utökning av datalagret

När en dator ska installera något så får den order om det och sen ropar den på närmaste installtionserver för att kopiera paketet från installationserven. Klienten sparar sen paketet i sin cache och installerar därifrån. Faktum är att inte ens klienten kastar paketet direkt utan det sker först när det blir fullt i cachen. Fram tills det ligger det kvar ifall man vill förändra/avinstallera (spar bandbrdd om man slipper tanka om)

Chansen för fel är ju linjär mot mängden lagrad data och därmed spelar det ingen roll om man har många servrar med lite data eller en enda med massor utan det är lagrad mängd som ska ge utslag och är risken för fel lika med noll på ca 200 TB så räcker det för mig. (2011 och 2012:s paketmängd).

Ok, då förstår jag. Det är ju bra att ni inte detekterat checksummefel på era paket diskarna nån gång.

En fråga, har ni någonsin detekterat ECC checksummefel? Som bl.a. Googles stora undersökning visar så fick de ECC checksummefel ganska ofta bland alla sina 100.000 tals servrar. Ni borde fått ECC checksummefel nån gång, och om ni inte nånsin sett ECC fel, så har ni haft tur, eller så har ni gjort fel nånstans. Om ni aldrig sett ECC fel, så kanske ni heller aldrig sett disk checksummefel heller. De kanske hänger ihop på nåt sätt?

Poängen är i alla fall att vi pratar ren statistik och sannolikheter. Bara för att ni inte sett några checksummefel så betyder det inte att ni är immuna. Eller så har ni haft tur. Eller så betyder det att ni vet exakt vad ni gör hur man för att motverka datakorruption. Vi kan i alla fall konstatera att ECC fel inträffar ofta, men diskar har massa rörliga delar och är långt känsligare så rimligtvis borde det inträffa datakorruption även på diskar. Brukar det stå i RAM spec sheet "1 fel per.... X lästa bitar"? Nej det gör det väl inte? Men det gör det i diskar, även hos mycket dyra high end Fibre Channel diskar, så det blir alltså mer fel bland diskar, än bland RAM. Och bland RAM blir det ofta fel, så då kanske det blir ännu mer fel bland diskar.

Vi pratar statistik och man kan inte uttala sig med visshet. Jag känner många personer, men har aldrig träffat någon som vunnit stort på lotto. Det betyder ingenting, inga slutsatser kan dras från det.

Poängen är att datakorruption bland diskar är ett reellt problem. Och folk får själva bedöma hur viktigt de tycker detta är. De som lagrar stora mängder data, ser datakorruption hela tiden. Detta är konstaterade fakta, det är bara att läsa länkarna från Amazon, CERN, NetApp, etc. Nu vet ni i alla fall om att problemet med datakorruption existerar, och det är upp till er hur ni vill hantera det. Ni kan köra utan ECC RAMkretsar på era servrar om ni vill, men det rekommenderas inte. Men ni kanske har tur och slipper ECC fel? Men även om ni inte får ECC fel, så är det väl onödigt att fresta på turen, och istället alltid köra ECC på era servrar. Vilket jag förutsätter att ni gör, för ni kör väl ECC på era servrar?

På samma sätt, om 10 år, så gissar jag att det rekommenderas att man bör köra lagringslösningar där det görs checksummor på precis allt, hela tiden. ECC RAM var inte ett stort problem förrut, men idag känner folk till det och fler och fler kör ECC, även hemanvändare. Är det dåligt att göra checksummor på allt, hela tiden? Bör man rekommendera emot såna lösningar?

Mer läsning och forskningsartiklar om datakorruption finns här, för den som är intresserad av ämnet:
http://en.wikipedia.org/wiki/Data_corruption
http://en.wikipedia.org/wiki/Soft_error
http://en.wikipedia.org/wiki/Cosmic_ray#Effect_on_electronics
http://en.wikipedia.org/wiki/ZFS#Data_Integrity

Trädvy Permalänk
Medlem
Plats
127.0.0.1
Registrerad
Jun 2004

Servrarna har ECC och nej, det är inte särksillt ofta de skriker heller men visst har det inträffat. Behöver ECC jobba så blir det en varning av det i övervakningen.
Blir det tillrcäkligt många varningar så flaggas det minnet som trasigt och servern stänger av det automatiskt samtidigt som den larmar om garantiutbyte direkt till leverantören (övervakningssystemet mailar en felanmälan).

Jag vet inte men rygraden säger att det var mer minnesstrul på sent 90 tal/tidigt 2000 tal än vad det är idag.
Som kuriosa kan jag nämna att man tom har raid5 på minnesbussarna på vissa servrar. Är ju ingen ide att ha ECC på cippet när man inte har skydd när datat går över moderkortet.

Arbetsdator: HFX Mini. Core-i5 2405S, Radeon 6570, Asus P8P67-M . Skärm: Dell 2407
HTPC: HFX Classic, E8500, Radeon 3450, P5K/EPU, Floppydtv-s2
Hyper-V Server: E6750 8GB minne 2X3TB Raid1 samt 2X1TB raid 1

Trädvy Permalänk
Medlem
Plats
Borås
Registrerad
Okt 2002

ECC på RAM-minnet är förstås ingen nackdel, men hur är det med det inbyggda cacheminnet i processorn, har det också ECC? Finns det checksummealgoritmer inuti processorn som kontrollerar att den har räknat allting rätt, eller ska man sköta detta i operativsystemet/applikationen och alltid beräkna samma sak två gånger och göra checksummekontroll att man får samma svar? Kan tänka mig det finns kritiska applikationer som gör så, typ styrsystem för kärnkraftverk och liknande. Fast är det samma fel i processorn så får man väl samma felaktiga svar så man kanske ska ha två parallella datorer, helst från olika tillverkare (typ en AMD-baserad och en annan intel-baserad) och låta dem lösa uppgiften var för sig, och helst också använda olika alternativa men likvärdiga algoritmer/metoder för att verifiera att man fått rätt svar.

Ja det här med datasäkerhet är intressant. Men man får lägga sig på en rimlig nivå. Min hemmaserver styr inget kärnkraftverk så den är det inte så noga med men det är klart finns det enkla saker man kan använda utan att det kostar massa besvär och pengar så använder man väl det. Jag kör ZFS (det var gratis) men inte ECC-minne eftersom det hade krävt nytt moderkort och nytt minne i inköp. Inte jättedyrt i och för sig men det får väl bli nästa gång jag uppgraderar.

All data man läser och skriver till disk passerar genom processor och RAM-minne så om någon av dessa krånglar så kan förstås filerna bli korrupta. En annan grej som nämnts är nätverkskommunikation,särskilt över internet. Hemma kör jag NFS mot servern på linuxmaskinerna och samba till servern på windowsmaskinerna (ja samba på linuxservern då, det heter väl CIFS eller något på klientsidan). Jag vet inte men misstänker att det inte är särskilt mycket checksummor i dessa protokollen? Men själva TCP/IP protokollet då, har det checksummor? Uppenbarligen inte tillräckligt mycket eftersom det ibland blir fel på vägen, särskilt om man laddar ner en fil via http från någon webbserver. Kanske webbservern i sig inte har ECC eller så passerar det någon annan server på vägen som ställer till det såvida det inte rentav är kosmisk strålning... Men däremot så verkar det sällan vara några problem med att ladda ner iso-filer via bittorrent (ofta finns det som alterntiv när någon ny version av favoritlinux-disten släpps). Antagligen är det inbyggt checksummor i bittorrent-protokollet och därför uppstår det inga problem med filerna när de väl verifierats som OK.

Jag kör backuper över internet via rsnapshot som använder ssh vid överföringen. Känns som att ssh-protokollet är ganska robust för det är sällan några problem med dessa överföringarna. Kanske är det bättre at köra sshfs på hemnätverket också om man är rädd för bitröta i nätverksöverföringarna. Eller vad anses som säkra (eller snarare robusta) nätverksprotokoll? Visst är ssh säkert med tanke på kryptering och sådant och kanske är checksummor nödvändigt för att kryptering överhuvudtaget ska fungera?

Annars tycker jag det är lurigt när mn installerar något från CD eller DVD. Visst kan man ofta verifiera checksumman på sin installationsskiva för linuxdisten man använder men sedan då när det förs över till hårddisken, kan det inte bli fel på vägen där? Ofta kör jag nätverksinstallation, alltså att huvudsakligen körs installationen av paketen via internet och detta cerka funka bra i praktiken Jag gissar att det ingår någon typ av verifiering av paketen innan de installeras. Men häromdagen lade jag in Windows 7 på yngsa dotterns dator. Kändes ganska skakigt med krånglande CD-läsare och så småningom kom det väl in, men den datorn har ju varken ECC eller ZFS så det blir nog sjukt korrupt allting hon gör (om vi ska överdriva lite). Fast hon bryr sig inte så länge hon kan spela sina barnspel utan att det hänger sig.

Vad mer kan gå fel på vägen? Ja största felet är nog vi människor. Någon öppnar ett textdokument och råkar ta bort eller skriva något på fel ställe. Man skulle ha några redundanta kopior på sig själv och om någon av oss dör så är det bara att skapa en ny klon... Men problemet är väl att en kopia av mig själv gör nog samma fel. Jag borde ersätta mig själv med likvärdiga alternativa människor som kan producera samma filer men med någon alternativ metod, de kanske kan köra MacOSX och Windows så kör jag linux...

I slutändan så är det väl jag själv som råkar trycka på delete och raderar hela lagringsservern av mistag trots all redundans och checksummor... Med min vanliga tur så brinner väl backupen upp samtidigt.

Ja en liten utvikning, kanske inte helt relevant till tråden men ändå tänkvärt tycker jag.

Trädvy Permalänk
Medlem
Plats
127.0.0.1
Registrerad
Jun 2004

Ack så tänkvärt och ack så rätt på många punkter.

Ytterligare är en felkälla om många bommar är diskcontrollern.
Skriver den data fel till disk är du rätt körd oavsett vad du gör i övrigt ....

Därför är och förblir en ordentlig backup det viktigaste steget i allt vad datasäkerhet heter.
Sen gäller det "bara" att se till att backupen är katastrofsäkrad och att den går att lägga tillbaka.

Många är de som har tagit backup i åratal för att efter att de behövde backupen upptäcka att de inte tog backup på det de behövde. Alternativt att backupen inte gick att återläsa

Arbetsdator: HFX Mini. Core-i5 2405S, Radeon 6570, Asus P8P67-M . Skärm: Dell 2407
HTPC: HFX Classic, E8500, Radeon 3450, P5K/EPU, Floppydtv-s2
Hyper-V Server: E6750 8GB minne 2X3TB Raid1 samt 2X1TB raid 1

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Jan 2003

Att "ta" backup är väl det minsta man kan begära, den dag den behövs kan det visa sig att den inte funkar i alla delar, vilket jag varit med om även i kommersiella sammanhang där man "kan" sina backuprutiner som ett rinnande vatten men sällan/aldrig övar katastrofscenarier för att i tid upptäcka "dolda" brister. Förvaring av backupper kan vara bristfällig.

Vanligt inom tex. flygtrafikövervakning är klustrade system, allt som sker i ett system speglas till ett annat på en annan plats. Undrar om VAX/VMS fortfarande är den högst rankande plattformen för driftsäkerhet i dessa sammanhang? Troligen inte då DEC inte finns kvar å OpenVMS ej längre supportas. Skall finnas en am. myndighet som säkerhetsklassar? Vilken? Kanske där finns info för den paranoida?

Trädvy Permalänk
Avstängd
Plats
Sthlm
Registrerad
Nov 2008
Skrivet av mats42:

Jag vet inte men rygraden säger att det var mer minnesstrul på sent 90 tal/tidigt 2000 tal än vad det är idag.

Jag tror det är mer minnesstrul idag än förr. Idag är man nere på typ 22nm och det är väldigt tunt och känsligt. Förr körde man på 135nm och det är inte alls lika känsligt. Dessutom har vi 16B kapslar idag, och allt är tätt packat och gissningsvis, mer känsligt

Skrivet av ronnylov:

ECC på RAM-minnet är förstås ingen nackdel, men hur är det med det inbyggda cacheminnet i processorn, har det också ECC? Finns det checksummealgoritmer inuti processorn som kontrollerar att den har räknat allting rätt, eller ska man sköta detta i operativsystemet/applikationen och alltid beräkna samma sak två gånger och göra checksummekontroll att man får samma svar? Kan tänka mig det finns kritiska applikationer som gör så, typ styrsystem för kärnkraftverk och liknande. Fast är det samma fel i processorn så får man väl samma felaktiga svar så man kanske ska ha två parallella datorer, helst från olika tillverkare (typ en AMD-baserad och en annan intel-baserad) och låta dem lösa uppgiften var för sig, och helst också använda olika alternativa men likvärdiga algoritmer/metoder för att verifiera att man fått rätt svar.

Det här är ett STORT problem för seriösa datortillverkare. T.ex. IBMs stordatorer kan spela tillbacka instruktioner om det är fel nånstans. Detsamma med vissa SPARC cpuer. Det du pratar om, kallas RAS (reliability, avaliability and servicebility) typ, hög upptid. Och det är RAS som Enterprise företag vill åt och är eftertraktat, inte prestanda. Och det är RAS som kostar mycket pengar. När man tittar på en svindyr Unix server, så är det RAS man betalar för. Inte prestanda. Nu råkar en del av de servrrarna vara snabba också, t.ex. IBMs P595 unix server som användes för det gamla TPC-C rekordet kostade 35miljoner USD, listpris. Det blir typ en kvarts miljard. För en enda server.

Om vi istället tittar på IBMs stordatorer som är dyra på riktigt, och inte alls något billigt Unix skit, så har Stordatorerna mycket långsammare cpuer än en vanlig high end x86 cpu, även den senaste cpun på 5.3GHz med ~200MB cpu cache är långsammare än en vanlig high end x86 cpu. Men Mainframes har extremt god RAS, viktiga komponenter är dubblade och kanske även tripplade. Har för mig att t.ex. beräkningar utförs tre i taget av tre cpuer, och om nån visar fel så stängs cpun av, och ett larm går. Allt detta kostar multum att utveckla. Då blir prestanda lidande. Prestanda är sekundärt. Vad är viktigast, att det går snabbt och siffror blir fel (tänk bank) och krascher ibland, eller att allt är korrekt men lite långsammare? När du kommit upp till en viss nivå så räcker prestandan och du behöver inget snabbare.

Detsamma med ZFS: checksummor på allt som drar ned prestandan men allt blir säkrare - eller vinna benchmarks och korrupta data? Jag börjar faktiskt prioritera RAS mer och mer, än prestanda. Förrut, innan jag började jobba, så var prestanda viktigast. Numera är det RAS, nästan. Annars skulle jag skita i ZFS och bara köra nåt snabbt filsystem, som inte gör ordentliga fsck kontroller och fuskar rent allmänt, som linux hackern Ted Tso förklarade. Han skapade ext4, och sade att Linux folk ofta fuskar och stänger av felkontroller och sånt, bara för att vinna benchmarks. T.ex. ville Ted Tso slå på nån säkerhetsgrej "write barrier" eller nåt sånt i ext3, men Linux hackern Andrew Morton förbjöd det, eftersom "datakorruptionen som kunde bli följden var sällsynt och det var viktigare att vinna benchmarks"!!!! Man kanske förstår varför det finns sysadmins som vägrar jobba med Linux, eller Windows. Här är lite mer info om Linux fusk:
http://milek.blogspot.se/2010/12/linux-osync-and-write-barrie...

Trädvy Permalänk
Medlem
Plats
127.0.0.1
Registrerad
Jun 2004

Sen får du inte bita dig fast i frekvens för att mäta prestanda.

En gammal Z390 maskin kan fortfarande sopa bana med en hel datorhall av Splitternya Sun/oracle burkar.
Stordatorer är brutala på batchkörningar eftersom det är vad de är byggda för och på det området så finns det inget som kommer i närheten.

Finns X antal pinsamma misslyckanden där man har försökt byta stordatorer mot klustrade Unix/Linux miljöer för att sen väldigt snabbt få byta tillbaka igen.

Ett sådant fall jag själv var inblandad i lovade besparingar på miljonbelopp per år i drift om man migrerade från stordator till Unix miljö. Först fick de nästan fyrdubbla mängden hårdvara från vad de hade räknat med. sen fick man räkna om kalkylen på vad det skulle kosta totalt sett med vad rackplatserna kostade inklusive kyla, el, brandskydd, nät osv så vart det snarare så att det var den gamle svarte som var miljoner billigare per år.

Man har spått stordatorns död i minst 15 år. Än lever de.

Angående minnen så var det mer av det praktiska slaget jag åsyftade.
När jag jobbade med fältservice på 90 talet så var det inte alls ovanligt att man åkte på garantijobb och bytte dåliga minnesmoduler.
Eller tog glasfiberborsten och borstade bort oxiden ur kontakterna (hej Sun)

Har inte varit med om sådanna behov på senare år så därmed min fundering på om det bara är vi eller om de faktiskt har blivit så mycket stabilare.

Sånt praktiskt jobb får jag inte göra nuförtiden (chefen hävdar att jag har för hög lön för att vara ute i hallen och springa). Jag ska bara skriva massa beslutsunderlag och liknande samt köra fram lite statistik som den jag nämde ovan, Sånt kallas tillgänglighetsrapporter och är rätt viktiga i uppföljningen har jag hört

Arbetsdator: HFX Mini. Core-i5 2405S, Radeon 6570, Asus P8P67-M . Skärm: Dell 2407
HTPC: HFX Classic, E8500, Radeon 3450, P5K/EPU, Floppydtv-s2
Hyper-V Server: E6750 8GB minne 2X3TB Raid1 samt 2X1TB raid 1