Plan9 fan. In glenda we trust.
Är hårdvaru raid på väg att dö ut?
Och med en ZIL Accelerator kastar du *DEDIKERAD HÅRDVARA* för att lösa ett problem som uppstår för att du inte vill använda dedikerad hårdvara.
Hehe, där fick du mig. Japp, jag erkänner att du har en poäng.
Hehe, där fick du mig. Japp, jag erkänner att du har en poäng.
ÄÄÄÄÄÄÄÄNTLIGEN!
Du kan dock ganska enkelt ersätta en trasig/utdaterad ZIL, lite jobbigare när ett raidkort ger upp, just sayin
Det du pratar om, är en dator. Du beskriver en dator helt enkelt. En dator är hårdvara som man kan programmera om att få olika funktioner. Så det du verkar vilja ha, är hårdvara som du kan programmera om med mjukvara. Så det verkar som att du är inne på linjen att om man kan göra samma sak i mjukvara, bara aningen sämre, så är det ingen stor poäng att köpa dedikerad hårdvara. Om jag har en cpu på 2.4GHz, så är det ingen mening att uppgradera till 3GHz. Visst är 3GHz lite snabbare, men inte så stor skillnad. Har man extrema behov så måste man uppgradera till 3GHz, men det har man oftast inte.
Min dator består alltså av 3-4 datorer? Så det kanske inte är nödvändigt för gamers att köpa ett grafikkort? Grafikkort är helt värdelösa helt enkelt och man borde inte ha dem ens integrerade i cpun? Det jag pratar om är något helt annat.
Det jag menar är att du gör som på en hårdvarubradvägg, där programmerar du regler som du sedan kompilerar till vhdl (eller något annat bös) och skriver om hur hårdvaran fungerar och det nuddar aldrig cpun, till skillnad mot en cpu där du ger den instruktioner men inte kodar om instruktionerna. Varför skulle man inte kunna göra så med controllers lika väl? Tror man till och med skulle kunna få ännu bättre prestanda av dem än i dagsläget utan att gå miste om speciellt mycket. Visst du kommer inte kanske kunna spela en låt varje gång en inode får sin kontrollsumma kontrollerad, känns som man kan leva med det.
Tror för det stora flertalet så kommer nog alltid hårdvaru raid att vara något rätt ointressant egentligen men tror det finns en marknad för dem, speciellt om det görs på ett bra vis.
Detta är tråden för folk som sitter fast i låder och inte kan se utanför dem tbh.
Men det är precis detta som jag har svårt att förstå och inte fått någon bra motargument om.
Du har fått massor med bra argument, men det saknas grundläggande grepp om hur hård och mjukvaran fungerar, som helt enkelt gör att du inte kan ta till dig dem.
Visst kanske hw-raid är effektivare och snålare än mjukvaruraid, så det hela leder till att du måste använda dubbelt så mycket mjukvaruraidresurser för att få samma prestanda som hw-raid använder. Så? Vad är problemet med det? Vad är problemet med att du måste använda mer cpu kraft, än ett hw-raid kort använder? Flexibiliteten uppväger det. Det är ungefär som att ett program kräver 1GB RAM, eller så kan du optimera det så det kräver 768MB RAM - vad är problemet? Det är bara att fläska på med mer RAM. Det är knappt nån skillnad i RAM.
Nu lyser det jag nämnde tidigare igenom igen. Det är inte kritik, utan ett konstaterande. Men om jag försöker förklara väldigt simplifierat. (jag är nu inte vidare pedagogisk, så det finns inga garantier för att jag gör ett bra jobb, jag ber om ursäkt på förhand.) Ett RAID kort, agerar som en enhet sett från mjukvaran. Mjukvaran ber OS om en fil, OS pekar på rätt plats i filsystemet och säger "apport" till RAID kontrollern. Man skickar då en förfrågan till RAID kontrollern om data på "ett" ställe. Exakt var, och på vilken disk, får kontrollern ta hand om. Jämför med med att läsa från en mjukvaruRAID. Mjukvaran frågar fortfarande OS om filen, OS går till mjukvaruRAIDen, och säger "apport". Så långt precis som med en RAID kontroller. Här kommer dock skillnaden. För att läsa data från mjukvaruRAIDen måste kommunikationsbussen transportera läsorder till varje disk, istället för en gång, till RAIDkontrollern. Det här är alltså vad jag syftar på när jag säger att man får mer overhead. Så länge du bara hanterar "ett fåtal" diskar och inte kommer i närheten av vad du har fritt i bandbredd är det inte ett problem, men det påverkar skalbarheten. En RAID kontroller med 10 diskar, vs 10 diskar, mjukvarurRAIDen genererar alltså 10 gånger mer kommunikation för att komma åt en given mängd data. Det är inte möjligt att stocka på en snabbare CPU, eller stoppa i mer minne, det här påverkas helt enkelt inte av de faktorerna. (nå, med för långsam CPU klarar du inte av att fylla din bandbredd...)
Man kan alltid stoppa i mera cpu och RAM i en ZFS maskin, så du når upp till samma prestanda som ett effektivare hw-raid kort. Och du kan stoppa i mer och mer CPU, så prestandan går förbi ett hw-raid kort. Ett hw-raid kort kan bara använda ett slot, och det finns bara en viss bandbredd där. Men ZFS kan använda 8 slots eller mer, och använda all den bandbredden. Så jag förstår inte varför du argumenterar för att det blir "stora fördelar för hw-raid när det kommer till bandbredd" med många diskar. Vad är fördelen? Kan du peka ut den? Antagligen 8 slots har högre bandbredd än ett hw-raid?
Ett vettigt hårdvaruRAID kan utan vidare spannas över flera kortplatser. Mängden tillgänglig bandbredd är med andra ord densamma. Skillnaden är att mjukvaruRAIDen delvis nyttjar moderkortets bandbredskapacitet för overhead, istället för data trafik. Vilket är orsaken till varför mjukvaruRAID inte skalar bra på samma sätt. Lösningen där är så klart att bygga ytterligare en burk när man börjar nå gränserna för vad man har bandbredd till, men det betyder att man får bygga den nya burken tidigare för mjukvaruRAID systemet.
Angående Youtube, jag har inte sett filmen. Men jag kanske borde göra det. Tills jag gjort det, ska jag inte nämna Youtube igen.
Jag har nu BARA tittat igenom det klippet, eftersom jag har sett det tidigare, och inte riktigt fick dina argument att passa ihop. Är övriga källor till dina fakta lika kritiskt granskade av dig, tror jag att vi kan lägga ned det här med en gång.
I Youtube fallet gissar jag på att grundtanken bakom, och orsaken till att de över huvudtaget tjänar på att köra mjukvara över hårdvara, är just hårdvarans fördelar. De kör en stripe av speglade diskar. En vettig hårdvarukontroller låter den disken av det speglade paret som har kortas "väg" till data läsa de data, och kan samtidigt låta den andra disken få order om att läsa andra data, de som står näst i kö. Mjukvaran har inte den fördelen. (Multiplex. I teorin kan man hantera så många diskar som kontrollern har stöd för, och utföra så många "simultana" läsningar. 2-3 brukar dock vara där gränsen går för praktisk nytta.) Så genom att lura OS'ett att se de 5 speglade paren och dra ihop dem som en mjukvaruRAID kan man skicka fler data requests än vad man kunde till den ursprungliga enheten. Det är helt en fråga om hur hårdvaran hanteras av OS'ett, och "rätt" sätt att lösa det på, är en vettig drivrutin som ser till att det är hårdvaran som står för den faktiska begränsningen. Det här med spegling via hårdvara, och stripe via mjukvara ovanpå hårdvaran är en "workaround", quick n' dirty, men det fungerar. Och det viktiga i sammanhanget, det fungerar där, och då, utan utvecklingstid.
Jag vet inte om jag tror att vi kommer längre här.
B!
Allting jag skriver är om inget annat uttrycks, min åsikt! Ingenting måste vara dagens sanning enligt din åsikt, och gör du antaganden baserade på mina åsikter hoppas jag att du övervägt mer än bara just min åsikt.
Det jag menar är att du gör som på en hårdvarubradvägg, där programmerar du regler som du sedan kompilerar till vhdl (eller något annat bös) och skriver om hur hårdvaran fungerar och det nuddar aldrig cpun, till skillnad mot en cpu där du ger den instruktioner men inte kodar om instruktionerna. Varför skulle man inte kunna göra så med controllers lika väl? Tror man till och med skulle kunna få ännu bättre prestanda av dem än i dagsläget utan att gå miste om speciellt mycket. Visst du kommer inte kanske kunna spela en låt varje gång en inode får sin kontrollsumma kontrollerad, känns som man kan leva med det.
Poängen är att jag inte förstår varför man ska köpa dedikerad hw som gör en sak helt optimalt bra. Om du istället köper ett stycke hårdvara som du kan ändra beteende på, antingen genom att programmera om en cpu, eller programmera om en hårdvarubrandvägg som du beskriver - så är det bättre även om du förlorar lite prestanda.
Om du kan göra samma sak i mjukvara, som i hårdvara, varför köpa massa olika hw som bara kan göra en enda specialiserad sak. Istället för att köpa en multimaskin som kan göra allting, men bara aningen sämre?
Du kan dock ganska enkelt ersätta en trasig/utdaterad ZIL, lite jobbigare när ett raidkort ger upp, just sayin
Jojo, men iXam har rätt. Jag pratar om att hw ska undvikas så långt som möjligt. Men när man behöver maXi skrivprestanda så ska man använda ZIL, dvs ett stycke hw. Som jag ifrågasatt.
Men det sa jag ju från början, mjukvara är lite långsammare än hw - det har jag aldrig motsagt. Det jag däremot sagt, är att med ZFS kan du skala uppåt och stoppa i mer och mer cpu och RAM så du till slut går förbi specialiserad dedikerad hw. Mao, behöver man inte snabbast möjliga prestanda så går mjukvara bra. Behöver du snabbast möjliga prestanda, så behöver du dedikerad hw, tex. ZIL. Alternativet är att du slänger på dubbelt så mycket cpu och RAM så då går prestandan förbi dedikerad hw - men det är varken effektivt eller resurssnålt.
Du har fått massor med bra argument, men det saknas grundläggande grepp om hur hård och mjukvaran fungerar, som helt enkelt gör att du inte kan ta till dig dem.
Det är inte så att jag har problem att fatta, jag tycker bara inte jag fått några bra motargument.
Nu lyser det jag nämnde tidigare igenom igen. Det är inte kritik, utan ett konstaterande. Men om jag försöker förklara väldigt simplifierat. (jag är nu inte vidare pedagogisk, så det finns inga garantier för att jag gör ett bra jobb, jag ber om ursäkt på förhand.) Ett RAID kort, agerar som en enhet sett från mjukvaran. Mjukvaran ber OS om en fil, OS pekar på rätt plats i filsystemet och säger "apport" till RAID kontrollern. Man skickar då en förfrågan till RAID kontrollern om data på "ett" ställe. Exakt var, och på vilken disk, får kontrollern ta hand om. Jämför med med att läsa från en mjukvaruRAID. Mjukvaran frågar fortfarande OS om filen, OS går till mjukvaruRAIDen, och säger "apport". Så långt precis som med en RAID kontroller. Här kommer dock skillnaden. För att läsa data från mjukvaruRAIDen måste kommunikationsbussen transportera läsorder till varje disk, istället för en gång, till RAIDkontrollern. Det här är alltså vad jag syftar på när jag säger att man får mer overhead. Så länge du bara hanterar "ett fåtal" diskar och inte kommer i närheten av vad du har fritt i bandbredd är det inte ett problem, men det påverkar skalbarheten. En RAID kontroller med 10 diskar, vs 10 diskar, mjukvarurRAIDen genererar alltså 10 gånger mer kommunikation för att komma åt en given mängd data. Det är inte möjligt att stocka på en snabbare CPU, eller stoppa i mer minne, det här påverkas helt enkelt inte av de faktorerna. (nå, med för långsam CPU klarar du inte av att fylla din bandbredd..
Du behöver inte beskriva så utförligt, det är onödigt, jag kan programmera och vet hur datorer funkar. Som de flesta andra här.
Jag håller med dig om att hw-raid är effektivare och resurssnålare än mjukvaruraid - det har jag aldrig bestridit. Ett optimerat dedikerat system är alltid resurssnålare än ett generellt system. Det jag däremot ifrågasätter, är följande:
Visst använder mjuvaruraid mer resurser - så vad spelar det för roll? Är det ett problem? Dagens datorer är så kraftiga att det spelar ingen roll om hw använder 20 klockcykler och mjukvara använder 100 cykler. 20 eller 100 cykler är billigt på dagens cpuer. Den enda gången du märker skillnad är om du måste ha max prestanda.
Ett vettigt hårdvaruRAID kan utan vidare spannas över flera kortplatser. Mängden tillgänglig bandbredd är med andra ord densamma. Skillnaden är att mjukvaruRAIDen delvis nyttjar moderkortets bandbredskapacitet för overhead, istället för data trafik. Vilket är orsaken till varför mjukvaruRAID inte skalar bra på samma sätt. Lösningen där är så klart att bygga ytterligare en burk när man börjar nå gränserna för vad man har bandbredd till, men det betyder att man får bygga den nya burken tidigare för mjukvaruRAID systemet.
Va? Kan ett hw-raid kort spänna över flera kortplatser?? Det var något nytt för mig. Hur går det till, kan du förklara? Eller pratar vi om olika saker, så det är missförstånd här?
Antag att ett hw raid kort sitter i en PCIe - x8 slot, kanske. Ett sånt slot ger 4GB/sek. Alltså kan du skicka data genom slotet med en hastighet av 4GB/sek. Antag att hwraid kortets cpu klarar av att läsa 5GB/sek - det kommer ändå inte att gå snabbare än 4GB/sek. Eftersom slotet bara klarar av 4GB/sek. Max hastighet du kommer få ut av hw raidet är 4GB/sek, pga slotet begränsar. Så antag att du daisy chainar massa diskar till hw-raid kortet så du har nu 255 diskar. Eftersom max är 4GB/sek så betyder det att varje disk får 15MB/sek. Du kan inte koppla fler än 255diskar, och det går inte snabbare än 4GB/sek. Bandbredden är begränsad. Hw-raidet skalar inte, det finns en gräns som inte går att spränga.
Antag nu att du använder mjukvaruraid. Det måste inte vara ZFS, det kan vara BTRFS eller mdadm eller windows mjukvaruraid. Till detta kopplar du nu ett disk kontroller kort i en PCIe-8x slot. Du får ut max 4GB/sek. Efter ett tag märker du att du behöver mer än så. Med hw-raid är det kört. Med mjukvaruraid så kan du istället koppla in ett till disk kontroller kort i en annan PCIe-8x slot och koppla några diskar till detta nya kort, som nu ger dig 4GB/sek till. Så nu har du 8GB/sek över mjukvaruraidet. Du kan stoppa i 3 disk kontrollers till, om du känner för det. Och koppla om diskarna. Antag att du har 255 diskar och 5 disk kontroller kort. Då kopplar du in 51 diskar på varje kort, och får 4GB/sek från varje kort. Totalt får du 20GB/sek. Du kan lägga i ännu fler disk kontroller kort och flera diskar, och få ännu mer prestanda. Nånstans tar väl cpun stopp, en cpu kan väl inte skyffla data i en takt av 100GB/sek. Men poängen är att du kan använda flera kort till mjukvaruraid, så du skalar uppåt mycket bra. Detta kan du inte på ett hw-raid.
Jag har nu BARA tittat igenom det klippet, eftersom jag har sett det tidigare, och inte riktigt fick dina argument att passa ihop. Är övriga källor till dina fakta lika kritiskt granskade av dig, tror jag att vi kan lägga ned det här med en gång.
Jag har inte granskat klippet alls, därför tänker jag inte ta upp det mera, förrän jag gjort det. Jag fick allting ifrån den här hackern, han verkar veta vad han pratar om, trodde jag.
http://blog.zorinaq.com/?e=10
Men om du nu säger att snubben har fel, så har han fel. Jag ska kolla på klippet och se vad som sägs.
Jag vet inte om jag tror att vi kommer längre här.
Nej, det jag inte heller. Jag tycker fortfarande att jag inte fått några bra motargument. Om en person kan göra allting som 10 andra specialister kan göra, men han är bara lite långsammare - så föredrar jag att anställa denna enda person. Det är enklare än att anställa 10 olika specialister. Visst är specialisterna bättre på att göra sin lilla grej, men varför anställa alla 10, när en person kan göra allting? Men bara lite långsammare.
Motargumentet går nånting i stil med
-Att anställa en specialist blir effektivare, det blir mindre overhead när han jobbar
-Javisst, det håller jag med om. Men spelar det någon roll om det blir lite overhead? Om specialisten ägnar 20 sekunder åt att göra en sak, och generalisten gör det på 100 sekunder, so what? Samtidigt slipper jag betala 10 löner och generalisten kan jag lära nya saker genom att ladda ned lite instruktioner. Alternativet är att anställa en specialist varje gång jag vill göra en ny sak. Varför inte bara lära om generalisten, även om han är lite långsammare?
-[här kommer massa motargument som jag inte alls förstår, typ: specialisten är snabbare, specialisten klarar av större arbetslaster (nej, mjukvaruraid skalar över flera kort så mjukvaruraid klarar större arbetslaster), etc]
Va? Kan ett hw-raid kort spänna över flera kortplatser?? Det var något nytt för mig. Hur går det till, kan du förklara? Eller pratar vi om olika saker, så det är missförstånd här?
Antag att ett hw raid kort sitter i en PCIe - x8 slot, kanske. Ett sånt slot ger 4GB/sek. Alltså kan du skicka data genom slotet med en hastighet av 4GB/sek. Antag att hwraid kortets cpu klarar av att läsa 5GB/sek - det kommer ändå inte att gå snabbare än 4GB/sek. Eftersom slotet bara klarar av 4GB/sek. Max hastighet du kommer få ut av hw raidet är 4GB/sek, pga slotet begränsar. Så antag att du daisy chainar massa diskar till hw-raid kortet så du har nu 255 diskar. Eftersom max är 4GB/sek så betyder det att varje disk får 15MB/sek. Du kan inte koppla fler än 255diskar, och det går inte snabbare än 4GB/sek. Bandbredden är begränsad. Hw-raidet skalar inte, det finns en gräns som inte går att spränga.
Som sagt, du kör inte Daisy-chains om du kör bandbreddsintensivt. Du kör multipla RAIDkort, med stöd för en RAID array över alla kontrollers. I dag tror jag det är bara XelCore som är aktuell. Funktionen som sådan har dock varit med sedan jag körde på Adaptec kort i 32 bitars ISA slots... Med andra ord, sedan Fantomen köpte gympadojor att ersätta trätofflorna med. I grund och botten skulle jag tro (gissning) att det handlar om drivrutinsbaserad spanning över flera kontrollers. Det ger alltså exakt samma nackdelar för varje kort, som du får för de individuella diskarna i en ren mjukvaruRAID. Det ger x gånger mer waste med mjukvaruRAID än hårdvaru, där x står för antalet diskar / kontroller.
(Jag tror LSI slutade erbjuda funktionen efter LSI Ultra320, så de kan vara villiga att dela med sig av information om exakt vad korten pysslar med. De plockade bort funktionen eftersom ingen efterfrågade den. Egentligen rätt naturligt, ingen individuell server kommer ha så mycket bandbredd att den behöver multipla RAIDcontollers för att serva användarna.)
B!
Allting jag skriver är om inget annat uttrycks, min åsikt! Ingenting måste vara dagens sanning enligt din åsikt, och gör du antaganden baserade på mina åsikter hoppas jag att du övervägt mer än bara just min åsikt.
Och mjukvara gör det på papper?
Nej, mjukvaruraid gör paritetsberäkningar i mjukvara, som körs på datorns processor.
Nej, mjukvaruraid gör paritetsberäkningar i mjukvara, som körs på datorns processor.
Jag tror att man här syftar på att CPU'n fortfarande är hårdvara. Alltså körs paritetsberäkningarna ytterst fortfarande i hårdvara. Dock har man inte tagit hänsyn till skillnaden mellan dedikerad, och delad hårdvara, varken för, eller nackdelar.
B!
Allting jag skriver är om inget annat uttrycks, min åsikt! Ingenting måste vara dagens sanning enligt din åsikt, och gör du antaganden baserade på mina åsikter hoppas jag att du övervägt mer än bara just min åsikt.
Som sagt, du kör inte Daisy-chains om du kör bandbreddsintensivt. Du kör multipla RAIDkort, med stöd för en RAID array över alla kontrollers.
Ok, coolt. Det visste jag inte att hw-raid kort kunde klara av. Men detta verkar inte så vanligt idag längre? Från din länk:
"In fact, the Broadcom XelCore RAID software is the only product available from a major storage vendor that does support spanning."
Även om det är flera som stödjer det idag, så verkar det inte vara vanligt?
I grund och botten skulle jag tro (gissning) att det handlar om drivrutinsbaserad spanning över flera kontrollers.
Ja, det verkar helt enkelt vara mjukvaruraid som de använder, vilket tydligen är väldigt flexibelt
"One unique architectural feature of XelCore RAID software that complements and empowers spanning is its operating system and hardware independence. XelCore is a software RAID stack...This relative independence results in a high degree of flexibility"
Och eftersom XelCore RAID är mjukvaruraid, så kan man använda XelCore RAID på två olika sätt, dels som mjukvaruraid som spänner över flera kontroller kort, eller dels som vanlig hw-raid som bara sitter i ett enda slot:
"It also means XelCore can be used in either a host-based or a controller-based RAID implementation. With host–based RAID, the RAID stack (the array configuration data and RAID algorithms) and data cache run on the host CPU and utilize CPU memory. With controller-based RAID, the RAID stack and data cache reside on the controller."
Och eftersom man kan spänna över flera slots, så tydligen ger den möjligheten högre prestanda, mer än ett enda hw-raid kort:
"From a technical perspective, controller spanning provides two obvious benefits: the ability to create very large data arrays and a dramatic boost in I/O performance....There are two ways that controller spanning boosts I/O performance. One is fairly basic — the more disk spindles there are in an array, the higher performance. Since spanning allows more disks to be included in an array, it boosts I/O performance. "
Och de verkar mycket nöjda med sin prestanda, när de spänner över flera kontrollerkort (år 2004):
"As proof of these performance boosts, independent reviewer Tom’s Hardware Guide, tested four BC4852s in a single RAID0 array spanning 32 SATA drives and achieved the unprecedented results of over 1 gigabyte per second sequential reads and writes."
Det är ju helt ok prestanda för att vara år 2004.
Kort därpå, 2 år senare, släpptes en ZFS maskin x4500. Den har 6st diskkontroller kort som spänner över 48 diskar (på så sättt kan en disk kontroller krascha utan några driftsproblem alls). Den gav 2.7 GB/sek read och 1.9 GB/write. Så vi ser att även om XelCore RAID lyckades dubbla sin prestanda på 2 år, så var det inte så stor skillnad mellan mjukvaruraid (XelCore) och mjukvaruraid (ZFS) i prestanda.
http://research.microsoft.com/en-us/um/people/gray/papers/JHU...
Artikeln slutar med att rada upp fördelar med att spänna över flera kontroller korts:
"Spanning puts an important tool into the hands of IT professionals tasked with optimizing and streamlining their storage. The technical and business benefits that make spanning such a potent weapon are straightforward:
Technical Benefits
• Larger data arrays - with spanning, a single data array can span all the drives connected to all the RAID controllers in a system.
• Better I/O performance - spanning boosts I/O performance by providing an array with more paths into memory and by allowing a greater number of disks to be included in an array, up to 32 with Broadcom.
Business Benefits
• Easy integration - when secure storage capacity growth is required, spanning makes integrating additional RAID controllers and disks into an existing data array easy.
• Investment protection - when data storage growth leverages existing equipment and IT knowledge, the storage ROI is greatly improved. In closing, spanning supports more data and faster I/O without negating existing equipment investments: goals of any sound storage strategy."
Jag kanske är lite inskränkt och läser bara det jag vill läsa, men jag tycker snarare det verkar som att din artikel snarare stödjer min tes än din tes? Dvs att mjukvaruraid skalar bra uppåt, och att ett hw-raid kort inte skalar uppåt? Och att mjukvaruraid kan ge bra prestanda samt är flexibelt. Är inte dessa saker exakt samma saker som jag räknat upp hela tiden? Eller missförstår jag din länk, eller missförstår jag dig? Spanning är samma sak som mjukvaruraid? Eller?
Problemet är att du måste använda mer resurser för mjukvara, kanske dubbelt så mycket, som för ett enda hw-raid kort. Men so what? Spelar det nån roll om det tar 20 cykler eller 100 cykler? Det finns ju miljarder cykler att ta av, det finns ingen brist på cykler i en cpu? Speciellt om du har 4 kärnor, och varje kärna har miljarder cykler. Förr i tiden så var hw-raid cpuer mycket snabbare än generella cpuer så mjukvaruraid var mycket långsammare. Men dagens cpuer har gott om cykler och det går nästan lika snabbt idag med mjukvaruraid:
http://storagemojo.com/2007/04/24/mo-better-zfs-performance-s...
"Back when RAID was young, dedicated hardware made sense because CPUs were too pathetic for words. Nor had anyone done a clean sheet design like ZFS. What Robert demonstrates is that a software RAID implementation is capable of delivering the performance of hardware RAID today. That is very good news for anyone on a budget.
RAID arrays may escape becoming commodities. They may simply become irrelevant."
Den hära snubben ovan pratar mycket om lagringslösningar, och pratar om ZFS ibland i några få artiklar. Han pratar mycket om NetApp, EMC, Hitachi och andra lagringsföretag. Han verkar alltså inte vara en ZFS fanboy (som jag), det är mycket sällan han rekommenderar ZFS, utan han pratar hellre NetApp, EMC och dom där. Han jobbar med såna system. Inte med ZFS. Men han försöker hålla sig ajour med vad som händer på lagringsmarknaden och försöker se trender.
Jag kanske är lite inskränkt och läser bara det jag vill läsa, men jag tycker snarare det verkar som att din artikel snarare stödjer min tes än din tes? Dvs att mjukvaruraid skalar bra uppåt, och att ett hw-raid kort inte skalar uppåt? Och att mjukvaruraid kan ge bra prestanda samt är flexibelt. Är inte dessa saker exakt samma saker som jag räknat upp hela tiden? Eller missförstår jag din länk, eller missförstår jag dig? Spanning är samma sak som mjukvaruraid? Eller?
Känns som om du faller i "inskränkt" kategorin här tyvärr. XelCore är ett mjukvarulager PÅ hårdvara. Det är även, om Broadcom får säga det själv, den enda produkten på marknaden, men ingalunda den första.
Och eftersom man kan spänna över flera slots, så tydligen ger den möjligheten högre prestanda, mer än ett enda hw-raid kort:
Eh, ja, det är ju själva poängen med att gå till fler kortplatser. Högre bandbredd. Istället för fyra PCI-E kanaler, kan du glatt köra 32st, via 2 16x kortplatser. Vid det laget har du andra problem än bandbredd, även om du begränsar dig till 24 diskar / kortplats. Du ska ju lyckas skicka det till mottagaren med.
Ok, coolt. Det visste jag inte att hw-raid kort kunde klara av. Men detta verkar inte så vanligt idag längre? Från din länk:
"In fact, the Broadcom XelCore RAID software is the only product available from a major storage vendor that does support spanning."
Även om det är flera som stödjer det idag, så verkar det inte vara vanligt?
Nä, rimligtvis har de flesta resonerat som LSI. När du kan hänga på över 24diskar på en kontroller är inte spanning över flera kort speciellt åtråvärt längre. Som jag nämnde nyss, du ska ju lyckas leverera till användaren med.
Ska man vara riktigt petig så skriver du gång på gång ut i klartext varför du inte förstår.
Dvs att mjukvaruraid skalar bra uppåt, och att ett hw-raid kort inte skalar uppåt?
Ett ensamt kort skalar givetvis inte utanför den bandbredd kortet har tillgång till, lika lite som de separata kontrollerna för mjukvaruRAIDen gör det. Ska du jämföra bör man ju rimligtvis jämföra lika frukter. Om du väljer att köra 4 billiga x4 PCI-E kontrollers mot en (mycket) dyrare x16 RAID kontroller får du ett rimligare men klart dyrare resultat. Tvivlar på att det finns speciellt många icke hårdvaruRAID x16 kontroller kort, och det finns nog få x4 hårdvaruRAID kontrollers som stödjer spanning, så det blir sannolikt aldrig "riktigt" rättvist, någon kommer alltid ha en fördel. Självklart går det att köra ett x16 RAIDkort med diskarna som individuella drives, men då försvinner fördelen med mjukvaruRAIDen helt, kostnadsbesparingen, och du åker på att hantera mer värme, trots den extra kostnaden i hårdvara från början.
B!
Allting jag skriver är om inget annat uttrycks, min åsikt! Ingenting måste vara dagens sanning enligt din åsikt, och gör du antaganden baserade på mina åsikter hoppas jag att du övervägt mer än bara just min åsikt.
Känns som om du faller i "inskränkt" kategorin här tyvärr.
Mycket möjligt.
XelCore är ett mjukvarulager PÅ hårdvara. Det är även, om Broadcom får säga det själv, den enda produkten på marknaden, men ingalunda den första.
Så du klassar inte XelCores lösning som mjukvaruraid? Jag menar, för att kunna spanna över flera hw-raid kort så måste du ha mjukvara som så att säga, inte är bundet till ett hw-raid kort. Mjukvaran måste se alla hw-raid kort och koordinera alla dem så de lirar ihop väl. Så det är alltså nån mjukvaruraid helt enkelt, precis som Linux mdadm(?), BTRFS, ZFS, etc. Dessa lösningar kontrollerar alla disk kontroller korten och mjukvaran styr över dem. Vad är det för skillnad?
I XelCores lösning, vem kör själva mjukvaran? Är det alla hw-raid korten var för sig som kör mjukvaran separat dvs distribuerad lösning, eller är det själva datorns cpu som kör mjukvaran som sen koordinerar mellan dem? Är det distribuerat och alla cpuer kör liten bit av koden, eller är det en cpu som bestämmer? Om det är cpun som kör - så måste det väl klassas som mjukvaruraid?
EDIT; kan man se utifrån denna bild, om mjukvaran är distribuerad och körs separat på varje hw-raidkort, eller om det är datorns cpu som koordinerar mellan alla korten?
http://www.tomshardware.com/reviews/sata-spells-trouble-scsi-...
Så du klassar inte XelCores lösning som mjukvaruraid?
Du försöker sparka in en vidöppen dörr.
I grund och botten skulle jag tro (gissning) att det handlar om drivrutinsbaserad spanning över flera kontrollers. Det ger alltså exakt samma nackdelar för varje kort, som du får för de individuella diskarna i en ren mjukvaruRAID. Det ger x gånger mer waste med mjukvaruRAID än hårdvaru, där x står för antalet diskar / kontroller.
Jag har alltså redan sagt att jag TROR att det rör sig om en drivrutins-styrd mjukvaruRAID för att få ut det på flera kontrollers, där sedan kontrollern tar över det individuella arbetet på hårdvarunivå. Jag passade samtidigt på att förklara varför, och "hur mycket" "bättre" den lösningen är en en ren mjukvaruRAID. Jag vet att det fungerade så att man konfigurerade en RAID-array på det primära kortet, och sen tog det över därifrån, då någon gång på Pentium tiden. Det indikerar ju att man i alla fall då lät kortets BIOShook ta över båda kortens konfigurering. Den RAID-array man fick var för övrigt bootbar. Inte att rekommendera, men trots allt. Att jag inte vet hur senare lösningar fungerat har sin grund i att jag helt enkelt inte haft incitament att leka med den typen hårdvara för egna pengar. Jag kan köpa en rätt rolig MTB för vad ett bättre RAID-kort kostar.
Se klippet på Youtube-infon, och återkom, så vi har något konkret att tala om. I realiteten är skillnaden i overhead insignifikant om vi snackar om få diskar, vs en kontroller, men när man pratar om fullt befolkade kort, med mängder av diskar blir det fort ohållbart att köra det på CPU. I deras scenario om 10 diskar indelat på 5 hårdvaruspeglade par, har vi bara 5x overhead, men kan samtidigt accessa alla 5 enheter samtidigt, vilket man tydligen inte kunde tidigare, om det sen var drivrutin, eller OS begränsning... Fan vet.
B!
Edit
EDIT; kan man se utifrån denna bild, om mjukvaran är distribuerad och körs separat på varje hw-raidkort, eller om det är datorns cpu som koordinerar mellan alla korten?
Jag vet inte riktigt vilken bild du syftar på, men det den reviewn kommer fram till är att broadcom/highpoint RAIDkorten som är mjukvaru/fakeRAID har sämst prestanda. Kanske inte så förvånande när de får slåss mot kort med 128MB cache, och själva kommer utan.
B!
Allting jag skriver är om inget annat uttrycks, min åsikt! Ingenting måste vara dagens sanning enligt din åsikt, och gör du antaganden baserade på mina åsikter hoppas jag att du övervägt mer än bara just min åsikt.
Se klippet på Youtube-infon, och återkom, så vi har något konkret att tala om.
Nu har jag sett klippet. Youtube hade en ren hw-raid lösning på 10 diskar som gav dem prestandaproblem. Istället konfade de om sina 10 diskar så att det blev 5 mirrors. Sen körde de Linux mjukvaruraid ovanpå de 5 mirrors och fick 20-30% bättre prestanda.
Som jag tolkar det, så använder de hw-raid numera, endast för att skapa mirrors så att de ökar tillförlitligheten: om en disk kraschar så gör det inget. De sade inget om att de spände över flera hw-raid kort med mjukvaruraidet, vad jag kunde höra. Om de hade spänt över flera hw-raid kort så borde prestandan ökats, precis som XelCore visade.
Då är frågan, varför gav mjukvaruraidet högre prestanda i detta fall? Vad tror du? Varför inte bara köra hw-raid?
Jag har alltså redan sagt att jag TROR att det rör sig om en drivrutins-styrd mjukvaruRAID för att få ut det på flera kontrollers, där sedan kontrollern tar över det individuella arbetet på hårdvarunivå. Jag passade samtidigt på att förklara varför, och "hur mycket" "bättre" den lösningen är en en ren mjukvaruRAID.
Jag ser ärligt talat inte vidare stor skillnad mot ren mjukvaruraid, som styr över flera kontrollers. Jfrt med en mjukvaruraid som styr över flera hw-raid kort. Båda tycker jag borde klassas som mjukvaruraid. Sen är det en annan sak hur intelligent själva diskkontrollern är, mycket intelligent som i hw-raid, eller en dum kontroller som mjukvaruraid.
I realiteten är skillnaden i overhead insignifikant om vi snackar om få diskar, vs en kontroller, men när man pratar om fullt befolkade kort, med mängder av diskar blir det fort ohållbart att köra det på CPU.
Det här var intressant. Du menar att cpuer inte klarar av mängder av diskar. Jag vet att ZFS suger massa kraft, eftersom den hela tiden bl.a. beräknar fletcher/SHA-256 checksummor så fort du gör något, och t.ex. SHA-256 är inte billigt att göra. Men du verkar mena att med endast ett gäng cpuer, så kommer man till en gräns där det tar stopp. Men att med hw-raid så fortsätter man förbi den gränsen och vidare uppåt? Jag menar ju nämligen helt tvärtom; att en cpu klarar av högre last än ett hw-raid kort.
För att göra en liknelse, om vi istället pratar kryptering. Visst är kryptering på hw snabbare än att göra det på cpun idag. Kanske kan man kryptera 10GB/sek i hw och 1GB/sek i mjukvara på cpun. Och 1GB/sek räcker nog inte idag till olika tillämpningar, eftersom det även blir för hög last på cpun som inte kan göra nåt annat. I framtiden kommer cpuerna att bli snabbare. Nån gång kommer man kunna kryptera 10GB/sek utan större besvär och om det då räcker för de flesta tillämpningar (det kommer alltid finnas special tillämpningar som kräver ännu mera) så då ser jag inte varför man ska köpa dedikerad hw som krypterar 100GB/sek? Om du får ut tillräckliga prestanda genom att köra i mjukvara så varför köpa dedikerad hw? Visst, om du måste få ut max prestanda så måste du ha dedikerade optimerade system, men om du inte måste ha det?
http://www.tomshardware.com/us/sponsored/Seagate-Drive-Based-...
En annan liknelse: om du kan köra fysikberäkningar på cpun tillräckligt snabbt, varför köpa dedikerad fysik processor idag? Visst är fysikprocessorn snabbare och effektivare. Men om du får 180fps med dedikerad fysikprocessor, och du får ut 150fps utan - så räcker 150fps till för de flesta personer. Om prestandan räcker till, varför envisas med att köpa dedikerad hw - med enda motiveringen att "ja, det blir effektivare, du sparar 38 klock cykler". Vad spelar 38 cykler för roll, när 150fps räcker till? Visst, är du ett gamingproffs så måste du väl ha väl ha maxad hårdvara, men om det räcker med 150fps - varför köpa dedikerad hw?
Jag tycker inte jag fått bra svar på ovanstående liknelser. Återigen frågar jag: vad spelar det för roll om dedikerad hw ger dig lite mera prestanda - om prestandan räcker till när du kör i mjukvara?
Nu har jag sett klippet. Youtube hade en ren hw-raid lösning på 10 diskar som gav dem prestandaproblem. Istället konfade de om sina 10 diskar så att det blev 5 mirrors. Sen körde de Linux mjukvaruraid ovanpå de 5 mirrors och fick 20-30% bättre prestanda.
Exakt. Problemet de hade med sin ursprungliga lösning var begränsat till att deras applikation stod och väntade på svar istället för att fortsätta jobba. Det hade alltså inget med RAIDkonfigurationen att göra, utan hur mjukvaran hanterade sina accesser. Det är så klart korkad design, och kan vara Linux OS'etts fel, drivrutinen till RAIDen's fel, eller deras mjukvaras fel. Det sista går nästan att utesluta eftersom problemet försvann när man konfigurerade om systemet, och de två kvarstående alternativen brydde de sig inte om att undersöka, de hade hittat en fungerande work around, och gick vidare. Min gissning ligger på en halvkass drivrutinsimplementering.
Som jag tolkar det, så använder de hw-raid numera, endast för att skapa mirrors så att de ökar tillförlitligheten: om en disk kraschar så gör det inget.
Eftersom de inte specificerar vilken kontroller de kör på, och vilka funktioner som är aktiverade, så är det svårt att uttala sig om. Jag hade dock förutsatt att de kör med synkroniserade spindlar, och därför kan läsa två olika filer från det speglade paret samtidigt. (Den disken som hittar rätt data först får läsa dem, den andra disken får en ny läsorder om andra data. Det ger både lägre söktid, och ökad tillgänglighet.
De sade inget om att de spände över flera hw-raid kort med mjukvaruraidet, vad jag kunde höra.
Nä, deras setup rymmer bara 10 diskar enligt exemplet, så de har ingen anledning att köra på flera kort.
Då är frågan, varför gav mjukvaruraidet högre prestanda i detta fall? Vad tror du? Varför inte bara köra hw-raid?
Han säger det i klippet. Av okänd anledning står mjukvaran och väntar på data efter varje request, istället för att fortsätta och fylla bandbredden. När de låter mjukvaruRAIDen stå för att göra en volym av det hela kringår de den problematiken. Om det sen är för att de lurar OS'ett att tro att det är 5 individuella diskar, eller om det är för att drivrutinen som flaskhalsar luras att tro att det är 5 enheter... Fritt val. Den informationen har vi inte.
Jag ser ärligt talat inte vidare stor skillnad mot ren mjukvaruraid, som styr över flera kontrollers. Jfrt med en mjukvaruraid som styr över flera hw-raid kort. Båda tycker jag borde klassas som mjukvaruraid. Sen är det en annan sak hur intelligent själva diskkontrollern är, mycket intelligent som i hw-raid, eller en dum kontroller som mjukvaruraid.
Skillnaden är att CPU'n ser möjligen de olika RAIDkorten som separata diskar. Alla paritetsberäkningar och dyligt ligger fortfarande på kontrollern. Jag måste fråga, har du över huvudtaget funderat på hur en RAID-array arbetar? Vid läsning går mjukvaruRAIDen ut till varje disk, med alokeringsdata, och får informationen om vad som finns i det fysiska utrymmet som efterfrågats, i tur och ordning, allt eftersom man bygger ihop filen. Med hårdvaruRAIDen går det lite annorlunda till väga, man ber helt enkelt RAID kontrollern utföra jobbet. Det gör att man inte belastar moderkortets bandbredd med varje data request till varje disk. Man skickar en, till kontrollern, och låtsas sen som om det regnar, tills den svarar med (förhoppningsvis) de data man ville ha tag på. Om du stockar en burk full med SATA kort för att köra en mjukvaruRAID på, och stoppar i ett RAIDkort med plats för 24 diskar, så får du alltså 24 gånger så mycket kommunikation mellan diskar och processor med mjukvaruRAIDen som med hårdvaran. Detta faktum kvarstår, även om du väljer att använda hårdvaruRAIDkortet som en stendum disk kontroller och kör mjukvaruRAID över den.
Det här var intressant. Du menar att cpuer inte klarar av mängder av diskar. Jag vet att ZFS suger massa kraft, eftersom den hela tiden bl.a. beräknar fletcher/SHA-256 checksummor så fort du gör något, och t.ex. SHA-256 är inte billigt att göra. Men du verkar mena att med endast ett gäng cpuer, så kommer man till en gräns där det tar stopp. Men att med hw-raid så fortsätter man förbi den gränsen och vidare uppåt? Jag menar ju nämligen helt tvärtom; att en cpu klarar av högre last än ett hw-raid kort.
Läs ovan. Det är inte CPU'n som tar slut, det är tillgänglig bandbredd för att kommunicera med diskarna, som tar slut. I teorin finns det inget som hindrar dig från att köra mjukvaruraid på 4x uh, ska vi säga 24 diskar, med 4 st x16 PCI-E kontroller kort Det är 96 diskar, för en ganska hemtrevlig fil-area. (nu skulle ingen bygga så, men för argumentets skull) För att hämta EN fil som är spannad över alla diskarna på mjukvaruRAIDen måste CPU'n ha tag i varje disk, individuellt. Även om kontrollerkorten som styr en fjärdedel av diskarna hela tiden är de samma, så måste CPU'n kommunicera varje gång. 96 gånger, som minimum. Med en spannad hårdvarulösning måste CPU'n göra 4 kommunikationer. Resten tar hårdvarukontrollrarna hand om. Den här trafiken förbrukar bandbredd du annars kunde använt till att skicka data med. Du skapar alltså trafik som när du skalar upp gör det ineffektivt.
För att göra en liknelse, om vi istället pratar kryptering. Visst är kryptering på hw snabbare än att göra det på cpun idag. Kanske kan man kryptera 10GB/sek i hw och 1GB/sek i mjukvara på cpun. Och 1GB/sek räcker nog inte idag till olika tillämpningar, eftersom det även blir för hög last på cpun som inte kan göra nåt annat. I framtiden kommer cpuerna att bli snabbare. Nån gång kommer man kunna kryptera 10GB/sek utan större besvär och om det då räcker för de flesta tillämpningar (det kommer alltid finnas special tillämpningar som kräver ännu mera) så då ser jag inte varför man ska köpa dedikerad hw som krypterar 100GB/sek? Om du får ut tillräckliga prestanda genom att köra i mjukvara så varför köpa dedikerad hw? Visst, om du måste få ut max prestanda så måste du ha dedikerade optimerade system, men om du inte måste ha det?
http://www.tomshardware.com/us/sponsored/Seagate-Drive-Based-...
liknelsen haltar, eftersom vi pratar om att serva användare med ett visst mått av data. Redan från början ligger man på x antal system. Är en lösning då 25% långsammare, måste man investera i 25% mer hårdvara. För behov där man varken räknar med ökade krav på prestanda, eller att man någonsin kommer nyttja all prestanda är det inte ett problem. Med andra ord, för hemma bruk fungerar ditt sätt att tänka, och för att få befintlig hårdvara att fungera som avsett, när det inte är de fysiska begränsningarna som bromsar en, så går det. Jag skulle inte räkna med att Youtube speccade sin nästa inköpsrunda i enlighet med att "vi ska köra mjukvaruRAID", utan deras primära önskemål har sannolikt varit att hårdvaruleverantören ska se till så att problemet de hade första rundan inte är ett återkommande.
En annan liknelse: om du kan köra fysikberäkningar på cpun tillräckligt snabbt, varför köpa dedikerad fysik processor idag? Visst är fysikprocessorn snabbare och effektivare. Men om du får 180fps med dedikerad fysikprocessor, och du får ut 150fps utan - så räcker 150fps till för de flesta personer. Om prestandan räcker till, varför envisas med att köpa dedikerad hw - med enda motiveringen att "ja, det blir effektivare, du sparar 38 klock cykler". Vad spelar 38 cykler för roll, när 150fps räcker till? Visst, är du ett gamingproffs så måste du väl ha väl ha maxad hårdvara, men om det räcker med 150fps - varför köpa dedikerad hw?
Ingen har sagt att du ska harva hemma med dedikerad hårdvara... Grejen är att det finns inget "tillräckligt" med hårdvara, kraven växer hela tiden. Det du kan göra är att se till så att den nya hårdvaran ger dig så mycket utrymme som möjligt att växa i. I en industrimiljö är det kritiskt.
I hela din argumentation gör du för övrigt fortfarande fel i det att du enbart ser till funktionen, utan att ta hänsyn till resan dit. Det spelar ingen roll om det är grafik, kryptering, eller paritetsberäkningar. En dedikerad enhet som är specialiserad på "just det" är effektivare. Då menar jag inte snabbare, utan för exakt samma resultat förbrukar den mindre energi. Energin avräknas direkt i form av elräkningen, men även värmen som ska hanteras. Det är inte riktigt lika enkelt som här hemma, där man bara öppnar balkongdörren, och sätter sig med kvasten i handen för att hålla isbjörnarna på avstånd. Visst, det finns datacenter som "säljer" sin överskottsvärme till fjärrvärmeverk, men de flesta får betala dyrt för att bli av med värmen. Den krassa verkligheten är att dagens hårdvara är mycket effektivare än mjukvaran, helt enkelt för att hårdvaran som kör mjukvaran inte är tillräckligt "generellt specialiserad" för att kunna utföra samma beräkningar på ett effektivt sätt. Konceptet GPGPU är i rätt riktning, men kanske inte för mjukvaruRAID's.
B!
Allting jag skriver är om inget annat uttrycks, min åsikt! Ingenting måste vara dagens sanning enligt din åsikt, och gör du antaganden baserade på mina åsikter hoppas jag att du övervägt mer än bara just min åsikt.
[QUOTE=saddam;11451283
En annan liknelse: om du kan köra fysikberäkningar på cpun tillräckligt snabbt, varför köpa dedikerad fysik processor idag? Visst är fysikprocessorn snabbare och effektivare. Men om du får 180fps med dedikerad fysikprocessor, och du får ut 150fps utan - så räcker 150fps till för de flesta personer. Om prestandan räcker till, varför envisas med att köpa dedikerad hw - med enda motiveringen att "ja, det blir effektivare, du sparar 38 klock cykler". Vad spelar 38 cykler för roll, när 150fps räcker till? Visst, är du ett gamingproffs så måste du väl ha väl ha maxad hårdvara, men om det räcker med 150fps - varför köpa dedikerad hw?
Jag tycker inte jag fått bra svar på ovanstående liknelser. Återigen frågar jag: vad spelar det för roll om dedikerad hw ger dig lite mera prestanda - om prestandan räcker till när du kör i mjukvara?[/QUOTE]
Om man har hårdvara som är tillräckligt snabb och varken vill eller behöver ha mer så är det nog ingen som säger att man *ska* köpa mer.
Men när millisekunder (experiment av stora ehandlare visar att köp ökar markant när ens webbsida är snabbare) faktiskt spelar en stor roll och den investering man behöver göra för denna understiger det man tjänar så tar man till det som krävs. Och eftersom vi snackar HW-RAID vilket faktiskt kan anses som SEMI-PRO+ och inte något som P12 funderar på att köpa så börjar trådan halta rejält.
Om man har hårdvara som är tillräckligt snabb och varken vill eller behöver ha mer så är det nog ingen som säger att man *ska* köpa mer.
Ok, bra. Vi verkar överens här. Om prestandan räcker till, så är det onödigt med dedikerade lösningar.
Men när millisekunder (experiment av stora ehandlare visar att köp ökar markant när ens webbsida är snabbare) faktiskt spelar en stor roll och den investering man behöver göra för denna understiger det man tjänar så tar man till det som krävs. Och eftersom vi snackar HW-RAID vilket faktiskt kan anses som SEMI-PRO+ och inte något som P12 funderar på att köpa så börjar trådan halta rejält.
Jag håller med om att ibland finns det problem som kräver extrema lösningar, och då får man ta till det som behövs. Men jag menar även att mjukvaruraid skalar uppåt så bra, att även det kan man ta till när man behöver extrema lösningar. T.ex. denna ZFS server från Oracle. Den har 576st diskar, väljer man 2TB diskar så får man 1.15Petabyte lagring. Med massiv I/O därtill. Det får väl ändå anses som en proffslösning, tycker jag.
http://www.oracle.com/us/products/servers-storage/storage/nas...
Det vore lite coolt att försöka replikera ZFS servern med 576st diskar. Undrar hur man skulle göra det? Det står att den har 24st rack med 24 diskar i varje. Det är en 42U lösning. Är det då 24st sas expanders? Det står att det är fyra st hex-core cpuer "per controller" vad menas med det? Undrar vad det är för skillnad mot NetApps stora lagringslösning, är det hw-raid däri?
http://www.oracle.com/us/products/servers-storage/sun-zfs-sto...
Eftersom de inte specificerar vilken kontroller de kör på, och vilka funktioner som är aktiverade, så är det svårt att uttala sig om. Jag hade dock förutsatt att de kör med synkroniserade spindlar, och därför kan läsa två olika filer från det speglade paret samtidigt. (Den disken som hittar rätt data först får läsa dem, den andra disken får en ny läsorder om andra data. Det ger både lägre söktid, och ökad tillgänglighet.
Men det verkar som att hw-raid endast skapade massa speglingar, och sen använde man mjukvaruraid för att koordinera mellan dem. Som XelCores spann lösning, typ.
Läs ovan. Det är inte CPU'n som tar slut, det är tillgänglig bandbredd för att kommunicera med diskarna, som tar slut. I teorin finns det inget som hindrar dig från att köra mjukvaruraid på 4x uh, ska vi säga 24 diskar, med 4 st x16 PCI-E kontroller kort Det är 96 diskar, för en ganska hemtrevlig fil-area. (nu skulle ingen bygga så, men för argumentets skull) För att hämta EN fil som är spannad över alla diskarna på mjukvaruRAIDen måste CPU'n ha tag i varje disk, individuellt. Även om kontrollerkorten som styr en fjärdedel av diskarna hela tiden är de samma, så måste CPU'n kommunicera varje gång. 96 gånger, som minimum. Med en spannad hårdvarulösning måste CPU'n göra 4 kommunikationer. Resten tar hårdvarukontrollrarna hand om. Den här trafiken förbrukar bandbredd du annars kunde använt till att skicka data med. Du skapar alltså trafik som när du skalar upp gör det ineffektivt.
Du verkar mena att bandbredden tar slut om man använder mjukvaruraid. Vad får dig att tro det? Dagens system klarar fett mycket bandbredd. Det gjorde de inte för ett tag sen, då var det inget snack: hw-raid var snabbare. Men jag tror ju att dagens system har I/O nog att klara av ett gäng diskar. Du verkar mena tvärtom? Har du länkar eller en förklaring till varför inte dagens system skulle hinna med ett gäng diskar? Självklart blir det ineffektivare än hw-raid och mer overhead, men det finns kraft så det räcker och blir över. Det är inget problem. Jag menar att mjukvaruraid skalar uppåt mycket bra, eftersom overheaden är så liten.
Förresten, GPFS och Lustre och Googles egna filsystem - alla skalar till många många PetaByte med extrem I/O - kan inte alla dessa räknas som mjukvaruraid? Är nån insatt och vet mer?
Ingen har sagt att du ska harva hemma med dedikerad hårdvara... Grejen är att det finns inget "tillräckligt" med hårdvara, kraven växer hela tiden. Det du kan göra är att se till så att den nya hårdvaran ger dig så mycket utrymme som möjligt att växa i. I en industrimiljö är det kritiskt.
Jag vill påstå att mjukvaruraid skalar uppåt mycket väl. Se länken ovan.
I hela din argumentation gör du för övrigt fortfarande fel i det att du enbart ser till funktionen, utan att ta hänsyn till resan dit. Det spelar ingen roll om det är grafik, kryptering, eller paritetsberäkningar. En dedikerad enhet som är specialiserad på "just det" är effektivare. Då menar jag inte snabbare, utan för exakt samma resultat förbrukar den mindre energi. Energin avräknas direkt i form av elräkningen, men även värmen som ska hanteras. Det är inte riktigt lika enkelt som här hemma, där man bara öppnar balkongdörren, och sätter sig med kvasten i handen för att hålla isbjörnarna på avstånd. Visst, det finns datacenter som "säljer" sin överskottsvärme till fjärrvärmeverk, men de flesta får betala dyrt för att bli av med värmen. Den krassa verkligheten är att dagens hårdvara är mycket effektivare än mjukvaran, helt enkelt för att hårdvaran som kör mjukvaran inte är tillräckligt "generellt specialiserad" för att kunna utföra samma beräkningar på ett effektivt sätt. Konceptet GPGPU är i rätt riktning, men kanske inte för mjukvaruRAID's.
B!
Jag har aldrig bestridit att ett optimerat system är effektivare än ett generellt system. Det jag bestrider är, när det generella systemet utvecklats så långt att det ger tillräckliga prestanda, så anser jag att man kan skrota det optimerade systemet. Om båda ger tillräckliga prestanda för dagligt bruk, så behövs inte en dedikerad lösning.
Om jag får välja mellan att bygga en 4U server med dubbla cpuer och 96GB RAM att virtualisera på, eller att ha 10st mindre servrar - så väljer jag den generella lösningen som ger lite sämre prestanda än en dedikerad server. Detta gäller förutsatt att den generalla lösningen ger tillräckliga prestanda för ens behov. Om jag måste nå en prestanda av 100, och om den generella lösningen ger 100, och om den dedikerade lösningen ger 150 - så spelar det ingen roll för mig. Nyckelordet är tillräckliga prestanda. Om det uppnås så spelar det ingen roll vem som gör det; en generellt system eller ett dedikerat system. Visst är det dedikerade lite effektivare, men är det värt den extra effektiviteten att ha massa olika system som gör en sak bra?
Sen finns det förstås speciella krav, ibland måste man nå 150 i prestanda och då duger inte den generella lösningen. Men det är sällan man ser extrema krav. Som en tumregel anser jag att en generell lösning som ger tillräckliga prestanda är överlägsen en specialiserad lösning som är effektivare. Här ser vi att QualComm verkar resonera liknande sätt, om en surfplatta är lika spelvänlig och har lika bra prestanda som en konsol, så har en specialiserad konsol inget existensberättigande.
http://www.nordichardware.se/nyheter/99-apple/43803-qualcomm-...
På samma sätt ger nu mjukvaruraid tillräckliga prestanda för att tävla mot hw-raid. Visst är hw-raid effektivare, men so what?
Jag tror att mjukvaruraid är framtiden och dedikerade lösningar har spelat ut sin roll snart. Mjukvaruraid kan idag leverera mycket bra prestanda, och skalar uppåt mycket väl. Jag tror även att lagringssystem med checksummor är viktiga, för sånt tänkte man inte på tidigare.
Jag förstår om folk tror att hw-raid är här för att stanna. Jag tror annorlunda. Kanske ska vi sluta här. Vi kommer inte längre. Jag upprepar samma argument "visst blir det overhead, so what?" och ni upprepar samma argument "ja det blir mer overhead med mjukvaruraid". Det känns som vi kommit in i en återvändsgränd där samma saker ältas gång på gång, och inget nytt sägs. Ni har hört mig, och jag har hört er. Ingen av oss ändrar ståndpunkt, tydligen. Då vet vi det, och får nöja oss så? "Vi är överens, om att vi är oense"
Förresten, GPFS och Lustre och Googles egna filsystem - alla skalar till många många PetaByte med extrem I/O - kan inte alla dessa räknas som mjukvaruraid? Är nån insatt och vet mer?
Dessa klustrade "filsystem" är lite andra saker. Här uppnår man hög IO och tillgänglighet genom att ha datan på en *massa* olika servrar. Vissa har masters som håller reda på vart datan är sparad och man kan ställa in hur pass hög redundansen ska vara och VAR den ska vara. Var i form av vilket kluster, vilket rack eller vilket DC. Dock så är det inte ett filsystem som går ner på blocknivå utan många av dessa är OS-filsystemagnostisk.
Dock så är det inte ett filsystem som går ner på blocknivå utan många av dessa är OS-filsystemagnostisk.
Ja just det, ja, det kan du ha helt rätt i. Det var ju prat om att Lustre skulle börja använda ZFS som filsystem, just pga bit röta. Flera av superdatorerna på top500 använder ju Lustre och lagrar stora datamängder. När man lagrar så stora datamängder så kommer bitröta uppstå förr eller senare:
http://www.solarisday.de/downloads/storageserver0609nau.pdf
Men Oracle är inte vidare intresserade av HPC marknaden så Oracle har nog lagt ned det projektet. SUN var intresserade, men inte Oracle.
Dessa klustrade "filsystem" är lite andra saker. Här uppnår man hög IO och tillgänglighet genom att ha datan på en *massa* olika servrar. Vissa har masters som håller reda på vart datan är sparad och man kan ställa in hur pass hög redundansen ska vara och VAR den ska vara. Var i form av vilket kluster, vilket rack eller vilket DC. Dock så är det inte ett filsystem som går ner på blocknivå utan många av dessa är OS-filsystemagnostisk.
Jasså är det så de är uppbyggda. Coolt! Tack för informationen.
- Dagens fynd — Diskussionstråden55k
- AMD marknadsför Ryzen X3D-processorer med 1 000 FPS52
- Frågor om bolån? Hit me!6,5k
- Snabbkoll: Kyler du processorn med luft eller vatten?90
- IPv6 dual wan, bara ett interface åt gången funkar3
- Köpa nya datorer till heltidare på studentnation i Uppsala1
- Rabbel.se - Ett dagligt ordspel2,6k
- AI-boom kan ge högre pris på konsument-SSD:er1
- Webbläsaren uppdaterar inte jämnt1
- Vilka av alla gratisspel man fått från Epic är värd ens tid?24
- Köpes ddr4 2133mhz 32gb
- Skänkes GTX 660 TI
- Säljes Noctua NH-D15G2
- Köpes Någon med 3d skrivare till hands?
- Säljes Steam Deck OLED 512gb + 512gb minneskort
- Köpes Blu-ray brännare
- Säljes ASUS RTX 2070 8GB ROG STRIX GAMING OC
- Säljes Samsung Odessy 27" G7 VA-panel 1440p 240Hz
- Säljes MSI 4060 Gaming X 8gb
- Säljes Asus RT-AC3200
- AI-boom kan ge högre pris på konsument-SSD:er1
- Stor uppdatering av Xbox-appen i Windows21
- Cougar släpper ”svävande” chassi23
- AMD marknadsför Ryzen X3D-processorer med 1 000 FPS52
- OLED-skärm på DDR5-minne visar hastighet och temperatur36
- Snabbkoll: Kyler du processorn med luft eller vatten?90
- Passivt kylt chassi väger in på 21,5 kilo36
- 5080 och 5090 Founders Edition är fortsatt i produktion32
- Kommentar: 184 dagar sedan den senaste incidenten19
- Nytt utpressningsprogram kringgår Secure Boot34
Externa nyheter
Spelnyheter från FZ
- Topp 100 med värme i bröstet och spykänsla i munnen idag
- Ubisoft-anställd om jättespelet Assassin's Creed Valhalla: "Ett monster" idag
- Battlefield 6-bekymmer på Xbox Series S gjorde i slutändan "hela spelet bättre" idag
- Ryktesdags! Marveltajm! Wolverine släpps 2026 – Venom på gång därefter? igår
- Squadron 42 kan missa 2026: "Jag vet inte om vi kommer klara det" igår