Unraid eller TrueNAS? (+Proxmox)

Permalänk
Medlem
Skrivet av diizzy:

Omständigt hur, det är som vilken annan NAS som helst?

Om jag har frösått det rätt, så du kan inte bara plugga in en ny HDD, utan du måste isåfall skapa en ny vdev som måste ha samma/mer antal hårddiskar (eller utrymme?) som den första vdev.

Permalänk
Medlem
Skrivet av cosmo_k:

Jag var i samma sits som dig för några år sedan och valde Unraid vilket jag har varit väldigt nöjd med hitils. Väldigt simpelt uppbyggt, grym community man kan använda om man har problem/frågor med snabba svar samt att det finns en community appstore med mycket trevliga appar. I grunden kör den Slackware vilket är bland den stabilaste Linux disten som finns, jag har 1140 dagar uptime på min Unraid server just nu och har inte haft något problem under den tiden.

Unraid är en mångsidig NAS med många olika funktioner utöver nas delen och det blir då svårt att vara 100% på allt, te.x så är hypervisorn väldigt simpel, den går absolut inte att jämföra med vmware eller proxmox men är helt okej om du inte ska köra mer avancerade VMs.
Docker delen har jag ingen större koll på hur avancerad den är då jag inte är spceciellt bevandrad i docker, jag kör 3-4st men det har funkat kanon hitils.

Ahh. Vilken RAID/filsystem kör du med?

Permalänk
Medlem
Skrivet av mambans:

Om jag har frösått det rätt, så du kan inte bara plugga in en ny HDD, utan du måste isåfall skapa en ny vdev som måste ha samma/mer antal hårddiskar (eller utrymme?) som den första vdev.

Jepp, verkligen inte som vilken NAS helst.

Det brukar rekommenderas att köra speglade diskar (dvs motsvarigheten till RAID-10) om man vill kunna utöka sin ZFS-pool. Då kan man alltid köpa till två nya hårddiskar i valfri storlek och lägga till poolen, eller byta ut två befintliga diskar mot större om man så önskar.

Det är folk som jobbat i åratal på kod som gör att man kan lägga till en disk till RAID-Z, men dels är den ännu inte officiellt mergad till ZFS, och dels görs det på ett lite "hackigt" sätt som gör att man inte får fullt lika mycket ytterligare utrymme som man kanske kan förvänta sig. (T ex 4x10 TB i RAID-Z2 ger 20 TB användbart utrymme. Fyller man det och lägger till en 10 TB disk kanske man förväntar sig 10 TB extra utrymme som man skulle få i RAID-6, men i själva verket får man bara 6 TB.)

Med det sagt så tycker jag ändå ZFS är guld. Men får verkligen ett lagringssystem man kan lita på! Det gäller bara att läsa på om begränsningarna så man vet att man kan leva med dem, och att testa lite innan man går "all in".

Permalänk
Medlem

Jag har hört att ZFS har börjat komma till Unraid, om man väljer ZFS i Unraid då får man väl också stor del av hastigheten som TrueNAS har?

Är där någon annan funktionalitet förutom ZFS (och enterprise saker) som man skulle vilja ha ifrån TrueNAS hemma?

Permalänk
Medlem
Skrivet av mambans:

Ahh. Vilken RAID/filsystem kör du med?

XFS. Men jag tror btrfs har kommit längre i utvecklingen nu så jag hade nog tittat på det om jag gjort om allt nu.

Permalänk
Medlem

@cosmo_k
Bortsett från att RAID5/6 fortfarande är trasigt så visst...
https://btrfs.readthedocs.io/en/latest/mkfs.btrfs.html#multip...

Permalänk
Medlem
Skrivet av diizzy:

@cosmo_k
Bortsett från att RAID5/6 fortfarande är trasigt så visst...
https://btrfs.readthedocs.io/en/latest/mkfs.btrfs.html#multip...

Nu använder Unraid varken raid 5 eller 6 så det spelar ingen roll. BTRFS har varit under utveckling i många år och jag vetefasen när dem tänkt att det ska komma en stabil version, jag har kört XFS i 20 år i olika servrar och har sällan stött på problem men det saknar vissa behändiga features som finns i btrfs.

Permalänk
Medlem
Skrivet av Allexz:

Ja, det är vad jag också hade gjort.
Men risken är dock att fler oläsbara sektorer kan påkommas under rsyncen på de "bra" diskarna eller att en av dem rentav rasar av att läsa 18TB data.

Det är över 10 år sedan som företagsvärlden slutade med Raid5 just för att det inte är tillräckligt pålitligt. Att köra en rsync och hoppas på att alla familjebilderna tagna de senaste 20 åren inte försvinner är en stressnivå ingen människa skall behöva gå igenom någonsin. Kör man backup offsite på samma gång (rekommenderas starkt!) så blir såklart stressnivån påtagligt mindre.... men så fort en disk i en raid5 går ner, då är det kritiskt läge och man står på kanten av klippan, stirrar mot sin död och hoppas att det går. Det är inte ett hälsosamt sätt att leva på

Behöver man läsa alla 18TB när man gör rsync så har man gjort fel. Man ska alltså rsynca mot den senaste backupen och då behöver man bara överföra det som ändrats sen sist man körde rsync. Förhoppningsvis har man kört backup någorlunda regelbundet och då är det inte så mycket data att överföra.

Givetvis bör man regelbundet köra tester mot diskarna för att se att de verkar OK. Vore ju tråkigt om backupen rasar när man gör restore.

Permalänk
Sötast
Skrivet av mambans:

Ah oke, beställde också en m2 SSD också innan jag visste att Unraid bara går att installera på USB, så då har jag ändå nytta av den till cache.
Men om jag kör vanlig RAID5 så kommer hastigheten vara lite bättre (med mindre säkerhet)?

Jag har också hört något om SMB (för network shares) att det kan vara väldigt långsamt, vet ni något om det? Hur långsamt isåfall?

Det är förmodligen bara med min windows dator (med m.2 SSD) via network shares som jag kommer uppnå serverns hårdiskarnas max hastighet och OM SMB hastigheten ligger runt samma som hårddiskarna då kommer inte någon hastighet jag får via vissa RAID's hjälpa mycket, stämmer det?

samtliga mjukvaror för nas har flera olika sätt att skyffla datan.
SMB / NFS är väl helt klart det vanligaste sättet att göra så på.

Jag körde NFS för nästan allt i unraid och kör nu istället nästan allt via SMB i OMW istället.
Gillar SMB mer, det tar lite längre tid att konfigurera men när allt är uppe så är det en mycket stark multi-user environment. Man loggar in som användare och man kommer åt exakt de filer man fått tillgång till och man kan t.ex tillåta vissa konton att endast läsa filer och andra skriva.

Prestandan har jag inte haft några problem med överhuvudtaget och den maxar alltid gbit, gbit å andra sidan är inte jättesnabbt När jag körde NFS så testade jag även att placera proxmox vm's direkt på filservern via nfs och det gick helt ok att köra dem där. Dock hade jag inga särskilt tunga laster och var mest för test.

Såvida du inte tänkt skriva till större databaser över nätverk så antar jag att smb/nfs räcker gott.

Skrivet av mambans:

Så ni har Unraid bara för lagringen (och proxmox), och sen helt annan dator för Plex? Hur kommer Plex åt hårddiskarna, network shares?
Vilken RAID kör ni på Unraid?

Angående den långsamma SMB, kommer inte de också påverka TrueNAS mm.., är det inte själva protokollet som är kast?
Har ni något automatisering för att spara senaste bilderna på SSD? Cache?

Finns många olika sätt att lösa sina problem och sålänge man inte stöter på större problem så är inget sämre än det andra per se. Du kan köra plex i en vm, eller docker eller hur du vill. Kör man linux i grund och botten så kan man montera shares som sökvägar direkt i OS.

Jag har kört både nextcloud och filerun under flera år och tycker själv att filerun är vinnaren när det kommer till filhantering. Har ett tiotal användare som synkar sina foton och videos via mobila klienter eller datorer till min nas.

Om du vill utföra synk via cache i unraid så föreslår jag att du kör 2st ssder i mirror, annars så är datan icke-redundant sålänge den ligger på ssd.

Det som skiljer är ju prestandan. Bara att göra tester och se om man når de mål man är nöjd med.

Skrivet av SAFA:

Behöver man läsa alla 18TB när man gör rsync så har man gjort fel. Man ska alltså rsynca mot den senaste backupen och då behöver man bara överföra det som ändrats sen sist man körde rsync. Förhoppningsvis har man kört backup någorlunda regelbundet och då är det inte så mycket data att överföra.

Givetvis bör man regelbundet köra tester mot diskarna för att se att de verkar OK. Vore ju tråkigt om backupen rasar när man gör restore.

Helt rätt har du här såklart. Jag kan säga att jag inte ens tänkte på på ett så positivt vis.
Jag är via arbetet nog mer eller mindre programmerad att alltid tänka wurst-case scenario och jag förutsätter väl aldrig att något funkat när det borde ^^

Permalänk
Medlem
Skrivet av mambans:

Så ni har Unraid bara för lagringen (och proxmox), och sen helt annan dator för Plex? Hur kommer Plex åt hårddiskarna, network shares?
Vilken RAID kör ni på Unraid?

Angående den långsamma SMB, kommer inte de också påverka TrueNAS mm.., är det inte själva protokollet som är kast?
Har ni något automatisering för att spara senaste bilderna på SSD? Cache?

Japp, exakt så. Plex kommer åt filerna med network shares, i Unraids fall disk share eller user share.

Unraid använder inte RAID, du kan lyssna här om hur det fungerar med Parity etc: https://www.youtube.com/watch?v=dX2PvD1qtKw

SMB per se är inte långsamt med Unraid, det är SMB i kombinationen med user shares och många små filer, bilder i mitt fall. När jag hanterar stora filer ser jag inget problem precis utan då är det vanliga problem som man har med mekaniska diskar.

Så protokollet kommer vara typ lika bra eller dåligt oavsett OS, men det finns edgecases som i mitt fall med bilderna där Unraids implementation i kombination med just user-shares fungerar dåligt.

Japp, den user-sharen för bilder har en cache-pool till sig så allting som är nytt kommer in dit först. Sen så har unraid en automatisering som kallas för "mover" vilket sen då flyttar filerna från cache till "storage". Mover kan du ställa in väldigt granulärt, eller så kör du manuellt, eller bygger egen automation.

Visa signatur

Computa: CPU: Intel 6850K Kylare: Nocuta NH-D15S RAM: 16GB 3000MHZ Grafikkort: GTX 1070x2 Nätagg: Corsair RM750X Mobo: MSI x99A Gaming Pro Carbon Lagring: SSD1 SanDisk Extreme II 240GB + SSD2(spel-disk) Kingston HyperX 240GB

Permalänk
Medlem
Skrivet av frekish:

Japp, exakt så. Plex kommer åt filerna med network shares, i Unraids fall disk share eller user share.

Unraid använder inte RAID, du kan lyssna här om hur det fungerar med Parity etc: https://www.youtube.com/watch?v=dX2PvD1qtKw

SMB per se är inte långsamt med Unraid, det är SMB i kombinationen med user shares och många små filer, bilder i mitt fall. När jag hanterar stora filer ser jag inget problem precis utan då är det vanliga problem som man har med mekaniska diskar.

Så protokollet kommer vara typ lika bra eller dåligt oavsett OS, men det finns edgecases som i mitt fall med bilderna där Unraids implementation i kombination med just user-shares fungerar dåligt.

Japp, den user-sharen för bilder har en cache-pool till sig så allting som är nytt kommer in dit först. Sen så har unraid en automatisering som kallas för "mover" vilket sen då flyttar filerna från cache till "storage". Mover kan du ställa in väldigt granulärt, eller så kör du manuellt, eller bygger egen automation.

Ah oke, har precis kollat igenom den videon och några till
Detta låter inte så dåligt, tack för infon och lättnaden.

Permalänk
Medlem
Skrivet av Allexz:

samtliga mjukvaror för nas har flera olika sätt att skyffla datan.
SMB / NFS är väl helt klart det vanligaste sättet att göra så på.

Jag körde NFS för nästan allt i unraid och kör nu istället nästan allt via SMB i OMW istället.
Gillar SMB mer, det tar lite längre tid att konfigurera men när allt är uppe så är det en mycket stark multi-user environment. Man loggar in som användare och man kommer åt exakt de filer man fått tillgång till och man kan t.ex tillåta vissa konton att endast läsa filer och andra skriva.

Prestandan har jag inte haft några problem med överhuvudtaget och den maxar alltid gbit, gbit å andra sidan är inte jättesnabbt När jag körde NFS så testade jag även att placera proxmox vm's direkt på filservern via nfs och det gick helt ok att köra dem där. Dock hade jag inga särskilt tunga laster och var mest för test.

Såvida du inte tänkt skriva till större databaser över nätverk så antar jag att smb/nfs räcker gott.

Finns många olika sätt att lösa sina problem och sålänge man inte stöter på större problem så är inget sämre än det andra per se. Du kan köra plex i en vm, eller docker eller hur du vill. Kör man linux i grund och botten så kan man montera shares som sökvägar direkt i OS.

Jag har kört både nextcloud och filerun under flera år och tycker själv att filerun är vinnaren när det kommer till filhantering. Har ett tiotal användare som synkar sina foton och videos via mobila klienter eller datorer till min nas.

Om du vill utföra synk via cache i unraid så föreslår jag att du kör 2st ssder i mirror, annars så är datan icke-redundant sålänge den ligger på ssd.

Det som skiljer är ju prestandan. Bara att göra tester och se om man når de mål man är nöjd med.

Helt rätt har du här såklart. Jag kan säga att jag inte ens tänkte på på ett så positivt vis.
Jag är via arbetet nog mer eller mindre programmerad att alltid tänka wurst-case scenario och jag förutsätter väl aldrig att något funkat när det borde ^^

Tusen tack för all hjälp!!
Kommer säkert läsa igenom detta igen sen när alla delar har kommit och det är dags att sätta upp allt.

Planen än så länge är att köra
- Unraid direkt med Unraid's egna RAID (1 parity)
- Och en m.2 Cache drive (kanske 2 i framtiden men datan är redan icke-redundant innan den kommer till servern).

- Börja med 3x18tb och sen när att data är överförd till server, flytta över de gamla 2x8tb till servern också.
- Kolla på någon typ extern/cloud backup med mindre lagring för t.ex. bilder/dokument. (har Dropbox på Windows för detta just nu).
- Ta en titt på FileRun.

Permalänk
Medlem
Skrivet av diizzy:

@cosmo_k
Bortsett från att RAID5/6 fortfarande är trasigt så visst...
https://btrfs.readthedocs.io/en/latest/mkfs.btrfs.html#multip...

Har kört dess RAID5 i flera år på 7 diskar inklusive 2 disk-haverier kort efter varandra och oplanerad strömavbrott och helt utan dataförluster - jag skulle säga att den vanligt använda mdadm-RAID använd i de flesta lite äldre NAS:ar innan LVM2 börja användas där är ett betydligt större problem, speciellt vid flera strömavbrott efter varandra på kort tid. Hur LVM2 hanterar strömavbrott är dock för mig okänt då jag inte har provat dessa personligen i NAS-sammanhang.

Men visst det finns några teoretiska corner-case i BTRFS med 'write hole' (som även mdadm-RAID och LVM2 också har då att hantera en skrivjournal är kostsamt - zfs har ju en egen hantering för just den biten) som inte är tillfredställande lappat, men största problemet är nog att ingen satt sin stämpel 'approved' och säger att koden är klar och så har det varit många år.

Kör man med 3-2-1 backupprincip och en RAID-haveri den dagen när den kommer inte svider så mycket så är faktiskt BTRFS RAID-hantering väldigt smidig då man själv kan bestämma RAID-mode när man känner för, inte beroende av att diskarna skall vara lika stora även när man kör RAID5/6 och att dessa kan ändras när som helst under drift inklusive att utöka med diskar eller ta bort diskar.

Kör man ZFS så måste man ha backuphantering då när den går trasig så är det inte mycket att rädda då det är väldigt dåligt med verktyg för att reparera dessa eller att extrahera filer ur den havererade setet (kan ha förbättrats med utvecklingen av ZFS för linux) - medans BTRFS har ett sådant verktyg redan 'by design' just för att rädda ut filer även om man inte kan rädda filsystemet till en fungerande igen. - man sa förr på ZFS att att man använder backuppen den dagen datasetet havererar - inget annat.

---

För min del är ZFS inte så intressant - den dagen när det implementerar 'reflink' (som det har frågats efter i ZFS öppna kod-del i > 10 år) som finns i 'orginal' ZFS:s senare kommersiella version, så kanske jag omvärderar då jag gillar verkligen inte ZFS:s farfar, far och son-hieraki när det gäller snapshot och kloner om man kommer från BTRFS-världen där allt sådan är helt oberoende av varandra och utan ordningsföljd-koppling - och med 'reflink' skulle man kunna få det hanterbart och mycket snabbare när det gäller att skapa kopia av dataset för att göra sig av med gamla dito när man vill bli av med de äldsta delarna i var set för att återvinna diskutrymme. (reflink = man gör en ny datahuvud/inod för den kopierade filen men låter den peka på samma datasektorer som originalet (gäller i BTRFS också för filens portion av metadatat också) - datan i filen behöver alltså inte kopieras med läsning och skrivning och ta upp ny diskplats när man kopierar med reflink - och i BTRFS går detta fort, väldigt fort även om filen man kopierar är 6 TB stor och man inte har 6 TB ledigt utrymme kvar på disken...)

Permalänk
Medlem
Skrivet av xxargs:

Har kört dess RAID5 i flera år på 7 diskar inklusive 2 disk-haverier kort efter varandra och oplanerad strömavbrott och helt utan dataförluster - jag skulle säga att den vanligt använda mdadm-RAID använd i de flesta lite äldre NAS:ar innan LVM2 börja användas där är ett betydligt större problem, speciellt vid flera strömavbrott efter varandra på kort tid. Hur LVM2 hanterar strömavbrott är dock för mig okänt då jag inte har provat dessa personligen i NAS-sammanhang.

Men visst det finns några teoretiska corner-case i BTRFS med 'write hole' (som även mdadm-RAID och LVM2 också har då att hantera en skrivjournal är kostsamt - zfs har ju en egen hantering för just den biten) som inte är tillfredställande lappat, men största problemet är nog att ingen satt sin stämpel 'approved' och säger att koden är klar och så har det varit många år.

Kör man med 3-2-1 backupprincip och en RAID-haveri den dagen när den kommer inte svider så mycket så är faktiskt BTRFS RAID-hantering väldigt smidig då man själv kan bestämma RAID-mode när man känner för, inte beroende av att diskarna skall vara lika stora även när man kör RAID5/6 och att dessa kan ändras när som helst under drift inklusive att utöka med diskar eller ta bort diskar.

Kör man ZFS så måste man ha backuphantering då när den går trasig så är det inte mycket att rädda då det är väldigt dåligt med verktyg för att reparera dessa eller att extrahera filer ur den havererade setet (kan ha förbättrats med utvecklingen av ZFS för linux) - medans BTRFS har ett sådant verktyg redan 'by design' just för att rädda ut filer även om man inte kan rädda filsystemet till en fungerande igen. - man sa förr på ZFS att att man använder backuppen den dagen datasetet havererar - inget annat.

---

För min del är ZFS inte så intressant - den dagen när det implementerar 'reflink' (som det har frågats efter i ZFS öppna kod-del i > 10 år) som finns i 'orginal' ZFS:s senare kommersiella version, så kanske jag omvärderar då jag gillar verkligen inte ZFS:s farfar, far och son-hieraki när det gäller snapshot och kloner om man kommer från BTRFS-världen där allt sådan är helt oberoende av varandra och utan ordningsföljd-koppling - och med 'reflink' skulle man kunna få det hanterbart och mycket snabbare när det gäller att skapa kopia av dataset för att göra sig av med gamla dito när man vill bli av med de äldsta delarna i var set för att återvinna diskutrymme. (reflink = man gör en ny datahuvud/inod för den kopierade filen men låter den peka på samma datasektorer som originalet (gäller i BTRFS också för filens portion av metadatat också) - datan i filen behöver alltså inte kopieras med läsning och skrivning och ta upp ny diskplats när man kopierar med reflink - och i BTRFS går detta fort, väldigt fort även om filen man kopierar är 6 TB stor och man inte har 6 TB ledigt utrymme kvar på disken...)

Vet inte om det är det du efterfrågar, men när man klonar ett snapshot av ett dataset inom samma pool fungerar det som du skrev, dvs ögonblickligen och utan att ta upp någon plats då det bara pekar bakåt till redan existerande data.
Vill du bara rensa gammal data är det ju bara att radera de äldsta snapshotsen.

Permalänk
Medlem
Skrivet av mambans:

Om jag har frösått det rätt, så du kan inte bara plugga in en ny HDD, utan du måste isåfall skapa en ny vdev som måste ha samma/mer antal hårddiskar (eller utrymme?) som den första vdev.

Nej, jag tror att du har blandat ihop det en aning.
Du kan inte utöka din vdev med fler diskar i efterhand. Men du kan skapa en ny vdev med nya diskar och den behöver inte se likadan ut som den första. Du kan även utöka utrymmet i din första vdev genom att byta ut diskarna mitt större. Dock måste alla diskarna bytas för att zfs ska implementera utökningen.

Kudos för att du skriver "omständligt" med L!

Permalänk
Medlem
Skrivet av guermantes:

Nej, jag tror att du har blandat ihop det en aning.
Du kan inte utöka din vdev med fler diskar i efterhand. Men du kan skapa en ny vdev med nya diskar och den behöver inte se likadan ut som den första. Du kan även utöka utrymmet i din första vdev genom att byta ut diskarna mitt större. Dock måste alla diskarna bytas för att zfs ska implementera utökningen.

Kudos för att du skriver "omständligt" med L!

Jag beskrev det kanske lite dåligt, menade en extra vdev med nya diskar.
Är där inga krav för den extra vdev:en?

Permalänk
Medlem
Skrivet av mambans:

Jag beskrev det kanske lite dåligt, menade en extra vdev med nya diskar.
Är där inga krav för den extra vdev:en?

99% säker på att du har full frihet att konfigurera vdev två. Kan ha annat antal diskar, av annan storlek, med annan zraid-nivå eller geometri. Men för den sista procenten, kolla med guruerna på truenas forumet.

Permalänk
Hedersmedlem

Ars Technicas ZFS-genomgång håller med om att en ny vdev kan se ut hur som helst.
https://arstechnica.com/information-technology/2020/05/zfs-10...

Men det är förstås viktigt att vara med på att om en vdev kraschar så kraschar hela zpoolen, så om man t ex lägger till en enstaka disk till en pool med en RAIDZ2-vdev så har man ingen redundans kvar överhuvudtaget.

Visa signatur

Asus ROG STRIX B550-F / Ryzen 5800X3D / 48 GB 3200 MHz CL14 / Asus TUF 3080 OC / WD SN850 1 TB, Kingston NV1 2 TB + NAS / Corsair RM650x V3 / Acer XB271HU (1440p165) / LG C1 55"
Mobil: Moto G200

Permalänk
Medlem
Skrivet av Thomas:

Ars Technicas ZFS-genomgång håller med om att en ny vdev kan se ut hur som helst.
https://arstechnica.com/information-technology/2020/05/zfs-10...

Men det är förstås viktigt att vara med på att om en vdev kraschar så kraschar hela zpoolen, så om man t ex lägger till en enstaka disk till en pool med en RAIDZ2-vdev så har man ingen redundans kvar överhuvudtaget.

Men kan man inte köra med två pooler? Det är ju viss sammanblandning av begreppen vdev och zpool, och jag är inte helt säker själv, men har man inte valet att lägga sin nya vdev i en ny zpool? Jag tycker mig ha sett "create pool" i storage-fönstret i truenas core.

Permalänk
Hedersmedlem
Skrivet av guermantes:

Men kan man inte köra med två pooler? Det är ju viss sammanblandning av begreppen vdev och zpool, och jag är inte helt säker själv, men har man inte valet att lägga sin nya vdev i en ny zpool? Jag tycker mig ha sett "create pool" i storage-fönstret i truenas core.

Jodå, det går bra -- men då får du ett nytt, separat filsystem (som C: och D: i Windows) som inte kan dela filer, och där du inte kan flytta filer mellan dem utan att det tar tid och en massa diskaktivitet.
Det har ju fördelar och nackdelar, så det beror ju på vad man vill göra.

En zpool är den "största" enheten i ZFS, så att säga.

Visa signatur

Asus ROG STRIX B550-F / Ryzen 5800X3D / 48 GB 3200 MHz CL14 / Asus TUF 3080 OC / WD SN850 1 TB, Kingston NV1 2 TB + NAS / Corsair RM650x V3 / Acer XB271HU (1440p165) / LG C1 55"
Mobil: Moto G200