Permalänk
Medlem

RAID 5 filsystem

Hej,

Jag står framför att välja filsystem till en hårdvaru RAID5-array 3x1.5TB.
Jag kör Ubuntu karmic, datorn användas som kombinerad htpc/router/filserver, så diskarna kommer mest att användas till lagring av film samt nätverkslagring.

Min fråga är helt enkelt vilket filsystem som passar mig bäst i detta
fallet, ext3/ext4? Eller kanske XFS eller reiser?
Efter en hel del googlande känner jag mig nästan bara mer vilsen så tips på vad ni tror skulle passa bäst skulle verklien uppskattas!

Tack på förhand!
//Niklas

Permalänk
Medlem

Jag har en viss skepsis mot hårdvaru-RAID i allmänhet och RAID5 på bara tre diskar i synnerhet. Femman gör sig bäst på 4-6 diskar och mjukvaru-RAID är oftast lika snabbt och mindre känsligt mot moderkortsbyte t.ex.

Ext4 är väl vad som är populärt just nu, med bra resultat i bänktest och så. Själv kör jag XFS av gammal vana.

Visa signatur

Dator: C=64 med bandare och diskdrive.

Permalänk
Medlem

Vad är problemet med RAID5 på tre diskar?
Förutom att den relativa utrymmes-förlusten blir större ju färre diskar man har...

Ang SW/HW-raid så kan jag ju säga att jag gick in i detta lilla projekt med tron att HW-raid var överlägsen i prestanda, men så visar det sig ju inte vara när man läser om det... Lutar nog mot att det blir SW-raid...

Permalänk
Hedersmedlem

http://blogs.zdnet.com/storage/?p=162 - läs först.

Vill du ha datasäkerhet med så stora diskar så titta på ZFS, eller ha helt enkelt bra backuprutiner (vilket man _alltid_ ska ha, inga undantag) på de viktiga sakerna. RAID5 löser dock inte riktigt några problem med så stora diskar - man får bättre prestanda med andra metoder, och säkerheten är förrädisk. Problemet är inte att RAID5 är dåligt i sig, men det är inte gjort för att hantera dagens hårddiskstorlekar.

För datasäkerhet så är det smidigaste för tillfället för hemanvändare enligt mig att helt enkelt se till att man byter diskarna med jämna mellanrum (definitivt inom 3 år - finns en anledning till varför tillverkarna lämnar just den garantin) och håller backup på det viktiga. Efter tre år ökar felfrekvensen snabbt på diskar.

Visa signatur

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

Permalänk
Medlem

Hur kan du vara emot hårdvarruraid? Kanske på futtiga moderkorts kontrollrar med på en påkostad raidkontroller så finns det ingen mjukvara som tar det.

Visa signatur

Vad vore världen utan silvertejp?

Permalänk
Medlem

undvik mjukvaruraid om du kan. Inget går upp mot en vettig hårdvaru raid-controller.

Visa signatur

GUD VÄLSIGNE DIG!
Ryzen 7 5700X3D - 64Gb DDR4 - RTX2060 - Coolermaster Stacker
---------------------------- www.roaddogs.se ------------------------
------- Bofors Interstellar - A Star Citizen Corporation --------
---------------------------------- Twitch ---------------------------------

Permalänk
Avstängd

Angande sakerhet och ADAPTEC hardvaru raid, las denna lank
http://marc.info/?l=openbsd-misc&m=125783114503531&w=2
Det ar en kille som sagar ADAPTEC for Linux ordentligt.

En polare som ar IT chef for ett litet foretag berattade for mig om 2 ggr da de forlorat data pga buggar i bios pa hw raid. Jag sjalv foredrar mjukvaruraid, det gar snabbt att patcha om det ar buggar. Att slappa en BIOS ar mera meck. Helst ska ju mjukvaruraid koden vara open source ocksa, sa flera oberoende utvecklare kan patcha.

Hardvaruraid ar pa vag ut. Man kan gora allt det dar i mjukvara nu. Jag skulle salja mitt hw raid kort medan man far pengar for det, och kora mjukvaruraid. Sjalv kor jag ZFS och det ar trevligt och sakert.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av saddam
Angande sakerhet och ADAPTEC hardvaru raid, las denna lank
http://marc.info/?l=openbsd-misc&m=125783114503531&w=2
Det ar en kille som sagar ADAPTEC for Linux ordentligt.

En polare som ar IT chef for ett litet foretag berattade for mig om 2 ggr da de forlorat data pga buggar i bios pa hw raid. Jag sjalv foredrar mjukvaruraid, det gar snabbt att patcha om det ar buggar. Att slappa en BIOS ar mera meck. Helst ska ju mjukvaruraid koden vara open source ocksa, sa flera oberoende utvecklare kan patcha.

Hardvaruraid ar pa vag ut. Man kan gora allt det dar i mjukvara nu. Jag skulle salja mitt hw raid kort medan man far pengar for det, och kora mjukvaruraid. Sjalv kor jag ZFS och det ar trevligt och sakert.

Det där är bara BS.
Mjukvaruraid lämpar sig på vissa håll och visst, ZFS är trevligt, men det förutsätter att du har en miljö för det, tex Solaris.

Vad händer när du kör Linux eller Windows-server?

Personligen skulle jag säga tvärt om om vi talar om servermarknad. Mjukvaruraid är påväg ut. Allt fler och fler kör SAN eller andra nätverkslagringslösningar och du skippar lokal lagring så långt det går. FCoE och iSCSI har löst många problem med lagring och i SANen är det hårdvaruraid som gäller.
Tillsammans med den ökande virtualliseringen kommer också färre och färre 1:1-scenarion finnas där ett system ligger på en server.

Tittar du på dagens servermarknad säljs nästan alla servrar från Dell, Hp osv. med hårdvaruraid, och det är de facto standard att köra så.

Jag har tappat mycke data på Suns disklådor, men jag har faktiskt aldrig tappat data pågrund av bugg i hårdvaruraid på dells och hps raid-kontrollers. Jag driftar till vardags ca 500 servrar.
Någon gång har den tappat en disk i onödan dock.

Däremot på hemmabyggen har jag tappat massor av data på 3ware och adaptec. Men det skulle jag snarare skylla på bioset i moderkortet inte är kompatibelt med firmwaren på raid-kontrollern.

Permalänk
Avstängd

Sjävklart säljs alla Dell, HP, etc servrar med hårdvaruraid, eftersom de endast kör Linux/Windows. De servrar som kör Solaris säljs inte med hårdvaruraid. Där är det mjukvaruraid (ZFS) istället som tar andelar i enorm fart. Och ingen tvivlar väl på att SUNs lagringsservrar som kör ZFS inte räcker till stora serverhallar, de piskar ju allt på marknaden i termer av prestanda och pris och funktionalitet och säkerhet.

Min teori är alltså att småningom när BTRFS och andra ZFS liknande filsystem börjar sprida sig, så kommer hårdvaruraid spelat ut sin roll. Vad är hw raid egentligen? Det är lite mjukvara som körs på en dedikerad CPU. Vad skiljer det sig mot ZFS som kör mjukvara direkt på datorns CPU?

Skälet till att vi inte ser fler servrar från HP, Dell, etc som inte kör s/w raid, är för att de inte har tillgång till ZFS eller BTRFS, helt enkelt. När såna filsystem spridit sig, så kommer det sluta säljas h/w raid.

Det är precis som ljudkort, modem, grafikkort, etc - i början är det dedikerade kort, men i takt med att datorerna blir kraftfullare så kan man köra allt i mjukvara, all funk flyttar in i ren mjukvara. Och då dör de dedikerade h/w korten ut. Jag kommer ihåg emulator hw kort till Amiga, den hade en intel CPU för att köra Windows program. Nu kan man göra det i mjukvara, och man behöver inte special hw längre. Det är en trend som alltid varit. Och om Dell/HP/etc ligger efter och inte kör moderna lösningar som ZFS/BTRFS/Hammer/etc så är det deras problem.

Detta är min tes.

EDIT:
Har du läst om undersökningar på CERN? De kollar 3000 hw raid servrar och ser att det är massor med läs/skrivfel som aldrig rapporteras av hw raid kortet. Sysadmin får aldrig reda på att det är fel, eftersom kortet själv inte upptäckt det. Så frågan är hur mycket data du tappat, utan att vetat om det? Hw raidet vet inte att det blivit fel, hur ska du få då reda på det? Det går inte.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av saddam
Vad skiljer det sig mot ZFS som kör mjukvara direkt på datorns CPU?

Hårdvaru-RAID slukar inte CPU cykler, vilket är signifikant om man har 10+ diskar och en throughput på gigabyte/sec-nivå; speciellt om man kör raid-5/6.

Mjukvaru-RAID saknar dessutom skrivcache, alternativt att dess skrivcache inte är lika tillförlitlig som den hos hårdvaru-RAID. Om systemet crashar (i.e. BSOD/kernel panic) så ryker det som fanns i skrivcachen hos mjukvaru-RAID medan det är något helt separat hos hårdvaru-RAID. För att inte nämna vad som sker vid strömavbrott och om man inte har batteribackup (vilket man inte har för mjukvaru-RAID)...

De flesta problemen folk har med hårdvaru-RAID härstammar från att man försöker använda sig av så billiga kort som möjligt; kort som då saknar skrivcache, batteribackup och ibland till och med en inbyggd processor (d.v.s. att det egentligen är frågan om mjukvaru-RAID).

Visa signatur

"Nothing is impossible because impossible itself says I M Possible..."

Permalänk
Avstängd

Här pratas det om CERNs undersökning av massa hårdvaruraid rack. Det blir fel som man aldrig får reda på. På 1TB data med hårdvaruraid så finns det i genomsnitt 3 filer som är fel utan att någon vet det. Som sysadmin skulle jag vara concerned. Hur långt tillbaka har man backups?
http://storagemojo.com/2007/09/19/cerns-data-corruption-resea...

Citat:

Ursprungligen inskrivet av Weeblie
Hårdvaru-RAID slukar inte CPU cykler, vilket är signifikant om man har 10+ diskar och en throughput på gigabyte/sec-nivå; speciellt om man kör raid-5/6.

Dagens CPUer är mycket snabba och flerkärnade samt flertrådade. Så detta är inget problem ju snabbare CPUerna blir. Dessutom utvecklas mjukvarualgoritmerna, så t.ex. ZFS kräver endast lite mera CPU än andra filsystem, numera.

Citat:

Ursprungligen inskrivet av Weeblie
Mjukvaru-RAID saknar dessutom skrivcache, alternativt att dess skrivcache inte är lika tillförlitlig som den hos hårdvaru-RAID. Om systemet crashar (i.e. BSOD/kernel panic) så ryker det som fanns i skrivcachen hos mjukvaru-RAID medan det är något helt separat hos hårdvaru-RAID. För att inte nämna vad som sker vid strömavbrott och om man inte har batteribackup (vilket man inte har för mjukvaru-RAID)...

Skrivcache är ju ett problem som man måste ta höjd för. Därför slår ZFS av skrivcachen så detta är inte heller ett problem för en modern mjukvaruraid lösning.

Citat:

Ursprungligen inskrivet av Weeblie
De flesta problemen folk har med hårdvaru-RAID härstammar från att man försöker använda sig av så billiga kort som möjligt; kort som då saknar skrivcache, batteribackup och ibland till och med en inbyggd processor (d.v.s. att det egentligen är frågan om mjukvaru-RAID).

Möjligt. Jag tycker ändå att man ska kunna lita på de prylar man köpt. Adaptec är väl ändå hyfsade och inget B-märke? Man måste köpa dyrare prylar? Men var går gränsen? Är kort för 8000kr tillräckligt bra? Eller är det 10000kr? Eller räcker det med 5000kr? Eller, så sparar man in kostnaden och ovissheten för ett kort och kör mjukvaruraid? Därför anser jag att man ska sälja sitt hw raid nu, medan man får pengar för det och hoppa på mjukvaruraid tåget som strax går.

Men nog om hw raid vs mjukvaru raid nu. Du tycker som du vill, jag tycker jag som jag vill. Har man hittat en lösning som passar en bra, så fortsätt att köra det? Varför byta? Helt onödigt.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av saddam
Här pratas det om CERNs undersökning av massa hårdvaruraid rack. Det blir fel som man aldrig får reda på. På 1TB data med hårdvaruraid så finns det i genomsnitt 3 filer som är fel utan att någon vet det. Som sysadmin skulle jag vara concerned. Hur långt tillbaka har man backups?
http://storagemojo.com/2007/09/19/cerns-data-corruption-resea...

Jag känner till den undersökningen.

Citat:

Ursprungligen inskrivet av saddam
Dagens CPUer är mycket snabba och flerkärnade samt flertrådade. Så detta är inget problem ju snabbare CPUerna blir. Dessutom utvecklas mjukvarualgoritmerna, så t.ex. ZFS kräver endast lite mera CPU än andra filsystem, numera.

Du har fortfarande kvar faktumet att CPU cykler slukas.

Paritetsberäkning är inte gratis. För 9+ diskar, 64-bitars "ord" och RAID-5 så kan du räkna med 1 cykel per byte för enbart pariteten. Det motsvarar "1+ GHz" för "1+ gigabyte/sec"... under optimala förhållanden. Släng på overhead för sådant runt omkring och du får att ännu fler CPU-cykler slukas.

RAID-6 är ännu långsammare då paritetsräkningen inte längre är enbart att "XOR-a ihop några värden".

Citat:

Ursprungligen inskrivet av saddam
Skrivcache är ju ett problem som man måste ta höjd för. Därför slår ZFS av skrivcachen så detta är inte heller ett problem för en modern mjukvaruraid lösning.

ZFS slår inte av skrivcachen om ZFS får tillgång till hela disken.

Den gör endast det i andra fall endast p.g.a. integritetsskäl.

Dessutom är det inte riktigt skrivcachen på diskarna som jag pratar om här utan istället RAM-minnet som sitter på vanliga high-end RAID-kort.

Citat:

Ursprungligen inskrivet av saddam
Möjligt. Jag tycker ändå att man ska kunna lita på de prylar man köpt. Adaptec är väl ändå hyfsade och inget B-märke? Man måste köpa dyrare prylar? Men var går gränsen? Är kort för 8000kr tillräckligt bra? Eller är det 10000kr? Eller räcker det med 5000kr? Eller, så sparar man in kostnaden och ovissheten för ett kort och kör mjukvaruraid? Därför anser jag att man ska sälja sitt hw raid nu, medan man får pengar för det och hoppa på mjukvaruraid tåget som strax går.

Men nog om hw raid vs mjukvaru raid nu. Du tycker som du vill, jag tycker jag som jag vill. Har man hittat en lösning som passar en bra, så fortsätt att köra det? Varför byta? Helt onödigt.

Jag kör mjukvaru-RAID hemma just p.g.a. kostnaderna.

Men för ett medelstort till stort företag så spelar det sällan roll om korten kostar 1000 kr eller 10 000 kr.

ps. ZFS's största problem är att det bara finns till Solaris/BSD. BTRFS's största problem är att det inte är färdigt ännu. Mjukvaru-RAID är idag synonymt med "gammal klassisk RAID-5/6" för den absolut största målgruppen.

Visa signatur

"Nothing is impossible because impossible itself says I M Possible..."

Permalänk
Avstängd

Slår ZFS inte av skriv cachen? Intressant. Har du källa på det?

Jag bränner hellre lite cykler och har säkra data, än snabbt och osäkert.

I vilket fall som helst, så tror jag att hw raid är på väg ut. Och man gör allt i mjukvara, småningom. Vi får se vem som får rätt.

Permalänk
Medlem

@Himpon: Om jag hade haft den kravspec som du har skulle jag kört Linux med mjukvaruraid (mdadm) + lvm + ext4. Distribution väljs efter vad HTPC-mjukvaran trivs bäst med.

Just filsystemet är jag lite osäker på, men barnsjukdomarna i ext4 är väl borta nu?

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av saddam
Slår ZFS inte av skriv cachen? Intressant. Har du källa på det?

http://en.wikipedia.org/wiki/ZFS

"When entire disks are added to a ZFS pool, ZFS automatically enables their write cache. This is not done when ZFS only manages discrete slices of the disk, since it doesn't know if other slices are managed by non-write-cache safe filesystems, like UFS."

Bättre källor från Solaris/OpenSolaris kan hittas om så önskas.

Det är för övrigt inte så mycket som att ZFS stänger av skrivcachen som att ZFS inte automatiskt aktiverar den, om ZFS inte får tillgång till hela disken.

Citat:

Ursprungligen inskrivet av saddam
Jag bränner hellre lite cykler och har säkra data, än snabbt och osäkert.

Varken du eller jag är tyvärr representativ för "stora företag".

Citat:

Ursprungligen inskrivet av saddam
I vilket fall som helst, så tror jag att hw raid är på väg ut. Och man gör allt i mjukvara, småningom. Vi får se vem som får rätt.

Man får tro vad man vill.

Visa signatur

"Nothing is impossible because impossible itself says I M Possible..."

Permalänk
Avstängd

Tack för länken!

EDIT: Här är hårdvaruraid benchad mot ZFS på samma hårdvara. ZFS vinner i benchmarks:
http://storagemojo.com/2006/08/15/zfs-performance-versus-hard...
10% snabbare, lägre latency

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Fnorken
@Himpon: Om jag hade haft den kravspec som du har skulle jag kört Linux med mjukvaruraid (mdadm) + lvm + ext4. Distribution väljs efter vad HTPC-mjukvaran trivs bäst med.

Just filsystemet är jag lite osäker på, men barnsjukdomarna i ext4 är väl borta nu?

Vad vinner jag på att köra LVM i mitt fall, jag förstår inte riktigt poängen?

Jag har iaf dratt igång en SW-raid nu med ext3, mest för att prova och utvärdera, kommer nog göra om det (ev. ändra chunk size och prova ext4).
Hur som helst så tycker jag det verkar som att jag får massa diskaktivitet när jag inte borde ha det, vad kan det finnas för anledningar till detta?
Kan det bero på hur partitionen monteras, vad finns det för parametrar att tweaka?
Maskinen kommer vara idle stora delar av dygnet, är det någon idé att föröska få till spin-down för att spara energi/diskliv eller sliter det mer på diskarna än att vara igång kontinuerligt?

Permalänk
Avstängd

Som jag har förstått det, så är dyra Enterprise diskar konstruerade för att inte sättas på och av, hela tiden. De ska vara på 24/7. Medan vanliga konsument diskar är konstruerade för att sättas på och av, och de är inte meningen att de ska vara på 24/7.

Men jag kan ha fel, jag är osäker på detta.

Permalänk
Medlem

@Himpon: Snapshots och möjligheten att flera filsystem på din raid.

Permalänk
Medlem

Jag skulle köra en mjuk raid5:a med mdadm och ext3 eller xfs som filsystem, jag har ext3 på mina arrayer men det är mest för att jag valde det från början och det är ju inte direkt så att man bara kan byta hur som helst. xfs har den fördelen att du kan fsck:a och resize2fs:a och rebuild medans arrayen är mountad men det har väl hänt en gång att jag resizat när jag lagt på mer disk så den funktionaliteten har ju inte direkt varit saknad, gör man det över natten är det en non issue.

du ska ju inte lösa världens alla lagringsproblem här va så en enkelt raid5:a med ext3 är min rekomendation baserat på att jag aldrig haft några problem med den setupen själv. jag har bytt trasiga diskar men aldrig ett trasigt filsystem i min setup.

Visa signatur

Cisco - Linux - VMWare
-- Citera mig om ni vill få återkoppling --

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av saddam
Tack för länken!

EDIT: Här är hårdvaruraid benchad mot ZFS på samma hårdvara. ZFS vinner i benchmarks:
http://storagemojo.com/2006/08/15/zfs-performance-versus-hard...
10% snabbare, lägre latency

Kort och gott så har du att raidz stryper antalet IOPS till detsamma som till en enda disk istället som för vanlig RAID-5/6 där varje extra disk ökar antalet IOPS. Benchmarken testar inte det.

Enbart det faktumet gör att ZFS inte duger till servrar som är hårt pressad av "många I/Os" (t.ex. databaser).

ps. Vanlig mjukvaru-RAID har inte detta problem. Men vanlig mjukvaru-RAID har då inte heller raidz-s fördelar.

Visa signatur

"Nothing is impossible because impossible itself says I M Possible..."

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av Weeblie
Kort och gott så har du att raidz stryper antalet IOPS till detsamma som till en enda disk istället som för vanlig RAID-5/6 där varje extra disk ökar antalet IOPS. Benchmarken testar inte det.

Enbart det faktumet gör att ZFS inte duger till servrar som är hårt pressad av "många I/Os" (t.ex. databaser).

ps. Vanlig mjukvaru-RAID har inte detta problem. Men vanlig mjukvaru-RAID har då inte heller raidz-s fördelar.

Menar du att ZFS inte duger till databasarbete, pga att du tror att alla konfigurerar sitt ZFS raid så att databasarbete straffas? Är du seriös? Det är som jag säger; "En Dell PC funkar inte till databas arbete, eftersom sånt kräver 4GB RAM, och Dell PC levereras standard med 2GB RAM". Det är bara en fråga om konfiguration och hur du väljer att sätta upp ditt ZFS raid. Ett ZFS raid består av en eller flera grupper av diskar. En enda grupp begränsas av IOPS, men isåfall, adda flera grupper så går du runt det problemet. Ju fler grupper av diskar ditt ZFS raid består av, desto mera IOPS. Du kan få hur många IOPS du vill, med rätt konfiguration. Istället för en enda grupp med många diskar, skapa flera små grupper.

Du kanske inte heller hört talas om SUNs nya lagringsservrar som består av AMD opterons + RAM + ZFS körandes på vanliga 7200 RPM diskar + SSD? De uppnår 250.000 IOPS i extremfall, med extremt låga latencys (under ms) och piskar skiten ur allt. Detta är i sanning extrema värden. En vanlig SAS 15000rpm Enterprise disk uppnår... vad är det? 100 eller 200 IOPS?

Permalänk
Hedersmedlem
Citat:

Ursprungligen inskrivet av saddam
Tack för länken!

EDIT: Här är hårdvaruraid benchad mot ZFS på samma hårdvara. ZFS vinner i benchmarks:
http://storagemojo.com/2006/08/15/zfs-performance-versus-hard...
10% snabbare, lägre latency

Jag vet inte om ni snackar prestanda för företag eller hemmabruk nu, men den som kör JBOD på en kontroller för 5000+ kronor förtjänar en spark därbak. Sedan känns ju Ultra320-diskar väldigt gammaldags faktiskt.

Visa signatur

SWECLOCKERS.COM :: If Quake was done today ::
WS: Gigabyte Z690 UD DDR5 :: Core i5 12600K :: 32 GB RAM :: Geforce RTX 3060 Ti :: 10 GbE NIC :: AOC C32G1 32" :: Seagate FireCuda 530 1TB :: Deepcool Matrexx 55
NAS: SM X10-SLM-F :: Mellanox Connect2X SFP+ :: Intel XL710-QDA1 QSFP+

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av saddam
Menar du att ZFS inte duger till databasarbete, pga att du tror att alla konfigurerar sitt ZFS raid så att databasarbete straffas? Är du seriös? Det är som jag säger; "En Dell PC funkar inte till databas arbete, eftersom sånt kräver 4GB RAM, och Dell PC levereras standard med 2GB RAM". Det är bara en fråga om konfiguration och hur du väljer att sätta upp ditt ZFS raid. Ett ZFS raid består av en eller flera grupper av diskar. En enda grupp begränsas av IOPS, men isåfall, adda flera grupper så går du runt det problemet. Ju fler grupper av diskar ditt ZFS raid består av, desto mera IOPS. Du kan få hur många IOPS du vill, med rätt konfiguration. Istället för en enda grupp med många diskar, skapa flera små grupper.

Du kanske inte heller hört talas om SUNs nya lagringsservrar som består av AMD opterons + RAM + ZFS körandes på vanliga 7200 RPM diskar + SSD? De uppnår 250.000 IOPS i extremfall, med extremt låga latencys (under ms) och piskar skiten ur allt. Detta är i sanning extrema värden. En vanlig SAS 15000rpm Enterprise disk uppnår... vad är det? 100 eller 200 IOPS?

Tänkte bara bryta in lite här pågrund av ett stort problem med dessa lösningar med cache som Sun leker med. Oracledatabaser använder sig av Sync Write Calls som skriver genom cachen, tvingar all cache att tömmas för att få respons av disken att det verkligen skrivs. Detta är ett problem på ZFS då prestandan sjunker till extrema nivåner. Det finns work arounds så den inte behöver tvinga bort cache-flushen, men det krävs att man skriver om databasrutiner.

Att suns nya lagringsservrar ger fina IOPS pågrund av SSD-cachen, inte ZFS i sig.
Det är faktiskt så att Sun ofta talar om, i databassamanhang, att de kan numera nå upp i nivåer som UFS med hjälp av olika tuning-options. Men i normalfall så är det faktiskt långsammare. Men det går med mycke arbete att få en mer optimal lösning för databaser i många miljöer. Men det klassar jag inte direkt som någon superduper-lösning.

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av Sidde
Att suns nya lagringsservrar ger fina IOPS pågrund av SSD-cachen, inte ZFS i sig.

ZFS använder SSD som cache på ett finurligt sätt. Du bara addar den till zpool så är det klart. Hur gör andra lösningar? Jag menar alltså att ZFS tillåter dig utnyttja en cache på ett enkelt sätt. Och andra lösningar är antagligen meckiga eller väldigt meckiga. Mao, så är det ZFS som utnyttjar SSD på ett bra sätt, och därför är det ZFS som ger dig fina IOPS. Har du en dålig lösning så kan du få dåliga prestanda ur bra hårdvara. Men ZFS ger bra prestanda ur billiga 7200 rpm diskar.

Hur som helst, att SUNs nya lagringsservrar kan uppnå hysteriska IOPS var mest ett motargument till Weeblie som påstod att ZFS inte kan uppnå höga IOPS, och därför inte duger till t.ex. databaser. Vilket inte verkar stämma.

Ett annat problem som ZFS har, är att ZFS litar på att hårdvaran följer standarder. Vilket inte alltid sker med billiga diskar. Så ibland kan vissa billiga diskar säga till ZFS att de gjort något, men egentligen inte gjort det utan sätter igång med det nu. Då tror ZFS att det är klart och ger nya orders till disken. Och om strömmen går i ett sånt här läge så kan det bli problem.

Samma som t.ex. Linux implementation utav... NFS(?). Den följer inte standarden och uppvisar därför bra prestanda. Nu har SUN också införlivat det som en växel för att avvika standarden på samma sätt som Linux. Folk frågar varför SUNs lösning är långsammare. Vilket beror på att SUN följer standarden och det gör inte Linux.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av saddam
Menar du att ZFS inte duger till databasarbete, pga att du tror att alla konfigurerar sitt ZFS raid så att databasarbete straffas? Är du seriös? Det är som jag säger; "En Dell PC funkar inte till databas arbete, eftersom sånt kräver 4GB RAM, och Dell PC levereras standard med 2GB RAM".

Ja, din nämnda Dell PC kanske inte fungerar (bra) till databasarbete eftersom 2 GB RAM också är vad det är som maximalt kan installeras.

Citat:

Ursprungligen inskrivet av saddam
Det är bara en fråga om konfiguration och hur du väljer att sätta upp ditt ZFS raid. Ett ZFS raid består av en eller flera grupper av diskar. En enda grupp begränsas av IOPS, men isåfall, adda flera grupper så går du runt det problemet. Ju fler grupper av diskar ditt ZFS raid består av, desto mera IOPS. Du kan få hur många IOPS du vill, med rätt konfiguration. Istället för en enda grupp med många diskar, skapa flera små grupper.

1. Hur får du tillgång till alla dessa extra S-ATA/SAS portar? Ironiskt nog så blir svaret oftast "med hjälp av RAID-kort"...

2. Hur många diskar har du i varje raidz2-array? 8 (något runt det är det (max) rekommenderade antalet) Hur många arrayer per pool? 6? 48 diskar med samma antal IOPS som ungefär en vanlig 8 diskars RAID-6 array?

Att du stoppar in fler diskar gör inte din ZFS konfiguration snabbare än en motsvarande RAID-5/6 konfiguration. Rättvis jämförelse här ska vara i stil med raidz versus RAID 6+0 eller 5+0. ZFS ligger alltid efter i termer av IOPS (förutom när man som du säger använder sig av L2ARC och en SSD). Och det är negativt.

Citat:

Ursprungligen inskrivet av saddam
Hur som helst, att SUNs nya lagringsservrar kan uppnå hysteriska IOPS var mest ett motargument till Weeblie som påstod att ZFS inte kan uppnå höga IOPS, och därför inte duger till t.ex. databaser. Vilket inte verkar stämma.

250 000 IOPS är vad du får när du arbetar mot RAM-minnet/disk-cachar eftersom SLC diskar som Intels X25-E endast når c:a 5 000 IOPS (jämför med SAS-diskar som når runt 200 per styck).

ZFS's förmåga att använda RAM som cache är helt meningslöst i databassammanhang då man mer effektivt kunde ha givit databasservern minnet.

L2ARC är i sig mycket intressant men långt ifrån någon gåva från högre makter. Märk här att många databassystem klarar av att t.ex. placera nycklarna i en separat fil på en SSD och därmed får man även en kraftig prestandaboost med en vanlig hederlig UFS/XFS/EXT+RAID-5/6 kombination.

Visa signatur

"Nothing is impossible because impossible itself says I M Possible..."

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Himpon

Maskinen kommer vara idle stora delar av dygnet, är det någon idé att föröska få till spin-down för att spara energi/diskliv eller sliter det mer på diskarna än att vara igång kontinuerligt?

På min egen hemmaserver somnar mina diskar efter ett tag. Jag struntar i eventuellt extra slitage eftersom jag inte har tänkt att använda diskarna i all tid och evighet. Om jag får fem års felfri nytta av dem är jag nöjd. Får jag inte det så har jag åtminstone garanti på diskarna och får se om det lönade sig med raidz2/raid6.

Men mest troligt är att jag kommer jag uppgradera diskarna innan garantin har gått ut eller att dom går sönder. När man minst anar det är utrymmet fullt och absolut inget går att slänga...

Tråkigt att din tråd förstördes av en massa ZFS tjafs.

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av Fnorken
Tråkigt att din tråd förstördes av en massa ZFS tjafs.

Helt rätt och det får vi be om ursäkt för.

Weeblie, vi fortsätter i OpenSolaris tråden.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Himpon
Maskinen kommer vara idle stora delar av dygnet, är det någon idé att föröska få till spin-down för att spara energi/diskliv eller sliter det mer på diskarna än att vara igång kontinuerligt?

Energibiten är försumbar eftersom en disk drar några watt vid idle. Utöver det så kan jag inte styrka det här påståendet med någon egen upplevelse men spindown på diskar som du har i en raid skapad med mdadm kan falla ur, återigen jag kan inte svära på att det här stämmer nu men när jag satte upp mina arrayer för nåt år sedan så var det iaf på tapeten men det kan ha fixats.

Men egentligen så bottnar det väl i att du kommer inte spara nog med energi för att det ska vara värt att försöka köra ner dom i idlemode, det handlar om typ 3.5-6w eller nåt sånt beroende på disk, och slitningen på disken tenderar ju att bli större om du håller på och kör spindown på den för så fort något ska syncas kommer alla diskarna spinna upp igen. not worth it.

Visa signatur

Cisco - Linux - VMWare
-- Citera mig om ni vill få återkoppling --

Permalänk
Avstängd

Att spinna upp och ned mina raid diskar är ett problem för mig. Jag har istället gjort följande.

Jag har kopplat en enda strömbrytare till alla mina raiddiskar. Så kan jag slå på diskarna, eller stänga av dem när jag vill. Normalt är raid diskarna avstängda. Jag har även en stor systemdisk, 1.5TB. Till den tankar jag över allt möjligt från raidet och så fort jag kopierat över, så stänger jag ned raidet. Jag får boota om för att stänga av/sätta på raidet. Så jag har alltså min stora systemdisk som en cache. Och när jag behöver data från raidet, så sätter jag på det och tankar över. Eller kopierar data tillbaka till raidet för lagring. Eftersom systemdisken är så stor, 1.5TB, så behöver jag aldrig sätta på raidet. Det är påslaget typ några timmar per månad, eller så. Resten av tiden är det avstängt. Detta sparar ström, och förlänger livslängden på raid diskarna samt minskar risken att jag tappar raiddata pga jag skriver klantigt kommando, eller strömmen går, blixten slår ned, etc. Skulle man ha en mycket stor systemdisk, typ 6TB, så skulle raidet sällan behöva vara påslaget, typ nån timme per år - endast för att backuppa dina data. Jag jobbar med mina data på systemdisken och när allt är färdigt så backuppar jag det till raidet för permanent lagring. Så slipper jag fragmentering på raidet.

Detta funkar skitbra för mig och jag är toknöjd. Datorn är knäpptyst, eftersom jag har en green systemdisk och mina 8 st raiddiskar är ju aldrig påslagna. Rekommenderas om du bekymrar dig över strömåtgång, buller samt säkerhet