Het grote ZFS topic

[JobH]

-Moondust- schreef op dinsdag 17 juni 2014 @ 21:19:
... Wellicht dat de Ziggo Cisco router nog een rol speelt, maar ik vermoed van niet. Wordt vervolgd...

Weet niet zeker hoe dat bij Ziggo zit, maar bij mijn UPC router had ik erg veel last van fluctuaties op de doorvoersnelheid (ook intern, zowel wifi als bekabeld!) zolang ik andere UPC-gebruikers toestond om via mijn router een wifi-verbinding te maken met het internet. Pas nadat ik het delen had uitgezet, werden mijn eigen transfers weer een beetje stabiel...

[_-= Erikje =-_]

code:

[erik@nas] /mnt/vol01/Downloads# dd if=/dev/zero of=/mnt/vol01/Downloads/test.bin bs=1M count=40960
40960+0 records in
40960+0 records out
42949672960 bytes transferred in 569.238155 secs (75451149 bytes/sec)
[erik@nas] /mnt/vol01/Downloads#

hmm, daar mag ik nog wel wat aan tunen (4x wd 2Tb Z1)

[-Moondust-]

@Cipher
Ok, ik ga binnenkort je aanwijzigingen volgen en zien of ik een tmpfs kan aanmaken en testen. Wordt vervolgd...

@JobH
De deelfunctie heb ik gelijk al uitgezet toen ik de modemrouter binnen had. Downloadsnelheden zijn ook altijd stabiel. Vrijwel nooit klachten over.

[Extera]

Iemand hier ervaring met VMware en NFS op ZFS?

door de sync writes is de write performance om te huilen, dit is bekend.
Het is ook bekend dat een SLOG toevoegen betere performance zou opleveren.

Wat zou deze performance ongeveer moeten worden? De snelheid van de SLOG (LOG) diskset?
Ik heb nu een mirror van 2 36GB 10k SAS disks als SLOG, en ik haal 8MB/s write snelheden in benchmarks...

Nu zijn die SAS disks niet de snelste, ik heb ze puur als test toegevoegd, maar ik had toch wel ongeveer de performance van 1 SAS disk verwacht rond de 60MB/s oid.

[Verwijderd]

10.000 rpm is maar iets meer dan 7200rpm en ook slechts het dubbele van een 5400rpm HDD. Als je de IOps vergelijkt met een SSD dan zit je met een SSD gauw aan factor 100 snellere performance.

Je kunt echter ook sync writes als async behandelen. Dan kun je zien wat je performance plafond is als je een oneindig snelle SLOG disk zou hebben. Gewoon 'zfs set sync=disabled poolname/filesystem' is genoeg en heeft direct effect. Kun je eenvoudig weer terug schakelen naar 'standard' setting. Bedenk wel dat bij sync=disabled de applicatiedata corrupt kan raken als ZFS niet netjes wordt afgesloten, zoals een stroomstoring of crash of spontane reset, enzovoorts.

[Extera]

Thanks, ik weet dat de SAS diskjes niet de snelste zijn, en SSDs sneller zijn.
Ik heb ook getest met sync disabled, maar wil zo niet in 'productie' draaien, ook niet met een UPS.

Ik ben benieuwd wat voor performance er ongeveer te halen is met een SLOG icm NFS en Vmware.
SSDs komen er aan... moet even sparen nog de SAS disks had ik nog liggen.

zonder sync kom ik rond de 380 MB/s uit (4x 2 disk mirror 1TB disks). Read rond de 600 MB/s

[Verwijderd]

Reads worden niet beïnvloed door de 'sync' setting; dat gaat enkel om writes. En het hele idee van sync=disabled is dat je goed kunt benchmarken. Dat is de performance die je met een maximaal snelle sLOG disk kunt behalen. In de praktijk ligt de sLOG performance ergens tussen jouw 10k SAS disk en sync=disabled in. Normaliter behaal je zeker een grote boost bij sLOG performance.

Maar ik vind het persoonlijk erg amateuristisch dat VMWare alles als sync writes doet. Dat is wat we deden bij eerste generatie filesystems; ten tijde van Windows 95 en je tijdens de boot altijd filesystem schade had die 'scandisk' moest verhelpen. Komop... we zijn nu 2014?!

[Paul]

Dat is de hoofdreden dat ik niet voor de 'native' NFS datastore ben gegaan maar voor iSCSI ben gegaan: in tegenstelling tot NFS wordt bij iSCSI voor zover ik heb kunnen achterhalen niet alles naar synced writes geforceerd...

[Verwijderd]

iSCSI is juist veel gevoeliger. Juist omdat je dan een ander filesystem gebruikt. En juist daar is het ultra-kritiek dat je sync writes ook als sync writes beschouwt. Anders kan je ZFS filesystem wel intact zijn, maar heeft je NTFS-op-iSCSI filesystem misschien wel wat vervelende schade opgelopen en verdwijnen er bestanden of dirs of zie je allemaal rare tekens. Dat soort dingen kunnen dan gebeuren.

Met NFS is de server het enige filesystem. De client weet niet wat voor filesystem er achter een NFS share ligt. Dit betekent dat ZFS het enige filesystem van belang is voor wat betreft de files die opslaat. Sla je ook VM images op, dan is het een ander verhaal. NFS heeft zijn eigen locking systeem. Je kunt dit ook uitschakelen door te mounten met -nolock of -locklock of zoiets. Zie de manpage. Dat betekent dat je alleen lokaal filelocks doet op NFS shares. Dat kan gevaarlijk zijn als meerdere computers met dezelfde data werken; bijvoorbeeld dat je een VM image op twee computers opent. Dan gebeuren er gekke dingen als je local filelocks gebruikt. Maar doe je dat niet in een thuisomgeving, dan is local locking net iets sneller.

Bij NFS sla je de files dus direct op een ZFS filesystem, en dat betekent eigenlijk direct dat de integriteit is gewaarborgd. Zelfs met sync=disabled, al zou je dan mogelijk wel verder terug de tijd in gaan. sync=standard - de default - zou prima moeten werken zonder enige significante performance overhead.

[FireDrunk]

Ik ben daar volgens mij al een aantal keer uitgebreid op ingegaan in het Zuinige ESXi topic, maar ik kan morgen nog wel een uitgebreide reply schrijven, het is niet allemaal waar wat hier gezegd word, en roepen dat VMware amateuristisch is omdat ze alles SYNC doen is *EXTREEM* kort door de bocht en echt niet waar.

Dat is een weloverwogen supergoede keuze en die zal ik morgen toelichten... Nu eerst eindelijk mijn diner wegwerken en slapen

[Verwijderd]

Ben benieuwd naar je reply.

Sowieso denk ik dat een hypervisor gewoon in RAM moet draaien en helemaal niet van de disk afhankelijk moet zijn. Als het hoofd OS alleen als een hypervisor gebruikt wordt, zou dat ook niet veel overhead mogen geven. Ook ZFSguru wil deze richting op, met een nieuwe Root-on-RAM distributie. Dan kan je OS ook nooit meer crashen als de systeemdisk onderuit gaat om wat voor reden.

[FireDrunk]

Zo, tijd voor een uitgebreide reply:

1: ESXi maakt (ook op NFS) niet *ALLE* writes SYNC... Hoeveel precies weet ik niet, maar volgens mij is het iig zo, dat voor elke VMFS allocatie (iSCSI) of VMDK vergroting (iSCSI en VMDK) er synced writes gebeuren. Default is dat volgens mij 5MB. Dit betekend dat elke 5MB er sowieso 1 SYNC actie gebeurt.
Ik heb uitvoerig getest, en je kan over NFS prima > 100MB/s doen. Als alle writes sync waren, had je dat echt niet gehaald...

2: De reden waarom ESXi aggresief om gaat met SYNC is simpel:

A ) VMWare is gemaakt om oudere besturingssystemen te draaien (het is een key selling point, dat bijvoorbeeld Windows 2000 nog werkt op VMware). Wat juist in oudere systemen niet zo goed is, is de journal rollback. VMware wil daarom JUIST dat eigenlijk alles sync is, zodat de kans dat zo'n systeem bij een failure van de vm of de host, een grotere kans heeft om zijn data te kunnen restoren.

B ) Kans en Impact... 1 Systeem wat stopt/crasht met wat data in write back cache geeft misschien niet zoveel. Maar je moet je goed beseffen dat wat wij doen met ESXi nog kinderspel is. 4-10 VM's is peanuts, ik heb systemen beheerd met 40-50VM's op 1 enkele ESXi host, en heb platforms gezien met > 100VM's op 1 host (512GB / 1TB geheugen in 1 bak). Als je dan een host verliest (wat zeker niet ondenkbaar is). Verlies je misschien alleen de data in write back ja, maar wel van 100 machines! De kans dat daar een machine tussen zit waar de journal rollback niet helemaal goed gaat, is toch 100 keer groter dan op 1 los systeem.

ESXi dekt zich dus gewoon in, ze nemen liever veiligheid boven performance... He wacht, dat is exact wat ZFS doet

@CiPHER
iSCSI is niet gevoeliger voor fouten dan NFS? Zolang je synced writes goed gehonoreerd worden, zal elk 3e generatie OS zijn journal logs perfect kunnen wegschrijven en kan het filesystem in principe niet stuk.
Dat is precies wat er met VMFS (het VMware filessystem ook gebeurt). VMFS kent een custom locking systeem waarmee meerdere hosts met elkaar communiceren om even maar 1 host tegelijk op de iSCSI link te laten schrijven bij metadata updates. Daarom heeft VMware ook een gigantisch boekwerk waarin staat dat je niet te grote volumes aan ESXi moet geven, omdat als je een 2TB LUN aan ESXi geeft, en daar 100 hosts op hangt, al die 100 Hosts even geen (write) IO mogen doen tijdens metadata updates.

NFS is zeker ook niet heilig, en het voorstellen van nolock op een ESXi machine is echt *uit den boze*, dat zou betekenen dat meerdere hosts tegelijkertijd naar dezelfde file mogen schrijven, dat wil je natuurlijk niet.
Sync=disabled betekend nog steeds dat alle NFS writes gecached worden, ook al zegt ESXi dat de NFS write niet gecached mag worden. Je kan dus wel degelijk al je VM's om zeep helpen als je ZFS machine crasht omdat ook de metadata updates in het RAM van je ZFS machine belanden.

Het allergrootste verschil tussen iSCSI en NFS, is het feit dat NFS geen io queues heeft... Het heeft wel meerdere threads, maar geen queue.. Waar ESXi bij iSCSI kan zeggen: "Hej server, hier heb je 10 read IO's en 2 write IO's, daarna 2 SYNC write IO's" moet hij bij NFS steeds 1 IO doorgeven aan 1 thread. Die kan ofwel SYNC zijn of niet. NFS writes zijn voor zover ik weet altijd SYNC, alleen gaat dat niet over 1 packet wat over de lijn gaat, maar over 1 stream. Dus als jij 100MB schrijft, kan het zijn dat er tussen de NFS client en NFS server een stream opgestart word van 50MB, en alleen aan het einde van zo'n stream word een SYNC gegeven. (let op: dit is pure speculatie, het is erg lastig om daar specifieke data over te vinden, omdat ESXi nou eenmaal closed source is )

VMFS zit wat dat betreft redelijk slim in elkaar, het is zeker niet zo goed als ZFS, maar het is dan ook een Clustered filesystem (het dient een heel ander doel).

ESXi draait overigens ook 100% in ram, je kan je USB stick er gewoon uit trekken en het blijft gewoon door draaien. De reden dat dit niet kan als je op een disk installeert, is omdat je dan een swap en log partitie hebt. Die mogen (uiteraard) niet wegvallen...

[Paul]

Verwijderd schreef op woensdag 18 juni 2014 @ 21:01:
iSCSI is juist veel gevoeliger. Juist omdat je dan een ander filesystem gebruikt.

Het zijn wat meer tussenliggende stappen dan NFS op ZFS (ZFS -> File -> iSCSI Target -> iSCSI initiator -> VMFS) maar het zijn wel proven technologies.

En juist daar is het ultra-kritiek dat je sync writes ook als sync writes beschouwt.

...daarom dus juist iSCSI. Geen SLOG nodig en geen sync=disabled om toch de snelheid er in te houden

ESXi draait overigens ook 100% in ram, je kan je USB stick er gewoon uit trekken en het blijft gewoon door draaien.

Daar kwam ik ook achter toen ik een USB-controller doorgaf aan een VM want daar hangt een labelprinter aan. Waarom slaat ESXi zijn instellingen niet meer op

Daarna kwam ik er achter dat je ook losse USB-devices door kon geven aan een VM

[FireDrunk]

Het verschil is zelfs:

ZFS -> ZVOL -> iSCSI Target -> iSCSI Initiator -> VMFS -> File
ZFS -> ZFS Filesystem -> NFS Daemon -> NFS Client -> File

Het maakt wel wat uit, maar veel... nee.. dat niet.

[Extera]

De reden dat ik graag NFS wil gebruiken is omdat het wat flexibeler is, ik wil niet van VMware afhankelijk zijn om door de files te browsen.
Nu kan ik de iSCSI ook op een windows machine mounten, maar NFS is hier toch flexibeler in.

Ik ga eerst kijken of ik de performance met een SLOG omhoog krig, mocht dat niet naar mijn zin zijn, kan ik altijd nog naar iSCSI

Verwijderd schreef op woensdag 18 juni 2014 @ 17:36:
Reads worden niet beïnvloed door de 'sync' setting; dat gaat enkel om writes. En het hele idee van sync=disabled is dat je goed kunt benchmarken. Dat is de performance die je met een maximaal snelle sLOG disk kunt behalen. In de praktijk ligt de sLOG performance ergens tussen jouw 10k SAS disk en sync=disabled in. Normaliter behaal je zeker een grote boost bij sLOG performance.

Het performance probleem wordt volgens mij voornamelijk veroorzaakt door de lange keten die een synced write moet doorlopen.
Deze keten wordt korter als je een SLOG gebruikt, omdat de NAS sneller een synced write bevestigd aan ESX.

Om te zeggen dat de performance ergens tussen de performance van het SLOG device en de performance van de storage zonder sync moet liggen lijkt me wat kort door de bocht,
een write wordt op het SLOG weggeschreven en dan bevestigd, daarna moet ESXi dit toch nog aan de guest doorgeven voordat een nieuwe write wordt uitgevoerd?
Je blijft dus nog steeds extra handelingen houden, waardoor -denk ik- de performance lager zal liggen dan de performance van het SLOG device.

Ik heb nog een 60GB Intel 320 liggen, ik zal vanavond de sas disken verwijderen, een benchmark doen op de SSD, en deze dan als log device toevoegen.
Nu is dat ook geen snelheidsmonster, maar hij is in ieder geval sneller dan de sas disken.

Even iets anders, het verwijderen van de slog disken uit de pool is gewoon veilig?
ZFS zal de data die nog moet worden weggeschreven wegschrijven en de disks uit de pool halen?
Kan dit gewoon live? Misschien voor de zekerheid even iscsi en nfs stoppen?

[FireDrunk]

Je kan het iSCSI volume van VMware *niet* in Windows mounten... Windows snapt geen VMFS.
Linux daarentegen wel, er is een opensource readonly VMFS driver volgens mij

[Paul]

Extera schreef op donderdag 19 juni 2014 @ 15:39:
De reden dat ik graag NFS wil gebruiken is omdat het wat flexibeler is, ik wil niet van VMware afhankelijk zijn om door de files te browsen.

Just curious, maar waarom zou je op je datastore willen browsen? Er zijn heeeel sporadisch dingen die je op moet lossen door bestandjes te editten in een datastore, maar die zijn heel erg zeldzaam. Mijns inziens kun je er meer mee kapot maken dan dat het oplost

Het performance probleem wordt volgens mij voornamelijk veroorzaakt door de lange keten die een synced write moet doorlopen.

Nee, een synced write forceert een commit op je huidige transaction group, die moet naar schijf, dan moet je nieuwe write er achteraan, die moet naar schijf, en dan pas krijgt degene die schrijft een bevestiging dat het gedaan is. Het flushen naar disk is hetgeen het traag maakt, dit gaat sneller doordat een SSD zoveel sneller is

Met betrekking tot het wisselen (of verwijderen) van SLOG: http://mikebeach.org/2013...l-zil-disk-live-by-gptid/

[Extera]

@ firedunk, thanks, weer iets geleerd

@ paul. Je hebt eigenlijk wel gelijk zo veel kom je niet op de datastore. Eigelijk niet genoeg om de keuze voor NFS / iSCSI van af te laten hangen...

vanavond zal ik eens testen met de intel ssd, ik ben benieuwd.

[FireDrunk]

@Paul, een synced write word gewoon mee genomen in de eerst volgende transactie hoor, het is niet dat de huidige groep eerst gecommit word.

Wel moet er gewacht worden tot de huidige transaction flush klaar is voor de nieuwe transaction group jouw synced write kan bevatten.

[_-= Erikje =-_]

_-= Erikje =-_ schreef op woensdag 18 juni 2014 @ 12:42:

code:

[erik@nas] /mnt/vol01/Downloads# dd if=/dev/zero of=/mnt/vol01/Downloads/test.bin bs=1M count=40960
40960+0 records in
40960+0 records out
42949672960 bytes transferred in 569.238155 secs (75451149 bytes/sec)
[erik@nas] /mnt/vol01/Downloads#

hmm, daar mag ik nog wel wat aan tunen (4x wd 2Tb Z1)

sowieso eerst maar even proxmox er van omheen slopen (zeker nu met de BSD jails in freenas) en misschien wat meer geheugen kopen, 8 Gbyte is wellicht net te weinig voor deze setup, helaas kan ik maar 2 DIMMS kwijt en ik zoek nog een leuke manier om eventueel makkelijk iets van een externe SAS drive bay aan te sluiten met een stapel drives

[ Voor 8% gewijzigd door _-= Erikje =-_ op 19-06-2014 17:17 ]

[Paul]

FireDrunk schreef op donderdag 19 juni 2014 @ 16:40:
@Paul, een synced write word gewoon mee genomen in de eerst volgende transactie hoor, het is niet dat de huidige groep eerst gecommit word.

Wel moet er gewacht worden tot de huidige transaction flush klaar is voor de nieuwe transaction group jouw synced write kan bevatten.

Is dat niet ongeveer hetzelfde? Overigens bestaat er na het quiesce'n toch al direct (nog voordat deze wordt geflusht) een nieuwe transaction group om te bufferen?

[FireDrunk]

Klopt, als er genoeg geheugen is wel, anders niet. Zfs kan immers het geheugen van de oude txg nog niet weggooien.

[Extera]

Intel 330 60GB SSD als SLOG toegevoegd

code:

[root@claustofobia] /mnt/test# dd if=/dev/zero of=/mnt/test/testfile bs=1024k count=50000
50000+0 records in
50000+0 records out
52428800000 bytes transferred in 148.476384 secs (353112047 bytes/sec)

Ik haal nu 65 MB/s write over NFS vanuit een VM. (crystaldisk)
iSCSI is van 260 MB/s naar 290MB/s gegaan.

Ik zou eigenlijk moeten kijken wat een VM haalt welke direct op de SSD draaien via NFS en sync disabled. Ik denk dat die 65 MB/s dicht tegen de max van de SSD zit op 4K random writes.

[FireDrunk]

Een Intel 330 SSD is niet geschikt als SLOG, het is een op SandForce Controllers gebaseerde SSD en die zijn daar niet geschikt voor om een heleboel redenen

Overigens: Test NFS nooit met CrystalDiskMark, ik heb daar hele slechte ervaringen mee.
Probeer IOMeter, en maak zelf een sequentieel patroon aan.

Daar haalde ik soms wel de dubbele snelheden.

[zzattack]

Is er op dit moment een goed verkrijgbare schijf die voor ZFS gebruik valt aan te raden? Heb momenteel veel 5K3000 schijven die erg zijn bevallen maar wil van 2TB --> 4TB gaan.
Ik heb ook een nieuwe controller nodig, maar ben niet kapot van de layout van de M1015; de plaatsing van de connectors is erg ver naar achteren. Hier goede alternatieven voor? (Excuses als dit niet het juiste topic is.)

[FireDrunk]

WD EZRX 4TB is een veel geliefde schijf. Maar in principe zijn er niet echt slechte schijven.
Hitachi heeft alleen 7200RPM 4TB modellen, en de Seagate HDD.15 is technisch ook ok. Niet super, maar gewoon ok.

Overigens is er ook een M1015 met de poorten aan de achterkant, alleen heeft die een ander nummertje.
Zal even kijken of ik kan vinden welke dat is.

http://forums.servethehom...ting-plus-oem-models.599/

Hier staan ze allemaal.

[ Voor 42% gewijzigd door FireDrunk op 20-06-2014 10:36 ]

[zzattack]

Bedankt voor de aanbeveling. Heb niet de beste ervaringen met WD, maar dat is al wel een flinke tijd geleden. Ik heb van Hitachi ook de 5K4000 gevonden, maar die is slecht verkrijgbaar. Een maat van me heeft ze uit deze gesloopt: pricewatch: Hitachi Touro Desk USB 3.0 4TB Zwart - is die aan te raden?

Tussen die lijst moet vast wel een voor mij goede controller zitten, bedankt

[FireDrunk]

De 5K4000 word niet meer gemaakt volgens mij, Hitachi is geloof ik gestopt met de productie.
Wat _ontzettend_ jammer is, want Hitachi maakt echt goede schijven...

Enige goede 4TB schijf van Hitachi is dus de 7k4000. pricewatch: HGST Deskstar 7K4000, 4TB
Of deze: pricewatch: HGST Deskstar NAS, 4TB

Maar die zijn dus 7200RPM, zonde van de energie.

Lijstje van 4TB schijven < 7200RPM:
http://tweakers.net/categ...VEyNDVGUmeEpMjU0gSoorYWAA

[zzattack]

Die 5K4000 lijkt inderdaad niet meer los gemaakt te worden, maar voor €140 wil ik ze best uit die enclosures vissen. Ik ga de WD EZRX er eens goed mee vergelijken.

[jacovn]

Hmm zfs server geupgrade, network configuratie weg... Tja ik had het kunnen weten als je het OS refreshed.

[FireDrunk]

Welk OS?

[jacovn]

Zfsguru van 9.2 naar 10.1

Had een extra driver voor de intel 10 GE kaart, ringbuffer instellingen en dan 3 verbindingen, nu een nieuw ip adres met dhcp, maar goed dat kun je via de console snel zien.
Gelukkig heb ik hetzelfde op zijn broertje staan, dus daar spiek ik wel even op voor de correcte instellingen.

[FireDrunk]

ZFSguru houdt nooit instellingen bij, je doet altijd een verse install.
'Ooit' komt er een Migration Manager, dan zou dat wel moeten werken.

[Arokh]

ik probeerde vandaag mijn server opnieuw op te starten (heb een nieuwe voeding erin gezet) maar nu start het systeem niet meer op.
Dit is het screenshot waar hij in de loop blijft hangen. Wat moet ik nu doen?

http://s12.postimg.org/ulom7htcd/WP_20140620_001.jpg

[FireDrunk]

Ziet er uit als een kapotte schijf. Even in een ander systeem hangen en smart data uitlezen.
Geen smart tests doen!

Er is overigens een Het Grote SMART data topic. Misschien je resultaten even daar posten.

[ Voor 71% gewijzigd door FireDrunk op 20-06-2014 16:00 ]

[Arokh]

ik ben er ook niet honderd procent zeker van dat ik de schijven in dezelfde Sata sloten heb gestopt als voorheen. Ik denk het wel (ik heb ze genummerd) maar helemaal zeker ben ik niet.
Kan dat er ook nog toe doen?

[FireDrunk]

Nope, tenzij je de kabels echt scheef/verkeerd hebt aangesloten.

Want dit zijn echte hardware foutmeldingen.

[Arokh]

ok bedankt. Hoe kan ik zien welke schijf kapot zou kunnen zijn?

[FireDrunk]

ada5 waarschijnlijk de schijf in sata poort 5

[Arokh]

dank je. Ik heb alle kabels even eruit gehad en er weer in gehad, en momenteel werkt het weer. Het kan zijn dat ik 1 kapotte kabel heb, want die had veel kabelfouten (wie weet zat die toch een beetje los ofzo)

Bedankt voor je analyse!

[toelie]

@extera en anderen die het interessant vinden.

Ik heb wel wat ervaring met het draaien van VMware ESXi, NFS en ZFS.

Hardware:
Supermicro workstation 7047A-73 (onboard LSI 2308 geflashed met IT firmware)
2 x Xeon E5-2620
128G ECC ram
8 x 4TB HGST HDS724040AL
Intel DC S3700 100G (SLOG)
Samsung 840 EVO 250G (L2ARC)
2 x 500G laptop schijf (datastores)
8GB USB-stick (boot)

Software:
ESXi 5.1 (met LSI 2308 en intel patsburg controllers doorgegeven via vt-d)
OmniOS met napp-it (64G geheugen en 8 vcpu, 8 x 4TB in RAID-Z2, slog partitie 20G)

Ik kan helaas de benchmarks niet meer vinden maar synced sequential writes zaten rond de 180mb/s met AS SSD benchmark. Server draait met gemak 10 virtuele machines, alles voelt lekker snel aan. En nog veel belangrijker, alles is heerlijk stabiel.

Intel DC S3700 heb ik gekozen op aanraden van OpenSolaris derived ZFS NAS op hardforum. Heb ik nooit spijt van gehad. Was veel sneller en stabieler in snelheid dan de samsung evo. Samsung evo is prima voor L2ARC. Al komt ongeveer 75% direct uit de 56G ARCsize die hij heeft gepakt.

ESXi 5.5 wilde mijn patsburg controller, waar de ssd's op zitten, niet meer doorgeven via vt-d. Ook heeft ESXi 5.5 nog een vervelende NFS bug. Toch blijf ik zweren bij NFS voor ESXi, al zoveel problemen met iSCSI gehad. NFS kan vele malen beter tegen kleine netwerkdips en vertragingen.

Een tweede server die 64G ram en maar 1 xeon cpu heeft, maar verder identiek is, draait elk half uur een replicatie van de NFS datastore via netcat en zfs send/snapshotting.

ZFS machines hangen in het domein zodat direct domein rechten op de smb shares kunnen worden uitgedeeld via windows machines. Dit in combinatie met windows ondersteunde snapshots (previous versions) maakt het geheel heerlijk om mee te werken.

Mochten jullie meer willen weten dan vraag het maar.

[Sartsj]

Ik heb een nogal vreemd performance probleem met transfers over NFS naar mijn nieuwe ZFS nas.
Als ik met dd op mijn oude nas ga schrijven via NFS naar de nieuwe ZFS nas, heb ik de volgende resultaten.

code:

root@tessie:/mnt/nymeria/movies# dd bs=4096 count=60000 if=/dev/zero of=test01a_10000x512b_async
60000+0 records in
60000+0 records out
245760000 bytes (246 MB) copied, 2.44287 s, 101 MB/s
root@tessie:/mnt/nymeria/movies# dd bs=4096 count=70000 if=/dev/zero of=test01a_10000x512b_async
70000+0 records in
70000+0 records out
286720000 bytes (287 MB) copied, 83.9969 s, 3.4 MB/s

Ik heb al wat zitten spelen met de block sizes (512B, 4096B, 25MB, 50MB), waarbij het omslagpunt een beetje verschilt. (bij 25M block size is het tussen de 160-180MB, bij 50MB is het weer tussen de 210-260MB)

Heeft iemand een idee waar dit aan kan liggen? De zpool is aangemaakt ashift=12 (vanwege de 4K schijven). Ik heb inmiddels ook al de 'sync=disabled' optie gezet op de betreffende pool/folder (? sorry termen zijn nog wat nieuw).

edit:


Excuus, ik realiseer me net dat het aan de nic bonding moet liggen. Ik had op beide servers balance-rr bonding aangezet, nou lijkt dit bij de nieuwe server geen punt te zijn met 2 fysieke i210 nics, echter de 2 vmxnet3 nics in de VM op de oude server vind dit niet zo'n goed idee blijkbaar (beide vmxnet3 nics hangen in een eigen vswitch met elk een eigen fysieke nic (r8169 onboard + intel pro/1000)).

Het ligt dus niet aan ZFS/NFS.

#	Product	Prijs	Subtotaal
1	Intel Xeon E3-1220 V3 Boxed	€ 175,50	€ 175,50
1	Supermicro X10SLH-F	€ 199,50	€ 199,50
6	WD Green WD40EZRX, 4TB	€ 131,31	€ 787,86
1	Kingston KVR1333D3E9SK2/16G	€ 157,51	€ 157,51
1	Crucial M500 2,5" 240GB	€ 91,92	€ 91,92
Bekijk collectie Importeer producten		Totaal	€ 1.412,29

[ Voor 6% gewijzigd door Sartsj op 20-06-2014 20:04 ]

[yeehaw]

Stomme vraag die misschien niet echt specifiek over ZFS gaat. Ik heb op dit moment een ZFS-server met 3x3TB in raidz1 en daar heb ik nog genoeg ruimte op. Tevens is er nog ruimte voor 3 disks in mijn chassis.

Nou heb ik via via 3x2tb gekregen en vraag ik mij af of ik deze nou beter in de verpakking kan laten zitten waardoor deze 'als nieuw' blijven en ook geen stroom verbruiken, of dat ik ze beter in de nas kan doen en kan laten draaien.

Wat is jullie mening over mijn first world problem ?

[FireDrunk]

@Sartsj, zet even in het security tabje van de vSwitch "Forged Transmits" aan, dat zal nog wel eens kunnen helpen

[Sartsj]

FireDrunk schreef op vrijdag 20 juni 2014 @ 20:27:
@Sartsj, zet even in het security tabje van de vSwitch "Forged Transmits" aan, dat zal nog wel eens kunnen helpen

Thanks maar 'Forged Transmits' staat helaas al op 'Accept' in beide vSwitches

Ik wilde zojuist hetzelfde proberen maar dan met e1000 virtual nics ipv vmxnet3, maar die hebben weer een heel ander probleem: 'detected tx unit hang' errors waardoor het hele netwerk zonder belasting al uitvalt

Ik ben een beetje door mijn ideeën heen om 2Gbps transfers aan de gang te krijgen tussen mijn 2 servers.
Misschien dan toch maar gewoon de 7TB aan data naar de nieuwe nas kopieren met een 1Gbps link. Zal ook wel weer niet extreem lang duren.

[EnerQi]

yeehaw schreef op vrijdag 20 juni 2014 @ 20:17:
Stomme vraag die misschien niet echt specifiek over ZFS gaat. Ik heb op dit moment een ZFS-server met 3x3TB in raidz1 en daar heb ik nog genoeg ruimte op. Tevens is er nog ruimte voor 3 disks in mijn chassis.

Nou heb ik via via 3x2tb gekregen en vraag ik mij af of ik deze nou beter in de verpakking kan laten zitten waardoor deze 'als nieuw' blijven en ook geen stroom verbruiken, of dat ik ze beter in de nas kan doen en kan laten draaien.

Wat is jullie mening over mijn first world problem ?

Verpakking . Kan er ook niets mee gebeuren, mocht de bliksem inslaan.
Mocht je ze wel willen inbouwen dan sowieso geen stroom geven, satakabels geen probleem geen stroom geven. Ze verbruiken stroom als de pc aanstaat (idle) dus zonde.

[yeehaw]

Dacht ik al inderdaad Laat ik ze lekker in de verpakking zitten voorlopig.

[ikkeenjij36]

Hallo ff een gek iets.
Na een week van huos kwam ik vandaag terug.
Is er ineens een schijf verwijderd.
Is aan de server niks veranderd of mee geschoven of maar iets wat in die richting komt.
Een week of 4 geleden ook al zoiets gehad met een andere disk.
Toen hersteld door ff aan mn kabels te rommelen en er werd resilverd.
Hoe kan dit nou gebeuren dat er schijven verwijderd door de server?
En na het rommelen aan de sata kabels ineens weer werken,heb overigens al mn sata kabels vernieuwd intussen.

[Freeaqingme]

Welk OS draai je? Ik heb iets vergelijkbaars gehad met FreeBSD 9 (disks die spontaan verdwenen nadat er wat IO gedaan werd). Dat is met een kale FreeBSD 10 install verholpen.

[ikkeenjij36]

Ik draai de laatste versie van zfsguru versie 10.1-001

[Verwijderd]

Check je SMART op kabelfouten. Maar dat is ook geen garantie. Verder de kernel logs bekijken of je de reden ziet van detachment. Als je 'vreemde' controllers gebruikt, kun je dit ook hebben met bad sectors maar op een echte controller (HBA) zou dit niet mogen.

[_-= Erikje =-_]

_-= Erikje =-_ schreef op woensdag 18 juni 2014 @ 12:42:

code:

[erik@nas] /mnt/vol01/Downloads# dd if=/dev/zero of=/mnt/vol01/Downloads/test.bin bs=1M count=40960
40960+0 records in
40960+0 records out
42949672960 bytes transferred in 569.238155 secs (75451149 bytes/sec)
[erik@nas] /mnt/vol01/Downloads#

hmm, daar mag ik nog wel wat aan tunen (4x wd 2Tb Z1)

code:

[erik@nas] /mnt/vol01/Downloads# dd if=/dev/zero of=/mnt/vol01/Downloads/test.bin bs=1M count=40960
40960+0 records in
40960+0 records out
42949672960 bytes transferred in 254.225842 secs (168942986 bytes/sec)
[erik@nas] /mnt/vol01/Downloads#

*kuch* toch niet zo'n strak plan om proxmox om je freenas heen te draaien

[ikkeenjij36]

Verwijderd schreef op zaterdag 21 juni 2014 @ 17:35:
Check je SMART op kabelfouten. Maar dat is ook geen garantie. Verder de kernel logs bekijken of je de reden ziet van detachment. Als je 'vreemde' controllers gebruikt, kun je dit ook hebben met bad sectors maar op een echte controller (HBA) zou dit niet mogen.

Ja er zitten cable errors in de schijf die vorige keer verdwenen was.
Niet op deze die nu verdwenen was.
Ik heb idd wat budget controllers erin zitten.
1x een 4 poorts in pci-e en 2x 2 poorts in mijn pci-expres.
Misschien heb je een advies voor een niet al te dure controller?
Heb ook nog een sleuf vrij waar een video kaart in kan.
Minstens een 8 poorts of 2x8?
En waar het beste in te steken dan?

[Quindor]

Je gebruikt balance-rr? Volgens mij is dat niet bepaald RFC compliant. Ik weet dat het een optie is voor bonding in linux, maar verder dan dat zul je het nergens terug vinden.

In wikipedia staat dit : "The linux bonding driver mode typically employed in configurations of this type is balance-rr; the balance-rr mode allows individual connections between two hosts to effectively utilize greater than one interface's bandwidth.".

Daar staat niet bij dat het dus problemen kan veroorzaken met andere hosts die geen linux bonding driver gebruiken (en eventueel) dezelfde setting, maar dat is wel mijn ervaring. Goed voor tussen met 2 systemen waarbij je ook daadwerkelijk 2Gbit moet kunnen halen, maar verder, niet gebruiken. ESXi struikelt waarschijnlijk over de niet standaard load-balancing, round-robin is een big no no in netwerk land, maar prima in iSCSI land.

In principe moet je er vanuit gaan dan 1 systeem naar 1 systeem altijd 1Gbit is. Ook al hebben beide systemen 4 kabels bijvoorbeeld. Er is een heel erg nieuwe standaard die op basis van TCP poort kan balancen, maar dit kan alleen met bepaalde (dure) switches volgens mij. Ook moet je teaming driver/programma dit ondersteunen.

Transmit load-balancing kan zonder meewerken van de switch, receive load-balancing in principe niet. Daarvoor heb je bijvoorbeeld 802.3ad of 802.11AX ook wel LACP genoemd.

Windows zelf kan eigenlijk helemaal niets. Veel gebruikte teaming software is van HP, Intel en Broadcom. Sinds Windows 2012R2 kan windows het zelf ook eindelijk geloof ik!

Ik weet niet waarvoor je 2Gbps wil halen. Maar is misschien iSCSI een optie voor je? iSCSI heeft zijn eigen manier en standaarden van load-balancen en dan hoef je dus niet iets te gebruiken wat officieel lastig ligt. Zelf gebruik ik het vanaf mijn ZFS server (fysiek) naar mijn ESXi doos (cross-cable). Verder dan dat is 1 naar 1 = 1 ben ik bang.

[ Voor 20% gewijzigd door Quindor op 21-06-2014 23:59 ]

[zzattack]

Ik dacht gisteren tegen bedtijd een falende harddrive te horen. Het was al laat dus ik ging pas vanochtend kijken of er wat mis was. De pool was in ieder geval nog online, want ik had zojuist nog een serie gekeken vanaf de NAS. Bleek de pool vanochtend toch weg. Even verder kijken: 3 disks weg, uit dezelfde raidz2 ;X
Begon me toch wel te zweten toen, maar redelijk snel bleek dat 1 SATA power connector niet goed zat. Aangeduwd en ik hoorde meteen disks opspinnen. SMART status gecontroleerd, en de disks die ik gisteren waarschijnlijk hoorde zullen niet hebben kunnen opspinnen: Spin_Retry_Count > 200. Volgens ZFSGuru duidt dit op falende schijven, al is de oorzaak nu vrij zeker de falende SATA connector. Moet ik me hier nu veel zorgen om maken?

[FireDrunk]

Sla de huidige smart waardes van al je disks op, en kijk of er waardes veranderen in de komende dagen/weken.

Zo niet, nergens meer druk over maken.

[zzattack]

Thanks voor je advies, ik ga het in de gaten houden. Fingers crossed

[EnerQi]

Hmm, is het mogelijk om 2 servers in 1 netwerk te hebben? Ik heb nu 2 servers en 2x ZFSguru geinstalleerd maar ik kan de 2e niet gebruiken. Blijkbaar krijgt de PC geen IP adres die ie wel gekregen heeft toen ie via usbstick opstarten. Zou het kunnen zijn dat dezelfde (host)naam een rol hierin speelt?

[Verwijderd]

Wat gebruik je als DHCP server, je internet modem? Normaliter behoort deze per MAC adres een uniek IP te geven. De kans dat de twee computers hetzelfde MAC adres hebben, is vrijwel uitgesloten.

Misschien kijkt jouw DHCP server naar het Samba NetBIOS adres. Dit is standaard wel hetzelfde: ZFSGURU. Je kunt dit aanpassen op de Access->Settings pagina in beta9. Normaliter is dit nodig om in Windows de \\<NetBIOS naam> shortcut te gebruiken in plaats van \\<IP adres>. Dat betekent dat je met \\ZFSguru je server kunt bereiken. Maar die naam moet natuurlijk wel uniek zijn om dit te laten werken.

Je kunt ook handmatig een IP instellen; maar ik zou toch proberen het via DHCP te proberen. Daar is dat voor... Een goede DHCP server geeft ook elke keer hetzelfde IP aan een terugkerende MAC-adres gebruiker. Soms moet je dit handmatig instellen; static DHCP volgens mij.

[EnerQi]

Verwijderd schreef op zondag 22 juni 2014 @ 18:01:
Wat gebruik je als DHCP server, je internet modem? Normaliter behoort deze per MAC adres een uniek IP te geven. De kans dat de twee computers hetzelfde MAC adres hebben, is vrijwel uitgesloten.

Ubee ziggo modem/router . Ik zie hier ook "zfsguru" instaan vandaar mijn vraag .

Misschien kijkt jouw DHCP server naar het Samba NetBIOS adres. Dit is standaard wel hetzelfde: ZFSGURU. Je kunt dit aanpassen op de Access->Settings pagina in beta9. Normaliter is dit nodig om in Windows de \\<NetBIOS naam> shortcut te gebruiken in plaats van \\<IP adres>. Dat betekent dat je met \\ZFSguru je server kunt bereiken. Maar die naam moet natuurlijk wel uniek zijn om dit te laten werken.

Gevonden maar er veranderde niets nadat ik 'm gerenamed had. Misschien onthoudt de router toch de combinatie mac/naam. Even router resetten

Je kunt ook handmatig een IP instellen; maar ik zou toch proberen het via DHCP te proberen. Daar is dat voor... Een goede DHCP server geeft ook elke keer hetzelfde IP aan een terugkerende MAC-adres gebruiker. Soms moet je dit handmatig instellen; static DHCP volgens mij.

Dit heeft mijn voorkeur tenminste niet

[Verwijderd]

Vergeet niet ook de server te herstarten. Dan de modem. Of tegelijkertijd.

Ik heb ook verschillende Ubee modems gehad, maar ik gebruik zelf een DHCP server dus ik kan er weinig over zeggen. Maar toch vreemd als de DHCP server je geen IP geeft? Je kunt ook handmatig 'killall dhclient; dhclient re0' proberen, als re0 je netwerkinterface is.

[EnerQi]

* EnerQi slaat zichzelf

soms is het ook handiger als je de (ethernet)kabel er goed insteekt....

Hoe ben ik erachter gekomen? Nas 1 uitzetten, router resetten en wachten tot nas 2 een ip adres krijgt. Dat gebeurde dus niet, dus controleren we toch maar de kabels. De lampjes bij de poort branden niet en met het opnieuw insteken deden ze het wel

[Verwijderd]

Je kunt ook met 'ifconfig' zien of je een netwerk 'link' hebt. Als dat niet zo is zie je iets als 'media: no carrier'.

[zzattack]

Is dit een geschikte controller (onder FreeBSD)?
http://www.newegg.com/Pro...aspx?Item=N82E16816116039

Kan er maar weinig over vinden, maar het ondersteund schijven >2TB en "Single disk". Ik kan er vrij goedkoop aan komen, maar vraag me af of er niet een hele goede reden is om hem links te laten liggen. Iemand ervaring mee?

[FireDrunk]

Iig niet voor ZFS...

[zzattack]

Vermoeden had ik al
Maar wat scheelt eraan? Corrigerende zooi die je niet uit kunt zetten ofzo?

[FireDrunk]

Het is een RAID controller...

[Extera]

toelie schreef op vrijdag 20 juni 2014 @ 17:07:
@extera en anderen die het interessant vinden.

Ik heb wel wat ervaring met het draaien van VMware ESXi, NFS en ZFS.

Hardware:
Supermicro workstation 7047A-73 (onboard LSI 2308 geflashed met IT firmware)
2 x Xeon E5-2620
128G ECC ram
8 x 4TB HGST HDS724040AL
Intel DC S3700 100G (SLOG)
Samsung 840 EVO 250G (L2ARC)
2 x 500G laptop schijf (datastores)
8GB USB-stick (boot)

Software:
ESXi 5.1 (met LSI 2308 en intel patsburg controllers doorgegeven via vt-d)
OmniOS met napp-it (64G geheugen en 8 vcpu, 8 x 4TB in RAID-Z2, slog partitie 20G)

Ik kan helaas de benchmarks niet meer vinden maar synced sequential writes zaten rond de 180mb/s met AS SSD benchmark. Server draait met gemak 10 virtuele machines, alles voelt lekker snel aan. En nog veel belangrijker, alles is heerlijk stabiel.

Intel DC S3700 heb ik gekozen op aanraden van OpenSolaris derived ZFS NAS op hardforum. Heb ik nooit spijt van gehad. Was veel sneller en stabieler in snelheid dan de samsung evo. Samsung evo is prima voor L2ARC. Al komt ongeveer 75% direct uit de 56G ARCsize die hij heeft gepakt.

ESXi 5.5 wilde mijn patsburg controller, waar de ssd's op zitten, niet meer doorgeven via vt-d. Ook heeft ESXi 5.5 nog een vervelende NFS bug. Toch blijf ik zweren bij NFS voor ESXi, al zoveel problemen met iSCSI gehad. NFS kan vele malen beter tegen kleine netwerkdips en vertragingen.

Een tweede server die 64G ram en maar 1 xeon cpu heeft, maar verder identiek is, draait elk half uur een replicatie van de NFS datastore via netcat en zfs send/snapshotting.

ZFS machines hangen in het domein zodat direct domein rechten op de smb shares kunnen worden uitgedeeld via windows machines. Dit in combinatie met windows ondersteunde snapshots (previous versions) maakt het geheel heerlijk om mee te werken.

Mochten jullie meer willen weten dan vraag het maar.

Bedankt voor de info
Je hebt geen bechmarks gedraait om te kijken welke snelheden je nu haalt?
Hoe de VM's draaien in mijn omgeving weet ik niet, ik ga alle VM's pas migreren naar de nieuwe datastore als ik helemaal klaar ben met testen.

Met iSCSI heb ik nooit problemen gehad, en ik denk dat ik dat nu ook maar ga gebruiken. Het kost best veel moeite om goede performance uit NFS te halen icm ESXi, wat mij betreft te veel.

Het nadeel van iSCSI vind ik dat je 1 file hebt, je extend, en daar zit alles in.
Ik maak elke dag een snapshot en stuur deze naar een backup datastore (1x 4TB disk).
Wil je 1 VM terugzetten vanuit een backup, dan moet je die uit je uit de iSCSI extend gaan vissen.
Alternatief daarvoor is het backuppen van je VMs, met bijvoorbeeld Veeam.

Voor nu ga ik iSCSI gebruiken, en als de financiën het weer toelaten zal ik eens gaan testen met goede SSDs als SLOG.

[FireDrunk]

Je kan ook even kijken naar Veeam, die kan gewoon individuele VM's backuppen.

[Extera]

Extera schreef op maandag 23 juni 2014 @ 14:22:
Wil je 1 VM terugzetten vanuit een backup, dan moet je die uit je uit de iSCSI extend gaan vissen.
Alternatief daarvoor is het backuppen van je VMs, met bijvoorbeeld Veeam.

[FireDrunk]

Ja precies, ik slaap nog

Maar dat is toch niet zo heel erg? Tuurlijk is het bij NFS iets makkelijker (ZFS Snapshot mounten, VM eventueel stoppen, files kopieren, VM eventueel opnieuw registeren, en klaar).

Maar ja, hoe vaak doe je nou zoiets?

[CurlyMo]

CurlyMo schreef op woensdag 30 november 2011 @ 17:52:
Na veel pijn en moeite ben ik nu overgestapt (over kopiëren kost namelijke erg veel tijd) van Solaris 11 Express naar FreeBSD (ZFSGuru) en van ZFS Pool 31 naar 28. Het enige wat ik niet werkend krijg is de vfs recycle module in Samba. Het configuratie bestand is vrijwel hetzelfde als ik gebruikte in Solaris waar de recycle module wel werkte. Iemand die het wel werkende heeft?

Even een drie jaar oud probleem als opgelost markeren

Het probleem en de oplossing wordt hier beschreven:
https://bugzilla.samba.org/show_bug.cgi?id=8637

De oplossing was dus het toevoegen van de crossrename vfs module. Zo ziet mijn huidige share eruit:

code:

[data]
    comment = Data Gebruikers
    path = /data/%U
    writable = yes
    browseable = yes
    read only = no
    follow symlinks = yes
    wide links = yes
    valid users = user1 user2
    vfs objects = recycle, acl_xattr, zfsacl, crossrename
    crossrename:sizelimit = 1000000
    recycle:repository = /data/recycle/%U
    recycle:keeptree = yes
    recycle:versions = yes
    recycle:touch = yes
    recycle:maxsize = 0
    dfree command = /usr/sbin/smbdiskspace data
    nfs4:mode = special
    nfs4:acedup = merge
    nfs4:chown = yes
    map acl inherit = yes
    inherit permissions = yes
    posix locking = yes
    nt acl support = yes
    store dos attributes = yes
    inherit acls = Yes
    inherit owner = Yes
    map archive = No
    map readonly = no

Lang leve documentatie

Dan blijkt er alsnog een bug in de vfs crossrename module te zitten waarvoor je deze patch nodig hebt (mits je aclmode=restrict gebruikt):
https://lists.samba.org/a...cal/2014-June/100720.html

When a user runs a ZFS filesystem with aclmode=restrict, then all chmod
operations will be restricted by ZFS and fail with "Operation not
permitted". In the vfs crossrename module, a move will fail when the
chmod operation returns an error and will therefor lead to undefined
behavior on a ZFS filesystem with aclmode=restrict.

[toelie]

Extera schreef op maandag 23 juni 2014 @ 14:22:
[...]


Bedankt voor de info
Je hebt geen bechmarks gedraait om te kijken welke snelheden je nu haalt?
Hoe de VM's draaien in mijn omgeving weet ik niet, ik ga alle VM's pas migreren naar de nieuwe datastore als ik helemaal klaar ben met testen.

Met iSCSI heb ik nooit problemen gehad, en ik denk dat ik dat nu ook maar ga gebruiken. Het kost best veel moeite om goede performance uit NFS te halen icm ESXi, wat mij betreft te veel.

Het nadeel van iSCSI vind ik dat je 1 file hebt, je extend, en daar zit alles in.
Ik maak elke dag een snapshot en stuur deze naar een backup datastore (1x 4TB disk).
Wil je 1 VM terugzetten vanuit een backup, dan moet je die uit je uit de iSCSI extend gaan vissen.
Alternatief daarvoor is het backuppen van je VMs, met bijvoorbeeld Veeam.

Voor nu ga ik iSCSI gebruiken, en als de financiën het weer toelaten zal ik eens gaan testen met goede SSDs als SLOG.

Er draaien nu al flink wat drukke productie servers op, dus aan die benchmarks zou je niet veel hebben. Maar ZFS NFS met standard sync op ESXi is altijd traag zonder goede SLOG.

Ik had bij mijn ZFS-iSCSI-ESXi test een probleem dat ESXi tijdens het booten de target niet kon vinden (duh!! gevirtualiseerde zfs machine was uiteraard nog niet opgestart) en toen lekker 15 minuten bleef wachten voordat ie uiteindelijk wilde doorstarten.

Backup is met NFS inderdaad een stukje makkelijker. Maar je zou eens kunnen testen of je met zfs clone een clone van je file extend via iSCSI als backup datastore kan mounten op ESXi. Dan kun je ook redelijk gemakkelijk hele VM's terugzetten via SSH.

Andere optie is om volumes binnen VM's die performance nodig hebben (bijvoorbeeld SQL data en log volumes) als iSCSI volume te mounten binnen je VM. Hierdoor wordt het geheel wel wat complexer.

Ik zal nog even op zoek gaan naar die write benchmarks van de intel S3700 als SLOG.

[FireDrunk]

Denk dat ESXi het niet leuk vind, om 2 (verschillende) LUN's met dezelfde interne ID's te zien op twee verschillende paden.

Je kan het allicht proberen, maar wees gewaarschuwd

[ Voor 4% gewijzigd door FireDrunk op 24-06-2014 12:18 ]

[CurlyMo]

@CiPHER, zouden jullie de ipsec kernel modules kunnen leveren van:

code:

[root@server /usr/src]# uname -a
FreeBSD server.workgroup 10.0-STABLE FreeBSD 10.0-STABLE #0: Sun Apr 20 21:20:08 UTC 2014     jason@zfsguru:/usr/obj/tmpfs/2-source/sys/NEWCONS-OFED-POLLING-ALTQ  amd64

En dit in het vervolg ook standaard doen?

Ik wil graag een L2TP VPN opzetten, maar daarvoor is kernel ondersteuning nodig die nu niet in ZFSGuru wordt geleverd:
https://forums.freebsd.org/viewtopic.php?&t=26755

[FireDrunk]

Waarom kan je die niet zelf compileren? Is maar een paar minuten werk.
Er is toch een kernel sources service?

[CurlyMo]

Ik kijk nooit naar de services Ik zal even kijken dan.

[matty___]

CurlyMo schreef op woensdag 25 juni 2014 @ 00:22:
@CiPHER, zouden jullie de ipsec kernel modules kunnen leveren van:

code:

[root@server /usr/src]# uname -a
FreeBSD server.workgroup 10.0-STABLE FreeBSD 10.0-STABLE #0: Sun Apr 20 21:20:08 UTC 2014     jason@zfsguru:/usr/obj/tmpfs/2-source/sys/NEWCONS-OFED-POLLING-ALTQ  amd64

En dit in het vervolg ook standaard doen?

Ik wil graag een L2TP VPN opzetten, maar daarvoor is kernel ondersteuning nodig die nu niet in ZFSGuru wordt geleverd:
https://forums.freebsd.org/viewtopic.php?&t=26755

Let je er wel op dat dit uit 2011 is.

[CurlyMo]

Klopt, maar zoveel veranderd er ook weer niet.

Toch ben ik een andere weg ingeslagen door OpenVPN te proberen. Dit lukt me in zoverre dat ik verbinding kan maken en mijn server adres kan pingen. Echter kan andere adressen in het lokale netwerk niet pingen en heb ik ook geen internet verbinding. Zijn er mensen die OpenVPN op FreeBSD werkend hebben gekregen?

[Verwijderd]

@CurlyMo: pagina Services->Manage->Install services->Misc->FreeBSD Sourcecode. Die installeren en je hebt /usr/src zoals de systeemversie is gebouwd; dus perfect in sync. Heb je hulp nodig, liever per DM. Dan voel ik me vrijer om uitgebreid te bespreken.

En als je een NAT relay wilt maken dan heb je ook in /etc/rc.conf nodig:
gateway_enable="YES"
(kan ook met sysctl)

En je hebt dan pf firewall nodig (pf_enable="YES" in /etc/rc.conf) en een geschikte configuratie in /etc/pf.conf. ZFSguru heeft volgens mij al wat staan in /etc/pf.conf, kun je als basis gebruiken eventueel.

[ Voor 39% gewijzigd door Verwijderd op 25-06-2014 21:53 ]

[CurlyMo]

Dank, maar ik heb de kernel module niet meer nodig gezien ik OpenVPN aan het proberen ben.

Weet je misschien ook wat ik in moet stellen in de pf firewall?

[ Voor 27% gewijzigd door CurlyMo op 25-06-2014 21:57 ]

[Verwijderd]

U vraagt wij leveren.

code:

## standard internal LAN-interface - modify re0 with the name of your NIC!
if_lan = "wlan0"
## external WAN-interface - only enable if you have two network interfaces
if_wan = "rl0"


## TRUSTED
table <trusted> { 10.0.0.1, 10.0.0.50, 10.0.0.51, 10.0.0.52, 10.0.0.53, 10.0.0.54, 10.0.0.55 }
protected_ports = "{ 22, 80, 111:1024, 2049 }"
open_ports = "{ 53 }"

### OPTIONS

## block-policy controls what happens when a packet is denied.
## return: send a TCP/ICMP reply that the connection is denied (exposes the host)
## drop: kills the package so that the server becomes stealth (causes timeouts)
set block-policy return
## log interface
set loginterface $if_lan
## skip loopback adaptor
set skip on lo

### SCRUB
scrub in all

### NAT
## Network Address Translation
## allows your server to function as gateway, sharing one IP address with many
## computers on your LAN. This function is typically taken care of by your
## internet modem (often incorrectly called a 'router').
## replace $interface by the external interface (the internet connection)
## note: do not forget to set gateway_enable="YES" in /etc/rc.conf
nat on $if_wan from !($if_wan) to any -> ($if_wan)

### RULES
## general firewall rules

## default rules (if no other rules match, this will be the default)
## open default policy (insecure)
#pass in all
#pass out all keep state
## closed default policy (secure but impractical)
#block in log all
#block out log all
## default safe policy (blocks inward but allows outward traffic)
block in log all
pass out all keep state

# hier je rules; maar om te beginnen gewoon ruim openzetten en testen:
pass in all

[Berkeley]

Sinds van de week mijn storage server(2x1Tb ) eens op ZFS gegooid. Wat werkt dit toch prachtig!

[Lekkerbek]

Hoi, sluit net een scherm aan en zie:

(da2:mps0:0:2:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read error)
(da2:mps0:0:2:0): Info: 0x58682318
(da2:mps0:0:2:0): Error 5, Unretryable error
(da2:mps0:0:2:0): READ(10). CDB: 28 00 58 67 f4 c0 00 00 40 00
(da2:mps0:0:2:0): CAM status: SCSI Status Error

En dat een aantal keer.

Echter onder smart zie ik niets, onder smart DA2 ook niet, tevens op de pool geen read errors.

Ideeen?


Ook zegt de ZFSGUI ineens dat ik het onder VMWorkstation draai....? Vreemd, wel mooi weer buiten :-)

[FireDrunk]

Die detectie is omdat je waarschijnlijk onder ESXi draait?

En de error is een UER, en zolang ZFS niet klaagt, hoef je je er niet druk over te maken.

[Verwijderd]

Detectie van virtualisatie is nog niet goed, maar het idee is wel leuk dat je dat kunt zien op de statuspagina. Alleen VirtualBox wordt goed ondersteund, omdat hier heel specifieke APIC informatie is te zien in de kernel boot message ('dmesg'). Daar kijkt ZFSguru naar. Er zijn ook utilities om BIOS informatie uit te lezen, dan kun je op een nette manier zien of je een VMWare/ESXi/etc product draait. Dat is nog iets voor de toekomst.

[FireDrunk]

Je kan volgens mij via dmidecode wel uitlezen dat de Platform Manufacturer VMWare inc is.

[Verwijderd]

Maar dan weet ik nog niet of het ESXi is enzovoorts. Althans, dat moet ik nog een keer uitzoeken hoe dat werkt. Want wel leuk als je kunt zien met welk product het gevirtualiseerd is.

[FireDrunk]

Ik zal eens kijken of het makkelijk te achterhalen is, misschien binnenkort eens tijd voor

[Verwijderd]

@CurlyMo:

Heb je routing aan staan? Ik weet het niet voor FreeBSD, maar voor linux moet je het volgende doen:

echo 1>/proc/sys/net/ipv4/ip_forward

[Verwijderd]

Met routing heb je nog geen NAT gateway, wat is wat hij wilt volgens mij.

[zzattack]

... wat bijvoorbeeld met pf snel geregeld is:
/etc/rc.conf: pf_enable="YES",
/etc/pf.conf:

code:

ext_if=em0
vpn_if="tun0"
vpn_net="10.8.0.0/24"

set skip on $vpn_if
nat on $ext_if from $vpn_net to any -> $ext_if

assuming the obvious, uiteraard

[ Voor 9% gewijzigd door zzattack op 27-06-2014 17:15 ]

[CurlyMo]

Ik wil natuurlijk best wel mijn OpenVPN config en wensen hier bespreken, maar weet niet of dat de juiste plek is...

[Verwijderd]

Nou eigenlijk vind ik dat je best elders een topic kan openen. En even goed op een rij zet wat er nu wel gelukt is en wat niet. Vermeld dit ook in je topic.

[CurlyMo]

Zal ik doen wanneer ik weer tijd heb om te testen. Dat is het nadeel van OpenVPN. Het is moeilijk om lokaal te testen.

[Beninho]

Ik draai een ubuntu 14.04 met ZFS-native en hieraan 6 schijven.

Ik krijg in de console allerlei fouten op /dev/sdb

Ik typ er even een aantal over.. want ik weet niet waar deze logs staan.
---
ata2.00 status: DRY ERR
end request i/o error dev sdb, sector 3870265416
etc..
---
Is dit de schijf of een fout op het moederbord?

Het lijkt er in elk geval op dat die schijf dus aan het stukgaan is. Of al is. Hoe kan ik dit verifieren? "sudo zpool status" geeft aan online. Verder niks. Bij laatste scrub (gisteren) heeft de pool 147M resilverd.

code:

 pool: pool
 state: ONLINE
  scan: resilvered 147M in 0h0m with 0 errors on Tue Jul  1 00:37:18 2014
config:

    NAME                                          STATE     READ WRITE CKSUM
    pool                                          ONLINE       0     0     0
      raidz2-0                                    ONLINE       0     0     0
        ata-WDC_WD20EARX-00PASB0_WD-WCAZAA032642  ONLINE       0     0     0
        ata-ST2000DL003-9VT166_5YD9Z9QQ           ONLINE       0     0     0
        ata-WDC_WD20EFRX-68EUZN0_WD-WMC4M3237416  ONLINE       0     0     0
        ata-WDC_WD20EARX-00PASB0_WD-WMAZA5862730  ONLINE       0     0     0
        ata-WDC_WD20EFRX-68AX9N0_WD-WCC300359484  ONLINE       0     0     0
        ata-WDC_WD20EFRX-68AX9N0_WD-WCC300374991  ONLINE       0     0     0

Hoe kom er ik achter wat er aan de hand is?

-edit--- dit haal ik uit dmesg--

code:

[   39.246092] ata2.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
[   39.246103] ata2.00: irq_stat 0x40000008
[   39.246111] ata2.00: failed command: READ FPDMA QUEUED
[   39.246123] ata2.00: cmd 60/08:00:38:c9:e9/00:00:e5:00:00/40 tag 0 ncq 4096 in
[   39.246123]          res 41/40:00:38:c9:e9/00:00:e5:00:00/40 Emask 0x409 (media error) <F>
[   39.246129] ata2.00: status: { DRDY ERR }
[   39.246133] ata2.00: error: { UNC }
[   39.257493] ata2.00: configured for UDMA/133
[   39.257537] sd 1:0:0:0: [sdb] Unhandled sense code
[   39.257542] sd 1:0:0:0: [sdb]
[   39.257546] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[   39.257551] sd 1:0:0:0: [sdb]
[   39.257555] Sense Key : Medium Error [current] [descriptor]
[   39.257562] Descriptor sense data with sense descriptors (in hex):
[   39.257565]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
[   39.257580]         e5 e9 c9 38
[   39.257587] sd 1:0:0:0: [sdb]
[   39.257593] Add. Sense: Unrecovered read error - auto reallocate failed
[   39.257597] sd 1:0:0:0: [sdb] CDB:
[   39.257600] Read(10): 28 00 e5 e9 c9 38 00 00 08 00
[   39.257614] end_request: I/O error, dev sdb, sector 3857303864
[   39.257652] ata2: EH complete
[   39.504336] init: failsafe main process (894) killed by TERM signal

en hier een knipje uit kern.log

code:

Jul  1 18:21:01 ubuntu kernel: [ 1683.407723] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jul  1 18:21:01 ubuntu kernel: [ 1683.407727] sd 1:0:0:0: [sdb]
Jul  1 18:21:01 ubuntu kernel: [ 1683.407730] Sense Key : Medium Error [current] [descriptor]
Jul  1 18:21:01 ubuntu kernel: [ 1683.407737] Descriptor sense data with sense descriptors (in hex):
Jul  1 18:21:01 ubuntu kernel: [ 1683.407739]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
Jul  1 18:21:01 ubuntu kernel: [ 1683.407754]         e6 ad 63 f8
Jul  1 18:21:01 ubuntu kernel: [ 1683.407761] sd 1:0:0:0: [sdb]
Jul  1 18:21:01 ubuntu kernel: [ 1683.407766] Add. Sense: Unrecovered read error - auto reallocate failed
Jul  1 18:21:01 ubuntu kernel: [ 1683.407771] sd 1:0:0:0: [sdb] CDB:
Jul  1 18:21:01 ubuntu kernel: [ 1683.407773] Read(10): 28 00 e6 ad 63 60 00 01 00 00
Jul  1 18:21:01 ubuntu kernel: [ 1683.407787] end_request: I/O error, dev sdb, sector 3870123000
Jul  1 18:21:01 ubuntu kernel: [ 1683.411655] ata2: EH complete
Jul  1 18:21:04 ubuntu kernel: [ 1687.032662] ata2.00: exception Emask 0x0 SAct 0x1f SErr 0x0 action 0x0
Jul  1 18:21:04 ubuntu kernel: [ 1687.036568] ata2.00: irq_stat 0x40000008
Jul  1 18:21:04 ubuntu kernel: [ 1687.040380] ata2.00: failed command: READ FPDMA QUEUED
Jul  1 18:21:04 ubuntu kernel: [ 1687.044180] ata2.00: cmd 60/00:10:60:68:ad/01:00:e6:00:00/40 tag 2 ncq 131072 in
Jul  1 18:21:04 ubuntu kernel: [ 1687.044180]          res 41/40:00:b8:68:ad/00:00:e6:00:00/40 Emask 0x409 (media error) $
Jul  1 18:21:04 ubuntu kernel: [ 1687.051825] ata2.00: status: { DRDY ERR }
Jul  1 18:21:04 ubuntu kernel: [ 1687.055646] ata2.00: error: { UNC }
Jul  1 18:21:04 ubuntu kernel: [ 1687.067611] ata2.00: configured for UDMA/133
Jul  1 18:21:04 ubuntu kernel: [ 1687.067669] sd 1:0:0:0: [sdb] Unhandled sense code
Jul  1 18:21:04 ubuntu kernel: [ 1687.067674] sd 1:0:0:0: [sdb]
Jul  1 18:21:04 ubuntu kernel: [ 1687.067678] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jul  1 18:21:04 ubuntu kernel: [ 1687.067682] sd 1:0:0:0: [sdb]
Jul  1 18:21:04 ubuntu kernel: [ 1687.067686] Sense Key : Medium Error [current] [descriptor]
Jul  1 18:21:04 ubuntu kernel: [ 1687.067692] Descriptor sense data with sense descriptors (in hex):
Jul  1 18:21:04 ubuntu kernel: [ 1687.067695]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
Jul  1 18:21:04 ubuntu kernel: [ 1687.067710]         e6 ad 68 b8
Jul  1 18:21:04 ubuntu kernel: [ 1687.067717] sd 1:0:0:0: [sdb]
Jul  1 18:21:04 ubuntu kernel: [ 1687.067723] Add. Sense: Unrecovered read error - auto reallocate failed
Jul  1 18:21:04 ubuntu kernel: [ 1687.067727] sd 1:0:0:0: [sdb] CDB:
Jul  1 18:21:04 ubuntu kernel: [ 1687.067730] Read(10): 28 00 e6 ad 68 60 00 01 00 00
Jul  1 18:21:04 ubuntu kernel: [ 1687.067744] end_request: I/O error, dev sdb, sector 3870124216
Jul  1 18:21:04 ubuntu kernel: [ 1687.071625] ata2: EH complete
Jul  1 18:21:09 ubuntu kernel: [ 1691.856521] ata2.00: exception Emask 0x0 SAct 0x1f SErr 0x0 action 0x0
Jul  1 18:21:09 ubuntu kernel: [ 1691.860428] ata2.00: irq_stat 0x40000008

Ik ben er bijna van overtuigd dat mijn /dev/sbd aan het overleiden is.. maar klopt dit, welke schijf is dat.. ik heb disk-by-id methode toegepast..

[ Voor 69% gewijzigd door Beninho op 01-07-2014 19:15 ]

[analog_]

Door je log meldingen te googlen, door in dit topic te zoeken op sleutelwoord 'kapot', 'ster'(vende/f..), ubuntu disk test, ...

[Verwijderd]

Een bad sector betekent niet dat je schijf is overleden hoor.

En wat ik doe is vaak even wat reads op de schijf om te kijken of hij goed functioneert:

dd if=/dev/sdb of=/dev/null bs=1M count=1000

[Beninho]

sbd geeft 048576000 bytes (1.0 GB) copied, 10.0968 s, 104 MB/s
sdc geeft 1048576000 bytes (1.0 GB) copied, 6.75121 s, 155 MB/s
sda geeft 1048576000 bytes (1.0 GB) copied, 9.35003 s, 112 MB/s
sde geeft 1048576000 bytes (1.0 GB) copied, 6.88092 s, 152 MB/s

Of "kan" je deze resultaten niet met elkaar vergelijken en constateren dat sdb een duidelijk mindere read heeft dan de overige.. in dat scenario presteert de sda ook niet bijzonder goed.

edit
net e2fsck -c -c gevonden.. maar dat is alleen voor ext partities, tenminste, die melding krijg ik.

mis ik iets.. ? heb net getracht te gokken welke schijf het was door er 1 offline te gooien met zpool pool offline ata-WDC_WD20EFRX-68EUZN0_WD-WMC4M3237416 .. maar dan kan ik nog wel gewoon de read tests uitvoeren.

[ Voor 26% gewijzigd door Beninho op 01-07-2014 19:33 ]

[ikkeenjij36]

Ik heb 1 schijf die op failing now staat in de smart
Wat is nu de weg te gaan om hem te vervangen met een 4tb wd red?