Är hårdvaru raid på väg att dö ut?

Raid 0 och 1 och kombinationer av det innebär inga paritetsberäkningar, så det lär inte belasta särskilt mycket, det är i princip bara en parallelkoppling av diskar och att buffra datat och lägga ut det i rätt ordning.
Vid virtualisering blir det inte så att varje virtuell maskin håller på med diskhanteringen? Det måste vara effektivare att bara ha en maskin som håller på med det eftersom en virtuell maskin inte vet vad de andra gör, så ett san/nas blir väl effektivare om man virtualliserar? Dessutom borde väl minnesbuffrar och cache bli effektivare om bara har en maskin som hanterar diskaktiviteten? Och sekundärt kanske det även påverkar möjligheten att använda ncq o dyl effektivare?

Ja men ojdå
Här var det mycket sagt.

Om vi börjar men grundfrågan: Kommer HW raid att dö ut?
Nej. En riktig HW controller har fortfarande massiva övertag när det gäller säkerhet och skrivprestanda i verkliga miljöer.

Sätter du upp en raid5 mjukvarumässigt så har du två val. Antingen sätta writecache till noll eller riskera att hela raiden blir skrot vid hängning eller power Failure. Då man på företagssidan inte kan tänka sig att ta den risken så vet jag faktiskt ingen "seriös" kontroller som tillåter writecache utan batteribackup på kortet.

Vi gjorde lite utvärderingar på att köra med och utan cache på en hyffsat stressad filserver och det skiljde nära 50% i write performance. Sen beror det väldigt mycket på hur I/O mönstret ser ut. En läsintensiv applikation som tex Google klarar sig garanterat bättre utan writecache då jag skulle tippa att deras IO är 95%+ read.

Sen var det någon som nämde SAN/NFS också. Ett riktigt SAN är snabbt men glöm inte att räkna på hur många system som ska dela på den I/O som SAN:et kan ge. Samma sak för NFS. Har man tex bara ett Gbit interface på NFS servern så blir det ju storstryk av ett par vanlga Sata diskar tom. Med 10Gbit ser det bättre ut men alldelles för många överlastar bussen på sina san likt förbaskat

Ett HW kort är i princip en egen dator ja. De har egen CPU och minne samt I/O bussar. Man använder faktist ibland generella processorer även på raidkort men det är fortfarande en enorm skillnad på ett riktigt kort och att köra via CPU.

En vanlig dator hänger sig någon gång oavsett OS. Har du då en writecache i minnet så är det datat borta och ditt filsystem är korrupt. Dags att hämta senaste backup samt att du förlorar det som är gjort från det tillfället och framåt. EN HW controller skyddar sin cache med eget batteri så det händer inte. Finns det ström till burken så kommer den dessutom att skriva ned datat oavsett hur datorns operativsystem mår. Sitter du då med data som är värt några miljoner så är det ett rätt avgörande argument

Nästa problem är att du måste använda huvudCPU, minnes och databussarna för att göra Raidjobbet. Även om CPU är snabb så har inte I/O bussarna utvecklats i samma takt så du kommer att lägga en hel del last på ditt systems I/O bussar för att hantera Raidfunktionerna. Det leder antingen till att du får köpa en dyrare maskin med bättre I/O bussar för att burken inte ska bli seg eller så får du skaffa fler burkar. I det läget blir tom en HW controller billigare.

Sen att köra en enda disk som cache är inte heller det bra. Den I/O kanalen kommer att bli överlastad ganska fort. Även om vi utgår från att vi skriver 3GB/sekund till en SSD så är inte det så mycket om vi pratar riktiga Raidsystem. Det krävs inte mer än 20-30 disk i raidsystemet innan det blir ett problem.

Ytterligare en fördel för en HW controller är att de är anpassade för att jobba ihop med diskar och bakplan i den servern. Iom det kan HW controllern styra diskarna och på så sätt få fram lite mer I/O också.

ZFS testade vi inte men det spelar egentligen ingen roll då samtliga faktorer jag nämner sitter i hårdvara och inte i mjukvarulagret

Nä, det finns ingenting som visar att ett filsystem är säkrare än hårdvara byggd för stabilitet. Som jag skrev ovan så räcker det med en hängning plus Writecache i ram så är det kört. Det kan inget filsystem alls skydda sig emot utan extrema prestandaförluster (Dvs stäng av writecache).

Nope, att köra Windowskärror är fortfarande relevant, så hårdvaru-raid kommer nog vara kvar ett bra tag till.

Tror jag har varit med om krasher på det flesta OS.

Windows på rätt HW (Dvs en riktig server med bra drivers) är väl i klass med Linux. Magkänslan säger att de båda har ett steg kvar till Solaris/Sparc dock men då var vi återigen inne på dedikerad HW för jobbet

För det första kan du inte jämföra två olika typer av HW på det sätt du gör. Det är en ruggig skillnad på specialiserad HW som gör sitt jobb och en generell processor som egentligen inte är riktigt bra på nått.

Titta tex på vad en gammal stordator från 90 talet har för mipstal och betänk sen att de funkade fint som databasservrar för 10000 plus användare. Prova sen att köra det på en quadCore med en singeldisk.

Du verkar ju utgå från att CPU och Minne också har tid att offra på att ta hand om diskI/O. Det stämmer inte i en större server utan där gäller det att ha ett balanserat system. Ett bra verktyg att testa med är tex I/O meter.

ZFS är precis lika sårbart som alla andra filsystem för förlorad WriteCache fortfarande. Tappar du en writecache är datat borta. Du kan inte backa något från en journal som inte finns då varken den eller datat har skrivits till disk ännu. Det enda försvaret mot det är som jag skrev att inte använda någon som helst writecache. Det är också exakt vad ZFS gör, man använder inte ramcache och tvingar diskarna att tömma sin cache direkt. Som privatperson kvittar det då man som sagt ALDRIG ska använda writecach utan batteribackup. På en lätt lastad server eller en server med högt read/write förhållande gör det ingen större skillnad heller. Där kan man ta till ett annat knepp för att få upp hastigheten, nämligen att stoppa i fler diskar. Problemet är när du kommer upp till servrar med högt Write/read förhållande. Nu börjar det kosta rejält att köra utan writecache. En vanlig filserver kan man se detta på men där det blir fruktansvärt uppenbart är en transaktionsserver eller dedikerad databasserver

Att ZFS försöker spara ändringar är trevligt men då får du nästa problem istället. Om du har ett ordentligt förändligt data som i en transkationsDB så kommer din diff hantering väldigt fort ta enorma mängder disk istället. Därmed blir man tvungen att begränsa den och så vart det dags för backupen i varje fall. (IBM:s Tivoli backup system jobbar just med Diff för att försöka hålla nere backuptiderna men till priset av att backuparkivet blir väldigt stort). Att förlora 30 sekunder i ett transaktionssytem kan innebära en stoppad fabrik för X antal miljoner i kostnad.

En bra och stabil lösning är tex en Proliant Server med dess Smart Array controllers. De hanterar de flesta av de fel som nämns i din artikel per automatik och de larmar om diskar håller på att rasa i förtid.

På snart 20 år i branchen och några tusen raidset så har jag varit med om att tappa ett. Där hadde man konfat larmhanteringen lite snett så att larmet för trasig disk gick till en person som hadde slutat. Servern hadde snyggt och prydligt larmat i tre dagar innan disken la av.

Sen finns det ingen mirakellösning för dataskydd överhuvudtaget. Alla är komromisser mellan pris, prestanda och säkerhet. Du kan få två utav de tre men du kan aldrig få alla tre. En snabb och säker lösning är görbar. Då blir det just HW controllers eller SAN. Du kan få det billigt och säkert med tex ZFS men då blir det inte så snabbt. Du kan få det snabbt och billigt med tex moderkorts raid 1 men det är inte särskillt säkert.

Vill du ha en garanti på att du har datat kvar så finns det bara en sak och det är backup.

Vilken HW raid kontroller fuskar med säkerheten menar du. Kan du nämna ett exempel på en riktig kontroller dvs inte (intels moderkort eller annat utan battreibackup) som fuskar med säkerheten? Att en utvecklare av ett filsystem gjorde det har återigen ingenting med hårdvaran att göra

Riktiga kontrollers hanterar svagheterna i Raid med hjälp av just sin hårdvara. Det näms tom i den wiki sida du länkade till. Därmed är de riskerna rejält minimerade till i praktiken obefintliga.

Att olika mjukvaruradier har olika hastigheter kan vara skäl för misstanke. Att jämföra mjukvara som ZFS med hårdvara år helt fel och där kan man inte dra någon specifik slutsats utan att veta mer om hur lösningen är byggd. Riktiga Kontrolelrs kan ju styra diskarna mer effektivt än vad ett moderkort kan och når därmed betydligt högre I/O värden. Har du tex 64 diskar i Raidsetet så kan du ju i vissa fall tex skriva med 64X150Mbyte i sekunden.

Som privatperson har du CPU:n och den gör troligen inte allt för mycket annat. Därmed gör säg 5-10% lst inte så mycket men för en väl balanaserad server så är 10-10% CPU rätt mycket (Den skriver mycket mer därav högre siffror). Sen kommer det ännu större problemet och det är datatransporten mellan disk och CPU. Just I/O bussarna är oftast det som är tyngst lastat i en server. Att då kunna skicka ett jobb till raidkontrollern istället för att behöva skicka 8-10 jobb till olika diskar är en massiv prestandaförbättring. Enda lösningen på det förutom "smarta" kort är att köpa en större och därmed betydligt dyrare server.

All energiförbrukning i en dator blir ju värme. I ett hem så gör det inte så mycket. I en datorhall så krävs det massiva kylanläggningar. Därmed är energiförbrukningen högintresant då varje extra watt är en onödig kostnad timme för timme.

Helt rätt att en stordator har I/O funktioner under sig. Det har även Raidkontrollern just för att vara effektivare.

Återigen så visst kan du emulera men vad kostar emuleringen? Den lasten är inte gratis den heller (för hemmabruk kan det vara snudd på men det är det inte i en datorhall. Där kostar som sagt varje watt, varje I/O, varje millisekund i extra väntetid). Därmed handlar det mer om att jämföra kostnader för Felix kontra Heinz ketchup.

Och fortfarande är inte någon SSD lösningen på avsaknad writecache. Du gör faktiskt tom problemet värre för nu ska du först skriva till SSD, sen lässa från SSD och sen skriva till disk. Dvs du tredubblade mängden I/O som krävdes för att skicka datat till disk och du kan fortfarande inte skriva fortare till disken heller.

Att skicka alla skrivningar till SSD är ju liksom lite omöjligt. Då ska ju all disk vara SSD. Annars är det samma cacheproblem som ovan igen.

Bra kontrollers kan mycket väl hantera bitröta. Det gör man geonom att läsa och skriva om bliocken. Därmed blir bitrötan ett i praktiken icke existernade problem. Ser man till att varje block är ok så behöver man inte hantera det längre upp. ZFS och andra mjukvarulösningar kan inte göra det och därmed måste de hantera dem längre upp.
Skulle bitröta vara ett reellt problem så skulle det ha rasat massor av raidset i samma takt som diskar i dem rasar. SOm jag sa tidigare så har det aldrig inträffat på de system jag har haft att göra med.

En SSD löser inte några I/O problem för du skriver fortfarande inte snabbare till diskarna. Vad gör du när din SSD är full? Eller när den krashar (har du bara en så är det ju dessutom ett singel point of failure).

Att läsa 2-3Gb/sekunden är inte så imponerande alls. Det är ju bara 3000/46 dvs ca 43-66Mbyte/s och disk. Titta på vad en vanlig disk i en standardpc fixar. Dessutom som du själv påpekar så har du skalningsproblem med ZFS också. När system blri större så går det långsammare. Normalt sett är det tvärtom. Ju fler diskar, ju fler huvuden man kan skriva med, ju snabbare I/O.

Sen vet jag faktiskt inte om du skämtar när du hävdar att Linux och solaris inte krachar pga minnesfel. I verkligheten krachar de precis lika hårt som windows eller något annat. Kan du inte läsa minnet där tex hårddiskdrivern låg så kan du inte längre prata med disken oavsett OS. Därmed kommer också krachen som ett brev på posten.

Anledningen till att MS ser mer av problemet är att MS hadde 90-95% marknadsnadel av kontors och hemdatorer. Gissa var de billigaste och därmed också sämsta komponenterna sitter? Sätter sen någon upp en server på en sån burk utan att ge den ett anständigt powersupply och vettig kylning. Tja det blir ingen stadig lösning.

Sen kan du ju försöka stoppa icke ECC minnen i en Sun server. Går precis lika dåligt som om man försöker stoppa dem i Prolianten. Rätt hanterat och på rätt HW så ligger Windows på ungefär samma siffror som Solarismaskinerna i tillgänglighet. (något lägre pga patchning men det är ju planerade stopp inte oplanerade).

ZFS kan kanske bli bra för enterprise marknaden på sikt men då kommer det troligen att krävas ZFS ner i HW för att få upp farten (sen är ju RAIDZ egentligen bara en utvecklad variant på raid5) och stabiliteten. Det finns ju en trave artiklar om problem med diskar och diskkontrollers som flaggar skrivning klar tillbaka till ZFS innan det är klart. Får man ett strömavbrott i det läget så är det fullständigt godnatt då ZFS tror att både data och journal är uppdaterade utan att så är fallet. Dvs samma problem som jag nämde tidigare med ramcachning.

HW-raid i form av Intels moderkort och likanande eller riktiga kontrollers? Dina länkar säger inget om det så utan det så tror jag att det är mer lågprisprylar i händerna på människor som inte vet hur de ska hantera prylarna än något annat. Jag ser ingenting som säger att raid-5 eller raid-6 är osäkert när det körs på riktiga kontrollers då de just utökar standarden för att ta itu med de svagheter som fanns i designen.

Kan det vara så att vi jobbar yrkesaktivt med servrar dagarna i ända? Jag tror inte att du gör det. Som jag tidigare nämde så har jag driftat ett antal tusen raidset. Du kan väl fundera på och förklara varför inte ett enda av dem har rasat pga bit-röta om det vorde ett reellt problem. Varken Windows eller Solarismaskinerna har rasat. Jag har aldrig hört talas om att ett SAN-skåp som kör raid internt skulle ha rasat heller. Och då har jag ett kontaktnät på några hundra aktiva servertekniker så jag har nog prat med minst lika många sysadmin och ingen har haft problemet.

Defekter i en disk detekteras av controllern och beroende på fel så flaggar den disken som dålig, slutar använda den och kopplar på spare disken istället. Rätt konfad så får man också ett larm om att det är dags att byta den dåliga disken.

Att flusha till SSD hjälper en del på ett system som inte har hög last då man hoppas kunna skjuta upp jobbet lite tills det är lugnare men på en lastad server funkar det fortfarande inte. Tre I/O operationer blir fortfarande mer jobb än en. Dessutom får man ju en risk för att SSD disken pajar och vipps var vi tillbaka i grundproblemet utan writecache.

Jag vet faktiskt inte vad som finns öppet publicerat om vad kontrollrarna kan. Samma sak gäller HDS skåpen. (Vi har ju avtal med dem så jag har andra informationsvägar). Har du en server och 30 disk kan du ju alltid testa med tex I/O meeter eller liknande. Det är ju normalt så man gör att man bygger upp den lösning man bedömmer ska klara kundens behov och sen testar man den och bifogar det protokollet till leveransdokumentationen

Med mjukvara kan du få sämre prestanda då det blir mer för CPU och moderkort att göra för att hålla rätt på diskarna och skicka jobb till dem. Med HW så ser inte datorn diskarna utan den ser en rackarns snabb disk från controllern. Den i sin tur gynnas av att ha flera diskar under sig. Du får ju fler huvuden att läsa/skriva med . Dessutom ökar du ju sanolikheten för att du har en disk som har ett läshuvud nära det begärda datat vilket också sparar tid (mer markant för random read/write naturligtvis). Det är därför man på databasservrar hellre vill ha en trave små diskar än några stora.

Du skrev själv att ZFS käkar ZPU med många diskar i maskinen. Det är ett skalningsproblem när man designar ett system då prestanda på systemet blir sämre när du utökar datamängden. Ska du då sälja på kunden en större server så att den klarar utlovade prestanda om ett år?

Du får ursäkta men din fasta övertygelse är fullständigt fel. Hur ska du hantera att du inte kommer åt din disk längre iom att driverns minne är borta?
Det kan du helt enkelt inte hur mycket du än vill tro det. Är det minnesblocket borta så är det borta, det är vad korrupt minne innebär. Det enda försvaret mot det är speglat minne och checksummor och det hittar du på lite större burkar. Har inte satt upp det hos någon kund ännu utan man tycker att ECC är bra nog.

Jo att det finns många som inte tror att WindowsServers sätter 99,99% i uptime. På riktig HW är det inga problem alls. Brukar vara standardkrav i upphandlingar. Vill du upp i fem nior så går det med men då pratar vi kluster på alla dessa då det mer handlar om att hantera HW haverier som tex moderkort eller just minnen.

ZFS kommer att tvingas börja skriva över så fort disken blir full eller ska du hela tiden köpa nya diskar?
Ta tex ett logsystem(mätvärden i tillverkningsindustri) som består av en Databas på 5GB som du skriver 200GB ändringar per dygn till. ska du då lagra 200GB ändringar per dag i en månad så behöver du du alltså 200X30 dvs 6TB för att lagra en DB som är 5GB stor. Tvekar på att någon kund vll betala det.

ZFS designproblem är detsamma som i princip alla andra filsystem, dvs att den utgår från att diskkontrollern alltid kommer att tala sanning om vad som är skrivet till disk och i rätt ordning. Ett Scenario är när kontrollern svarar med att datat är skrivet så fort kontrollern har tagit emot det. Då tror ZFS att datat är på plats och ändrar pekaren utan att datat finns på disken. Detta har ZFS inget skydd emot därför att man från mjukvara fortfarande inte kan hantera HW problem. Man kan ev detektera dem men man kan inte förebygga dem.

Och återigen utan writecache så kommer du få sådanna prestandaproblem på den typen av system så att du antagligen behöver fler system istället och då var en HW controller billigare.

Den dagen man får ned ZFS i HW så tror jag på den. RaidZ är ju egentligen bara en utökning av software raid-5 så det borde inte vara helt omöjligt att få ned det i rommen på en Controller. På så sätt kan man också stoppa dit en riktig writecache och lösa prestandafrågan runt multidisk I/O.

Fram tills dess är Raid eller san (som iofs kör raid internt i 9 fall av 10) som kommer att regera datorhallarna

ZFS på ett san bli också intresant. Ska skrivande dator styra diskarna i sanet direkt eller ska man nu göra ett fullständigt avsteg från ZFS specen och klarflagga när datat har nått skåpet? Det första alternativet skulle ju vara kul att se prestandan på. Helst med sanspegling och en 30 mil mellan skåpen eller så.