Svarar utifrån ZFS generellt då jag inte testat proxmox. Ja, utan att fråga vad du har för CPU så kan jag instämma i att det är snurrdiskarna och inget annat som är problemet. Om lagringsbehovet endast är 1Tb så borde det inte bli snordyrt att byta ut diskarna mot t.ex. 2x 1Tb SATA-ssd.
Ang:
Skrivet av DoDaN:
[...] skulle detta kunna avhjälpas av tex 4st ssd i en zfs raidz2?
Det finns få scenarier där 4st ssd i raidz2 är att föredra över 4st ssd i en pool av 2x 2-vägs mirrors. Förvisso klarar raidz2 att vilka 2 enheter som helst rasar, medan 2x2 mirrors klarar att tappa en i varje spegel (men inte båda). Men raidz2 belastar cpu mer och gör det svårare att optimera utrymmet, pga halvkomplexa mekanismer som beskrivs här: https://www.delphix.com/blog/delphix-engineering/zfs-raidz-st... - med mirrors blir allt enklare och du vinner prestanda främst vid läsning. "Space efficiency" (mängd data du kan lagra per Tb diskutrymme) är i teorin densamma i dessa två scenarier, men blir i praktiken något sämre med raidz2 pga. mekanismerna som beskrivs i länken. Sen har vi också fenomenet write amplification som ofta blir värre med raidz.
Citat:
Och sista frågan, då Google säger lite olika. Är det någon idé att prova vanliga konsument sata ssd eller kommer de ”skrivas sönder” direkt?
Det beror mycket på vad dina VMs gör. Jag körde under ett par år en gaming-VM med Windows 10 på en zpool bestående av en ensam 1Tb Samsung 860evo. TBW drog inte iväg nämnvärt, detta var med ashift=12 och zvols med volblocksize=16k om jag minns rätt (förklarar inställningarna strax, och rekommenderar numera högre ashift). Men då skrev den inte så mycket i dagligt användande.
Resten är utifrån teori, enligt min bästa förståelse av att ha läst mig in, och inte min så mkt egen testning:
TL;DR: zpools bestående av ssd:er bör, för bästa livstid, skapas med ashift = minst 12, gärna 13.
Något som är viktigt att ha koll på är orsakerna till write amplification - dvs. när skrivningar sker i mindre chunks än minsta adresserbara storlek som stöds av lagren under. Principen är att om jag skriver 4k, men disken som tar emot skrivningen bara kan adressera 8k i taget, ja då måste den läsa in 8k, modifiera 4k av dessa, och skriva ut alla 8k = 2x write amplification. Med zfs kan detta ske på flera nivåer, t.ex. mellan NTFS i VM och den underliggande zvol (eller fil i ett dataset) som den ligger på, eller (och det är värre) mellan zfs och den underliggande hårdvaran. Det sista är inte mätbart med zfs-verktyg (t.ex. 'zpool iostat') eftersom det sker internt i SSD:n.
Det största problemet här, särskilt med konsument-ssd:er, är att de ofta ljuger om hur stora "chunks" av data disken kan adressera åt gången, dvs. deras interna blockstorlek. Moderna ssd:er adresserar i regel minst 4k bytes som minsta enhet, ofta 8k eller mer. Detta dokumenteras inte av tillverkarna, samtidigt som diskarna av kompatibilitetsskäl kommunicerar att de kan adressera betydligt mindre enheter, ibland så smått som 512 bytes. Om man skriver 512b till en disk som egentligen addresserar 8k, då måste den läsa in 8k, ändra 512b, och skriva ut 8k =16x write amplification! I praktiken är detta inte så farligt som det låter för vanliga filsystem när de ligger direkt på disken. T.ex. NTFS och ext4 skriver alltid i chunks om minst 4k, och aggregerar skrivningar i större chunks. Så om ssd:n har en intern blockstorlek på 8k, så kommer alla skrivningar <=8k att leda till write amplification, men det blir i praktiken bara ett problem för små filer. Större filer delas upp i betydligt större chunks än 8k när de skrivs ut till disk.
Men för ZFS blir det annorlunda. ZFS försöker optimera allt utifrån diskens kommunicerade interna blockstorlek - det som konsumentdiskarna normalt ljuger om. Om disken säger att dess blockstorlek är 512b, så kommer ZFS att försöka optimera allt till 512b skrivningar. Det leder till write amplification även för skrivningar av betydligt större mängder data (jag har inte exakt koll på mekanismerna här och om detta gäller för alla skrivningar, men det är så jag förstått det). Lösningen på detta är att override:a ZFS gissning om diskens layout, och det görs med ashift - en inställning som bara kan göras då en ny zpool skapas ('zpool create -o ashift=...'). Det står för "alignment shift" och bestämmer vilken minsta blockstorlek ZFS kommer att jobba med, enligt formeln (blockstorlek i bytes) = 2^ashift. Då har vi att 512b motsvarar ashift=9, 4k <=> ashift=12, 8k <=> ashift = 13. Vill man veta vilken ashift en existerande zpool har, så framgår det av 'zdb | grep ashift'.
Det är som sagt odokumenterat för de flesta SSD:er hur de fungerar internt. Men någon slags konsensus på nätet verkar vara att den faktiska blockstorleken för moderna diskar är minst 4k, för Samsung ska den vara 8k. Men har ingen säker källa på detta, detta kommer delvis av folks spekulationer. Fördelen är att det är relativt liten förlust att ha för stor ashift, jämfört med för liten. Därför är den generella rekommendationen att mycket write amplification kan avhjälpas med ashift=13, evt. räcker det med ashift=12. Men aldrig ashift=9 dvs 512b, har man en zpool av ssd:er med ashift=9 så bör man bygga om den.
När man väl har valt en vettig ashift så har det viss betydelse hur man organiserar lagringen för sina VMs. ZFS har som du kanske vet också en egen blockstorlek som bestämmer hur läsning, skrivning och checksummor organiseras, den kallas 'recordsize' för datasets, och 'volblocksize' för zvols. Oavsett om man lagrar sina VMs på zvols eller i filer (qcow2 eller raw) på datasets så kommer denna parameter att spela in, då den bestämmer hur stora skrivningar som tas emot av lagret ovanför, dvs. filsystemet i VM. Här är det frestande (utifrån resonemangen om write amplification) att sätta den till samma som blockstorleken enligt ashift, men det är inte rekommenderat, för då tappar man fördelar med t.ex. ZFS inbyggda komprimering. För liten volblocksize/recordsize leder också till mer metadata, vilket också leder till fler extra skrivningar! Här kan det vara värt att tänka på sin workload, hur stora skrivningar väntar jag mig normalt i min VM? Det brukar ofta rekommenderas att optimera för det.
En åldrande men bra och concis guide är denna: https://jrs-s.net/2018/08/17/zfs-tuning-cheat-sheet/
Också värt att tänka på att zfs komprimering opererar "mellan" volblock/recordsize å ena sidan, och blockstorleken enligt ashift å andra sidan. Ingen skrivning kan komprimeras till mindre än 8k på en drive med 8k sektorer (ashift=13). Säg att du har volblocksize=16k vilket är default för zvol:s, då kommer ett 16k block att komprimeras till ett 8k block bara om komprimeringsgraden är 50%, vilket den sällan är. Det kan vara skäl att öka volblocksize för en zvol ovanpå en pool av 8k-diskar.
Tänker man på allt ovanstående och optimerar någorlunda därefter (ffa ashift, det är den enda parametern som är verkligt kritisk), då klarar man sig i min förståelse långt på konsument-ssd:er för ZFS, i vart fall för "konsument"-workloads. Med det sagt så går det också att hitta relativt billiga begagnade enterprise-ssder med rejäl livstid kvar, särskilt i storleksordningen 480Gb < 1Tb. Vet säljaren vad de pysslar med så brukar de kommunicera TBW och smart-värden.
En sista sak att tänka på med konsument-ssd:er är Power-Loss Protection (PLP). Det handlar om att SSDer kan, beroende på kontroller, ha ett fönster där de kan bekräfta skrivningar (till OS) innan data skrivits ut från DRAM-cache till flash. Tappar man strömmen vid fel tillfälle för dessa diskar, så tappar man data, och får kanske ett inkonsistent filsystem. Det går inte att lita på sin mirror här, eftersom alla diskar i en maskin kan drabbas samtidigt. UPS hjälper en bit här, men inte t.ex. mot en fallerande PSU. Dokumentationen för ZFS on Linux går igenom det, och har en lista på ssd:er som antas vara säkra: https://openzfs.github.io/openzfs-docs/Performance%20and%20Tu...
I den länken kan man också läsa:
Citat:
Discussion of power failures bricking NAND flash SSDs appears to have vanished from literature following the year 2015.
Men det är värt att hålla koll på, särskilt om man shoppar äldre enheter. Jag har också sett exempel i närtid på när båda (relativt nya men billiga) diskarna i en raid1-spegel dör samtidigt, vilket i detta fall tycks ha berott på en power-spike pga. dåligt elnät eller psu: https://forum.level1techs.com/t/anyone-else-having-failure-is...
Så även om SDD och ZFS i all väsentlighet är säkert så har SSD:er, särskilt billigare, lite knepigheter som inte HDD har. En tanke om du prövar med en SSD-pool men är osäker på hur säker den är jämfört med HDD, är att behålla din HDD-mirror i maskinen, och göra täta backuper från SSD till HDD-poolen. T.ex. en snapshot 1 gång i timmen, den mängden läsning bör inte påverka din prestanda nämnvärt förutsatt att du gör inkrementella backups.
