iSCSI, ZFS of toch "ouderwets" Linux software RAID?

[Xudonax]

Ik heb een drie tal 500GB schijven (2x Seagate, 1x Samsung) in mijn "server" zitten. De bedoeling hiervan is dat ze via iSCSI te benaderen zijn voor mijn Mac met o.a. Final Cut Pro X. Op dit moment loopt dit via een RAIDZ1 (ZFS) pool, waar ik vervolgens een ~850GB ZVOL heb aangemaakt. Deze word weer via iSCSI gedeeld.

Nu zit ik alleen te denken, is het niet net zo handig (of handiger) om de stap naar software RAID te maken?
Ik bedoel, ik sla hiermee ZFS over, en zorg dat er nog maar één filesystem gebruikt word. Op dit moment gebruik ik namelijk ZFS én HFS+. Nu haal ik nog steeds makkelijk snelheden die hoger liggen dan 1Gbit/s, maar dat maakt niet uit, toch?

Op deze schijf staat o.a. de volledige Final Cut Pro X bibliotheek (~250GB op dit moment), mijn Aperture bibliotheek (~175GB) en nog wat andere losse dingen. Ik draai natuurlijk een extra backup voordat ik de schijven omzet

Wat zouden jullie in dit geval doen?

[Verwijderd]

Gewoon ZFS gebruiken met AppleShare of Samba of NFS? Waarom zou je iSCSI willen? Waarom zou je een legacy filesystem willen als je ZFS kunt draaien?

Het hele idee van ZFS is dat je je betrouwbaarheid en bescherming een flinke boost geeft. Dat geef je natuurlijk op als je met legacy filesystems gaat werken. Als enkel performance relevant is en de integriteit en bescherming van je bestanden niet belangrijk is, dan heb je natuurlijk geen ZFS nodig, afgezien van de extra features die ZFS kan bieden.

[Q]

Als de performance gelijk zou zijn, zou ik 100% voor CiPHERs suggestie gaan. Dus SMB of NFS op ZFS.

Echter, mijn individuele ervaring met mijn Mac Mini en mijn NAS/Router als iSCSI target is dat iSCSI tien tallen MB/s sneller is dan SMB of NFS. Dat zou niet echt zoveel uit hoeven maken, maar dat is toch mijn ervaring. Omdat je zelf al iSCSI gebruikt kun je dit zelf ook testen/controleren.

iSCSI op ZFS geeft volgens mij nog steeds betere bescherming tegen bit rot. Werken met snapshots, als dat zou boeien, is minder handig, als dat belangrijk is dan zou SMB/NFS een betere optie zijn denk ik.

Je limiet is je gigabit link dus qua performance maakt het denk ik niet heel veel uit. Als je met een Mac Pro werkt en je 2x gigabit hebt, zou je nog nut kunnen hebben van iSCSI Multipathing. Dit gaat je niet lukken met NFS of SMB of AFP.

Anno 2013 zou ik - zeker als het belangrijke data is - zeker onderzoeken of ZFS als onderliggende laag gebruikt kan worden tegen bitrot.

Helaas is de functionaliteit om ZFS als native iSCSI target beschikbaar te stellen niet beschikbaar in ZFS on Linux. Dan zou je dus een grote file moeten maken en die als iscsi target exporteren (bah!).

Misschien ga ik een beetje te ver maar de anti-bit-rot functionaliteit van ZFS heeft niet heel veel zin als je continue met je data werkt op een niet-ZFS file system en alleen af en toe data 'bewaard' op je ZFS storage. Als bitrot optreedt terwijl je op een niet-ZFS file system werkt, gaat ZFS het later nooit zien dat er corruptie is geweest. Als je continue werkt vanaf het ZFS volume weet je zeker dat er geen bitrot is geweest. Dat is hoe ik het begrijp.

[ Voor 6% gewijzigd door Q op 26-07-2013 02:17 ]

[Verwijderd]

iSCSI tien tallen MB/s sneller is dan SMB of NFS

Bij anderen juist weer veel langzamer. Het verschilt per setup. Of dit doorslaggevend zou moeten zijn is verder nog maar de vraag.

iSCSI op ZFS geeft volgens mij nog steeds betere bescherming tegen bit rot.

Pardon? Juist andersom?! Het gebruik van iSCSI impliceert dat je een legacy filesystem gebruikt die zelf geen bescherming heeft tegen corruptie, doordat het zelf geen checksums gebruikt. iSCSI is dus vrijwel per definitie gevoeliger voor bitrot en de bescherming van je bestanden neemt dan ook gelijk flink af. Nog steeds heeft ZFS nut omdat je zowel met snapshots de integriteit kan bewaken als dat ZFS beschermt tegen bad sectors op de fysieke hardeschijven.

Werken met snapshots, als dat zou boeien, is minder handig, als dat belangrijk is dan zou SMB/NFS een betere optie zijn denk ik.

Juist niet. Snapshots zijn de enige methode om tegen corruptie voor iSCSI legacy filesystem containers te beschermen. Voor NFS/Samba heb je dat om die reden niet nodig omdat ZFS de bestanden direct beschermt. Dan wil je het alleen hebben als 'backup' oftewel historie; zoals een virus wat aan je bestanden knaagt of je perongeluk een directory verwijdert enzo. Voor iSCSI images wil je snapshots gebruiken om een soort van restore points te gebruiken waarop je filesystem verondersteld nog corruptievrij is. Mocht je filesystem corrupt raken kun je dan terug naar de laatste snapshot.

Nadeel is echter wel dat snapshots op iSCSI volumes zoals ZVOLs wel ernstige performancedegradatie kan veroorzaken. Het copy-on-write principe is sowieso niet erg handig voor iSCSI images.

[Xudonax]

Verwijderd schreef op vrijdag 26 juli 2013 @ 01:02:
Gewoon ZFS gebruiken met AppleShare of Samba of NFS? Waarom zou je iSCSI willen? Waarom zou je een legacy filesystem willen als je ZFS kunt draaien?

Omdat Final Cut Pro X de bibliotheek enkel wil benaderen als het een (virtueel) blockdevice is. Ik zit dus vast aan ofwel iSCSI, ofwel een diskimage bovenop AFP/SMB/NFS. Dat laatste is echt baggertraag. Je mag blij zijn als OS X dan nog ~10MByte/s kan doen over een 1Gbit/s link.

Q schreef op vrijdag 26 juli 2013 @ 02:15:
Als de performance gelijk zou zijn, zou ik 100% voor CiPHERs suggestie gaan. Dus SMB of NFS op ZFS.

Echter, mijn individuele ervaring met mijn Mac Mini en mijn NAS/Router als iSCSI target is dat iSCSI tien tallen MB/s sneller is dan SMB of NFS. Dat zou niet echt zoveel uit hoeven maken, maar dat is toch mijn ervaring. Omdat je zelf al iSCSI gebruikt kun je dit zelf ook testen/controleren.

De performance is praktisch gelijk, het verschil is bij mij hooguit een paar MByte/s, niet echt iets waar ik me héél erg druk over maak dus. Maar zodra ik (zoals hierboven) een diskimage aanmaak dan stort de performance wél heel erg in

Q schreef op vrijdag 26 juli 2013 @ 02:15:
Helaas is de functionaliteit om ZFS als native iSCSI target beschikbaar te stellen niet beschikbaar in ZFS on Linux. Dan zou je dus een grote file moeten maken en die als iscsi target exporteren (bah!).

Dat is inderdaad wat ik nu doe, maar het heet dan een ZVOL. Zelfde idee, maar het volume (bestand) is niet zichtbaar in de file listing, maar als enkel als los volume in zfs list

Ik neig eerlijk gezegd zelf heel erg naar een overstap naar Linux' eigen software RAID, vooral omdat ik het gevoel heb dat een extra tussenlaag (ZFS in dit geval) a) niet nuttig is, en b) de zaak alleen maar complexer maakt.

Misschien dat ik gewoon de meuk moet backuppen en wat benchmarks moet draaien. Over iSCSI, dat dan wel natuurlijk

[analogworm]

@Xudonax, zou je je resultaten en uiteindelijk je gekozen oplossing willen posten? Ik vind het namelijk zeer interessant om mee te lezen. Al dan niet ter voorbereiding voor wanneer ik zelf behoefte ga hebben aan Nas opslag.

[Xudonax]

Ik begin te twijfelen of ik nog wel kán benchen met Linux software RAID. Volgens mij is de schijf een beetje op z'n eindje. de Hardware_ECC_Recovered waarde gaat met ~500.000 per minuut omhoog. Vanmiddag maar even kijken of ik niet gewoon 2 nieuwe schijven kan halen om in RAID1 te zetten.

Het enige wat ik waarschijnlijk wel ga missen met software RAID is de SSD caching. Dat werkte wel echt super

code:

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   100   098   051    Pre-fail  Always       -       2412
  3 Spin_Up_Time            0x0007   100   100   015    Pre-fail  Always       -       7168
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       527
  5 Reallocated_Sector_Ct   0x0033   253   253   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   253   253   051    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0025   253   253   015    Pre-fail  Offline      -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       536
 10 Spin_Retry_Count        0x0033   253   253   051    Pre-fail  Always       -       0
 11 Calibration_Retry_Count 0x0012   253   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       56
187 Reported_Uncorrect      0x0032   253   253   000    Old_age   Always       -       2359296
188 Command_Timeout         0x0032   253   253   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   061   042   000    Old_age   Always       -       39
194 Temperature_Celsius     0x0022   121   064   000    Old_age   Always       -       39
195 Hardware_ECC_Recovered  0x001a   100   100   000    Old_age   Always       -       510188795
196 Reallocated_Event_Count 0x0032   253   253   000    Old_age   Always       -       0
197 Total_Pending_Sectors   0x0012   253   253   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   253   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x000a   100   100   000    Old_age   Always       -       0
201 Soft_Read_Error_Rate    0x000a   100   100   000    Old_age   Always       -       5
202 Data_Address_Mark_Errs  0x0032   253   253   000    Old_age   Always       -       0

[Q]

Verwijderd schreef op vrijdag 26 juli 2013 @ 02:56:

Pardon? Juist andersom?! Het gebruik van iSCSI impliceert dat je een legacy filesystem gebruikt die zelf geen bescherming heeft tegen corruptie, doordat het zelf geen checksums gebruikt. iSCSI is dus vrijwel per definitie gevoeliger voor bitrot en de bescherming van je bestanden neemt dan ook gelijk flink af. Nog steeds heeft ZFS nut omdat je zowel met snapshots de integriteit kan bewaken als dat ZFS beschermt tegen bad sectors op de fysieke hardeschijven.

Dat is precies wat ik bedoel?

Juist niet. Snapshots zijn de enige methode om tegen corruptie voor iSCSI legacy filesystem containers te beschermen. Voor NFS/Samba heb je dat om die reden niet nodig omdat ZFS de bestanden direct beschermt. Dan wil je het alleen hebben als 'backup' oftewel historie; zoals een virus wat aan je bestanden knaagt of je perongeluk een directory verwijdert enzo. Voor iSCSI images wil je snapshots gebruiken om een soort van restore points te gebruiken waarop je filesystem verondersteld nog corruptievrij is. Mocht je filesystem corrupt raken kun je dan terug naar de laatste snapshot.

Nadeel is echter wel dat snapshots op iSCSI volumes zoals ZVOLs wel ernstige performancedegradatie kan veroorzaken. Het copy-on-write principe is sowieso niet erg handig voor iSCSI images.

Ik dacht dat het meer gedoe is om een snapshot met data te benaderen als je scsi er bovenop gooit als dat je gewoon meteen tegen het filesystem aan praat, zoals je dat met NFS/SMB zou hebben.

[ Voor 56% gewijzigd door Q op 26-07-2013 20:07 ]

[Xudonax]

Ik heb helaas geen directe vergelijkende benchmarks kunnen doen omdat, zoals hierboven geschreven, één van de drie disks op sterven na dood is. Ik heb nu dus 2x 3TB in RAID1 liggen en ben hier goed over te spreken, ik doe ~150MByte/s sustained read hierop op de machine zelf. Schrijven kan ik helaas niet veilig testen aangezien er een HFS+ bestandssysteem op staat, en ik vertrouw Linux daar toch niet helemaal mee.

Ik ga eens kijken naar link aggregation om te zien hoeveel ik nu daadwerkelijk kan schrijven over iSCSI.

Wel moet ik CiPHER gelijk geven, ZFS bied een stuk meer bescherming dan "legacy filesystems" zoals HFS+/NTFS/Ext4 etc., maar ik zit voor deze specifieke toepassing helaas vast aan ofwel HFS+, ofwel een variant op Apple's XSan. En aangezien iSCSI voor beide oplossing vereist is en XSan een flinke bak duiten extra kost is de keuze voor mij niet heel moeilijk

Dat neemt echter niet weg dat zodra OS X officieel ondersteuning gaat bieden voor ZFS of iets soortgelijks, dat ik over ga naar dat systeem.

[Q]

De GlobalSAN initiator zou MPIO (multipathing) support moeten hebben. Je zou geen gekke dingen hoeven te moeten doen met link aggregation op de switches als je voor beide netwerk kaarten aparte ip ranges gebruikt volgens mij.

[Xudonax]

Ik doe liever link aggregation (heb toch al een managed switch staan) dan dat ik moeilijk ga doen met aparte IP ranges Maar inderdaad, multipath is wel de mooiere oplossing, dat ben ik met je eens. Ik kan natuurlijk ook nog altijd kijken of ik OS X zover kan krijgen dat ik een bepaald IP adres over een bepaalde connectie kan routeren.

[Q]

Link aggregation kan MPIO wel eens in de weg zetten volgens mij. Maar daar kom je vanzelf achter. Ik ben benieuwd.

[ Voor 57% gewijzigd door Q op 29-07-2013 11:22 ]

[Xudonax]

Ik heb nu dus een tweede netwerkkaart en MPIO, maar echt werken zoals ik op basis van je post had verwacht doet het niet wall of text over het probleem

Enig idee hoe en/of wat Q?