Önskar hjälp med förbättra "disk-konfigurationen" på min server för bättre prestanda

Verkar som att du kan köra en SSD cache till din lagringsvolym.
Det borde ju snabba upp saker och ting rejält.

Du skriver inte vad för typ av raid du kör, men jag skulle gissa att det är LVM eller mdraid?
Kör du LVM så kan du använda en cache device för både läs och skriv, tänk bara på att om du använder en (1) disk som skriv-cache så tappar du det som inte hunnit flushas till backing disk ännu. https://wiki.archlinux.org/title/LVM#Cache
För mdraid kan du kolla på bcache, men jag hade övervägt att konvertera bort från md till något annat. LVM och mdraid kör idag samma kod för RAID, så finns inga nackdelar med att köra LVM över mdraid.
Själv kör jag BTRFS utan cache devices, även där är det bcache som gäller, men om jag skaffar cache devicer någon gång kommer jag också gå över till ZFS istället.

Läs #19064181 angående mina erfarenheter av bcache - kör inte writeback om du verkligen inte har behov av det och om det ändå görs - se till att det är väldigt välprovad SSD-märke/modell för jobbet - typ enterprise-version av SSD...

Med för BTRFS fungerande deduplicerinsprogrammet 'Bees' och Bcachade disken fylld med diskimages kommer man ganska snabbt se om använda SSD pallar trycket eller blir utkastad - kör i writethrough och writearound så blir du i alla fall inte av med filsystemet när SSD tackar för sig i testet - kraschen brukar ske inom 12-16 timmar deduplicering med SSD:n utkastad av OS för att den inte längre ger respons på minutnivåer (syns med dmesg) om den har TRIM-tabell/FTL-layer trubbel med många små accesser hela tiden...

Räkna med att du får göra en secure erase på SSD:n efteråt innan den visar sin forna jag när det gäller skriv och läsprestanda efter att den har kraschat i testet, fulla zerofill, fyllning med slumptal och användning av TRIM/discard på hela disken kan behövas göra i många omgångar innan knutarna i trim-tabellen/FTL-lagret har löst upp sig och man återfår fulla prestandan, vissa som Samsung 830 repar sig aldrig innan en secure erase är utförd...

En sak till, se till att bcache synkar sig med backenddisken med ganska täta intervaller - default gör den inte detta alls någonsin vilket i praktiken gör att all filsystemmetadata bara ligger på SSD och bara gamla bitar som inte accessat på mycket lång tid är utträngd och ligger ute på snurrdisken och vid SSD-krasch så är data på backenddisken inte räddningsbart om man har kört i writeback-mode.

För övrigt står det hos 'bees' hemsida numera att det kan fungerar illa med bcache pga. firmware-problem på själva använda SSD:erna av vissa modeller och tillverkare - men det kom långt efter jag själv upptäckte det...

Hur eller hur en SSD/NVMe som inte överlever testet med 'bees' är inget man vill ha som SSD i en bcache-lösning eller annan cachelösning ändå - för latenta fel som dyker upp när man minst behöver det vill man helst undvika...

Håll det enkelt men använd bra grejer, är mitt förslag.
Om du inte har behov av större mängder diskplats än vad som får plats på en ensam disk, kör en disk per volym istället för RAID och satsa på bra backup istället.

Helt rätt tänkt med SSD för VM-/containerändamål. Köper du en enterprise-SSD med power loss protection kan du köra vilket filsystem som helst på den; XFS eller EXT4 om du bara vill få ut rå prestanda; ZFS eller möjligen btrfs om du vill ha lite mer möjligheter på bekostnad av lite prestanda.
Om du verkligen vill köra RAID hemma är min personliga åsikt att rätt väg framåt är ett HBA-kort och ZFS för dina datadiskar. Innan du sätter ZFS i "produktion", läs på en del om att trimma in systemet för dina behov; särskilt med tanke på blockstorlek beroende av vad du använder varje filsystem till. Jim Salter på Ars Technica har en del nyttiga artiklar både där och på sin privata blogg.

Cachedisk på SSD är i min erfarenhet kontraproduktivt jämfört med att bara stoppa mer RAM i datorn: du har sannolikt inte hundratals eller tusentals användare som värmer upp din cache så du har större nytta än nackdel av den vid läsning, och du förvarar troligen inte skrivintensiva saker på mekanisk disk så du skulle ha nytta av skrivcache på SSD.

En RAID i en köpeNAS är oftast utformad att du kan ta ut den gamla trasiga disken och sätta in en ny - minst lika stor disk (och är rensad på MBR/UEFI-sektorer om det är redan använd disk) så startar synkningen automagiskt.

Bra och regelbunden backuprutin (med revision/generationsbackupper på helst mer än en lagringsställe/media-set så att man kan gå tillbaka några generationer om man tex. fått sin lagrings filer utbytta mot ransomware-krypterade dito) och inte krav på 24/7 upptid utan kan klara av till 1 dygns nedtid (för backupåterställning) så är det ofta en mer datasäker metod än en RAID.

Problemet med RAID är att många tror att det också är en backup och struntar i backuprutiner helt. - och en RAID skyddar inte mot ransomware eller användarfel[1] då katastrofen sker lika fort och nära synkront på båda diskarna samtidigt!.

[1] med BTRFS över RAID och tex. bakgrundsprogram som snapper som gör dagliga snapshot dolt och skrivskyddat (och utan att ta extra diskplats) så kan man förvisso ha en viss skydd mot ransomware - tex. Synology plus-modeller kan man får sådant om man slår på det - men hjälper inte om själva NAS:en blir kapad på root/admin-nivå vilket är det som hänt numera på de flesta stora köpeNAS-tillverkarna - alltså regelbunden backup på media som är urkopplad vid förvaring mellan backupperna behöver man ändå ha då och då för att det inte skall bli full dataförlust den dagen när angreppet sker...