Het grote ZFS topic

[NIK0]

HyperBart schreef op zondag 03 juni 2012 @ 13:28:

Performance-wise valt er dan weer wat minder goeds over te zeggen, in die zin dat hij zogezegd "block devices" gebruikt terwijl het eigenlijk VMDK's zijn op ESXi-niveau... Nu aan de andere kant geeft hem dat ook heel wat flexibiliteit... In theorie kan je deze setup compleet vMotionen naar een nieuwe, zwaardere build... Het grote nadeel hiervan is het feit dat je een extra performance penalty krijgt omwille van de VMDK's... Voor zover ik ook begrepen heb is het gebruik van VMDK's niet echt zo sexy voor ZFS en vindt ZFS dat mechanisme niet lief...

@Hyperbart, thanks voor je reactie..!
Heb je wat meer info omtrent de problemen omtrent vmdk icm met ZFS..? wil proberen een weloverwogen keus te maken. Ik ken nog iemand die zoiets gemaakt heeft en die was er ook tevreden over.
Nexenta is verder volledig supported onder ESXi dus men zal toch wel vaker een setup tegenkomen waar men op VMFS, VMDK's aanbiedt op ZFS..?

Ik meende wel iets gelezen te hebben omtrent corruptie wanneer je een disk toewijst via RDM:
(bron: http://hardforum.com/showthread.php?t=1673228 )

Mocht deze route een no-go worden dan moet ik gaan kijken naar een andere CPU die VT-D ondersteuning heeft (Core i5 ipv Core i3 of Intel G620) wat weer wat extra knaken betekent. Dan zit je weer met het probleem dat je moet oppassen met verschillende merk disken terwijl je dat juist graag zou willen ivm uitval.

@Goderic:
1 Tb = ongeveer 930 GB bruikbaar dus dat valt wel mee, je hebt ook ruimte nodig voor het OS van Nexenta die kun je op 2 vmdks installen op het restant van 2 disks bijv..nog wat ISO-tjes en dan krijg je die disken wel vol..

[ Voor 20% gewijzigd door NIK0 op 03-06-2012 17:08 ]

[FireDrunk]

Waarom zou je deze setup willen als RDM wél werkt met ZFS?
Wat zou (voor jou) het voordeel zijn om VMDK's te gebruiken?

[NIK0]

FireDrunk schreef op zondag 03 juni 2012 @ 17:22:
Waarom zou je deze setup willen als RDM wél werkt met ZFS?
Wat zou (voor jou) het voordeel zijn om VMDK's te gebruiken?

Hi FireDrunk,
Voordeel is denk ik:
- dat ik geen VT-D hoef te gebruiken en dan toekan met een Intel G620 of Core i3 CPU
- dat ik geen extra HD's hoef te (mis/ge)bruiken om het OS op te installen. (wil het Nexenta OS op 2 diskjes van 16 GB installen).
- geen (mogelijk) gezeur met het feit dat ik nu 1 TB samsung HD's heb (3x HD103SJ en 1 HD103UJ) en ik geen idee heb of een 1 TB HD van Seagate bijgeprikt kan worden zonder dat Nexenta over z'n zuigers gaat.
- Prijsverschil tussen 1 TB 7200 rpm en 2 TB disks is +/- 20 euro, via die vmdk oplossing kan ik 900GB toewijzen aan 1 pool en 900 GB toewijzen aan een andere pool. (wil eigenlijk geen geld meer aan 1 TB disken uitgeven en ik weet niet hoe ik dat met een "fysieke install" kan oplossen)
Voorop staat dat het gewoon moet werken, dan nog het liefst zo energie en goedkoop mogelijk + met een klein beetje performance.
Setup die ik nu in gedachten had was voor de storage bak:
- B75MA-P45 (wacht nog op terugkoppeling vanuit het energie zuinige ESXi server topic of een HBA werkt in het x16 slot van dit moederbord).
- 8 of 16GB memory (non ECC)
Intel G620, Core i3 2100 of Core i5 2400 afhankelijk van hoever we virtualisatie gaan toepassen.
Deze bak is dedicated voor storage, op een andere machine met soortgelijke specs (CPU is dan wel een Intel G62) wil ik dan VM's gaan draaien waarbij de VMDK's via NFS worden aangeleverd door de storage machine..

Je input in dit topic is bijna legendarisch dus ik hoop dat me in de juiste richting kunt duwen gezien je ervaring met deze materie..
@everyone (all input is natuurlijk welkom!)

[FireDrunk]

RDM kan zonder VT-d.
Nexenta kan je ook prima installeren op disks die via RDM doorgeven zijn.

Je verhaal over bijprikken raakt kant nog wal? Waarom zou een Storage OS over de kop gaan als er een disk bij komt

Prijs is helemaal niet relevant in dit verhaal. Het ging over Software... RDM of VMDK...

Je bak is trouwens Niet dedicated voor Storage als je ESX gaat gebruiken, dan kan je beter Nexenta bare-metal installeren

[NIK0]

FireDrunk schreef op zondag 03 juni 2012 @ 20:36:
RDM kan zonder VT-d.
Nexenta kan je ook prima installeren op disks die via RDM doorgeven zijn.

Oke, enig idee waar Hyperbart het hierboven dan over heeft..? ZFS icm met vmfs, vmdk of RDM..?
Heb je die ervaring zelf icm RDM want ik heb daar nogal wat mixed zaken over gelezen:
(bron: http://hardforum.com/show...?p=1037507027&postcount=4) RDM niet lekker werkend, passthrough wel..

Je verhaal over bijprikken raakt kant nog wal? Waarom zou een Storage OS over de kop gaan als er een disk bij komt

Ik heb gezegd dat ik geen idee heb of Nexenta het prettig vind wanneer ik seagate en samsung disken door elkaar gebruik niet dat ik hier vanuit ging..

Prijs is helemaal niet relevant in dit verhaal. Het ging over Software... RDM of VMDK...

Je vroeg mij aan te geven waarom voor de 1 of de ander zou kiezen, prijs maakt daar deel van uit aangezien budget altijd deel uitmaakt van een project..

Je bak is trouwens Niet dedicated voor Storage als je ESX gaat gebruiken, dan kan je beter Nexenta bare-metal installeren

Als ik esxi install en dat als enige VM gebruik is dit dan niet dedicated..?

Mijn excuses als ik verkeerds heb gedaan of gezegd, ik dacht dat we hier samen kwamen om elkaar te helpen..?

[FireDrunk]

Sorry, de toon was (in mijn hoofd) absoluut niet corrigerend of boos hoor

Even kort: Er zijn twee vormen van RDM, via -r of -z. Het verschil zit hem de controller.

Voorbeeld van -z optie:
http://blog.davidwarburto...al-sata-storage-for-esxi/

Voorbeeld van -r optie:
http://vm-help.com/esx40i/SATA_RDMs.php

Dit kan zonder VT-d (en theoretisch zelfs zonder VT-x) support met elke ondersteunde SATA controller en kost niets extra.

Je kan in elk OS disken mixen. Of de RAID laag daar blij mee is, is wat anders. Zeggen dat een OS niet met verschillende merken disks overweg kan gaat dus niet op. Je kan hoogstens stellen dat een bepaald RAID mechanisme niet met verschillende merken overweg kan.

VMFS en VMDK betekenen in dit verhaal hetzelfde, je gaat het interne filesystem van ESX gebruiken. VMFS is het filesystem, VMDK's zijn de bestanden die daarop komen. Bij RDM heb je geen van beide.

Of RDM 100% veilig is icm ZFS is nog niet bekend, maar er zijn op Tweakers al een paar mensen die het al een aantal weken/maanden werkend hebben. (Staatslot? of was het diegene met die bacterie als picture )

ZFS is gemaakt om direct met een disk te communiceren en elke disk afzonderlijk te behandelen (als het gaat om commando's sturen). Vanwege dit karakter kan ZFS met elk merk overweg.

[Snow_King]

Goderic schreef op zondag 03 juni 2012 @ 13:39:
Waarom wordt er 20% van de disks niet gebruikt? voor de SSD kan ik dat nog begrijpen maar voor de HDD's lijkt me dat gewoon verspilling.

Een ZFS pool krijgt te maken met een verlaagde schrijf performance wanneer de disks vol raken.

ZFS wil namelijk vrije blokken hebben om zijn schrijf acties kwijt te kunnen. Bij een volle disk kan het zijn dat je langer moet wachten tot de platter op zijn plek is, dat kost tijd en dus performance.

Om die reden kan je beter een pool niet verder vullen dan 80 a 90%.

[NIK0]

Thanks..

Nog tips wat betreft de CPU die ik voor zo'n project dien te gebruiken? Zou een Pentium G620 zoiets moeten kunnen trekken? (compression: on, dedup: off) Of moet ik minimaal aan de Core i3 2100..?
Zelfde geldt ook voor de SSD, is daar nog een rekenmethode voor hoeveel diskspace je moet toewijzen aan een cache voor mirror of raidz1..?

Wat betreft memory heb ik gelezen +/- 1 GB per TB maar gezien de lage prijzen van memory op het moment zou 16GB altijd goed moeten gaan..(als is men het daar ook niet altijd over eens http://www.zfsbuild.com/2...-zfs-use-all-of-your-ram/ )

[FireDrunk]

1GB / 1TB is voor Enterprise doeleinden, en niet echt een vuistregel die je thuis perse *moet* hanteren. Het is wel een indicatie. MDADM kan je al met 128MB RAM ofzo draaien... Dat kan met ZFS zeker niet

Over je CPU: Neem wat je budget toelaat. Het is goedkoper om nu te investeren dan om dubbel te kopen als je andere features wil. Als je dus VT-d wil, kan je dat beter nu aanschaffen dan straks een swap moeten doen...
_{Maar sommige mensen kunnen heel goed 2e hands handelen. Dan zou het misschien goedkoper zijn}

Compressie is redelijk zwaar en dedup al helemaal. Als je het perse wil, ga voor een i3, die is toch net wat sneller dan een G620. Je kan ook voor de Celeron 830 gaan, die is (correct me if i'm wrong..) even snel als een i3 maar mist de snellere GPU.

Heb je compressie en dedup echt nodig? Ik lees dat je veel files dubbel hebt, maar kan je daar niet beter 1x in de maand een tooltje op je Windows desktop voor runnen?

[Snow_King]

FireDrunk schreef op maandag 04 juni 2012 @ 13:23:
1GB / 1TB is voor Enterprise doeleinden, en niet echt een vuistregel die je thuis perse *moet* hanteren. Het is wel een indicatie. MDADM kan je al met 128MB RAM ofzo draaien... Dat kan met ZFS zeker niet

Over je CPU: Neem wat je budget toelaat. Het is goedkoper om nu te investeren dan om dubbel te kopen als je andere features wil. Als je dus VT-d wil, kan je dat beter nu aanschaffen dan straks een swap moeten doen...
_{Maar sommige mensen kunnen heel goed 2e hands handelen. Dan zou het misschien goedkoper zijn}

Compressie is redelijk zwaar en dedup al helemaal. Als je het perse wil, ga voor een i3, die is toch net wat sneller dan een G620. Je kan ook voor de Celeron 830 gaan, die is (correct me if i'm wrong..) even snel als een i3 maar mist de snellere GPU.

Heb je compressie en dedup echt nodig? Ik lees dat je veel files dubbel hebt, maar kan je daar niet beter 1x in de maand een tooltje op je Windows desktop voor runnen?

Compressie kan je juist een snelheidswinst opleveren.

De CPU's van tegenwoordig zijn snel en die kunnen lzio of gzip zonder problemen doen. Het leuke is juist doordat je compressie toepast je minder hoeft te schrijven naar de disk en dus snelheid wint.

Wij passen ZFS (Nexenta) toe in een omgeving met 22TB aan kleine files zoals PHP, HTML, CSS, etc, etc en daar zitten twee Quad Xeon's met 96GB RAM in.

Die omgeving doet zo'n 2k write IOps en 20k read iops en die CPU's staan echt uit hun neus te eten.

Een leuke i3 of i5 moet echt voor thuis gebruik meer dan voldoende aan kunnen met compressie.

dedup zou ik wel bij weg blijven, dat eet ram.

[NIK0]

Aangezien er positief nieuws te melden valt uit het zuinige esxi topic,

Ultimation schreef op zondag 03 juni 2012 @ 21:54:
[...]
Getest. Het systeem start gewoon ESXi op, geen reboots of andere problemen. Ik kan de RR3520 (nog) niet aanroepen/zien binnen ESXi zelf. Maar daar gaan we nog even een oplossing voor zoeken.

lijkt het erop dat zo'n MSI B75MA-P45 bordje zou moeten werken icm met een HBA.
Een Core i5 2400 CPU zou er dan bij moeten kunnen aangezien zo'n MSI Bord de helft kost van een Intel bord
Dan kan ik beginnen met virtueel en mocht ik hier tegen probs aanlopen dan omzetten naar een VT-D oplosssing.
Nog even uitzoeken of er een mega verschil is tussen een G620/i5 qua stroomverbruik (is 1 vd speerpunten van m'n project)

[FireDrunk]

Snow_King schreef op maandag 04 juni 2012 @ 13:35:
[...]
Compressie kan je juist een snelheidswinst opleveren.

De CPU's van tegenwoordig zijn snel en die kunnen lzio of gzip zonder problemen doen. Het leuke is juist doordat je compressie toepast je minder hoeft te schrijven naar de disk en dus snelheid wint.

Wij passen ZFS (Nexenta) toe in een omgeving met 22TB aan kleine files zoals PHP, HTML, CSS, etc, etc en daar zitten twee Quad Xeon's met 96GB RAM in.

Die omgeving doet zo'n 2k write IOps en 20k read iops en die CPU's staan echt uit hun neus te eten.

Een leuke i3 of i5 moet echt voor thuis gebruik meer dan voldoende aan kunnen met compressie.

dedup zou ik wel bij weg blijven, dat eet ram.

2 QC Xeon's staan natuurlijk in verhouding tot een DC Pentiumpje... Clock-voor-Clock zijn die Xeon's beestachtig veel sneller Logisch dat het ding uit zijn neus staat te eten.

Bovendien is Compressie VEEL zwaarder op grote files, omdat de hele file gescanned moet worden voordat deze weggeschreven kan worden. Bij kleine files heb je meerdere threads die kunnen compressen. Dat werkt allemaal niet bij 1 grote file.

Wat ik denk is dat je in een thuissituatie veel meer grote files hebt, en je dus automatisch meer belasting hebt bij het gebruik van compressie.

Of het *echt* uitmaakt weet ik zelf ook niet, ik gebruik het niet...

[Snow_King]

FireDrunk schreef op maandag 04 juni 2012 @ 14:32:
[...]


2 QC Xeon's staan natuurlijk in verhouding tot een DC Pentiumpje... Clock-voor-Clock zijn die Xeon's beestachtig veel sneller Logisch dat het ding uit zijn neus staat te eten.

Daar moet ik je gelijk in geven

FireDrunk schreef op maandag 04 juni 2012 @ 14:32:
Bovendien is Compressie VEEL zwaarder op grote files, omdat de hele file gescanned moet worden voordat deze weggeschreven kan worden. Bij kleine files heb je meerdere threads die kunnen compressen. Dat werkt allemaal niet bij 1 grote file.

Wat ik denk is dat je in een thuissituatie veel meer grote files hebt, en je dus automatisch meer belasting hebt bij het gebruik van compressie.

Of het *echt* uitmaakt weet ik zelf ook niet, ik gebruik het niet...

Vaak hebben grote files sowieso al compressie.

Een AVI, MKV, JPEG oid hebben allemaal al compressie. ZFS probeerd de eerste paar bytes van een file te compressen, als dat niet lukt zal het bestand zonder compressie worden opgeslagen.

De kans dat je een file van 2GB aan het compressen bent is wel klein, tenzij iemand een text-file van 2GB op aan het slaan is.

Ik zou het gewoon aan zetten, als het niet lekker presteert kan je het zo weer uit zetten.

[FireDrunk]

Je slaat de spijker op z'n kop. Als compressie aan staat, word die file van 2GB dus wel even door het compressie mechanisme gehaald, en dat kost natuurlijk wat performance.

Maar inderdaad: Probeer het eens, en kijk hoe het werkt. Maar hij vroeg zich af welke CPU je erbij moest nemen, dat is wel even lastig te bepalen zonder realtime cijfers...

[NIK0]

Nog even eea nagelopen en ik zag dat een Core i5 3550 een paar euros meer kost maar wel een TDP heeft van 77W tov 95W voor een Core i5 2400 (prijsverschil heb je er snel uit met 24x7 denk ik)
Features zijn nagenoeg hetzelfde:
http://ark.intel.com/compare/65516,52207

[FireDrunk]

TDP is *NIET* het verbruik. Idle schelen deze CPU's misschien 1W.

[jackorobot]

Iemand nog een antwoord op mijn vraag?
Ik wil graag weten of het de moeite waard was om die kaart aan te schaffen!

[Snow_King]

jackorobot schreef op vrijdag 01 juni 2012 @ 13:37:
Hallo mensen,
Ik ben mij aan het orienteren naar een opslagmethode voor mijn aankomende virtualisatie bak.
Ik heb op dit moment 4x 1 TB schijven en een Dell PERC 5/i.
Nu ben ik overtuigd dat ZFS wat interessanter is dan zo een dedicated kaart.
Maar nu is mijn vraag of ZFS nog zal profiteren van de 256 MB cache die op die PERC zit, of zal dit alleen nuttiger zijn bij het gebruiken van de kaart zijn RAID functie.

Het idee is om RAIDZ2 te maken in ZFSguru en dat virtueel te gaan draaien, die array dan delen met NFS naar de ESX host als datastore voor zijn vm's.

Alvast bedankt!

Ik denk dat die kaart je mee kapot maakt dan lief is.

Zo'n cache zonder BBU is gevaarlijk voor je pool. ZFS denkt dat een transactie gelukt is en op disk staat, maar stiekem staat hij nog in de cache van de PERC. Stroom valt uit, *poef*, data weg.

Als je voldoende RAM hebt in het systeem kom je met async schrijven al heel ver. Eventueel zou je nog een SSD kunnen nemen voor de ZIL, maar ik zou die PERC links laten liggen.

[jackorobot]

Snow_King schreef op maandag 04 juni 2012 @ 20:06:
[...]
Ik denk dat die kaart je mee kapot maakt dan lief is.

Zo'n cache zonder BBU is gevaarlijk voor je pool. ZFS denkt dat een transactie gelukt is en op disk staat, maar stiekem staat hij nog in de cache van de PERC. Stroom valt uit, *poef*, data weg.

Als je voldoende RAM hebt in het systeem kom je met async schrijven al heel ver. Eventueel zou je nog een SSD kunnen nemen voor de ZIL, maar ik zou die PERC links laten liggen.

Bedankt voor het antwoord!
Ik had zo een kaart met BBU liggen en ik dacht misschien dit hiervoor te kunnen gebruiken.
Een SSD erin zetten is denk ik iets te overkill voor wat ik zou gebruiken, aangezien ik geen zware applicaties ga draaien.
Maar dan wordt het waarschijnlijk gewoon de on-board sata controller gebruiken daarvoor.
Dan maar even de V&A weer eens opzoeken

[Snow_King]

jackorobot schreef op maandag 04 juni 2012 @ 21:08:
[...]

Bedankt voor het antwoord!
Ik had zo een kaart met BBU liggen en ik dacht misschien dit hiervoor te kunnen gebruiken.
Een SSD erin zetten is denk ik iets te overkill voor wat ik zou gebruiken, aangezien ik geen zware applicaties ga draaien.
Maar dan wordt het waarschijnlijk gewoon de on-board sata controller gebruiken daarvoor.
Dan maar even de V&A weer eens opzoeken

Als er een BBU op zit is het geen probleem, dan blijven je writes na een stroomuitval tenminste bewaard.

Als de machine dan binnen 24 uur even onder spanning gaat kan de controller alles flushen naar de disk.

Het gevaar zit hem in een write-cache op een kaart zonder BBU.

[jackorobot]

Snow_King schreef op dinsdag 05 juni 2012 @ 11:23:
[...]
Als er een BBU op zit is het geen probleem, dan blijven je writes na een stroomuitval tenminste bewaard.

Als de machine dan binnen 24 uur even onder spanning gaat kan de controller alles flushen naar de disk.

Het gevaar zit hem in een write-cache op een kaart zonder BBU.

Ok, dat is duidelijk dus.
Ik kijk gewoon eerst hoe het loopt met de PERC en on-board, en welke ik het beste vind werken neem ik.
En het is natuurlijk altijd handig om meer sata/sas poorten te kunnen hebben
Ik post nog wel een keer terug als ik uitslag heb!

[HyperBart]

Iemand nog ideeën hoe ik samen met een collega eventueel de storage-performance kan troubleshooten? Zijn queue depths in VM's worden nogal groot (3 à 4) en ik had graag geweten wat daar de limiting factor is...

In aanloop naar mijn volgende blogpost over een all-in-one opstelling had ik ook graag geweten wat jullie zoal zouden runnen om benchmarks te kunnen krijgen...

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

Ik heb ondertussen zelf iets proberen in mekaar te knutselen:

VMDK op het NFS volume geplaatst, dit rechtstreeks doorgegeven aan een VM en een IOmeter gestart:

bart@OpenIndianaVirtual:~$ zpool iostat -v tank
                             capacity     operations    bandwidth
pool                      alloc   free   read  write   read  write
------------------------  -----  -----  -----  -----  -----  -----
tank                       123G   175G      1      0   193K  61.8K
  raidz1                   123G   175G      1      0   193K  61.8K
    c8t3d0                    -      -      0      0  48.3K  20.7K
    c5t0d0                    -      -      0      0  48.3K  20.7K
    c6t1d0                    -      -      0      0  48.3K  20.7K
    c7t2d0                    -      -      0      0  48.3K  20.6K
cache                         -      -      -      -      -      -
  c10t0000120000000000d0  13.1G  98.7G      0      0  2.08K  19.5K
------------------------  -----  -----  -----  -----  -----  -----

Total I/Os per Second 110.07
Total MBs per Second 0.43
Average I/O Response time (ms) 9.0782
Maximum I/O Response time (ms) 140.9235

Dit is een single worker naar het NTFS-volume, aangemaakt in Windows XP met een workload van

Size: 4KB
Transfer request size: 4KB
100% random
100% write
burst length: 1 I/O
align I/O's op sector boundaries
100% access specification
reply size: no reply

[ Voor 64% gewijzigd door HyperBart op 06-06-2012 17:00 ]

[Verwijderd]

zfs set atime=off pool/export kan nog wat helpen. Verder zit je toch aardig in de buurt van die beste man zijn blog?

Als het nog sneller moet zou ik een log device bij plaatsen.

gebruik:

nfsstat -s -z -v 3 -n 1

om te zien wat je NFS ops zijn, voor je cache het aantal hits werkt deze aardig:

dtrace -n 'sdt:zfs::arc-hit { @io = count(); } tick-1sec { printa("Total per second: %@d\n", @io); trunc(@io); }'

of anders ook:

kstat -m zfs -n arcstats

[HyperBart]

Hey psssst ik ben die blogger he

Wat doen bovenstaande commando's eigenlijk allemaal?

[FireDrunk]

Uuuuh... Niet om het even hoor, maar waarom vind je een queue depth van 4 hoog? Ik zie op drukke servers wel eens een queue van 100


Over je blog:

But, to enable those 10Gb speeds, you're ESXi host needs to be equipped with 10GB nic cards... You can't create a "virtual 10Gb network" without equipping your host with 10Gb pNIC's...

Is klets... Kan prima als je alleen 1Gb fysiek hebt.

[ Voor 57% gewijzigd door FireDrunk op 06-06-2012 21:13 ]

[Verwijderd]

Ze laten wat stats zien, met name het nfs commando (laat nfsv3 calls zien zoals read/write/getattr etc) dit is allemaal op basis can kstats, counter van de kernel. Zo heb je ook fsstat om te zien hoeveel operaties een zfs dataset heeft gedaan etc.

om een idee te krijgen wat dtrace is, zou je dit kunnen lezen Wikipedia: DTrace kort komt het er op neer dat je elke kernel call kunt tracen. In dit voorbeeld tel je hoe vaak de arc-hit() probe "fired".

Je kunt er hele leuke dingen mee doen zoals zien hoeveel "IOPS" je hebt per VMDK. Of de tijd meten tussen binnenkomst van het pakketje, het pakketje helemaal volgen tot aan disk I/O niveau en meten hoe lang het duurt totdat de ACK van dat pakketje naar buiten gaat etc..

[HyperBart]

FireDrunk schreef op woensdag 06 juni 2012 @ 21:10:
Uuuuh... Niet om het even hoor, maar waarom vind je een queue depth van 4 hoog? Ik zie op drukke servers wel eens een queue van 100


Over je blog:

Ik bedoelde de queue lengths, my bad.

[...]


Is klets... Kan prima als je alleen 1Gb fysiek hebt.

Leek mij ook, en ik had toevallig een echte VMware engineer aan de lijn en ik zat met hem wat te kletsen en toen popte ik die vraag en hij gaf het omgekeerde antwoord...

[FireDrunk]

Ik heb het hier thuis al jaren draaien... Dus wat hij zegt, zal vooral verkoopkolder zijn...

Even de technische achtergrond:

Een ESX Host heeft een vSwitch, daarop zitten een aantal poorten. Op deze poorten kunnen fysieke netwerkkaarten, maar ook VM netwerkpoorten aangesloten worden. De switch heeft intern geen vaste snelheid (zo is deze designed). Als je dus een 14.23Gbit netwerkkaart aan beide kanten erop aansluit, heb je gewoon een 14.23Gbit verbinding.

Als je 2 VM's aansluit met 10Gbit en een fysieke adapter van 1Gb als uplink aanwijst, word alle verkeer dat over die buitenlijn moet 'afgeremd', en daar zit je probleem. Als je dus de verbinding tussen VM's via een router of iets dergelijks (vanwege VLAN's) doet, dan heb je inderdaad geen 10Gbit meer.

Maar zolang het verkeer echt binnen de vSwitch blijft, heb je gewoon 10Gbit.

BIj VirtIO onder Linux, is er zelfs geen officieel limiet van de VirtIO adapter. Ik heb daar wel eens 17Gb/s gehaald.

[HyperBart]

Ja, dat dacht ik dus in eerste instantie ook... Maar dat wil daarom niet zeggen dat je per default altijd standaard lekker zoveel Gbit ziet in je VM? Maar dan moet je de vmxnet2/3 adapters dus wel gebruiken, dat was me duidelijk...

Bedankt om het van iemand die ik nu wel voor de volle 100% vertrouw op dat gebied nog eens recht te trekken .

[libero]

Ik heb een zfs server in de test hangen, echter twijfel ik nogal aan de prestaties.
De specs zijn als volgt:

Iluminos/Open indiana
2x xeon 5620
96GB RAM
12x 2TB seagate tank (1 tank van ca. 10TB) (daarna 1 iscsi target naar 1 lun/volume van 10TB)
2x 250GB SSD rpool
1x 240GB SSD cache

Dit is gekoppeld via comstar iscsi met 10GB aan een ESX machine.
De test voer ik vanaf een windows 7 vm uit. MTU=1500
Zijn onderstaande scores normaal voor een systeem van deze specs?
De sequential writes lijken me nogal laag?

[ Voor 3% gewijzigd door libero op 07-06-2012 21:50 ]

[jadjong]

Heeft die vm de 10Gb kaart via vt-d of via een vswitch met een vmxnet3?

[libero]

jadjong schreef op donderdag 07 juni 2012 @ 22:14:
Heeft die vm de 10Gb kaart via vt-d of via een vswitch met een vmxnet3?

De vm heeft gewoon een vmdk op de datastore (die is dus gemount op de host dmv iscsi), de esx host en de zfs machine zijn direct verbonden dmv. 10gb iscsi. Dus zonder switch.
De esx machine is overigens een e5-2620.

[ Voor 5% gewijzigd door libero op 07-06-2012 22:24 ]

[HyperBart]

Doe al eens een keertje een dd met if=/dev/zero...

Kijk eens wat daar je seq writes zijn... Stap voor stap de lagen gaan troubleshooten...

Als dat wel een ander resultaat geeft zou je eens kunnen proberen een LUN als RDM aan een VM te geven ipv als datastore te gebruiken voor het hosten van een VMDK die je aan een VM geeft...

[analog_]

Hoor je niet een veel hogere MTU te gebruiken?

[libero]

HyperBart schreef op donderdag 07 juni 2012 @ 23:05:
Doe al eens een keertje een dd met if=/dev/zero...

Kijk eens wat daar je seq writes zijn... Stap voor stap de lagen gaan troubleshooten...

Als dat wel een ander resultaat geeft zou je eens kunnen proberen een LUN als RDM aan een VM te geven ipv als datastore te gebruiken voor het hosten van een VMDK die je aan een VM geeft...

Dan krijg ik dit:


deze resultaten zijn dus niet goed? wat zou ongeveer normaal moeten zijn?

[libero]

analog_ schreef op donderdag 07 juni 2012 @ 23:18:
Hoor je niet een veel hogere MTU te gebruiken?

geen idee?
Ik dacht ook aan jumbo frames, maar voor kleinere files is een lagere mtu weer beter toch?

[HyperBart]

libero schreef op donderdag 07 juni 2012 @ 23:31:
[...]


Dan krijg ik dit:
[afbeelding]

deze resultaten zijn dus niet goed? wat zou ongeveer normaal moeten zijn?

Je read is prima... Maar je writes zijn idd belabberd, zeker voor het aantal spindles wat je hebt... Een collega van mij haalt hetzelfde aan writes (iets minder) met maar 3 disks in een VM dan nog met RDM's naar de disks...

[FireDrunk]

344MB/s write vind ik niet belabberd... Het kan misschien beter, maar echt slecht is het niet...
Kan je eens met iostat -x (ik geloof dat dat wel op Solaris te runnen is) kijken of je veel IOWAIT hebt?

iostat -x 1

Deze dus:


En belast:

[ Voor 28% gewijzigd door FireDrunk op 08-06-2012 09:08 ]

[HyperBart]

FireDrunk schreef op vrijdag 08 juni 2012 @ 09:00:
344MB/s write vind ik niet belabberd... Het kan misschien beter, maar echt slecht is het niet...
Kan je eens met iostat -x (ik geloof dat dat wel op Solaris te runnen is) kijken of je veel IOWAIT hebt?

iostat -x 1

Deze dus:
[afbeelding]

En belast:
[afbeelding]

Hij heeft 12 spindles, dan zou je toch al mogen verwachten dat het richting de 600 tot 800 MB/s write mag gaan?

[libero]

met iostat -x 1 is alle wait time 0.0
systeem doet ook nog niks voor de duidelijkheid.

Blocksize van de lun op indiana is 512 op vmware is de VMFS5 storage 1MB, kan dat nog zorgen voor vertraging?
write cache is uit.

[ Voor 112% gewijzigd door libero op 08-06-2012 11:32 ]

[HyperBart]

Ik heb ondertussen eens wat benches getrokken met IOmeter:


SERVER TYPE: VMware ESXi 5
CPU TYPE / NUMBER: Xeon E1230
HOST TYPE: SuperMicro X9SCA-F
STORAGE TYPE / DISK NUMBER / RAID LEVEL:
IBM 1015 flashed to IT-firmware passtroughed to a VM with OpenIndiana. Controller has 4 HP Seagates 80GB 7.2K SATA and a Patriot Pyro SE in RAIDZ and the SSD as ZIL-device
1 vCPU and 1GB of RAM

Test name Latency Avg iops Avg MBps cpu load
4K; 100% Read; 0% random 0.11 9104 35 48%
4K; 75% Read; 0% random 0.17 5815 22 34%
4K; 50% Read; 0% random 0.25 3932 15 27%
4K; 25% Read; 0% random 0.34 2938 11 22%
4K; 0% Read; 0% random 0.44 2251 8 20%
4K; 100% Read; 100% random 0.11 9063 35 51%
4K; 75% Read; 100% random 0.17 5789 22 33%
4K; 50% Read; 100% random 0.25 3984 15 27%
4K; 25% Read; 100% random 0.34 2906 11 21%
4K; 0% Read; 100% random 0.45 2235 8 18%

[FireDrunk]

libero schreef op vrijdag 08 juni 2012 @ 11:21:
met iostat -x 1 is alle wait time 0.0
systeem doet ook nog niks voor de duidelijkheid.

Blocksize van de lun op indiana is 512 op vmware is de VMFS5 storage 1MB, kan dat nog zorgen voor vertraging?
write cache is uit.

Je zou de blocksize eens kunnen veranderen naar 4K, maar dat zal weinig uitmaken.
Write caching op iSCSI staat uit? Want dat scheelt wel enorm omdat elk pakketje synced over de lijn gaat dan.

@HyperBart
Je grafiekje is niet helemaal correct... 9104 MB/s is niet echt haalbaar
En 35MB/s is weer erg langzaam, maar dat krijg je met 1GB RAM met ZFS... Dat is veel te weinig.

[ Voor 61% gewijzigd door FireDrunk op 08-06-2012 14:37 ]

[HyperBart]

Dat zijn mijn IOPS toch... (?)

[FireDrunk]

Ja, maar het aantal kolommen klopt niet. (of is niet duidelijk)

[ Voor 22% gewijzigd door FireDrunk op 08-06-2012 14:38 ]

[HyperBart]

HyperBart schreef op vrijdag 08 juni 2012 @ 14:12:
Ik heb ondertussen eens wat benches getrokken met IOmeter:


Test name Latency Avg iops Avg MBps cpu load
4K; 100% Read; 0% random 0.11 9104 35 48%
4K; 75% Read; 0% random 0.17 5815 22 34%
4K; 50% Read; 0% random 0.25 3932 15 27%
4K; 25% Read; 0% random 0.34 2938 11 22%
4K; 0% Read; 0% random 0.44 2251 8 20%
4K; 100% Read; 100% random 0.11 9063 35 51%
4K; 75% Read; 100% random 0.17 5789 22 33%
4K; 50% Read; 100% random 0.25 3984 15 27%
4K; 25% Read; 100% random 0.34 2906 11 21%
4K; 0% Read; 100% random 0.45 2235 8 18%

Test name
Latency
Avg iops
Avg MBps
cpu load

4K; 100% Read; 100% random
0.11
9063
35
51%

[ Voor 8% gewijzigd door HyperBart op 08-06-2012 14:41 ]

[FireDrunk]

Die test is dus vrij nutteloos als je sequential read wil weten. 4K is veel te klein. Pak 16M, dat werkt veel beter...

[HyperBart]

Ik wou ook gewoon mijn 4K IOPS weten, want mijn sequential reads en writes die weet ik al aan de hand van de dd toch?

[FireDrunk]

Ja klopt wel redelijk, alleen heeft DD geen queue depth, en IOMeter wel.

[libero]

FireDrunk schreef op vrijdag 08 juni 2012 @ 14:36:
[...]


Je zou de blocksize eens kunnen veranderen naar 4K, maar dat zal weinig uitmaken.
Write caching op iSCSI staat uit? Want dat scheelt wel enorm omdat elk pakketje synced over de lijn gaat dan.

@HyperBart
Je grafiekje is niet helemaal correct... 9104 MB/s is niet echt haalbaar
En 35MB/s is weer erg langzaam, maar dat krijg je met 1GB RAM met ZFS... Dat is veel te weinig.

Writecaching aan zetten is toch nogal ongebruikelijk/risicovol in zo'n setup?, stel je zou er productie op draaien?

Die DD scores die ik op de NAS zelf heb zien er dus wel acceptabel uit? denk je dat ik de problemen vooral moet zoeken in de ISCSI connectie?

[FireDrunk]

Tja, lastig te zeggen, ik ben nog niet zo bekend met verschillende setups icm ZFS, en ik kan je dus echt niet vertellen wat de max zou zijn die je zou moeten kunnen halen.

Begin bij het begin zou ik zeggen. Probeer eens verschillende blocksizes.
Wat je bijvoorbeeld ook kan doen, is eens met minder disks testen in een pool. Als de snelheid niet omlaag gaat, kan het zijn dat je aan de max doorvoersnelheid van je SATA / SAS controller zit.

Je kan ook async aanzetten om te kijken of het daar aan ligt.
Voor zover ik weet doet ESX alle shares / mounts geforceerd met SYNC. Als je dus ook nog SYNC op NFS aan hebt staan, kan het misschien zijn dat dat dubbelop is. Maar zeker weten doe ik het niet.

[Brains]

Ik zat een beetje na te denken over SSD's ism ZFS en daarbij ontstond een vraag.

Er valt te lezen dat een ZFS pool corrupt kan raken als een SSD met ZIL zijn schrijfactie niet heeft kunnen verwerken wanneer de spanning wegvalt. Daarvoor zou een SSD met condensator gebruikt moeten worden.
Maar geldt dit corrupt raken voor alle ZFS pools met SSD's? Als je een mirror zou hebben van twee SSD's dan kan een schrijfactie ook niet volledig afgerond zijn en is de pool dan ook corrupt?

Nu lees ik wel dat een pool te herstellen valt van een dergelijke crash en alleen "wat" data verloren gaat.

Geldt het risico van "consumenten" SSD's nu altijd bij ZFS (en bij alle bestandssytemten)?

[FireDrunk]

Je pool kan (theoretisch gezien) maar corrupt raken tot een bepaald moment in tijd waarop alle writes wél goed gegaan zijn. ZFS heeft de eigenschap dat het een aantal writes opspaart en daarna pas naar disk flushed.
Als je weinig activiteit hebt kan het voorkomen dat er ook niet geflushed word, maar dat dat uitgesteld word.

Als je pool corrupt raakt doordat je SSD zijn actie niet afmaakt, kan je terug gaan tot het moment dat alles koek en ei was. Ik las laatst van iemand dat dat om minuten gaat. In een thuissituatie dus echt niet erg, maar in het geval van een productiedatabase kan dat knap lastig zijn.

Veel verschil tussen consumenten SSD's en enterprise SSD's is er niet, de URER ligt niet heel ver uit elkaar volgens mij.

[Brains]

Het geheel zal wel semi-professioneel worden ingezet. Maar bij een spanningsuitval is 1 minuut te overzien. Als het gebeurd pech, maar de UPS zal toch een deel van het risico wegnemen.

Ik dacht dat in enterprise SSD's vaker een condensator werd toegepast.

Maar we hebben een stel kleinere SSD's "over" en daar wil ik een pool van maken om daar wat VM's op te draaien. Dus lekker vlot met de zekerheid van ZFS, mocht één van de SSD falen.

[ Voor 7% gewijzigd door Brains op 08-06-2012 22:29 ]

[libero]

Is het eigenlijk gebruikelijk om writeback cache aan te zetten? of is dat een erg groot risico?
stel je server valt uit, what happens? de cache staat dan op ssd die is er nog steeds na een power failure, of stat die op geheugen en is dan weg?

[nielsdc]

ZFS zal normaal gesproken een flush commando naar de ZIL sturen, zodat het zeker is dat de data weggeschreven is en niet meer in de cache staat. (Of de SSD dit ook daadwerkelijk doet is de vraag natuurlijk).
Je pool zou nooit corrupt moeten raken, maar je kan wel data verliezen als je systeem crashed binnen 5 seconden nadat je de zil verliest, en dan maximaal de laatste 5 seconden. De ZIL wordt normaal gesproken alleen gebruikt voor recovery als er een crash/power outage is geweest, normaal wordt het gewoon in het geheugen bewaard.

[HyperBart]

FireDrunk schreef op vrijdag 08 juni 2012 @ 14:36:
[...]


Je zou de blocksize eens kunnen veranderen naar 4K, maar dat zal weinig uitmaken.
Write caching op iSCSI staat uit? Want dat scheelt wel enorm omdat elk pakketje synced over de lijn gaat dan.

@HyperBart
Je grafiekje is niet helemaal correct... 9104 MB/s is niet echt haalbaar
En 35MB/s is weer erg langzaam, maar dat krijg je met 1GB RAM met ZFS... Dat is veel te weinig.

Dus die 35 mb is te traag? Ik heb maar 4 disks van 80gb dus ik dacht met 1gb wel ruim voldoende te hebben....

[FireDrunk]

Afgaande dat een gemiddelde 80GB schijf in z'n uppie 50-75MB/s doet, ja dan is 35MB/s traag ja...
Waar dat aan ligt? Geen idee, maar ik vermoed het geheugen, omdat met 1GB je echt nul prefetching en caching hebt. Alles is dus write-thru en read-thru.

[HyperBart]

Hoe komt het eigenlijk dat je telkens bij ZFS-folder een ander getal ziet qua beschikbaarheid van diskruimt:


your datasets:
NAME USED AVAIL REFER MOUNTPOINT
tank 114G 127G 47.9K /tank
tank/test1 92.1G 105G 92.1G /tank/test1
tank/test4 47.9K 105G 47.9K /tank/test4
tank/test5 47.9K 105G 47.9K /tank/test5

Ik heb 4 disks van 80GB in RaidZ staan... Dat is dus 320 - 80 = 240

Hoe verklaart men dat dit tabelletje? In mijn NFS-datastores zie ik zogezegd ook maar 197GB capaciteit...

[FireDrunk]

Een 80GB schijf is 80.000.000.000 bytes... == 74.5 GiB
4 * 74.5 = 298 GiB - 74.5 = 223.5 GiB

[HyperBart]

105 + 92.1 = 197,1

Dan kom ik er nog niet, right?

[FireDrunk]

zpool status?

[HyperBart]

root@OpenIndianaVirtual:/home/bart# zpool status
  pool: rpool
 state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          c3t0d0s0  ONLINE       0     0     0

errors: No known data errors

  pool: tank
 state: ONLINE
  scan: none requested
config:

        NAME                      STATE     READ WRITE CKSUM
        tank                      ONLINE       0     0     0
          raidz1-0                ONLINE       0     0     0
            c8t3d0                ONLINE       0     0     0
            c5t0d0                ONLINE       0     0     0
            c6t1d0                ONLINE       0     0     0
            c7t2d0                ONLINE       0     0     0
        logs
          c10t0000120000000000d0  ONLINE       0     0     0

errors: No known data errors
root@OpenIndianaVirtual:/home/bart#

[FireDrunk]

tank 114G 127G 47.9K /tank

114G + 127G = 241G? Klopt toch?

[HyperBart]

Mja, maar waar is dan plots die 114 - 105 naar toe ?

[FireDrunk]

Aan Tank/* toegewezen?

[ Voor 4% gewijzigd door FireDrunk op 12-06-2012 10:56 ]

[Staatslot]

Ik ben begonnen aan mijn eerste ZFS build, maar loop helaas tegen problemen aan.
Ik heb de LSI 9221-8i geflasht naar IT firmware en met sas naar sata kabels mijn harddisks aangesloten.

Helaas zie ik mijn harddisks niet verschijnen, zowel in Freenas als in Ubuntu (live cd).
Ik heb de 9221-8i ingesteld op disabled, enabled OS only, enabled BIOS only en enabled BIOS and OS maar dat werkt allemaal helaas niet.

Moet ik nog iets bijzonders doen om die kaart mijn harddisks te laten doorgeven?

[matty___]

Staatslot schreef op dinsdag 12 juni 2012 @ 12:11:
Ik ben begonnen aan mijn eerste ZFS build, maar loop helaas tegen problemen aan.
Ik heb de LSI 9221-8i geflasht naar IT firmware en met sas naar sata kabels mijn harddisks aangesloten.

Helaas zie ik mijn harddisks niet verschijnen, zowel in Freenas als in Ubuntu (live cd).
Ik heb de 9221-8i ingesteld op disabled, enabled OS only, enabled BIOS only en enabled BIOS and OS maar dat werkt allemaal helaas niet.

Moet ik nog iets bijzonders doen om die kaart mijn harddisks te laten doorgeven?

als je de bios van de controller in gaat bij het booten. Zie je dan wel alle disks?

[Staatslot]

matty___ schreef op dinsdag 12 juni 2012 @ 12:43:
[...]

als je de bios van de controller in gaat bij het booten. Zie je dan wel alle disks?

Nee

[FireDrunk]

Verkeerde kabel? (Forward breakout vs Backward breakout?)

[Staatslot]

FireDrunk schreef op dinsdag 12 juni 2012 @ 13:03:
Verkeerde kabel? (Forward breakout vs Backward breakout?)

held! nu kijken waar ik in de buurt terecht kan voor de juiste...

[Pantagruel]

Een van de 2TB EARS (ca. 11 maanden oud) is de geest aan t geven volgens de S.M.A.R.T info:

code:

ID# ATTRIBUTE_NAME        FLAG   VALUE WORST THRESH TYPE UPDATED  WHEN_FAILED RAW_VALUE
1   Raw_Read_Error_Rate   0x002f  001  001   051    Pre-fail  Always FAILING_NOW 67901      
3   Spin_Up_Time          0x0027  253  239   021    Pre-fail  Always    -        2016
4   Start_Stop_Count      0x0032  100  100   000    Old_age   Always    -        104
5   Reallocated_Sector_Ct 0x0033  163  163   140    Pre-fail  Always    -        703

WD's DLGDIAG crashed met een error 0108 (seek not completed) naar de prompt

Dat wordt dus RMA aanvraag doen bij WD, DBAN runnen, netjes verpakken, uitzwaaien en dan wachten.
(Ja ik weet dat je xpress RMA kunt doen, maar met de gestelde marktwaarde van $180 die ze op je CC blokkeren ben ik het niet echt eens, waarde in NL is ca €120 )

En dan voor de resterende 9 stuks in de RAIDZ2 array (nu dus RAIDZ1) is het hopen dat ze in leven blijven

[Snow_King]

Pantagruel schreef op vrijdag 15 juni 2012 @ 13:44:
Een van de 2TB EARS (ca. 11 maanden oud) is de geest aan t geven volgens de S.M.A.R.T info:

code:

ID# ATTRIBUTE_NAME        FLAG   VALUE WORST THRESH TYPE UPDATED  WHEN_FAILED RAW_VALUE
1   Raw_Read_Error_Rate   0x002f  001  001   051    Pre-fail  Always FAILING_NOW 67901      
3   Spin_Up_Time          0x0027  253  239   021    Pre-fail  Always    -        2016
4   Start_Stop_Count      0x0032  100  100   000    Old_age   Always    -        104
5   Reallocated_Sector_Ct 0x0033  163  163   140    Pre-fail  Always    -        703

WD's DLGDIAG crashed met een error 0108 (seek not completed) naar de prompt

Dat wordt dus RMA aanvraag doen bij WD, DBAN runnen, netjes verpakken, uitzwaaien en dan wachten.
(Ja ik weet dat je xpress RMA kunt doen, maar met de gestelde marktwaarde van $180 die ze op je CC blokkeren ben ik het niet echt eens, waarde in NL is ca €120 )

En dan voor de resterende 9 stuks in de RAIDZ2 array (nu dus RAIDZ1) is het hopen dat ze in leven blijven

Wel de idle uit gezet van de disks?

http://idle3-tools.sourceforge.net/

[Pantagruel]

Snow_King schreef op vrijdag 15 juni 2012 @ 15:43:
[...]
Wel de idle uit gezet van de disks?

http://idle3-tools.sourceforge.net/

Yep, bij de eerste 4 disks pas na een week (en die hebben inderdaad een flinke load cycle count) bij de andere 6 meteen na binnenkomst. De wdidle3 tool was wel een zeurtje, wilde enkel op SATA-1 een disk vinden en de APM setting aanpassen, is maar goed dat SATA hot plug is.

[HyperBart]

Pantagruel schreef op vrijdag 15 juni 2012 @ 13:44:
Een van de 2TB EARS (ca. 11 maanden oud) is de geest aan t geven volgens de S.M.A.R.T info:

code:

ID# ATTRIBUTE_NAME        FLAG   VALUE WORST THRESH TYPE UPDATED  WHEN_FAILED RAW_VALUE
1   Raw_Read_Error_Rate   0x002f  001  001   051    Pre-fail  Always FAILING_NOW 67901      
3   Spin_Up_Time          0x0027  253  239   021    Pre-fail  Always    -        2016
4   Start_Stop_Count      0x0032  100  100   000    Old_age   Always    -        104
5   Reallocated_Sector_Ct 0x0033  163  163   140    Pre-fail  Always    -        703

WD's DLGDIAG crashed met een error 0108 (seek not completed) naar de prompt

Dat wordt dus RMA aanvraag doen bij WD, DBAN runnen, netjes verpakken, uitzwaaien en dan wachten.
(Ja ik weet dat je xpress RMA kunt doen, maar met de gestelde marktwaarde van $180 die ze op je CC blokkeren ben ik het niet echt eens, waarde in NL is ca €120 )

En dan voor de resterende 9 stuks in de RAIDZ2 array (nu dus RAIDZ1) is het hopen dat ze in leven blijven

Daarvoor heb je RAIDZ2 he, geen zorgen, je draait nu met NOG een pariteit... Moet al gek gaan als er nu op korte termijn NOG 2 disks voor of tijdens je rebuild kaduuk gaan...

Ik kreeg het pas warm toen mijn QNAP 439 Pro II met 4 disks in RAID5 al voor de 3de keer een disk er uit knalde

[Pantagruel]

HyperBart schreef op vrijdag 15 juni 2012 @ 21:36:
[...]

Daarvoor heb je RAIDZ2 he, geen zorgen, je draait nu met NOG een pariteit... Moet al gek gaan als er nu op korte termijn NOG 2 disks voor of tijdens je rebuild kaduuk gaan...

Ik kreeg het pas warm toen mijn QNAP 439 Pro II met 4 disks in RAID5 al voor de 3de keer een disk er uit knalde

Klopt Z2 kan twee falende disks hebben (en staat dan zonder pariteit te draaien) en inderdaad de vingers gekruist houden dat er nu en straks tijdens de rebuild van de array er geen disk uit knalt. RMA is gedaan, ongeduldig afwachten (ben nog in brio of ik wel of niet en 2TB disk zal gaan halen/bestellen)

Wat dat betreft met de vorige hardware oplossing (3ware R5 en consumer disks) altijd geluk gehad, nooit een brakke disk of array rebuild gehad (anders dan door kapot configgen )

[FireDrunk]

ZFS heeft geen Rebuild, maar een Resilvering, en dat werkt volgens mij nog even anders.
Als je écht bang bent dat er een disk klapt tijdens de rebuild, en je oude schijf doet het nog wel maar heeft bad sectors, kan je een complete disk dump maken van je oude schijf, en die op de nieuwe schijf zetten.

Als je dan rebuild, is het met 10 minuten gedaan, omdat resilvering vele malen intelligenter is dan rebuilden.

[matty___]

FireDrunk schreef op zaterdag 16 juni 2012 @ 10:10:
ZFS heeft geen Rebuild, maar een Resilvering, en dat werkt volgens mij nog even anders.
Als je écht bang bent dat er een disk klapt tijdens de rebuild, en je oude schijf doet het nog wel maar heeft bad sectors, kan je een complete disk dump maken van je oude schijf, en die op de nieuwe schijf zetten.

Als je dan rebuild, is het met 10 minuten gedaan, omdat resilvering vele malen intelligenter is dan rebuilden.

ga je dit met de disk doen die online is in de pool of ga je hem eerst offline halen en dan met dd aan de slag?

[FireDrunk]

Als hij als faulty gemarkeerd word kan je hem er net zo goed uit halen

(ik heb zelf wel reserve 2TB disks liggen, dus voor mij zou dit een optie zijn, maar voor mensen die de disk eerst op moeten sturen natuurlijk niet.)

[Pantagruel]

FireDrunk schreef op zaterdag 16 juni 2012 @ 10:10:
ZFS heeft geen Rebuild, maar een Resilvering, en dat werkt volgens mij nog even anders.
Als je écht bang bent dat er een disk klapt tijdens de rebuild, en je oude schijf doet het nog wel maar heeft bad sectors, kan je een complete disk dump maken van je oude schijf, en die op de nieuwe schijf zetten.

Als je dan rebuild, is het met 10 minuten gedaan, omdat resilvering vele malen intelligenter is dan rebuilden.

Yep een resilver werkt een stukje sneller, probleem is wel dat bij een dd poging tegen een 'seek error' aanliep en de schijf vervolgens geen bitje verder kwam.

matty___ schreef op zaterdag 16 juni 2012 @ 11:37:
[...]

ga je dit met de disk doen die online is in de pool of ga je hem eerst offline halen en dan met dd aan de slag?

Disk uit de pool mikken en offline dd-en.

FireDrunk schreef op zaterdag 16 juni 2012 @ 13:34:
Als hij als faulty gemarkeerd word kan je hem er net zo goed uit halen

(ik heb zelf wel reserve 2TB disks liggen, dus voor mij zou dit een optie zijn, maar voor mensen die de disk eerst op moeten sturen natuurlijk niet.)

Mijn cold-spare is bij mijn broer in gebruik, die had 3 weken terug een rotte Seagate. Tja, wat zou de kans zijn dat een schijf uit eigen zfs pool vervolgens over de nek gaat, zou je denken.

[Nielson]

Pantagruel schreef op zaterdag 16 juni 2012 @ 13:44:
Yep een resilver werkt een stukje sneller, probleem is wel dat bij een dd poging tegen een 'seek error' aanliep en de schijf vervolgens geen bitje verder kwam.

dd_rescue gaat in zo'n geval als het goed is wel verder.

[Pantagruel]

Nielson schreef op zaterdag 16 juni 2012 @ 13:56:
[...]
dd_rescue gaat in zo'n geval als het goed is wel verder.

ik dd_rescue hem op dit moment naar een image op een andere machine (RAID-0 uit 3x 1TB disk) want ik kon in de buurt geen 2 TB drive krijgen bij de hardware boeren (strikt genomen bij eentje wel, maar 200 euro had ik niet voor de drive over)

[FireDrunk]

Ik ben wel beniewd of dat werkt (het was vooral een theorie) ik vraag me af of de print die ZFS op een disk zet per disk afhankelijk is van bijvoorbeeld het serienummer.

Als dat zo is, kan je hem misschien niet importeren...

Ik ben benieuwd naar je resultaten...

[Snow_King]

FireDrunk schreef op zaterdag 16 juni 2012 @ 19:29:
Ik ben wel beniewd of dat werkt (het was vooral een theorie) ik vraag me af of de print die ZFS op een disk zet per disk afhankelijk is van bijvoorbeeld het serienummer.

Als dat zo is, kan je hem misschien niet importeren...

Ik ben benieuwd naar je resultaten...

Nee, ZFS schrijft gewoon een label op een disk, die kijkt niet naar het serienummer van de disk.

[FireDrunk]

Hoe weet hij dan welke disk het is van een bepaald set

[Snow_King]

FireDrunk schreef op zaterdag 16 juni 2012 @ 19:32:
Hoe weet hij dan welke disk het is van een bepaald set

ZFS schrijft een label en op basis daarvan weet ZFS welke disk bij een pool hoort.

Het staat gewoon in de eerste aantal X bytes (weet niet het aantal) van de disk, daarin staat alle meta informatie.

[FireDrunk]

Dat snap ik, maar ik vraag me af of dat label transporteerbaar is

[Pantagruel]

FireDrunk schreef op zaterdag 16 juni 2012 @ 20:19:
Dat snap ik, maar ik vraag me af of dat label transporteerbaar is

Ik ga t wel zien, mocht het om wat voor redenen niet lukken is er niets verloren, behalve extra tijd om de boel te resilveren.

[FireDrunk]

Precies, we wachten het gewoon af

[Snow_King]

FireDrunk schreef op zaterdag 16 juni 2012 @ 20:19:
Dat snap ik, maar ik vraag me af of dat label transporteerbaar is

Ah, zo.

Ja, dat is het zeker. Als je gewoon vanaf sector 0 de originele disk leest tot het einde en dat ook precies weer weg schrijft op een andere disk is er geen verschil voor ZFS.

[Rexel]

Ik heb even zitten experimenteren van FreeNAS en ZFS RAIDZ1 in een VMWare, nou viel me op dat nadat ik een RAIDZ1 had opgebouwd met 3 schijven en een 4de hier aan toe wilde voegen dat deze werd bestempeld als stripe. , ik ben me er van bewust dat je nadat je een RAIDZ1 hebt aangemaakt deze niet kan vergrote.(heb de opening post doorgelezen).

Nu vraag ik me dus af hoe moet ik deze stripe zien. Word dit een nieuwe RAIDZ1 pool die samen met de 1ste pool een soort RAID50 vormt? De grote van de disk komt namelijk wel bij het totaal van de 1ste pool.

Alvast bedankt!

[Aurora_71]

Rexel schreef op maandag 18 juni 2012 @ 01:03:
Ik heb even zitten experimenteren van FreeNAS en ZFS RAIDZ1 in een VMWare, nou viel me op dat nadat ik een RAIDZ1 had opgebouwd met 3 schijven en een 4de hier aan toe wilde voegen dat deze werd bestempeld als stripe

Graag output van 'zpool status' van je raidz en het exacte commando wat je hebt gebruikt om de 4e disk "toe te voegen"

[Rexel]

Aurora_71 schreef op maandag 18 juni 2012 @ 01:23:
[...]

Graag output van 'zpool status' van je raidz en het exacte commando wat je hebt gebruikt om de 4e disk "toe te voegen"

#Manier van toevoegen, disk zijn afzonderlijk toegevoegd. dus niet als hele set in een keer.
http://www.uploadplaatjes.nl/image/view/606423

#Overzicht van de opbouw van DATA na 1 disk toegevoegen
http://www.uploadplaatjes.nl/image/view/606424

#Overzicht van de opbouw van DATA nadat er 3 extra disks afzonderlijk zijn toegevoegt
http://www.uploadplaatjes.nl/image/view/606427

#Lijst van active volumes in FreeNAS 8.2 - 2de 'pool' als striped
http://www.uploadplaatjes.nl/image/view/606428

# Output van zpool in de shell
http://www.uploadplaatjes.nl/image/view/606429

Ik zag bij het maken dat screenshots dat zodra ik de laatste 3 schijf ook als een groep toevoeg dat hij hier ook een raidz1 van kan maken. Alleen nu is het voor me zelf niet duidelijk wat er dan anders is wanneer hij striped aan geeft of raidz1 voor de 2de pool. De totale opslag veranderd niet in iedergeval.

#Overzicht van DATA nadat de laatste 3 schijven ook als RAIDZ1 zijn toegevoegd
http://www.uploadplaatjes.nl/image/view/606433

#Output van zpool status
http://www.uploadplaatjes.nl/image/view/606434

Ik hoop dat ik jullie voldoende informatie heb gegeven met de screenshots. Het gaat hier trouwens om FreeNAS 8.2 BETA4

[matty___]

Rexel schreef op maandag 18 juni 2012 @ 01:03:
Ik heb even zitten experimenteren van FreeNAS en ZFS RAIDZ1 in een VMWare, nou viel me op dat nadat ik een RAIDZ1 had opgebouwd met 3 schijven en een 4de hier aan toe wilde voegen dat deze werd bestempeld als stripe. , ik ben me er van bewust dat je nadat je een RAIDZ1 hebt aangemaakt deze niet kan vergrote.(heb de opening post doorgelezen).

Nu vraag ik me dus af hoe moet ik deze stripe zien. Word dit een nieuwe RAIDZ1 pool die samen met de 1ste pool een soort RAID50 vormt? De grote van de disk komt namelijk wel bij het totaal van de 1ste pool.

Alvast bedankt!

2x raidz1 in stripe = raid50 (laatste screenshot geeft dat weer)

[ Voor 37% gewijzigd door matty___ op 18-06-2012 09:02 ]

[Goderic]

Rexel schreef op maandag 18 juni 2012 @ 01:56:
Ik zag bij het maken dat screenshots dat zodra ik de laatste 3 schijf ook als een groep toevoeg dat hij hier ook een raidz1 van kan maken. Alleen nu is het voor me zelf niet duidelijk wat er dan anders is wanneer hij striped aan geeft of raidz1 voor de 2de pool. De totale opslag veranderd niet in iedergeval.

Dat komt omdat zpool status de grootte van de hele disks optelt bij raidz. Als je een zfs list doet zul je zien dat de stripe van raidz + raidz minder plaats heeft dan die van raidz + 3x disk.
Het verschil is er dus wel.

In het eerste geval heb je 2 raidz vdevs die in raid0 staan, pas als 1 van de raidz vdevs kapot is ben je je data kwijt.
In het tweede geval heb je 1 raidz vdev en 3 vdevs die gewoon uit een disk bestaan. Wanneer een van deze losse disks (of de raidz vdev) kapot gaat ben je je data kwijt.

[Ultraman]

Rexel schreef op maandag 18 juni 2012 @ 01:56:
[...]

#Manier van toevoegen, disk zijn afzonderlijk toegevoegd. dus niet als hele set in een keer.
http://www.uploadplaatjes.nl/image/view/606423

#Overzicht van de opbouw van DATA na 1 disk toegevoegen
http://www.uploadplaatjes.nl/image/view/606424

#Overzicht van de opbouw van DATA nadat er 3 extra disks afzonderlijk zijn toegevoegt
http://www.uploadplaatjes.nl/image/view/606427

#Lijst van active volumes in FreeNAS 8.2 - 2de 'pool' als striped
http://www.uploadplaatjes.nl/image/view/606428

# Output van zpool in de shell
http://www.uploadplaatjes.nl/image/view/606429

Ik zag bij het maken dat screenshots dat zodra ik de laatste 3 schijf ook als een groep toevoeg dat hij hier ook een raidz1 van kan maken. Alleen nu is het voor me zelf niet duidelijk wat er dan anders is wanneer hij striped aan geeft of raidz1 voor de 2de pool. De totale opslag veranderd niet in iedergeval.

Hierboven toon je een 3-disk raidz1 + 1 losse disk + 1 losse disk + 1 losse disk, dus 4 vdevs, die samen een pool vormen.
Gaat er één van die vier vdevs kapot -> pool stuk.
Dus bijvoorbeeld een losse disk die stuk gaat of twee disken uit de raidz1 vdev, resulteert in dataverlies.

#Overzicht van DATA nadat de laatste 3 schijven ook als RAIDZ1 zijn toegevoegd
http://www.uploadplaatjes.nl/image/view/606433

#Output van zpool status
http://www.uploadplaatjes.nl/image/view/606434

Ik hoop dat ik jullie voldoende informatie heb gegeven met de screenshots. Het gaat hier trouwens om FreeNAS 8.2 BETA4

Dit is een 3-disk raidz1 + 3-disk raidz1.
Waarschijnlijk is dit de gewenste opstelling, dit is namelijk vergelijkbaar met RAID50.
Er zal wel degelijk een verschil in grootte zijn, je heb hier een disk minder aan pure opslagruimte.

Ben je van plan een dergelijke opstelling te maken? Heb je ook een 6-disk raidz2 overwogen?
Wat voor een I/O verwacht je nodig te hebben? Striped raidz1 zal een hogere IOPS hebben, maar 6-disk raidz2 is veiliger omdat je 2 willekeurige disken kan verliezen zonder dat je data gevaar loopt.

[Rexel]

Allereerst bedankt allemaal voor jullie reacties. het is me een stuk duidelijker!.

Ultraman schreef op maandag 18 juni 2012 @ 10:07:
[...]
Hierboven toon je een 3-disk raidz1 + 1 losse disk + 1 losse disk + 1 losse disk, dus 4 vdevs, die samen een pool vormen.
Gaat er één van die vier vdevs kapot -> pool stuk.
Dus bijvoorbeeld een losse disk die stuk gaat of twee disken uit de raidz1 vdev, resulteert in dataverlies.

[...]

Dit is een 3-disk raidz1 + 3-disk raidz1.
Waarschijnlijk is dit de gewenste opstelling, dit is namelijk vergelijkbaar met RAID50.
Er zal wel degelijk een verschil in grootte zijn, je heb hier een disk minder aan pure opslagruimte.

Ben je van plan een dergelijke opstelling te maken? Heb je ook een 6-disk raidz2 overwogen?
Wat voor een I/O verwacht je nodig te hebben? Striped raidz1 zal een hogere IOPS hebben, maar 6-disk raidz2 is veiliger omdat je 2 willekeurige disken kan verliezen zonder dat je data gevaar loopt.

Ik ben inderdaad van plan om een ZFS opstelling te maken, wilde even kijken hoe het precies werkte met schijven toevoegen en dergelijke dus van daar de VMWare met 6 schijven. Ik draai nu nog een windows bak met software raid 5 maar die bevalt me niet zo..

Ik heb momenteel 3x 1.5TB waarvan er 1tje bad sectors heeft en 1x 2TB schijven. en zat er dus aan te denken om momenteel 1 RAIDZ1 pool met alle schijven aan te maken en het verlies van 500GB nog even voor lief te nemen en later de 3x 1.5TB schijven te vervangen door 2TB schijven.

De server word gebruikt voor muziek, film en documenten op te slaan. hij word niet heel intensief gebruikt. hij word wel gebruikt voor het streamen van films naar de TV.

[iRReeL]

Helaas gaat het niet helemaal goed met mijn servertje, vorige week een probleem dat 1 client wel nog toegang had tot de shares maar de andere machines niet. Gisteren weer geen shares, geen ZFSguru en krijg dit te zien:


Een reboot werkt dan ook niet, niet alle disks waren beschikbaar en begrijp ik het correct dat 1 van de 2 M1015 kaarten niet goed werkt en uitvalt? Na een power off/on werkt dan alles weer voor 'n paar dagen..

In ZFSguru system / kernel log kon ik verder geen foutmeldingen vinden.

[FireDrunk]

Worden de kaartjes te warm misschien?

[iRReeL]

Ik dacht het niet, er is toch wel een redelijk flow maar niets direct op de kaartjes, ik zal er tijdelijk een fan bijhangen en kijken of dat iets uitmaakt

[matty___]

iRReeL schreef op maandag 18 juni 2012 @ 14:20:
Ik dacht het niet, er is toch wel een redelijk flow maar niets direct op de kaartjes, ik zal er tijdelijk een fan bijhangen en kijken of dat iets uitmaakt

kan ook een freebsd driver probleem zijn. Heb je al de freebsd-stable/fs/current mailinglist gecheckt.