Disk layout för Proxmox? Hög IO Delay

Permalänk
Medlem

Disk layout för Proxmox? Hög IO Delay

Hej!

Jag har idag en Fujitsu PRIMERGY TX100 S2, 16gb ram
Som snurrar med Proxmox 7.

Os ligger på en SSD med ext4

jag några VM som körs jämt, bla för Home Assistant, en Ubuntu Server som kör ett gäng Docker containers samt en ubuntu Server som kör Unifi Controllers.

Utöver detta har jag några som jag spinner upp vid labb.

Oftast funkar detta väldigt bra. VM ligger på 2st 1tb hdd som kör ZFS Mirror.

Dock får jag ibland super höga IO Delay och det blir lika snabbt som att sitta vid en gammal 486a. Speciellt om man spinner upp en Windows VM. Även när backuper körs sticker IO Delay iväg.

Ni som har erfarenhet av det här, är det datorn i sig som inte orkar mer eller skulle detta kunna avhjälpas av tex 4st ssd i en zfs raidz2?

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?

Permalänk
Medlem

Händer detta kanske efter att mekaniska diskarna har slutat surra? Det tar ett tag att starta upp motorn och börja läsa igen isf, så kallade spin up time. Resten går kanske snabb då det är cachat i minnen.

Hur länge varar laggen i värsta fall? Kan ju också handla om att en disk håller på att dö, trasiga sektorer o sånt gör ju att all I/O kan bli väldigt slö (tom när man kör mirror raid då kontrollern väntar ändå på disken) - när har du kollat SMART-värden sist?

Iallafall kan SSD hjälpa, kanske börja med en enda SATA som cache. Blir definitivt lite mer skrivandet på den då.

Visa signatur

Louqe Ghost S1 | Ryzen 5600X | 32 GB DDR4-3600 | Asus B550-I | RTX2080Ti FE | X34 (2016)

Permalänk
Medlem

Nu är det äldre diskar men inga varningar eller något som tyder på att det är när på att ge upp i SMART utläsningarna. Jag skulle säga att det om jag drar igång en Windows VM extra så är det slött tills jag stänger av den. Så tror inte det har med spinn upp tiden att göra.

Men är det någon ide att köpa några konsument ssd diskar eller är det lite att kasta pengarna i sjön om de ändå strax kommer vara sönder skrivna. google nämner allt i från några månader och uppåt. Men de nämner inte hur många VMs de har på de olika instanserna.

Permalänk
Sötast

Du skriver att OS ligger på ssd.
Vilket tänker du på? Hypervisorn?

Om de virtuella maskinerna ligger på HDD så är problemet direkt där.
I min mening är inte en mekanisk disk tillräckligt snabb för att ens köra ett OS, så att köra ännu fler, samt de applikationerna som körs på de olika VMerna tycker jag inte är konstigt om det går segt som sirap.

Du kan väl dra ut loggar på diskskrivningar över tid och jämföra det med TBW antal på de SSDer du tittar på.
Jag har en mix av både konsument och enterprise SSD och ingen har rasat än, inte ens cache diskarna för nasen...

En standard konsument disk kan ju lätt hålla i 10+ år på en gaming/workstation, så att sätta dem på en server som skriver lika mycket eller mindre lär ju ge liknande resultat.

Edit: Tydligen är write amplification ett reellt problem om man kör zfs. Annars bör det vara rätt lugnt.

Permalänk
Medlem

Var med om samma sak. Har en ganska "beafy" server ändå, men I/O delay var konstant högt - tills jag addade 2 VDEVs till (tot 3). Då började det ta fart. Så adda fler mirrored VDEVs så du får RAID 10. Enbart två diskar kommer man tyvärrinte långt med när det gäller ZFS.

Visa signatur

Citera för svar

- Stora Owncloud/Nextcloud-tråden: http://www.sweclockers.com/forum/122-server/1212245-officiell...
- Jobbar på: T&M Hansson IT AB https://www.hanssonit.se

Permalänk
Medlem

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.

Visa signatur

Här hade jag en historik sen 1990-talet, men den blev tillslut för lång. Aktiva maskiner 2022-framåt:
Work/Play/Everythingstation: AMD Epyc 7443p, Pop OS host, Win10 + Linux guests (KVM/Qemu)
Work/Play nr 2: AMD Phenom II 1090t, Debian + Win 10 (dual boot)
Server x3: Epyc 7252 (TrueNAS Core), Atom 2550 (FreeBSD, backup), Opteron 6140 (Ubuntu, off prem backup)
Retrohörna under uppbyggnad: Dual Pentium Pro 200MHz, Pentium P54C 90MHz, Gravis Ultrasound MAX

Permalänk
Medlem

Tack för all feedback! Super bra! Ska kolla igenom länkarna som nämnts och så med.

Permalänk
Medlem

Hej! Tänkte jag skulle återkoppla lite om någon annan söker efter denna info i framtiden.

Hade några diskar liggandes så provade att kör två VDEV med en spegel i varje. Detta gjorde stor skillnad, ska utvärdera detta ett tag. Annars blir det nog SSD framöver.

Permalänk
Medlem

Fint att du kunde lösa det så! Lade du till en vdev till den befintliga, eller tog du backup på allt och byggde om arrayen? (det senare kan vara lite bättre för prestanda, men det varierar hur stor roll det spelar)

En sak jag tänkte på efter mitt tidigare inlägg var att ashift spelar roll även för mekaniska diskar. Du bör ha ashift=12 för de allra flesta utom de mest antika HDD, för att undvika write amplification. WA påverkar inte livslängden på HDD samma sätt som på SSD, men det påverkar prestandan av samma skäl som jag beskriver ovan. Den märkbara prestandaskillnaden av ashift är större för HDD än för SSD i de flesta fall. Vet du vad du har för ashift, eller kan du kolla? (enklast är 'zpool get ashift <poolnamn>', eller om proxmox web-GUI listar det)

Om ashift=9 så kan det vara värt att bygga om arrayen med ashift=12, men om det känns aktuellt ska vi först kolla exakt vilka diskar du har, för säkherhets skull.

En annan sak som kan ställa till det för ZFS-prestanda är om diskarna har SMR-teknik. Sådana diskar har en intern blockstorlek som är så stor att ingen realistisk ashift hjälper, och dessa är därför inte rekommenderade för ZFS. Men jag tror att risken för det är liten med 1Tb-diskar, detta är mest en grej för större diskar.

Visa signatur

Här hade jag en historik sen 1990-talet, men den blev tillslut för lång. Aktiva maskiner 2022-framåt:
Work/Play/Everythingstation: AMD Epyc 7443p, Pop OS host, Win10 + Linux guests (KVM/Qemu)
Work/Play nr 2: AMD Phenom II 1090t, Debian + Win 10 (dual boot)
Server x3: Epyc 7252 (TrueNAS Core), Atom 2550 (FreeBSD, backup), Opteron 6140 (Ubuntu, off prem backup)
Retrohörna under uppbyggnad: Dual Pentium Pro 200MHz, Pentium P54C 90MHz, Gravis Ultrasound MAX

Permalänk
Medlem

Hej!

Skrotade hela poolen och började om och gjorde ny med ashift 12. Återskapade sedan VM från backups. Gick mycket smidigare än jag trodde. Var länge sedan jag kollade dessa diskar men de ska inte var SMR.