Acties:
  • 0 Henk 'm!

  • Mystic Spirit
  • Registratie: December 2003
  • Laatst online: 28-09 05:58

Mystic Spirit

PSN: mr_mysticspirit

ja 113 (piek) keer kak.... Zat dat het modelleren van een paar weken terug er niet zo gek ver naast en was het zelfs nog positief.

Zijn de RED's een beetje te draaien met een 512 blocksize? Dat kan ik nog wel even proberen en natuurlijk ga ik de pool ook nog even weer afbreken en naar 6 schijven RZ2 brengen om te kijken wat dat oplevert.

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
ZFSguru gebruikt in de interface de waarden die het van ZFS krijgt.

zpool list geeft de ruwe ruimte weer. Bij RAID-Z2 is dat dus inclusief de pariteit. Ook de gebruikte ruimte is dus inclusief pariteit.
zfs list geeft de bruikbare ruimte weer. Dat is exclusief overhead, exclusief pariteit.

19T betekent 19TiB en dat lijkt me correct voor 7x 3TB in RAID-Z2. 21TB ~= 19TiB. Effectief kun je gebruiken: 5x3TB= 15TB = 13,64TiB. Wat klopt er niet volgens jou? Misschien dat je het nog even op een rijtje kunt zetten want met je verschillende posts raak ik een beetje in de war. :P

Edit: ah je bent met ashift aan het spelen. En je test hoeveel ruimte je kwijt bent met een dergelijke niet-optimale config. I see.

[ Voor 10% gewijzigd door Verwijderd op 20-11-2013 20:17 ]


Acties:
  • 0 Henk 'm!

  • Mystic Spirit
  • Registratie: December 2003
  • Laatst online: 28-09 05:58

Mystic Spirit

PSN: mr_mysticspirit

Ja ik ben met 4k dus ashift=12 met een config van 7 disk in RAID Z2 bezig. Mijn berekening is toch wel behoorlijk ongunstig.

In een niet ZFS situatie zou mijn config dit opleveren:
schijf TB TiB (/1,024) data pariteit pool
132.92968752.92968752.9296875
232.92968752.92968752.9296875
332.92968752.92968752.9296875
432.92968752.92968752.9296875
532.92968752.92968752.9296875
632.92968752.92968752.9296875
732.92968752.92968752.9296875
totaal2120.507812514.64843755.85937520.5078125


In de situatie die ik nu heb levert het 19TiB op wat sowieso al 1,5 TIB minder is. Uit mijn dataset blijkt ook nog eens dat ik effectief bij het schrijven van de files niet 1 TiB = 1,4 TiB inclusief pariteit haal, maar dat het rond de 1TiB = 1,6 TiB ligt. Wat nog eens een 15% verlies inhoud. Daarmee komt het totale verlies van de 7e schijf op ongeveer 65%. Dat is natuurlijk alles behalve goed voor je €/GB ratio.

Acties:
  • 0 Henk 'm!

  • ]Byte[
  • Registratie: April 2000
  • Laatst online: 13-09-2020
Wat een drama...
Zelfs op mijn SSD-pool haal ik dramatische snelheden.

ZFSguru 0.2.0-beta8 (9.2-001) pool benchmark
Pool : pool2 (928G, 0% full)
Test size : 64 GiB
normal read : 2 GB/s
normal write : 286 MB/s
I/O bandwidth : 36 GB/s

Ik heb dit nu getest met de LSI Logic SAS-controller.
Ik heb de VM aangemaakt met 16GB mem, 2 cpu's met 2 cores per cpu.
(met de M1015's in passthru hangt de hele server zodra de VM boot. dat doe ik dus maar ff niet meer)

Heeft iemand nog een idee?
Anders ga ik denk ik maar weer terug naar ZFSguru op fysiek ijzer en de ML110 op ESX laten.
(het was zo mooi geweest als het wel goed zou werken...)

Acties:
  • 0 Henk 'm!

  • Mystic Spirit
  • Registratie: December 2003
  • Laatst online: 28-09 05:58

Mystic Spirit

PSN: mr_mysticspirit

Ik heb ook M1015 (flashed naar LSI) in passtrough, maar draai ESXi 5.1 en ZFSguru 0.2.0-beta8 (9.1-006). Er hangt tot nog toe niks en perforance lijkt in orde.
Misschien dus andere ESXi proberen of andere ZFSguru?

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
@Mystic: je rekent verkeerd. Van TB naar TiB is niet /1024 delen.
3TB = 2,728 TiB en geen 2,929 TiB.

@]byte[: probeer je passthrough opnieuw te doen. Dat trucje hoor ik soms van ESXi icm BSD + vt-d passthrough. Maar geen idee of dat helpt. ESXi is wat gevoelig. Als het eenmaal wel goed werkt kan het prima performen. Je kunt eens kijken met top en shift+S wat je systeemverbruik is (interrupts/devicekerneldriver).

[ Voor 61% gewijzigd door Verwijderd op 20-11-2013 22:10 ]


Acties:
  • 0 Henk 'm!

  • ]Byte[
  • Registratie: April 2000
  • Laatst online: 13-09-2020
@Mystic:
ik zal 5.1 eens downloaden en testen.
Ik gebruik nu 5.5 met 9.2-001.
Welke fw heb je op de M1015's zitten? P17?
Welke getallen haal jij nu met benchmarks?

Acties:
  • 0 Henk 'm!

  • Mystic Spirit
  • Registratie: December 2003
  • Laatst online: 28-09 05:58

Mystic Spirit

PSN: mr_mysticspirit

@ Cipher: Verkeerde TiB's rekenen helpt natuurlijk niet echt 8)7 dan valt het wel mee, want dan is het verlies ongeveer 15% dat is behoorlijk acceptabel denk ik.

@]Byte[: Ik weet niet meer welke firmware ik geflashed heb, maar die heb ik iets van 4 maanden geleden geflashed en ik heb toen denk ik gewoon de laatste gepakt. Ik weet niet van wanneer 17 is, maar denk dat development redelijk stil staat voor deze oude controler.
Ik heb nog niet echt gebenched omdat ik bezig was met mijn capaciteits-issue.
Nu dat is opgelost wil ik best even benchen. Bench je met de ZFSguru ingebouwde benchmark?

Acties:
  • 0 Henk 'm!

  • ]Byte[
  • Registratie: April 2000
  • Laatst online: 13-09-2020
Mystic Spirit schreef op woensdag 20 november 2013 @ 22:24:
[...] Bench je met de ZFSguru ingebouwde benchmark?
Ja

Acties:
  • 0 Henk 'm!

  • Mystic Spirit
  • Registratie: December 2003
  • Laatst online: 28-09 05:58

Mystic Spirit

PSN: mr_mysticspirit

Ik heb een heel andere firmware dan p17 zie ik nu. Dit staat in de change log van de firmware die ik heb geflashed.

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Release date: 10/15/12

====================== 
Supported Controllers:
======================

MegaRAID SAS 9240-4i
MegaRAID SAS 9240-8i

Component:
=========
SAS MegaRAID Firmware Release for MegaRAID Controllers
Release date: 10/15/2012


Version Numbers:    
===============

Current Firmware Package:     20.10.1-0119  (Merged) 
Firmware 2.130.364-1847
WebBIOS 4.0-59-e_48-Rel 
ROMENV 1.08
BootBlock 2.02.00.00-0001 
NVDATA 3.09.03-0043
PCLI 03.02.20
Hii 1.31.00
UEFI_Driver 0x05180000
FCODE 4.12.05.00
BIOS 4.31.00


Een snelle 8GiB bench levert het volgende op:
code:
1
2
3
4
5
6
ZFSguru 0.2.0-beta8 (9.1-006) pool benchmark
Pool            : ZFS_RZ2 (19T, 8% full)
Test size       : 8 GiB
normal read : 462 MB/s
normal write    : 419 MB/s
I/O bandwidth   : 11 GB/s

[ Voor 27% gewijzigd door Mystic Spirit op 20-11-2013 22:35 ]


Acties:
  • 0 Henk 'm!

  • ]Byte[
  • Registratie: April 2000
  • Laatst online: 13-09-2020
P17 is van 19-JUL-2013
Hoe is je pool opgebouwd? Z2? hoeveel spindels?

[ Voor 52% gewijzigd door ]Byte[ op 20-11-2013 22:42 ]


Acties:
  • 0 Henk 'm!

  • Mystic Spirit
  • Registratie: December 2003
  • Laatst online: 28-09 05:58

Mystic Spirit

PSN: mr_mysticspirit

Ik weet niet meer hoe ik op deze firmware uitgekomen ben, maar ik weet wel dat het een hele zoektocht was en ik op een forum terecht kwam waar deze werd aangeraden voor ESXi en ZFS. Ik kan de firmware wel ergens uploaden voor je.

Benchmark 64GiB
code:
1
2
3
4
5
6
ZFSguru 0.2.0-beta8 (9.1-006) pool benchmark
Pool            : ZFS_RZ2 (19T, 8% full)
Test size       : 64 GiB
normal read : 652 MB/s
normal write    : 342 MB/s
I/O bandwidth   : 29 GB/s

Ik heb trouwens maar 6GB memory toegewezen en een enkele core, dus het kan mogelijk sneller als ik meer toewijs.

EDIT:

Benchmark 128 GiB
code:
1
2
3
4
5
6
ZFSguru 0.2.0-beta8 (9.1-006) pool benchmark
Pool            : ZFS_RZ2 (19T, 8% full)
Test size       : 128 GiB
normal read : 548 MB/s
normal write    : 340 MB/s
I/O bandwidth   : 29 GB/s

[ Voor 16% gewijzigd door Mystic Spirit op 20-11-2013 23:02 ]


Acties:
  • 0 Henk 'm!

  • ]Byte[
  • Registratie: April 2000
  • Laatst online: 13-09-2020
Verwijderd schreef op woensdag 20 november 2013 @ 22:07:
@]byte[: probeer je passthrough opnieuw te doen. Dat trucje hoor ik soms van ESXi icm BSD + vt-d passthrough.
Ik heb het al 3 keer geprobeerd, diverse reboots etc. maar zodra ik de VM start...
1 * PSOD
2 * volledig hangend systeem (zelfs de [NumLock] op het Keyboard reageerde niet meer)
Maar in naam van de wetenschap... Ik zal het nog eens proberen. :)
Ik moet zo weg, maar laat het jullie morgen wel even weten wat er uitgekomen is,

  • CU2morO
  • Registratie: September 2001
  • Laatst online: 05-08 11:56
Is er trouwens een goede reden dat er voor RAID-Z (RAID5 equiv.) geadviseerd wordt om 3 óf 5 schijven te nemen? Ik was net van plan 4x 3TB of 4x 4TB te gaan nemen.

In de topicstart staat dat het handig is om machten van 2 te gebruiken voor het aantal effectieve schijven, maar ga je dat direct in performance merken als dit niet precies klopt?

[ Voor 35% gewijzigd door CU2morO op 21-11-2013 05:23 ]


  • Mystic Spirit
  • Registratie: December 2003
  • Laatst online: 28-09 05:58

Mystic Spirit

PSN: mr_mysticspirit

Dat is precies wat ik nu aan het onderzoeken ben. De performance is het probleem niet. Het is vooral dat je er ruimte door verliest omdat de 4k block size niet goed past en je dus van iedere 4k op een schijf <4k daadwerkelijk gebruiken kan.

  • ]Byte[
  • Registratie: April 2000
  • Laatst online: 13-09-2020
Misschien dat dit een puntje van aandacht is qua standaardisering inzake TB / TiB in een toekomstige versies.
Gebruik 1 eenheid, en geen verschillende door elkaar.

  • CU2morO
  • Registratie: September 2001
  • Laatst online: 05-08 11:56
Mystic Spirit schreef op donderdag 21 november 2013 @ 06:54:
Dat is precies wat ik nu aan het onderzoeken ben. De performance is het probleem niet. Het is vooral dat je er ruimte door verliest omdat de 4k block size niet goed past en je dus van iedere 4k op een schijf <4k daadwerkelijk gebruiken kan.
Enig idee hoe groot dat verlies is?

  • Mystic Spirit
  • Registratie: December 2003
  • Laatst online: 28-09 05:58

Mystic Spirit

PSN: mr_mysticspirit

Dat is dus eigenlijk niet te zeggen. Iedere situatie is anders. Zoals het er voor mij nu uitziet lijkt het ongeveer 15% bij 5 data disks, maar voor 3 data disks kan het weer anders zijn. Het is ook nog eens afhankelijk van de grote van de files die je hebt.

De keuze voor 4TB schijven was in ieder geval in mijn berekeningen verwachting niet gunstig. Voor de prijs van vier 4TB schijven koop je ongeveer zes 3TB schijven. Als de laatste 3TB schijf dan maar voor 33% effectief is, blijven 3TB schijven goedkoper. Vandaar dat ik voor 3TB ben gegaan en nu aan het kijken ben wat het oplevert.

Overigens is het zo dat als je 512 byte blocken naar je hdd blijft schrijven en je HDD deze om laat zetten naar 4K blokken dat dat waarschijnlijk qua ruimte betere resultaten geeft, maar dat de performance daarvan weer minder is.
Ik ben er nog niet over uit of ik dat wil testen. Dat hangt er vanaf hoe lang mijn data erover doet om van mijn oude NAS naar mijn nieuwe ZFS storage VM te kopieren. Dat lijkt nu ruim twee dagen te gaan kosten...

[ Voor 27% gewijzigd door Mystic Spirit op 21-11-2013 13:00 ]

Je vergeet stroomverbruik. 2 schijven extra is 8-10W meer verbruik. dat is 20 euro per jaar. Dat is het verschil in prijs met 4TB schijven.

Even niets...


  • ]Byte[
  • Registratie: April 2000
  • Laatst online: 13-09-2020
Heb besloten om ZFSguru toch maar op bare-metal te gaan draaien.
Het was zo mooi geweest om het in een VM te kunnen draaien, maar ik krijg de HBA's gewoonweg niet in passthru zonder dat de hele machine gaat hangen.
En de andere optie kost mij teveel performance.
Ik ga over op FC (heb nog twee QLE2460's liggen) die ik in ieder geval op de ESX-host wil gaan gebruiken (ML110).
De rest gaat over iSCSI / NAS / ...

[ Voor 4% gewijzigd door ]Byte[ op 21-11-2013 13:48 ]

Heb je al eens een oudere versie van ESXi geprobeerd?

Even niets...


  • Mystic Spirit
  • Registratie: December 2003
  • Laatst online: 28-09 05:58

Mystic Spirit

PSN: mr_mysticspirit

FireDrunk schreef op donderdag 21 november 2013 @ 13:11:
Je vergeet stroomverbruik. 2 schijven extra is 8-10W meer verbruik. dat is 20 euro per jaar. Dat is het verschil in prijs met 4TB schijven.
Het begint behoorlijk offtopic te raken, maar die 2 schijven extra is ook 3TB (met verlies misschien 1,5) extra ruimte. Dus je bent die 6e schijf niet nodig voor dezelfde hoeveelheid ruimte. Laat je die achterwege dan heb je opeens geld "over" voor 12 jaar stroom. Dan zijn die schijven al lang weer vervangen voor een andere config. :+

@]Byte[
Jammer dat het niet wil lukken op ESXi. De performance van mijn setup is toch niet slecht voor gewone schijven?
code:
1
2
3
4
5
6
ZFSguru 0.2.0-beta8 (9.1-006) pool benchmark
Pool            : ZFS_RZ2 (19T, 8% full)
Test size       : 128 GiB
normal read    : 548 MB/s
normal write    : 340 MB/s
I/O bandwidth    : 29 GB/s

  • ]Byte[
  • Registratie: April 2000
  • Laatst online: 13-09-2020
@Mystic:
Als ik zie dat ik op bare-metal dit haal:

pool1 (10*4 TB WD Red's in RAID-Z2)
code:
1
2
3
4
5
6
7
8
9
10
ZFSguru 0.2.0-beta8 (9.2-001) pool benchmark
Pool            : pool1 (36.2T, 0% full)
Test size       : 128 GiB
normal read : 537 MB/s
normal write    : 699 MB/s
lzjb read   : 5 GB/s
lzjb write  : 3 GB/s
gzip read   : 5 GB/s
gzip write  : 3 GB/s
I/O bandwidth   : 37 GB/s


pool2 (4 * 250 GB Samsung 840 EVO's in RAID-Z)

code:
1
2
3
4
5
6
ZFSguru 0.2.0-beta8 (9.2-001) pool benchmark
Pool            : pool2 (928G, 0% full)
Test size       : 128 GiB
normal read : 2 GB/s
normal write    : 749 MB/s
I/O bandwidth   : 38 GB/s


Dan snap je dat ik niet vrolijk wordt van maar 60 MB ipv 699 MB writes op mijn WD's en 275 MB ipv 749 MB op mijn SSD's

@ FireDrunk: Nee. Oke, zal vanavond proberen met de 9.1-RC3 build.
ff USB-stickie maken...

  • Mystic Spirit
  • Registratie: December 2003
  • Laatst online: 28-09 05:58

Mystic Spirit

PSN: mr_mysticspirit

Nee daar wordt je zeker niet vrolijk van..... Ik heb mijn disks niet op bare metal getest.... Denk wel dat ik nog verschil kan maken in ESXi door wat meer CPU en memory toe te wijzen. Ik zal wel even kijken wat ik nog kan winnen als mijn copy van mijn huidige data rond is.

Status voor mijn dataset is momenteel:
3,4TiB daadwerkelijk in gebruik door files.
5,11TiB in gebruik inclusief pariteit en verlies.
Verlies is dus bijna 8% momenteel.

  • ]Byte[
  • Registratie: April 2000
  • Laatst online: 13-09-2020
Hier een kleine update...
Dezelfde config, maar dan met ZFSguru 9.1-RC3 haal ik in een VM op de SSD-pool nu een write van 456 MB/s tov 275 MB/s met 9.2-001 :?
En de grote test... de M1015's in passthru...
NO WAY!
Alleen hangt ESXi nu niet meer als de VM opstart! :)

In de console van ZFSguru blijft ie hangen op:

run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config mps_startup mps_startup
run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config mps_startup mps_startup
run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config mps_startup mps_startup
run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config mps_startup mps_startup
run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config mps_startup mps_startup

en van de VM lopen 3 van de 4 cores op 100% load en de 4e core 12-15% load.

<zucht...>
nu maar ff kijken of ik ESXi 5.1 kan downloaden en dan het zelfde testrondje nogmaals maken...

Verwijderd

Topicstarter
Draai je wel moderne firmware op je M1015? Ik dacht dat dat een issue was met die foutmelding. Anders even googlen of zoeken in deze (en DIY RAID NAS) want dat was een redelijk bekende foutmelding. Ik ben even kwijt want er zijn meerdere bugs/issues in combinatie met FreeBSD en ESXi. In het bijzonder met die mps driver. De nieuwere driver in FreeBSD heeft nieuwe versie firmware nodig, dat weet ik in elk geval. 9.0 volgens mij niet, die kan met oudere firmware overweg. Corrigeer me maar als je anders hebt ondervonden.

Succes!
Dat is het bekende msi/msi-x verhaaltje.
Even msix uitzetten.

Even niets...


  • Mystic Spirit
  • Registratie: December 2003
  • Laatst online: 28-09 05:58

Mystic Spirit

PSN: mr_mysticspirit

precies.
Even de boot onderbreken (bij het keuze schermpje)

en invoeren:
set hw.mps.disable_msix=1
boot

Is niet permanent, maar voor testen goed genoeg om je interrupt probleem op te lossen.

[ Voor 9% gewijzigd door Mystic Spirit op 21-11-2013 20:57 ]


  • ]Byte[
  • Registratie: April 2000
  • Laatst online: 13-09-2020
Verwijderd schreef op donderdag 21 november 2013 @ 20:27:
Draai je wel moderne firmware op je M1015? Ik dacht dat dat een issue was met die foutmelding.
Ik heb P17, en voor zover ik weet is dat de laatste.

@FireDrunk & Mystic: tnx voor de tip. Ga ik ff doen.

[update]
Dit was een gedeeltelijk succes.
Booten ging nu allemaal goed, en ook zag ik de disken en de pools die al eerder aangemaakt waren.
(ik helemaal blij...)
Alleen zodra ik 1 van de pools opnieuw wilde importeren hing de VM zich helemaal op!

De laatste error in het console:

panic: mps_reinnit transition operational failed with error 6

<zucht> 8)7

[update 2]
Grrrrrr.... :(
Nu weer een PSOD
Ik hou het even voor gezien.
Ik heb de USB-stick er uit getrokken en de mSATA er uitgehaald...
Draait nu weer als een zonnetje met 9.2-001 op bare-metal.
(dan de VM's maar op FC en/of iSCSI)

[ Voor 51% gewijzigd door ]Byte[ op 21-11-2013 23:24 ]


  • Quindor
  • Registratie: Augustus 2000
  • Laatst online: 17-09 14:50

Quindor

Switching the universe....

Ik heb een wazig probleem met mijn ZFSguru installatie.

Ik krijg mijn netwerk kaarten niet op MTU 9000, althans, 1tje niet, 1tje wel.

Nu had ik om te beginnen 2xIntel Pro/1000 PT, prima dingen, niet al te nieuw meer, maar toch. Deze gebruikten de ME driver. Hiermee heb ik dat uren proberen te testen maar wilde het niet werken, wat ik ook deed.

Ik heb vandaag een i350T-4 ingebouwd in de ZFSguru server en een i350T-2 in mijn ESXi server. Die deed het eerder ook al prima met de PT's maar ik wilde graag daar ook naar de nieuwere kaarten vanwege de betere offloading, toen ik vervolgens ook nog eens goede aanbeidingen op ebay vond was het zo gedaan. ;)

Efin, net lopen testen.... EXACT hetzelfde probleem aan de kant van ZFSguru. igb0 schakelt zonder problemen naar MTU 9000. De igb1 doet dit ook, zegt succesfull maar komt nooit online. igb2 heb ik niet in gebruik en igb4 is mijn LAN NIC en werkt ook prima (MTU 1500).

Hoewel dit dus een andere driver is (en zelfs een ander moederbord, maar dat is een ander verhaal) heb ik dus exact hetzelfde probleem nog steeds. Dat doet me denken dat het iets in het OS is.

Heeft iemand een clue? Ik heb dit wel vaker geconfigureerd binnen VMware, Switches, Storage, etc. en daar was het nooit een probleem zolang je de juiste drivers, revisies, etc. gebruikte. Mijn FreeBSD kennis is echter beperkt (Word snel meer) maar hier sta ik eventjes voor een raadsel.

Met MTU1500 zijn mijn resultaten al een stuk beter dan hiervoor. Alles 'voelt' ook sneller, maar dan natuurlijk een placebo effect zijn. :+

Afbeeldingslocatie: https://lh5.googleusercontent.com/-8Q3LGjmmN6g/Uo6SHhcuBsI/AAAAAAAACUY/2yhKNibevE4/w1690-h591-no/i350TvsPT.png
Mijn trage snelheid van het zenden van ZFSguru naar VMware is in ieder geval gefixed. Nou kan het zijn dat die PRO/1000 PT's gaar waren, maar toch! En dat is nog zonder enige netwerk tuning settings voor de i350T's! _/-\o_ ESXi CPU usage is ook een stuk lager geworden! :*)

update--
Fixed it, er moesten enkele tunables aangepast worden binnen ZFSguru/FreeBSD om genoeg buffer ruimte vrij te maken voor de jumbo frames.

Wat exact is eventjes te complex om neer te zetten maar gaat sowieso verwerkt worden in een blog post die ik aan het schrijven ben.

De belangrijkste daarbij was waarschijnlijk n de /etc/sysctrl.conf:
kern.ipc.maxsockbuf=16777216
kern.ipc.nmbclusters=131072
kern.ipc.nmbjumbo9=38400

De nmbclusters is veel over te lezen in combinatie met meerdere cores en meerdere netwerk kaarten en al helemaal als er jumbo frames gebruikt worden.

Ik heb nog veel meer aangepast, maar dit was het voornaamste om het werkend te krijgen verwacht ik.

Benchmark laat niet al te veel verschil zien, maar ach. :)

Afbeeldingslocatie: https://lh5.googleusercontent.com/-Y4HYo2EZp-o/Uo6sNcZnRQI/AAAAAAAACUw/RRb4djQaG1w/w894-h626-no/tuned+igb+and+tcp+with+polling+and+max+burst+vmware+iops1+i350t+and+jumbo+9000.png

[ Voor 35% gewijzigd door Quindor op 22-11-2013 02:02 ]

Intermit.Tech YouTube Kanaal, Intermit.Tech Blog, QuinLED


Acties:
  • 0 Henk 'm!

  • ]Byte[
  • Registratie: April 2000
  • Laatst online: 13-09-2020
Met al het ge.... van de afgelopen dagen zie ik nu ZFS weer op bare-metal loopt opeens onder:
Ik denk dat ik eerder ergens een foutje gemaakt heb... maar wat...?

[pool] => [Cache devices]:
boot_mirror	-   MUST BE 7+ !!	RAID1 (mirroring)	27.8G	2.32G	25.4G	ONLINE


en de tab [Log devices]
boot_mirror	-   MUST BE 10+ !!	RAID1 (mirroring)	27.8G	2.32G	25.4G	ONLINE


Iemand een idee hoe ik deze melding er uit kan krijgen?
Ik heb ook al geprobeerd om de partities te destroyen en opnieuw aan te maken, maar deze melding blijft terugkomen.
met een zool status lijkt alles goed te zijn:
[root@zfsguru ~]# zpool status
  pool: boot_mirror
 state: ONLINE
  scan: scrub repaired 0 in 0h0m with 0 errors on Fri Nov 22 00:52:39 2013
config:

	NAME           STATE     READ WRITE CKSUM
	boot_mirror    ONLINE       0     0     0
	  mirror-0     ONLINE       0     0     0
	    gpt/boot   ONLINE       0     0     0
	    gpt/boot2  ONLINE       0     0     0

errors: No known data errors

  pool: hdd_pool1
 state: ONLINE
status: The pool is formatted using a legacy on-disk format.  The pool can
	still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the
	pool will no longer be accessible on software that does not support feature
	flags.
  scan: none requested
config:

	NAME               STATE     READ WRITE CKSUM
	hdd_pool1          ONLINE       0     0     0
	  raidz2-0         ONLINE       0     0     0
	    gpt/hdd_dsk_0  ONLINE       0     0     0
	    gpt/hdd_dsk_1  ONLINE       0     0     0
	    gpt/hdd_dsk_2  ONLINE       0     0     0
	    gpt/hdd_dsk_3  ONLINE       0     0     0
	    gpt/hdd_dsk_4  ONLINE       0     0     0
	    gpt/hdd_dsk_5  ONLINE       0     0     0
	    gpt/hdd_dsk_6  ONLINE       0     0     0
	    gpt/hdd_dsk_7  ONLINE       0     0     0
	    gpt/hdd_dsk_8  ONLINE       0     0     0
	    gpt/hdd_dsk_9  ONLINE       0     0     0
	logs
	  mirror-1         ONLINE       0     0     0
	    gpt/slog       ONLINE       0     0     0
	    gpt/slog2      ONLINE       0     0     0
	cache
	  gpt/l2arc        ONLINE       0     0     0
	  gpt/l2arc2       ONLINE       0     0     0

errors: No known data errors

  pool: ssd_pool1
 state: ONLINE
status: The pool is formatted using a legacy on-disk format.  The pool can
	still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the
	pool will no longer be accessible on software that does not support feature
	flags.
  scan: none requested
config:

	NAME               STATE     READ WRITE CKSUM
	ssd_pool1          ONLINE       0     0     0
	  raidz1-0         ONLINE       0     0     0
	    gpt/ssd_dsk_0  ONLINE       0     0     0
	    gpt/ssd_dsk_1  ONLINE       0     0     0
	    gpt/ssd_dsk_2  ONLINE       0     0     0
	    gpt/ssd_dsk_3  ONLINE       0     0     0

errors: No known data errors
[root@zfsguru ~]# 


Leeg gooien en alles opnieuw installeren is ook een optie, maar wil eigenlijk weten wat ik fout gedaan heb, en hoe op te lossen.

[ Voor 3% gewijzigd door ]Byte[ op 22-11-2013 09:46 ]


Acties:
  • 0 Henk 'm!

  • Quindor
  • Registratie: Augustus 2000
  • Laatst online: 17-09 14:50

Quindor

Switching the universe....

Heb je toevallig je bootmirror geupgrade van v28 naar v5000? Mijn v5000 volumes krijgen in ieder geval ook die melding in het console, is puur cosmetisch en met de volumes en configuratie is niets mis. :)

Je zpool status zou dit ook suggeren.

[ Voor 12% gewijzigd door Quindor op 22-11-2013 10:10 ]

Intermit.Tech YouTube Kanaal, Intermit.Tech Blog, QuinLED


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Dat is inderdaad foute detectie door ZFSguru. Verder niet zo'n groot issue; komende update is ook de web-interface v5000-friendly, en kun je LZO-compressie via de webUI inschakelen wat nu ook nog niet kan. Maar afgezien hiervan kun je v5000 pools prima gebruiken met de huidige ZFSguru beta8.

Acties:
  • 0 Henk 'm!

  • ]Byte[
  • Registratie: April 2000
  • Laatst online: 13-09-2020
Lol... YUP!
Heb net de twee pools ook een zpool upgrade gegeven, en in de interface geeft ie daar nu dezelfde melding op.
Was mij nog niet eerder opgevallen.
tnx!

[update]
vraagje:
Moet ik nog iets doen voor ARC (dus niet L2ARC) om dat te laten gebruiken voor een pool? (ramdisk aanmaken?)

[ Voor 28% gewijzigd door ]Byte[ op 22-11-2013 14:38 ]


Acties:
  • 0 Henk 'm!

  • Mystic Spirit
  • Registratie: December 2003
  • Laatst online: 28-09 05:58

Mystic Spirit

PSN: mr_mysticspirit

Volgens mij hoe je voor ARC niets te doen. Als je meer dan 4GB geheugen hebt staat caching automatisch aan. Dit geeft ZFSguru ook aan in een van de status tabs.

Acties:
  • 0 Henk 'm!

  • ilovebrewski
  • Registratie: Augustus 2010
  • Laatst online: 02-04 21:37
Hoe kan ik in ZFSguru instellen dat mijn server automatisch uit en aan gaat op een bepaalde tijd.
Of kan ik beter WOL instellen?

Acties:
  • 0 Henk 'm!
Automatisch uit kan in een cronjob, automatisch aan moet in je BIOS(/UEFI). Remote aanzetten kan inderdaad ook via WoL.

Even niets...


Acties:
  • 0 Henk 'm!

  • ilovebrewski
  • Registratie: Augustus 2010
  • Laatst online: 02-04 21:37
FireDrunk schreef op vrijdag 22 november 2013 @ 16:36:
Automatisch uit kan in een cronjob, automatisch aan moet in je BIOS(/UEFI). Remote aanzetten kan inderdaad ook via WoL.
ok thnx :*)

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
]Byte\[ schreef op vrijdag 22 november 2013 @ 11:30:
vraagje:
Moet ik nog iets doen voor ARC (dus niet L2ARC) om dat te laten gebruiken voor een pool? (ramdisk aanmaken?)
Level 1 ARC is je RAM-geheugen, Level 2 ARC is optioneel een SSD. Beide worden standaard actief zonder verdere interventie, door de instellingen: primarycache en secondarycache. Die kun je instellen op All (Metadata+Data) Metadata en None. Vooral de metadata-instelling is interessant. Dan wordt er geen data gecached maar enkel metadata. Dat is overal nuttig, vooral bij zoekopdrachten, grote directories en vermindert het aantal seeks wat je hardeschijven moeten verrichten. Hierdoor kunnen de schijven zich vooral op sequentiële toegang richten, dat is het idee met L2ARC (en ook L1ARC).

Maar in plaats van alles botweg te activeren, kun je ook wat gaan tunen. Dit kan via de ZFSguru web-interface op de Files pagina zodra je op een filesystem klikt. Dan kun je onderaan bij Cache strategy zowel L1 ARC als L2 ARC instellen.

Ik raad aan dat je L2ARC op 'metadata' instelt voor de hele pool. Dan zal de SSD standaard enkel metadata cachen en pas data gaan cachen wanneer jij dit expliciet aangeeft. Bijvoorbeeld je filesystem vol met virtual machine images. Of een ZVOL die je als iSCSI-target gebruikt. Enzovoorts.

Er zijn ook mensen die L1ARC tunen naar metadata, maar daar moet je erg voorzichtig mee zijn. Je kunt hierdoor performance mislopen. Al zou bij je huidige patroon dit in sommige gevallen gunstig kunnen uitpakken, in de toekomst kan dit dubbel weer terugkomen en dan was je die instelling allang vergeten.

Concluderend: L1 lekker zo houden (All-instelling) en L2 alleen metadata cachen by default tenzij jij een fs op 'All' instelt. Dat lijkt mij het beste advies.

Acties:
  • 0 Henk 'm!

  • ]Byte[
  • Registratie: April 2000
  • Laatst online: 13-09-2020
Nah... Ik laat het voorlopig wel ff as-is.
Er zit 32 GB RAM in en is dus wel ff voldoende.
Ben nu bezig met een rsync om data van mijn QNAP's over te pompen naar m'n ZFS-doos.
puntjes van onderwerp zijn nu nog FC en iSCSI.

Vraag:
De eerste share heb ik overgezet (met rsync)
Dit zijn 40126 files met een totale size (du -h) van 353 GB
Kijk ik met een zpool iostat hdd_pool1 geeft ie een alloc. cap. aan van 464 GB
Als ik dit even plat doorreken is dit een overhead van 2,766 MB/file gemiddeld.

Weten jullie mij hier iets meer duidelijkheid over?

(ik ben benieuwd wat dit straks met de Foto's voor impact heeft (74 GB - 35411 files))

[ Voor 49% gewijzigd door ]Byte[ op 23-11-2013 10:13 ]


Acties:
  • 0 Henk 'm!

  • Mystic Spirit
  • Registratie: December 2003
  • Laatst online: 28-09 05:58

Mystic Spirit

PSN: mr_mysticspirit

Mijn backup van de synology blijft haken op de backup van een aantal files en ik heb het opgelost, maar wil even wil graag van jullie weten of mijn redenatie klopt.

Probleem ziet er als volgt uit:

Op de Synology heb ik een mappen structuur en komt daarbij dit voor:
/Map_naam/nog_een_map/files.x
/MAP_NAAM/een_andere_map/files

de eerste directory heeft dus feitelijk dezelfde naam, maar de een bestaat uit hoofdletters en dan andere voornamelijk kleine letters.

Bij het kopiëren van de synology naar ZFSguru worden beide mappen door ZFSguru tot een map samengevoegd waardoor mijn synology de back-up failed, want voor de synology klopt de map indeling niet meer.

Klopt het dat ZFSguru / FreeBSD mappen met hoofdletters en kleine letters als een en dezelfde map ziet of is dit toch een dingetje aan de synology kant?

Acties:
  • 0 Henk 'm!

  • ]Byte[
  • Registratie: April 2000
  • Laatst online: 13-09-2020
Mystic Spirit schreef op zaterdag 23 november 2013 @ 10:09:
Klopt het dat ZFSguru / FreeBSD mappen met hoofdletters en kleine letters als een en dezelfde map ziet of is dit toch een dingetje aan de synology kant?
Een bestand file1.txt en File1.txt in dezelfde map... tja, dat gaat inderdaad niet goed komen.

[ Voor 8% gewijzigd door ]Byte[ op 23-11-2013 10:24 ]


Acties:
  • 0 Henk 'm!

  • Mystic Spirit
  • Registratie: December 2003
  • Laatst online: 28-09 05:58

Mystic Spirit

PSN: mr_mysticspirit

Ja is natuurlijk ook logisch dat dat niet werkt, maar kennelijk was het wel mogelijk op de Synology. Dat vond ik ook al raar. 1 van de mappen heb k zelf gemaakt, maar de ander is gecreëerd door Headphones. Kennelijk maakt Synology (linux) case sensitive onderscheid in folder namen.

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
UNIX is standaard case sensitive. Een bestand met de naam 'FILENAME' kan bestaan naast een bestand met de naam 'filename'. Bij Windows is dit echter niet zo.

Als jullie Samba gebruiken, oftewel Windows filesharing, dan zijn de defaults volgens mij ook dat opslag case insensitive is, omdat anders Windows in de war kan raken met bepaalde dingen. Ik had daar in een ver verleden ooit mee te maken.

Wil je Samba case insenstive gebruiken, zul je smb.conf moeten instellen met:
case sensitive = yes

Acties:
  • 0 Henk 'm!

  • Ultraman
  • Registratie: Februari 2002
  • Laatst online: 20:49

Ultraman

Moderator Harde Waren

Boefje

Mystic Spirit schreef op zaterdag 23 november 2013 @ 10:09:
Bij het kopiëren van de synology naar ZFSguru worden beide mappen door ZFSguru tot een map samengevoegd
[..]
Klopt het dat ZFSguru / FreeBSD mappen met hoofdletters en kleine letters als een en dezelfde map ziet of is dit toch een dingetje aan de synology kant?
Dit zal niet aan ZFS, ZFSguru of FreeBSD liggen. In Unix zijn directories en filenames case-sensitive.
Ik heb even een lege dir aangemaakt en daarin drie op dezelfde manier gespelde dirs aangemaakt als voorbeeld:

$ mkdir dir_naam
$ mkdir DIR_Naam
$ mkdir DIR_NAAM
$ ls -l
total 18
drwxr-xr-x  2 stefan  stefan  2 Nov 23 16:32 DIR_NAAM
drwxr-xr-x  2 stefan  stefan  2 Nov 23 16:32 DIR_Naam
drwxr-xr-x  2 stefan  stefan  2 Nov 23 16:32 dir_naam

Dit zijn dus drie verschillende directories.
Als ik een file kopieer naar directory DIR_NAAM, dan komt hij daar in terecht en niet in DIR_naam en/of dir_naam.

Kopieer je je file mogelijk via Samba?
Want volgens mij zit daar wel een dergelijke case-insensitive mechanisme in. Omdat directories onder oudere Windows en DOS versies niet case-sensitive waren, alles was in CAPS immers. Later zijn daar kleine letters en lange bestandsnamen aan toegevoegd (vanaf Win95). Maar FAT filesystems zijn bij mijn weten niet case-sensitive. NTFS weet ik eigenlijk niet zeker, en ik heb ook geen Windows bak draaien om het even te proberen...

Dus als je Samba gebruikt wil je daar mogelijk case sensitivity inschakelen.

[edit]
CiPHER was mij net voor zo te zien.

[ Voor 5% gewijzigd door Ultraman op 23-11-2013 17:32 ]

Als je stil blijft staan, komt de hoek wel naar jou toe.


Acties:
  • 0 Henk 'm!

  • Mystic Spirit
  • Registratie: December 2003
  • Laatst online: 28-09 05:58

Mystic Spirit

PSN: mr_mysticspirit

Jullie hebben gelijk. Het is een Samba issue. Ik had namelijk via samba een directory gemount op de synology om de files makkelijk naar ZFSguru te krijgen. Het is dus inderdaad een samba / cifs ding waardoor het de mist in ging.

Nu al mijn files gekopieerd zijn heb ik trouwens ook besloten om niet te gaan testen met blocks van 512 bytes. Het verlies is momenteel maar ruim 7%. Dat is dus heel erg beperkt. Volledig tegen mijn verwachting in lijken kleinere files minder verlies te geven dan grotere files.

[ Voor 37% gewijzigd door Mystic Spirit op 23-11-2013 17:45 ]


Acties:
  • 0 Henk 'm!
Kan er iemand uitleggen waarom er meer writes op een Pool zouden kunnen gebeuren dan er daadwerkelijk door een remote machine opgestuurd worden?

Als ik in een VM een 4k write benchmark draai, zie ik ongeveer een gelijk aantal operations als wat er daadwerkelijk door de VM gedaan worden, maar qua size klopt het gewoon niet.

De VM doet bijvoorbeeld 3000 4k writes (12MB/s), maar via zpool iostat zie ik soms wel dik 400-500 MB/s langskomen (dat zouden dan haast 100.000 IOPS moeten zijn).

Er word dus ergens in de keten meer geschreven dan er daadwerkelijk nodig was. iemand die daar een idee over heeft?

Even niets...


Acties:
  • 0 Henk 'm!

  • Mystic Spirit
  • Registratie: December 2003
  • Laatst online: 28-09 05:58

Mystic Spirit

PSN: mr_mysticspirit

Dat zijn wel erg veel writes voor 3000 4k writes. He enige wat ik kan bedenken is dat pariteit schrijven ook writes kost, dus afhankelijk van de hoeveelheid pariteit heb je ook meer writes.

Acties:
  • 0 Henk 'm!
Maar factor 10 voor parity klopt natuurlijk niet... 8-)

Even niets...


Acties:
  • 0 Henk 'm!

  • ]Byte[
  • Registratie: April 2000
  • Laatst online: 13-09-2020
In hoeverre ga je er van uit dat iostat in ZFS 100% de correcte waardes afgeeft?
Het is misschien ver gezocht, maar ik begrijp je wantouwen wel.
Ik weet niet uit hoeveel en welke disken jou pool bestaat, maar voor 100k IOPS ga je met geen mogelijkheid halen op HDD's.
Ik heb zo'n vermoeden dat hier ook veel mem./cache IOPS in verwekt zitten.
(of jij moet een FusionIO-drive hebben... :) )

[ Voor 6% gewijzigd door ]Byte[ op 23-11-2013 20:47 ]


Acties:
  • 0 Henk 'm!
Mijn pool bestaat uit 2*840Pro 128GB, die volgens diverse benchmarks/reviews toch een dikke 34000 iops zou moeten halen bij 4k random writes (single queue). Bij twee stuks in een stripe zou ik toch minimaal 50000 iops ofzo verwachten. Ze halen daadwerkelijk: 300 iops.
dd if=/dev/zero of=test.4k bs=4k oflag=sync count=1024000

                capacity     operations    bandwidth
pool         alloc   free   read  write   read  write
-----------  -----  -----  -----  -----  -----  -----
propool      35.3G   203G      0    490      0  3.83M
  propool-A  17.7G   101G      0    245      0  1.92M
  propool-B  17.7G   101G      0    244      0  1.91M
-----------  -----  -----  -----  -----  -----  -----

Dat is fysiek op de bak.

Als ik deze tests via ESXi (NFS) doe, zie ik dezelfde snelheden (3-10MB/s) maar zpool iostat geeft meer zoiets:

                capacity     operations    bandwidth
pool         alloc   free   read  write   read  write
-----------  -----  -----  -----  -----  -----  -----
propool      37.7G   200G     32  3.96K  49.0K   481M
  propool-A  18.8G   100G     18  1.99K  30.5K   239M
  propool-B  18.8G   100G     13  1.97K  18.5K   242M

Even niets...


Acties:
  • 0 Henk 'm!
En even ter referentie, hier zijn die resultaten met 4 x een M4 128GB in STRIPE (!) ook belabberd.

Acties:
  • 0 Henk 'm!

  • ]Byte[
  • Registratie: April 2000
  • Laatst online: 13-09-2020
FireDrunk, op welke controller heb je de SSD's zitten? Zitten die op je MB? of op een M1015?
Ik verwacht niet dat de M1015 een probleem zal geven.
Daarmee zijn getallen tot 2500 MB/s en 350k IOPS ge-benchmarkt.

Andere optie... Heb je al eens geprobeerd om jumbo-frames te gebruiken?
Kijken of die IOPS op de pool dan omlaag gaan.
Mijn idee erachter is... Je schrijft met 4k blocks... Je MTU is standaard 1500.
Ergo voor een 4k block het je op je netwerk minimaal 3 blocks nodig om die 4k te versturen ex overhead!
(de cursus 'Computernetwerken en Protocollen' is al weer tijdje geleden, weet dus ff niet de exacte getallen meer uit mijn hoofd)
Maar het gaat er om dat een enkele 4k write opgedeeld wordt in meerdere pakketten op je netwerk.
Dit zou dus wel een verschil kunnen verklaren van lokaal tov via NFS.

[update ...]
Ik heb de dd-test van jou eens gedaan (zonder de oflag - die kent ie niet) zowel naar disk, maar ook van disk naar /dev/null.
Wat mij opvalt is dat ik volgens de iostat rond de 900 MB/s uitkom (read vanaf disk), maar dd komt iets hoger uit...
[root@zfsguru /ssd_pool1/share]# dd of=/dev/null if=test.4k bs=4k count=4096000
4096000+0 records in
4096000+0 records out
16777216000 bytes transferred in 12.370682 secs (1356207847 bytes/sec)

Dit is dus volgens dd geen 900 MB/s maar 1,3 GB/s. (4 * Samsung 840 EVO in RAID-Z op de M1015)
Bijzonder....

[ Voor 90% gewijzigd door ]Byte[ op 23-11-2013 23:27 ]


Acties:
  • 0 Henk 'm!
Compressie?

Als ik hier met CDM of AS SSD een benchmark draai, dan haal ik om en bij de 1 à 2MB/s aan 4K writes maar op de pool geeft dat gemiddeld 30MB. (zakt soms tot 20 of lager en geeft dan af en toe een piek van 80/90/100/111MB/s)

In AS SSD is de snelheid 1.08MB/s

Op zpool iostat

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
m4ftw       60.2G   416G     29     80  3.64M  5.34M
m4ftw       60.2G   416G      0    316      0  2.48M
m4ftw       60.2G   416G      0  1.03K      0   100M
m4ftw       60.2G   416G      0    820      0  62.7M
m4ftw       60.2G   416G      0    305      0  2.39M
m4ftw       60.2G   416G      0    303      0  2.37M
m4ftw       60.2G   416G      0    305      0  2.39M
m4ftw       60.2G   416G      0  1.34K      0   143M
m4ftw       60.2G   416G      0    468      0  19.6M
m4ftw       60.2G   416G      0    311      0  2.44M
m4ftw       60.2G   416G      0    300      0  2.35M
m4ftw       60.2G   416G      0    312      0  2.44M
m4ftw       60.2G   416G      0  1.36K      0   146M
m4ftw       60.2G   416G      0    611      0  21.6M
m4ftw       60.2G   416G      0    301      0  2.36M
m4ftw       60.2G   416G      0    312      0  2.44M
m4ftw       60.2G   416G      0    310      0  2.43M
m4ftw       60.2G   416G      0  1.12K      0   119M
m4ftw       60.3G   416G      0    687      0  48.8M
m4ftw       60.3G   416G      0    347      0  2.72M
m4ftw       60.3G   416G      0    304      0  2.38M
m4ftw       60.3G   416G      0    281      0  2.20M
m4ftw       60.3G   416G      0  1.47K      0   161M
m4ftw       60.2G   416G      0    333      0  2.73M
m4ftw       60.2G   416G      0    350      0  2.74M
m4ftw       60.2G   416G      0    270      0  2.11M
m4ftw       60.2G   416G      0    321      0  2.51M
m4ftw       60.2G   416G      0  1.53K      0   161M
m4ftw       60.2G   416G      0    339      0  2.65M
m4ftw       60.2G   416G      0    309      0  2.42M
m4ftw       60.2G   416G      0    301      0  2.36M
m4ftw       60.2G   416G      0    340      0  2.66M

[ Voor 80% gewijzigd door HyperBart op 23-11-2013 23:41 ]


Acties:
  • 0 Henk 'm!

  • ]Byte[
  • Registratie: April 2000
  • Laatst online: 13-09-2020
Ik heb geen compressie aan staan.
Maar de ARC... die zou wel eens wat extra roet in het eten kunnen gooien.
Bij een read van mijn 16 GB file in 4k blocks lees, dan gaat ie maar een paar keer even vanaf de pool lezen. de rest... 0
[root@zfsguru ~]# zpool iostat ssd_pool1 1
               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
ssd_pool1    355G   573G     16     39  2.06M  4.76M
ssd_pool1    355G   573G      0      0      0      0
ssd_pool1    355G   573G      0      0      0      0
ssd_pool1    355G   573G      0      0      0      0
ssd_pool1    355G   573G      0      0      0      0
ssd_pool1    355G   573G      0      0      0      0
ssd_pool1    355G   573G      0      0      0      0
ssd_pool1    355G   573G      0      0      0      0
ssd_pool1    355G   573G  1.10K      0   140M      0
ssd_pool1    355G   573G  3.96K      0   507M      0
ssd_pool1    355G   573G      0      0      0      0
ssd_pool1    355G   573G      0      0      0      0
ssd_pool1    355G   573G      0      0      0      0
ssd_pool1    355G   573G      0      0      0      0
ssd_pool1    355G   573G      0      0      0      0
ssd_pool1    355G   573G      0      0      0      0
ssd_pool1    355G   573G      0      0      0      0
ssd_pool1    355G   573G      0      0      0      0
ssd_pool1    355G   573G     50      0  6.37M      0
ssd_pool1    355G   573G      0      0      0      0
ssd_pool1    355G   573G      0      0      0      0
ssd_pool1    355G   573G      0      0      0      0
[...]

Acties:
  • 0 Henk 'm!
Maar wat geeft het als resultaat?

Even niets...


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
]Byte\[ schreef op zaterdag 23 november 2013 @ 21:40:
Wat mij opvalt is dat ik volgens de iostat rond de 900 MB/s uitkom (read vanaf disk), maar dd komt iets hoger uit...
[root@zfsguru /ssd_pool1/share]# dd of=/dev/null if=test.4k bs=4k count=4096000
4096000+0 records in
4096000+0 records out
16777216000 bytes transferred in 12.370682 secs (1356207847 bytes/sec)

Dit is dus volgens dd geen 900 MB/s maar 1,3 GB/s. (4 * Samsung 840 EVO in RAID-Z op de M1015)
Bijzonder....
Dat is niet zo vreemd. Je test deels je RAM geheugen op deze manier. IOstat kan minder aangeven omdat een deel van de requests uit L1ARC RAM cache komt. Ik denk dat je dat niet terugziet in iostat commando; dat is meer wat er naar de disks worden gestuurd (met -v flag in detail).

In plaats van 16GiB test file dien je minimaal 8 * RAM te doen. Of je moet je (test) pool exporteren en weer importeren. Dan ben je alle cache kwijt. Dus wat je kunt doen is dd write, export, import, dd read. Dan krijg je andere resultaten vermoed ik. ;)

Acties:
  • 0 Henk 'm!
Wat mij zojuist opvalt:


Propool-B is het GPT label van de SSD.
root@NAS2:/# dd if=/dev/zero of=/dev/disk/by-partlabel/propool-B bs=4k count=2048000 oflag=sync
84693+0 records in
84693+0 records out
346902528 bytes (347 MB) copied, 133.747 s, 2.6 MB/s

Test waarin ik direct schrijf naar de SSD (zonder filesystem dus).
Dat is natuurlijk echt pokke traag... 665 IOPS.
Iemand een idee? Dit is onder Linux btw.

Even niets...


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Sync writes; dat is erg vreemd wat je doet en komt niet vaak voor; een sequential write stream met 4K sync writes. Probeer dus eens zonder oflag=sync.

Acties:
  • 0 Henk 'm!
ESXi doet continu sync writes, dat is net het hele punt van ons verhaal en waarom we het deftig en snel willen...-

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Maar dat is het punt; als alle writes sync zijn, dan is je performance klote. Ik denk wel dat sommige SSDs stiekem helemaal geen echte sync writes doen, maar nog steeds writes bufferen maar dan in beperkte mate. Echte sync writes zijn gewoon heel traag; de SSD kan dan maar één kanaal (zelfs maar één die per kanaal) gebruiken. Pas als een SSD vals speelt en stiekem toch writes opspaart, kan het toch meerdere kanalen tegelijk gebruiken. Ik ben dus wel benieuwd als je deze test uitvoert met een Samsung SSD en met een echte Intel (320/S3500). Ergens verwacht ik dat Samsung sync writes gedeeltelijk negeert. Zou me weinig verbazen in elk geval.

Acties:
  • 0 Henk 'm!
Het is juist een Samsung...

Bronnen:
http://www.nexentastor.org/boards/5/topics/6465
http://forums.freenas.org...hy-is-iscsi-faster.12506/
http://blog.laspina.ca/ub...ver-nfs-as-a-vmware-store
And there are the cons:

Every write I/O from VMware is an O_SYNC write.
https://communities.vmware.com/thread/263165

Nou is dat wel per VM volgens mij, dus meerdere VM's gaan niet op elkaars O_SYNC wachten, en een O_SYNC geld volgens mij alleen voor de NFS thread die op dat moment loopt. Nexenta zegt ook dat je het aantal NFS worker threads op 2048 moet zetten, hierdoor krijg je misschien wel een hoog aantal concurrent SYNC writes binnen op ZFS en zou het misschien nog kunnen performen.

Maar dat neemt niet weg dat met O_SYNC schrijven naar een SSD niet zulke belabberde resultaten op zou moeten leveren...

[ Voor 38% gewijzigd door FireDrunk op 24-11-2013 14:31 ]

Even niets...


Acties:
  • 0 Henk 'm!
Verwijderd schreef op zondag 24 november 2013 @ 13:43:
Maar dat is het punt; als alle writes sync zijn, dan is je performance klote. Ik denk wel dat sommige SSDs stiekem helemaal geen echte sync writes doen, maar nog steeds writes bufferen maar dan in beperkte mate. Echte sync writes zijn gewoon heel traag; de SSD kan dan maar één kanaal (zelfs maar één die per kanaal) gebruiken. Pas als een SSD vals speelt en stiekem toch writes opspaart, kan het toch meerdere kanalen tegelijk gebruiken. Ik ben dus wel benieuwd als je deze test uitvoert met een Samsung SSD en met een echte Intel (320/S3500). Ergens verwacht ik dat Samsung sync writes gedeeltelijk negeert. Zou me weinig verbazen in elk geval.
Als ze writes bufferen moet dat toch ook slechte resultaten geven onder AS SSD en CDM als de SSD zelf getest wordt. Met ESXi en een datastore gaat het stevig vooruit hoor...

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
HyperBart schreef op zondag 24 november 2013 @ 15:06:
[...]


Als ze writes bufferen moet dat toch ook slechte resultaten geven onder AS SSD en CDM als de SSD zelf getest wordt. Met ESXi en een datastore gaat het stevig vooruit hoor...
Nee. AS SSD en CDM testen inderdaad wel 4K writes met qd=1. Maar dat is niet hetzelfde als sync writes!

4K write met qd=1 kun je bereiken door zogenaamde 'blocking I/O'. De applicatie stuurt een API-request en wacht totdat die request is afgehandeld. Je kunt qd=10 bereiken door 10 threads blocking I/O te laten doen, of door één thread non-blocking I/O te laten doen. De applicatie wacht dan niet totdat de data binnen is maar kan andere dingen gaan doen.

Bij een sync write wordt de write request gevolgd door een 'FLUSH' commando. Dat flush commando is voor de SSD een boosdoener. Dit beveelt dat de SSD de write eerst moet afhandelen voordat het andere writes mag behandelen.

Met async writes zoals in AS SSD en CDM kan de SSD deze gewoon bufferen, terwijl dat bij sync writes onmogelijk is. Ook met qd=1 kan de SSD een buffer van writes aanleggen, datzelfde doen mechanische schijven ook trouwens. Alleen de SSD kan extra voordeel bereiken omdat het alle 8 kanalen (* 2 dies per channel = 16-way interleaved minus 1 vanwege parity) kan aanspreken en zo 4K writes met bakken tegelijk wegzetten. Dat gaat veel sneller (maximaal tot 15 keer sneller) dan met sync writes.

Bovenstaande zou ik nog verder willen testen om er zeker van te zijn dat het klopt. Maar ik denk van wel. Sync writes en qd=1 writes zijn niet hetzelfde, dat is denk ik de conclusie.

Acties:
  • 0 Henk 'm!
Ok, een ding vergeten: we zetten dan wel telkens op ZFS het FS in sync always.

Acties:
  • 0 Henk 'm!
@CiPHER, wat je zegt klopt ook wel. We zien ook wel dat dr performance beter is dan puur synced writes op de ssd, maar nog steeds ver ver onder de max van de ssd bij non synced writes.

De waarheid zal dus ergens in het midden liggen.

Even niets...


Acties:
  • 0 Henk 'm!

  • ]Byte[
  • Registratie: April 2000
  • Laatst online: 13-09-2020
Verwijderd schreef op zondag 24 november 2013 @ 16:18:
[...]
4K write met qd=1 kun je bereiken door zogenaamde 'blocking I/O'.
En die kan je vervolgens weer voorkomen door gebruik te maken van MPIO.
De IO RoundRobin zet je in ESX vervolgens van de standaard 1000 IO's (zo even snel uit mijn hoofd) naar 1... en voila... :)

Acties:
  • 0 Henk 'm!

  • Mystic Spirit
  • Registratie: December 2003
  • Laatst online: 28-09 05:58

Mystic Spirit

PSN: mr_mysticspirit

ik heb het idee dat ik wat over het hoofd zie, maar wie weet zit het gewoon niet in ZFSguru.

Ik heb een file system aangemaakt op mijn pool /zfs_rz2/share/ nu heb ik al mijn files in die directory gekopieerd vanaf mijn synlogy. Nu wil ik eigenlijk submappen delen via samba en nfs, maar zie in de interface van ZFSguru hier geen mogelijkheden voor.

Kan ik alleen maar andere / nieuwe filesystems aan maken en die sharen of is het ook mogelijk voor submappen in een filesystem?

Acties:
  • 0 Henk 'm!

  • tvwes
  • Registratie: Augustus 2013
  • Laatst online: 06-04-2022
Nadat ik Firedrunk had toegezegt hem te zullen helpen met het bepalen van een performance baseline en vervolgens hem te zullen helpen liep ik tegen een aantal zaken aan. Het soort benchmark wat de gemiddelde tweaker hier runt, het OS en de vaardigheden van de gemiddelde tweaker hier mbt tot ZFS/UNIX en performance vraagstukken.
Het eerste waar ik tegenaan liep was het gebruik van een afwijkende dd in FreeBSD tov linux of illumos. Daar heb ik een minimalistische equivalent voor geschreven die portable is maar wel alle essentiele functies biedt.
Tweede is het soort workload en benchmark. De meeste tweakers zijn alleen geinteresseerd in sequentiele overdrachten, oftewel je HD film opslaan en lezen. Bijna niemand heeft echt concurrency. In het bedrijfsleven is dat juist precies andersom. Ik had niet echt een goed beeld van de performance karakteristiek van ZFS bij dit soort streaming workloads. Er is eigenlijk heel weinig data over bekend in het algemeen. Enthousiast begin ik met het schrijven van een testsuite. Dat ging prima. Alleen toen ik de resultaten zag was ik niet blij en ronduit verast. Ik zag enorme variaties in MB/sec en latency per write. Ook high level testen via SMB en NFS lieten een onregelmatig patroon zien.
Na veel Dtrace bleek er een stukje code te ontbreken in de nieuwe ZFS IO scheduler. (Overigens niet door mij als eerste gevonden, iemand die aan de ZFS voor Linux implementatie heeft het als eerste gevonden)
Ik heb snel de patch op mijn source tree geinstalleerd en ...

wauw!

De nieuwe scheduler weet ongeacht block grootte een constante schrijfsnelheid vast te houden. Iedereen kent wel het trappetje van atto. Na deze patch zijn alle rode lijntjes even lang. Dit op een zpool waar geen andere processen i/o's op doen, dus niet je root zpool! Bij meer threads neemt de performance wel af. Niet dramatisch maar ik moet daar verder naar kijken. Wel is het zo dat alle threads mooi even hard schrijven. De scheduler verdeelt de writes heel evenredig over de threads.

Ik denk dat de nieuwe ZFS IO scheduler samen met deze patch veel goeds betekent voor de tweakers hier. Het zal wel een tijdje duren voor dat dit beschikbaar komt.

Nog even een waarschuwing. Inmiddels weet een ieder dat ZFS zich niet gedraagt als NTFS of EXT4. Het benchmarken van ZFS is ronduit lastig. Ook bij het maken van deze benchmark liep ik weer tegen wat unieke kenmerken van ZFS aan. Het belangrijkste voor hier is laat ik het maar de "write cache" noemen (is het niet maar voldoet voor nu even) Deze "write cache" is afhankelijke van de hoeveelheid ram. Met een paar GB ram maakt het niet zoveel uit maar van 16GB zijn de effecten goed zichtbaar. En Firedrunk met 64GB ram in zijn ZFS NAS zal hier helemaal last of voordeel van hebben. Als je test niet goed inelkaar zit meet je alleen je RAM snelheid. Als je even snel een grote file wilt schrijven is dat prachtig. Je schrijft een paar GB ongeveer direct. Fijn, zolang je daarna even niks doet. Want die data moet uiteindelijk natuurlijk een keer op disk komen en dat gaat veel minder snel. Als je wel meer dan een paar GB wilt schrijven dan zal je zien dat die eerste paar GB weer extreem snel gaat en dat daarna je de schrijfsnelheid van de zpool benadert. Als je test niet goed inelkaar zit meet je die eerste paar GB (ook).

@Firedrunk,
nu dit is opgelost zal ik weer aan jouw project wat tijd besteden.

Hieronder het resultaat van met een kleine zpool met twee mirrors en gewone desktop sata drives.
All files are 4GB

Blocksize | 4096 | 8192 | 16384 | 32768 | 65536 | 131072
Thread 1 of 1 | 245 | 231 | 282 | 244 | 241 | 181

Blocksize | 4096 | 8192 | 16384 | 32768 | 65536 | 131072
Thread 1 of 2 | 112 | 119 | 108 | 123 | 130 | 126
Thread 2 of 2 | 109 | 119 | 108 | 122 | 132 | 125

Blocksize | 4096 | 8192 | 16384 | 32768 | 65536 | 131072
Thread 1 of 4 | 54.8 | 45.9 | 49.3 | 40.5 | 39.5 | 39.8
Thread 2 of 4 | 54.6 | 47.8 | 51.1 | 39.8 | 39.4 | 39.5
Thread 3 of 4 | 54.2 | 46.0 | 49.3 | 39.8 | 39.4 | 39.3
Thread 4 of 4 | 54.2 | 45.6 | 50.7 | 40.1 | 39.8 | 39.3

Blocksize | 4096 | 8192 | 16384 | 32768 | 65536 | 131072
Thread 1 of 8 | 20.7 | 21.6 | 20.9 | 21.5 | 23.3 | 22.1
Thread 2 of 8 | 20.9 | 22.1 | 20.8 | 20.3 | 23.0 | 22.2
Thread 3 of 8 | 20.6 | 22.2 | 20.8 | 20.4 | 23.0 | 22.0
Thread 4 of 8 | 20.9 | 21.4 | 20.8 | 20.3 | 23.0 | 22.1
Thread 5 of 8 | 20.7 | 22.2 | 20.8 | 21.5 | 23.0 | 24.0
Thread 6 of 8 | 20.7 | 21.4 | 21.4 | 22.2 | 23.0 | 22.0
Thread 7 of 8 | 20.7 | 21.4 | 21.1 | 20.4 | 23.1 | 22.0
Thread 8 of 8 | 20.7 | 21.4 | 21.0 | 20.5 | 23.0 | 22.2

Acties:
  • 0 Henk 'm!

  • Durandal
  • Registratie: Juli 2002
  • Laatst online: 24-07 13:18
(Overigens niet door mij als eerste gevonden, iemand die aan de ZFS voor Linux implementatie heeft het als eerste gevonden)
Is dit in ZoL dan al gepatched (in de huidige stabiele versie)?

[ Voor 10% gewijzigd door Durandal op 25-11-2013 04:58 ]


Acties:
  • 0 Henk 'm!

  • ]Byte[
  • Registratie: April 2000
  • Laatst online: 13-09-2020
Ik kan maar 1 ding zeggen: Goed bezig! _/-\o_

Acties:
  • 0 Henk 'm!

  • tvwes
  • Registratie: Augustus 2013
  • Laatst online: 06-04-2022
Ik zal proberen uit te vinden wanneer deze patch als commit in Illumos, FreeBSD en Linux. De patch is namelijk nog niet officieel opgenomen. Als je hier wat mee wil zal jezelf een kernel moeten bouwen of wat iedere tweaker hier natuurlijk doet, de nieuwe scheduler + patch backporten naar z'n huidige versie van z'n favoriete OS :)
Vermoedelijk gaat dit een tijdje duren voordat dit algemeen beschikbaar is, sorry voor de teleurstelling.
Daarnaast zal er de komende tijd door een aantal mensen kritisch gekeken worden naar de (performance) karakteristieken van de nieuwe scheduler om mogelijke regressies op te sporen. Ik ga ervan uit dat er geen fouten in de scheduler zitten maar een regressie kan altijd.

Acties:
  • 0 Henk 'm!
Wat zou je willen testen? Ik ben vandaag toevallig de SSD's even aan het gebruiken voor een ander projectje (VMware vSphere VSAN :+).

Ik heb 2* 840Pro 128GB, 1*840Pro 256GB en 3*320GB 2.5" schijfjes waar je elke test mee mag verzinnen die je wil. Ze kunnen in een i5 server met 8GB ram als FreeBSD / ZFSonLinux of van mij part Solaris install getest worden. Of ik hang ze in mijn Opteron.

Roep maar wat jij handig vindt.

Even niets...


Acties:
  • 0 Henk 'm!

  • tvwes
  • Registratie: Augustus 2013
  • Laatst online: 06-04-2022
@Firedrunk,
na de lunch kom ik erop terug. Maar ik denk aan het volgende:
je FreeBSD 10 beta 3 op de i5 met 8GB
2x840PRO als mirror mspool
3x320GB als raidz1 rzpool

de opteron heeft teveel ram en maakt testen lastiger. De test bij 8GB zal veel meer mensen een goede indruk geven. Als je daarna switch naar de opteron zal de resultaten weer wat verbeteren.
Het andere waar even wat aandacht aan besteed moet worden zijn de SSD's. Kan je die beperken tot 100GB? Het liefst via het instellen van de HPA via iets als HDAT. En kan je evt de SSD's eerst terug brengen in fabriekstoestand of wipen? Anders lopen we direct tegen de garbage collection van de ssd aan.

Het andere is dat jij nog niet de nieuwe scheduler hebt, maakt niet uit maar is om de verwachtingen wat te temperen.

Acties:
  • 0 Henk 'm!
Als jij een korte tutorial maakt hoe ik die patch kan inbouwen op FreeBSD 10, wil ik dat best even doen, word wel morgenavond.

De 840 Pro stond geloof ik bekend als een SSD met vrij goede garbage collection, maar FreeBSD ondersteund gewoon TRIM (zelfs op partities) dus dat zou toch niet zo'n probleem moeten zijn?

Ik wil ze best even Secure Erasen hoor, maar in mijn ogen is TRIM toch voldoende?

PS: persoonlijk wilde ik de SSD's als stripe inzetten zodat ik wat meer ruimte heb, en 's nachts een ZFS send en Receive backup doen naar de 320GB pool. Maar als jij graag wil testen met een mirror vind ik dat ook best.

[ Voor 21% gewijzigd door FireDrunk op 25-11-2013 11:13 ]

Even niets...


Acties:
  • 0 Henk 'm!

  • tvwes
  • Registratie: Augustus 2013
  • Laatst online: 06-04-2022
That's the spirit. En bedankt voor het vertrouwen, maar ik ik ben niet zo vertrouwd met de huidige status van de FreeBSD source tree en het build process. Ik zal er straks naar kijken.
Met of zonder patch we kunnen natuurlijk en de mirror en de stripe testen of welke config dan ook. Behalve verschillende modellen drives.

Wel denk ik dat het voor de performance en de levensduur van je ssd beter is om toch de ssd's te beperken tot 100GB via HPA oid. Zie ook http://www.storagereview.com/samsung_ssd_840_pro_review. Kijk vooral even halverwege bij het onderdeel preconditioning. Het is duidelijk dat de 840PRO het over tijd steeds moeilijker krijgt, ondanks TRIM. Ik kan de bron van een review over de 840 PRO en overprovisioning even niet zo snel vinden. Maar je kan uit het andere artikel wel halen dat de 840PRO wel degelijk vatbaar is voor performance verlies over tijd.

Heb jij al mbuffer op beide systemen, voor send and receive?

Acties:
  • 0 Henk 'm!
Nee, nog niet, heb ZFSonLinux weer even uitgezet, en de host draait momenteel weer even als ESXi host (in een clustertje), maar kan er zo weer wat op installeren.

Even niets...


Acties:
  • 0 Henk 'm!

  • tvwes
  • Registratie: Augustus 2013
  • Laatst online: 06-04-2022
@Firedrunk,

ik ben nog aan het uitzoeken wat er nu wel of niet qua ZFS commits in FreeBSD 10 en head zit.

Acties:
  • 0 Henk 'm!

  • FREAKJAM
  • Registratie: Mei 2007
  • Laatst online: 18:19

FREAKJAM

"MAXIMUM"

is everything cool?


Acties:
  • 0 Henk 'm!

  • matty___
  • Registratie: Augustus 2005
  • Laatst online: 06-10 09:15
tvwes schreef op maandag 25 november 2013 @ 23:02:
@Firedrunk,

ik ben nog aan het uitzoeken wat er nu wel of niet qua ZFS commits in FreeBSD 10 en head zit.
Misschien hem (Andriy Gapon <avg@freebsd.org of Xin LI <delphij@freebsd.org> ) mailen. Zij verzorgen de meeste patches vanuit de openzfs groep.

Acties:
  • 0 Henk 'm!
http://napp-it.org/doc/manuals/benchmarks.pdf

Wow, even een vergelijking gevonden van jongens die hele uitgebreide tests doen.
Als ik zo kijk, zijn mijn scores zo slecht nog niet 8-)

Even niets...


Acties:
  • 0 Henk 'm!

  • ]Byte[
  • Registratie: April 2000
  • Laatst online: 13-09-2020
Bijzonder dat ze met SMB hogere doorvoersnelheden behalen dan met iSCSI... (zei het soms marginaal...)

Acties:
  • 0 Henk 'm!

  • Kek
  • Registratie: Maart 2007
  • Laatst online: 08-10 11:36

Kek

3flix

ohh nice, zitten wel leuke dingen in zoals, debian 7 jails! ik heb helemaal geen esxi meer nodig jongens :P

Acties:
  • 0 Henk 'm!
Groot nadeel van de implementatie van FreeNAS' Jails vind ik nog altijd dat elke Jail zijn eigen IP krijgt...
Als je goede DNS thuis hebt, is het misschien wel te doen, maar om nou voor 3-7 jails allemaal losse IP's te moeten gebruiken :S

Wil je FTP-en naar je server moet je ip .2 hebben, gebruik je OwnCloud moet je weer .3 hebben... Niks voor mij...

Even niets...


Acties:
  • 0 Henk 'm!

  • Tsurany
  • Registratie: Juni 2006
  • Niet online

Tsurany

⭐⭐⭐⭐⭐

Daarvoor heb je toch gewoon je eigen domeinnaam met reverse proxy? Ik gebruik de standaard plugins in FreeNAS en dat zijn ook allemaal losse jails. Via m'n domeinnaam maakt het niet uit op welk IP ze staan. Groot voordeel is dat het me eigenlijk amper configuratiewerk kost en performancewise erg handig is :)

[ Voor 64% gewijzigd door Tsurany op 27-11-2013 12:36 ]

SMA SB5.0 + 16x Jinko 310wp OWO + 10x Jinko 310wp WNW |--|--| Daikin 4MXM68N + 1x FTXA50AW + 3x FTXM20N


Acties:
  • 0 Henk 'm!
Mja, maar interne DNS met dd-wrt (zoals ik hier heb) is een kutwerk :)
Reverse proxy of niet, ik heb het liefst gewoon 1 IP :D

Even niets...


Acties:
  • 0 Henk 'm!

  • Durandal
  • Registratie: Juli 2002
  • Laatst online: 24-07 13:18
Wat is er mis met dd-wrt?
Je kan toch gewoon ftp.server(.lan) en cloud.server(.lan) voor je verschillende virtuele machines gebruiken als je dat wil. Niet eens een domein naam nodig.

Hoe los je trouwens 2 FTP servers op dezelfde poort op verschillende virtuele machines op, als ze hetzelfde IP hebben?

[ Voor 5% gewijzigd door Durandal op 27-11-2013 13:18 ]


Acties:
  • 0 Henk 'm!

  • Tsurany
  • Registratie: Juni 2006
  • Niet online

Tsurany

⭐⭐⭐⭐⭐

Externe DNS? Werkt toch ook prima?

En FTP kan toch ook via een reverse proxy?

SMA SB5.0 + 16x Jinko 310wp OWO + 10x Jinko 310wp WNW |--|--| Daikin 4MXM68N + 1x FTXA50AW + 3x FTXM20N


Acties:
  • 0 Henk 'm!
Er is niks mis met DD-WRT maar een lokale DNS server opzetten is een stuk lastiger dan met bijvoorbeeld pfSense (waar het 4 klikken is). In de versie van DD-WRT die ik momenteel gebruik, moet je in de startupconfig met de hand de hosts file gaan zitten wijzigen. Nogal krom dus...

Even niets...


  • Eagleman7
  • Registratie: Januari 2009
  • Laatst online: 24-07 03:01
Ik ben van plan om in de komende dagen over te gaan naar ZFS met behulp van een Guest ( FreeNAS ) en VT-D

Ik ben van plan dit er te voor aan te schaffen (Ik weet niet of de AMC CBL-SFF8087OCF-10M gaat werken met de IBM M1015) :
#ProductPrijsSubtotaal
1AMC CBL-SFF8087OCF-10M€ 15,-€ 15,-
1IBM ServeRAID M1015 SAS/SATA Controller for System x€ 118,58€ 118,58
Bekijk collectie
Importeer producten
Totaal€ 133,58


Op dit moment heb ik de volgende hardware draaien:

#ProductPrijsSubtotaal
1Intel Core i5 4670 Boxed€ 187,90€ 187,90
1Intel Desktop Board DB85FL€ 77,10€ 77,10
1WD Green SATA 6 Gb/s, 1TB€ 51,99€ 51,99
1Western Digital Red WD30EFRX, 3TB€ 114,40€ 114,40
1BitFenix Merc Alpha€ 32,-€ 32,-
1Kingston DataTraveler 100 G2 8GB Zwart€ 8,90€ 8,90
1Intel Gigabit CT Desktop Adapter€ 22,13€ 22,13
1Crucial Ballistix Sport BLS4C8G3D1609ES2LX0BEU€ 265,53€ 265,53
1be quiet! Pure Power L7 300W€ 38,40€ 38,40
1Seasonic G-Serie 360Watt€ 54,30€ 54,30
1Samsung 840 series Pro 256GB€ 192,95€ 192,95
Bekijk collectie
Importeer producten
Totaal€ 1.045,60


Nu ben ik op het moment nog bezig om te kijken hoeveel IO performance mijn huidige setup gebruikt. Doormiddel van ESXi te monitoren met de ingebouwde performance grafiekjes. En ook door IOStat te gaan draaien in sommige Guests.

Is het nu handig om straks een L2ARC te maken van de Samsung 840 Pro SSD, en dan de Guests op een disk pool te draaien met de WD RED en de SSD als L2ARC om zo meer read performance te behalen. Of is het nu handiger om de SSD te gebruiken in een pool zonder een achterliggende hardeschijf inplaats van L2ARC.

Natuurlijk gebruik ik een ISCSi om een gedeelte van de pool door te geven aan ESXi.

Ook weet ik niet hoe ZFS omgaat met de pool en L2ARC als datastore ( hoeveel er gecached wordt van de .vmdk bestanden ).

Voor de Guests ben ik van plan NFS te gaan gebruiken zodat de Guests ( Linux ) hun bestanden op ZFS kunnen opslaan. Hier kan ik op het moment nog geen tests van doen dus ik weet ook nog niet of ik een ZIL nodig heb voor NFS om de performance een boost te geven.

  • Mystic Spirit
  • Registratie: December 2003
  • Laatst online: 28-09 05:58

Mystic Spirit

PSN: mr_mysticspirit

Ik volg niet helemaal wat je wilt bereiken met het maken van de ZFS pool en de L2ARC cache etc. Sterker nog zoals ik je verhaal lees kom je er helemaal niet uit, want je ZFS pool kan niet starten zonder dat je VM is gestart en je VM kan straks niet starten omdat die op de ZFSpool staat die niet bereikbaar is omdat de VM nog niet draait.

Of ik lees verkeerd of er gaat iets heel erg mis in je uitwerking van je systeem.

  • Eagleman7
  • Registratie: Januari 2009
  • Laatst online: 24-07 03:01
Mystic Spirit schreef op donderdag 28 november 2013 @ 14:31:
Ik volg niet helemaal wat je wilt bereiken met het maken van de ZFS pool en de L2ARC cache etc. Sterker nog zoals ik je verhaal lees kom je er helemaal niet uit, want je ZFS pool kan niet starten zonder dat je VM is gestart en je VM kan straks niet starten omdat die op de ZFSpool staat die niet bereikbaar is omdat de VM nog niet draait.

Of ik lees verkeerd of er gaat iets heel erg mis in je uitwerking van je systeem.
>want je ZFS pool kan niet starten zonder dat je VM is gestart en je VM kan straks niet starten omdat die op de ZFSpool staat die niet bereikbaar is omdat de VM nog niet draait.

The Hyperactive Blog: An all in one ESXi-NAS-SAN build


>Ik volg niet helemaal wat je wilt bereiken met het maken van de ZFS pool en de L2ARC cache etc.

Ik heb op dit moment een WD Red 3 TB en een Samsung 840 Pro 256GB.

Wat ik nu wil doen is een pool maken van de SSD en daar dan de Guests op te zetten en dan via de all in one esxi nas build opstarten.

Of de 3TB WD Red inzetten als pool en hier dan de Samsung 840 Pro 256GB aanhangen als L2ARC.

Ik weet dus niet welke van de 2 methodes het beste is, dus de vraag is welke van de 2 beter is?
Eagleman7 schreef op donderdag 28 november 2013 @ 15:38:
[...]


>want je ZFS pool kan niet starten zonder dat je VM is gestart en je VM kan straks niet starten omdat die op de ZFSpool staat die niet bereikbaar is omdat de VM nog niet draait.

The Hyperactive Blog: An all in one ESXi-NAS-SAN build
Het klopt wel wat Eagleman7 zegt, ook al heb je zoals mijn blogpost een all in one. Je hebt nog altijd een onafhankelijk medium nodig op je machine die virtueel draait en ZFS storage aanbiedt op te stockeren.

Of je kan als ie aan staat wel die VM sVMotionen naar die datastore, maar als de stroom dan uitvalt is het gedaan :+ dan moet je wat gekke dingen doen om die machine terug aan te krijgen.

  • Mystic Spirit
  • Registratie: December 2003
  • Laatst online: 28-09 05:58

Mystic Spirit

PSN: mr_mysticspirit

Met wat tweakwerk is het dus kennelijk mogelijk om een ZFSpool als datastore in te zetten in ESXi zonder dat je daarvoor een geboote VM nodig hebt.

Dan blijft mijn basis vraag nog steeds overeind, wat Eagleman7 bereiken wil. Het een is namelijk niet beter als het ander. Het plaatsen van SSD als L2ARC is handig als je SSD onvoldoende storage biedt voor je VM's. Als je die storage niet nodig hebt kun je beter gewoon op je SSD blijven draaien en je WD red voor andere doeleinden inzetten.

  • Eagleman7
  • Registratie: Januari 2009
  • Laatst online: 24-07 03:01
Mystic Spirit schreef op donderdag 28 november 2013 @ 16:42:
Met wat tweakwerk is het dus kennelijk mogelijk om een ZFSpool als datastore in te zetten in ESXi zonder dat je daarvoor een geboote VM nodig hebt.

Dan blijft mijn basis vraag nog steeds overeind, wat Eagleman7 bereiken wil. Het een is namelijk niet beter als het ander. Het plaatsen van SSD als L2ARC is handig als je SSD onvoldoende storage biedt voor je VM's. Als je die storage niet nodig hebt kun je beter gewoon op je SSD blijven draaien en je WD red voor andere doeleinden inzetten.
Daarom de vraag:

Ook weet ik niet hoe ZFS omgaat met de pool en L2ARC als datastore ( hoeveel er gecached wordt van de .vmdk bestanden ).

Als er genoeg gecached wordt van de Guests op de SSD en de snelheid niet lager komt dan ongeveer 25% dan als het normaal op een SSD draait, biedt zo'n L2ARC meer voordelen omdat de bestanden die op de HDD staan ook meteen gecached worden, win win lijkt mij.

Alleen dit ligt er natuurlijk aan hoeveel er gecached wordt.

  • damanseb
  • Registratie: Maart 2002
  • Laatst online: 24-07 07:24
Caching gaat op basis van veelgebruikte IO blocks..
Draai je een actieve MySQL binnen een vmdk dan zal de L2ARC deze database blocks zo snel mogelijk proberen te cachen.
ZFS kan de volledige snelheid van een SSD benutten als de L2ARC eenmaal is opgewarmt..

Ik gebruik hiervoor een bestaand perl scriptje om de status van ARC/L2ARC te monitoren.
Google hiervoor op arcstat.pl
Deze geeft het volgende netjes weer: read hits miss hit% l2read l2hits l2miss l2hit% arcsz l2size
Zo kan je zien hoeveel hits er uit je ARC (ram) dan wel L2ARC (ssd) komen..
Dit in combinatie met: zpool iostat -v
En je weet vrij nauwkeurig hoe vol je cache devices zijn en hoeveel data er als cache hit word uitgelezen..

Na het 4 keer draaien van een FIO benchmark (binnen 15 minuten) met een benchmark bestand van 8GB was nagenoeg de volledige 8GB aan data op mijn L2ARC aanwezig en zag ik met arcstat.pl 70% L2ARC hits en 30% ARC hits..

Volgende resultaten komen van een linux VM over een 1gbE iSCSI verbinding van SAN naar VMWare ESXi 5.1
Sequential read:
Random read:
Sequential write:
Random write:
io=3127.4MB, bw=106735KB/s, iops=26683 , runt= 30003msec
io=3093.2MB, bw=105598KB/s, iops=26399 , runt= 30003msec
io=3038.7MB, bw=103689KB/s, iops=25922 , runt= 30003msec
io=2368.6MB, bw=80821KB/s, iops=20205 , runt= 30003msec
Zoals je ziet is een 1gbE aansluiting als een bammetje pindakaas voor ZFS..
Om alles op 10gbE over te zetten kost me helaas nog meer dan de hele SAN bij elkaar dus dat zit er nog even niet in..

Echter.. lokaal zonder iSCSI lopen de benchmark resultaten op van 20k (90mbps HDD) tot 280k iops (500mbps L2ARC) tot 1500k iops (6000mbps ARC)

Ik heb 16GB ram in mijn SAN en mijn ZFS configuratie heeft een verhoogde L2ARC fillrate ten opzichte van de defaults: (/etc/modprobe.d/zfs.conf)
# ZFS zfs_prefetch_disable
options zfs zfs_prefetch_disable=1
# ZFS zfs_write_limit_overwrite from 0 to 1073741824 (1GB)
options zfs zfs_write_limit_override=1073741824
# ZFS zfs_no_write_throttle
options zfs zfs_no_write_throttle=1
# L2ARC noprefetch from 1 to 0
options zfs l2arc_noprefetch=1
# L2ARC write max from 8388608 to 67108864 (8MB to 64MB * 4 = 256MB)
options zfs l2arc_write_max=16777216
# L2ARC write boost from 8388608 to 100663296 (8MB to 96MB * 4 = 384MB)
options zfs l2arc_write_boost=33554432
# L2ARC headroom from 2 to 4
options zfs l2arc_headroom=4

Ik heb echter l2arc_noprefetch=1 gewoon gelaten voor wat het was aangezien sequentieel vanaf HDD mirrors snel genoeg is en niet via SSD hoeft te verlopen en dus voortijdig SSD slijtage voorkomt.

Hopelijk geeft deze post wat meer inzicht in mogelijke resultaten en hoe ZFS intern werkt..
Als je meer wilt weten over bijvoorbeeld gebruikte instellingen drop me dan ff een PM :)

[ Voor 10% gewijzigd door damanseb op 28-11-2013 18:53 ]


  • matty___
  • Registratie: Augustus 2005
  • Laatst online: 06-10 09:15
Waarom heb je de zfs_prefetch uit staan?

  • Eagleman7
  • Registratie: Januari 2009
  • Laatst online: 24-07 03:01
Ik moet zelf even testen wat er dan het beste werkt voor mijn situatie, thanks voor de info :)

Krijg ik nog problemen met deze kabels en de raid controller, of gaat dit gewoon werken?

#ProductPrijsSubtotaal
1AMC CBL-SFF8087OCF-10M€ 15,-€ 15,-
1IBM ServeRAID M1015 SAS/SATA Controller for System x€ 118,58€ 118,58
Bekijk collectie
Importeer producten
Totaal€ 133,58

[ Voor 1% gewijzigd door Verwijderd op 28-11-2013 20:46 ]


  • damanseb
  • Registratie: Maart 2002
  • Laatst online: 24-07 07:24
matty___ schreef op donderdag 28 november 2013 @ 20:01:
Waarom heb je de zfs_prefetch uit staan?
Na aanleiding van: https://wiki.freebsd.org/ZFSTuningGuide
Ik heb ik met deze instelling zitten spelen en ik heb er goeie ervargingen mee in de zin dat het betere random read/write resultaten oplevert terwijl de impact op sequentieel minimaal is.
(Na een hele week benchmarken met nagenoeg alle mogelijk combinaties aan instellingen)

Ik gebruik SSDs voor ZIL en L2ARC en deze setting lijkt voor wat balans te zorgen tussen de performance van de HDDs en de SSDs

Ik draai nu al een paar maanden stabiel ZFS on Linux op Ubuntu 12.04 LTS met SCST voor exporteren via iSCSI naar VMWare en in tegenstelling tot OP moet ik zeggen dat op moment van schrijven ZoL behoorlijk volwassen is want het loopt hier vooralsnog zonder problemen als een trein..

VMWare voelt super responsive aan; virtuele machines installeren gaat extreem snel en benchmarks met FIO binnen VMs trekken de beschikbare gbE verbindingen helemaal vol..
ZFS op deze manier voelt aan als een 3000 euro raidkaart met superieure IO scheduler, 16gb aan RAM en SSD all rolled into one, I LOVE IT! _/-\o_ En dat op een zelfgebouwde SAN van nog geen 800 euro..

De complete configuratie van het OS tot Multi Path IO op iSCSI niveau..
Hiervoor heb ik een HOWTO bijgehouden en ben meer dan bereid deze te delen als iemand interesse heeft..

[ Voor 61% gewijzigd door damanseb op 28-11-2013 21:55 ]

Pagina: 1 ... 95 ... 214 Laatste

Let op:
Voor het bouwen van een ZFS NAS en andere hardwarevragen kun je beter terecht in Het grote DIY RAID NAS topic deel 3, zodat we dit topic reserveren voor ZFS-specifieke vragen en discussies.