Het grote ZFS topic

[nwagenaar]

Ik zat te denken aan out-of-the-box performance met een aantal kleine tweaks (geen sync, geen compressie, geen deduplication).

[matty___]

nwagenaar schreef op donderdag 26 juli 2012 @ 10:32:
Ik zat te denken aan out-of-the-box performance met een aantal kleine tweaks (geen sync, geen compressie, geen deduplication).

geen sync bij zfs?

en je arc grootte, txgroup timeout etc? en het is een nas dus lijkt me de netwerkperformance ook niet geheel onbelangrijk dan krijg je weer een hoop samba en nfs tuning, niet te vergeten de tcp tuning en de nic driver (polling op de EM driver scheelt bij mij 8mb/s met samba) bij freebsd

[justice strike]

Even om een andere discussie aan te zwengelen.

Ik heb recentelijk mijn bsd server opgebouwd gebruik makende van een platinum voeding, een brazo's bord en een aantal 3.5 inch green drives (3 in totaal, daar zijn nog 3 normale drives bij gekomen maar dat doet niet terzake).

Ik vraag mij eigenlijk af of ik wat betreft zuinigheid nog wat beters had kunnen kiezen (het is dus een pure prijs energie discussie).

Er vanuit gaande dat de server 24 uur per dag draait en de schijven zo''n 8 tot 16 uur aan moeten staan (de overige 8 uur is snachts). Was het goedkoper geweest om laptop hd's te kopen en/of een ssd als cache?.
De premium van een laptop hd is wel substantieel overigens. je kunt anderhalf keer zoveel schijfruimte krijgen voor dezelfde prijs als je voor 3.5 inch schijven gaat. Dus de vraag is Kun je dat bedrag dan ook in stroom op je rekening terug verwachten? Ik had zelf de inschatting gemaakt van niet, maar ik twijfel er nog een beetje aan.

verder vraag ik mij af of je met een ssd niet kunt zorgen dat veel schrijfacties delayed kunnen worden (soms wel substantieel) zodat de schijven niet meteen hoeven op te spinnen. Dan heb ik het ansich over delays van een uur ofzo (mits je ssd dat toelaat). Dat kan namelijk ook in stroom verbruik schelen.

En dan nog de vraag of een g530 niet beter was geweest ipv een brazo's bord.

[matty___]

justice strike schreef op donderdag 26 juli 2012 @ 12:35:
Even om een andere discussie aan te zwengelen.

Ik heb recentelijk mijn bsd server opgebouwd gebruik makende van een platinum voeding, een brazo's bord en een aantal 3.5 inch green drives (3 in totaal, daar zijn nog 3 normale drives bij gekomen maar dat doet niet terzake).

Ik vraag mij eigenlijk af of ik wat betreft zuinigheid nog wat beters had kunnen kiezen (het is dus een pure prijs energie discussie).

Er vanuit gaande dat de server 24 uur per dag draait en de schijven zo''n 8 tot 16 uur aan moeten staan (de overige 8 uur is snachts). Was het goedkoper geweest om laptop hd's te kopen en/of een ssd als cache?.
De premium van een laptop hd is wel substantieel overigens. je kunt anderhalf keer zoveel schijfruimte krijgen voor dezelfde prijs als je voor 3.5 inch schijven gaat. Dus de vraag is Kun je dat bedrag dan ook in stroom op je rekening terug verwachten? Ik had zelf de inschatting gemaakt van niet, maar ik twijfel er nog een beetje aan.

verder vraag ik mij af of je met een ssd niet kunt zorgen dat veel schrijfacties delayed kunnen worden (soms wel substantieel) zodat de schijven niet meteen hoeven op te spinnen. Dan heb ik het ansich over delays van een uur ofzo (mits je ssd dat toelaat). Dat kan namelijk ook in stroom verbruik schelen.

En dan nog de vraag of een g530 niet beter was geweest ipv een brazo's bord.

je kunt je afvragen hoe lang het duurt voordat je een ssd hebt terug verdiend. Zelfde met een ander platform kiezen.
en je zou het systeem snachts uit kunnen zetten.

[justice strike]

matty___ schreef op donderdag 26 juli 2012 @ 12:43:
[...]

je kunt je afvragen hoe lang het duurt voordat je een ssd hebt terug verdiend. Zelfde met een ander platform kiezen.
en je zou het systeem snachts uit kunnen zetten.

dat is idd de discussie. Of je het er uit zou verdienen.

Ik zou hem uit kunnen zetten ja, maar dat gaan we niet doen omdat er ook een website op draait.

[CurlyMo]

Laten we voor het gemak even het gemiddelde nemen tussen het idle en actieve verbruik:

Samsung HD204UI: 5w
Samsung M8: 1,5w

Kosten van één schijf 24/7 per jaar bij een energieprijs van 0,22 is:

Samsung HD204UI: ((5 * 24 * 365) / (1000)) * 0,22 = +/- 9,5 euro
Samsung M8: ((1,5 * 24 * 365) / (1000)) * 0,22 = +/- 3 euro

Energieprijs voor een RAIDZ2 van 4TB:

Samsung HD204U: 4 * 9.5 = 38 euro
Samsung M8: 6 * 3 = 18 euro

De aanschafprijs:

Samsung HD204U: 4 * 95 = 380 euro
Samsung M8: 6 * 87 = 522 euro

Kosten na één jaar incl. energie:

Samsung HD204U: 380 + 38 = 418 euro
Samsung M8: 522 + 18 = 540 euro

Hoeveel moeten je schijven meegaan totdat je het verschil gaat merken:

380 + 38X = 522 + 18X
38X = 142 + 18X
20X = 142
X = 7,1

Na 7,1 jaar ga je dus de kosten terug verdienen voor het kopen van 2,5" HDD

Hoe zou het dan zijn geweest bij normale HDD prijzen (naar schatting):

(4 * 55) + 38X = (6 * 60) + 18X
38X = 140 + 18X
20X = 140
X = 7

Dan zou je er ook 7 jaar over gedaan hebben

[matty___]

CurlyMo schreef op donderdag 26 juli 2012 @ 13:08:
Laten we voor het gemak even het gemiddelde nemen tussen het idle en actieve verbruik:

Samsung HD204UI: 5w
Samsung M8: 1,5w

Kosten van één schijf 24/7 per jaar bij een energieprijs van 0,22 is:

Samsung HD204UI: ((5 * 24 * 365) / (1000)) * 0,22 = +/- 9,5 euro
Samsung M8: ((1,5 * 24 * 365) / (1000)) * 0,22 = +/- 3 euro

Energieprijs voor een RAIDZ2 van 4TB:

Samsung HD204U: 4 * 9.5 = 38 euro
Samsung M8: 6 * 3 = 18 euro

De aanschafprijs:

Samsung HD204U: 4 * 95 = 380 euro
Samsung M8: 6 * 87 = 522 euro

Kosten na één jaar incl. energie:

Samsung HD204U: 380 + 38 = 418 euro
Samsung M8: 522 + 18 = 540 euro

Hoeveel moeten je schijven meegaan totdat je het verschil gaat merken:

380 + 38X = 522 + 18X
38X = 142 + 18X
20X = 142
X = 7,1

Na 7,1 jaar ga je dus de kosten terug verdienen voor het kopen van 2,5" HDD

Hoe zou het dan zijn geweest bij normale HDD prijzen (naar schatting):

(4 * 55) + 38X = (6 * 60) + 18X
38X = 140 + 18X
20X = 140
X = 7

Dan zou je er ook 7 jaar over gedaan hebben

en dan maar hopen dat de schijven het ook 7 jaar volhouden en niet na 3 jaar al aan vervanging toe zijn.

[justice strike]

CurlyMo schreef op donderdag 26 juli 2012 @ 13:08:
Laten we voor het gemak even het gemiddelde nemen tussen het idle en actieve verbruik:

Samsung HD204UI: 5w
Samsung M8: 1,5w

Kosten van één schijf 24/7 per jaar bij een energieprijs van 0,22 is:

Samsung HD204UI: ((5 * 24 * 365) / (1000)) * 0,22 = +/- 9,5 euro
Samsung M8: ((1,5 * 24 * 365) / (1000)) * 0,22 = +/- 3 euro

Energieprijs voor een RAIDZ2 van 4TB:

Samsung HD204U: 4 * 9.5 = 38 euro
Samsung M8: 6 * 3 = 18 euro

De aanschafprijs:

Samsung HD204U: 4 * 95 = 380 euro
Samsung M8: 6 * 87 = 522 euro

Kosten na één jaar incl. energie:

Samsung HD204U: 380 + 38 = 418 euro
Samsung M8: 522 + 18 = 540 euro

Hoeveel moeten je schijven meegaan totdat je het verschil gaat merken:

380 + 38X = 522 + 18X
38X = 142 + 18X
20X = 142
X = 7,1

Na 7,1 jaar ga je dus de kosten terug verdienen voor het kopen van 2,5" HDD

Hoe zou het dan zijn geweest bij normale HDD prijzen (naar schatting):

(4 * 55) + 38X = (6 * 60) + 18X
38X = 140 + 18X
20X = 140
X = 7

Dan zou je er ook 7 jaar over gedaan hebben

Ok. Das duidelijk. Maar ik denk dat een ssd wel zou kunnen helpen. Alleen ligt het er dan aan of je ZFS write delay kan laten toepassen totdat de ssd vol is (en dat deze dan in een keer leeg geschreven wordt naar de hdd). Zo kun je dus de hdd laten opspinnen wanneer de ssd buffer volloopt. Als je een 64 gb ssd is dan tikt dat aardig aan. Dit zou dan ontzettend veel stroom kunnen besparen want in principe blijven je schijven dan in sleep mode (a 0.1 watt? tov 5 watt)


Ik weet alleen niet of zfs zo werkt. Iemand die hier helderheid over kan geven?

[matty___]

justice strike schreef op donderdag 26 juli 2012 @ 13:22:
[...]


Ok. Das duidelijk. Maar ik denk dat een ssd wel zou kunnen helpen. Alleen ligt het er dan aan of je ZFS write delay kan laten toepassen totdat de ssd vol is (en dat deze dan in een keer leeg geschreven wordt naar de hdd). Zo kun je dus de hdd laten opspinnen wanneer de ssd buffer volloopt. Als je een 64 gb ssd is dan tikt dat aardig aan. Dit zou dan ontzettend veel stroom kunnen besparen want in principe blijven je schijven dan in sleep mode (a 0.1 watt? tov 5 watt)


Ik weet alleen niet of zfs zo werkt. Iemand die hier helderheid over kan geven?

dus je wilt het risco op 64 gb aan data verlies nemen om 4x3 watt aan energie te besparen
de ssd write cache helpt alleen echt bij nfs writes.

als je een keer in de week een biertje minder drinkt heb je het er al uit

[ Voor 3% gewijzigd door matty___ op 26-07-2012 13:28 ]

[justice strike]

matty___ schreef op donderdag 26 juli 2012 @ 13:26:
[...]

dus je wilt het risco op 64 gb aan data verlies nemen om 4x3 watt aan energie te besparen
de ssd write cache helpt alleen echt bij nfs writes.

als je een keer in de week een biertje minder drinkt heb je het er al uit

hoezo risico op data verlies? Het is geen non volatile geheugen.

[matty___]

justice strike schreef op donderdag 26 juli 2012 @ 13:30:
[...]

hoezo risico op data verlies? Het is geen non volatile geheugen.

Dus dan kan die niet stuk? Hoe dan ook gaat het op zo een manier niet werken. Je kunt de ssd prima als l2arc (read) gebruiken en paar gb voor nfs sync writes en niet dat die eerst de ssd volpompt met data en dan 64gb in een keer gaat wegschrijven..

Je wilt je data zo snel mogelijk op disk hebben zodat zfs er iets mee kan als een disk uitvalt. Daarom moet je een ssd ook in mirror uitvoeren wil je hem als write cache gebruiken.

Als echt nog wilt besparen zou ik naar een setup gaan met 2 disk.

[ Voor 5% gewijzigd door matty___ op 26-07-2012 13:38 ]

[Kristofferson]

Ik heb advies nodig voor het opzetten van ZFS op een HP Microserver N40L ter vervanging huidige setup.

Nieuwe configuratie:
* 8GB ECC RAM
* Intel 320 40GB SSD
* Areca 1320-4i4e HBA
* 4x Samsung HD753LJ (750GB)
* 2x Samsung HD203WI (2TB)
* 2x WD 20EARX (2TB)

Huidig systeem:
* Ubuntu Precise 12.04
* ZFS on Linux 0.6.0.65
* 4x HD753LJ in een pool met 2 mirrors
* 2x HD203WI in een pool met 1 mirror

De bedoeling is om de Ubuntu installatie over te zetten op de Microserver met volgende aanpassingen
* 4x HD753LJ in RAIDZ
* 2x HD203WI en 2x WD 20EARX in RAIDZ

Volgende vragen:

1. Geldt het advies om oneven aantallen disks (3,5,9) te gebruiken bij RAIDZ enkel met advanced format (4K) schijven of is het een algemene performance aanbeveling?
2. Als ik de mixed Samsung (512bytes) en WD (4K) pool inricht met ashift=12, is dit dan voldoende om een optimale performance te garanderen?
3. De Intel SSD is bedoeld als systeemschijf. Is het aan te bevelen om een gedeelte als ZIL en L2ARC te voorzien? Is dit uberhaupt nodig op dit systeem met 2 pools?

[justice strike]

matty___ schreef op donderdag 26 juli 2012 @ 13:36:
[...]

Dus dan kan die niet stuk? Hoe dan ook gaat het op zo een manier niet werken. Je kunt de ssd prima als l2arc (read) gebruiken en paar gb voor nfs sync writes en niet dat die eerst de ssd volpompt met data en dan 64gb in een keer gaat wegschrijven..

Je wilt je data zo snel mogelijk op disk hebben zodat zfs er iets mee kan als een disk uitvalt. Daarom moet je een ssd ook in mirror uitvoeren wil je hem als write cache gebruiken.

Als echt nog wilt besparen zou ik naar een setup gaan met 2 disk.

Volgens mij zijn er gewoon filesystems die aan de hand van een log nog steeds het cache kunnen wegschrijven na een power outage. Ik zie niet in waarom dat met ZFS niet kan. Dat een hdd uitvalt, ja dat kan gebeuren en dat betekent idd dat je hem dubbel moet uitvoeren, maar anders dan dat je je gecachte data kwijt bent lijkt me niet moeten gebeuren.

Zowieso is ssd anders in de zin dat deze per sector kapot gaat en vaak niet per schijf.

[ Voor 26% gewijzigd door justice strike op 26-07-2012 13:41 ]

[matty___]

justice strike schreef op donderdag 26 juli 2012 @ 13:40:
[...]


Volgens mij zijn er gewoon filesystems die aan de hand van een log nog steeds het cache kunnen wegschrijven na een power outage. Ik zie niet in waarom dat met ZFS niet kan. Dat een hdd uitvalt, ja dat kan gebeuren en dat betekent idd dat je hem dubbel moet uitvoeren, maar anders dan dat je je gecachte data kwijt bent lijkt me niet moeten gebeuren.

Zowieso is ssd anders in de zin dat deze per sector kapot gaat en vaak niet per schijf.

Ik weet niet of zfs na reboot alsnog zijn cache kan wegschrijven. wat ik zo lees op internet is dat vaak een hele ssd stuk gaat ala wordt niet meer herkend of alles is weg.

Hoe dan ook gaat het niet werken zoals je voor ogen hebt met een write cache.

[justice strike]

matty___ schreef op donderdag 26 juli 2012 @ 13:45:
[...]

Ik weet niet of zfs na reboot alsnog zijn cache kan wegschrijven. wat ik zo lees op internet is dat vaak een hele ssd stuk gaat ala wordt niet meer herkend of alles is weg.

Hoe dan ook gaat het niet werken zoals je voor ogen hebt met een write cache.

dus basically is de setup die ik heb al zuinig voor het geld dat je ervoor uitgeeft.

[matty___]

justice strike schreef op donderdag 26 juli 2012 @ 13:51:
[...]

dus basically is de setup die ik heb al zuinig voor het geld dat je ervoor uitgeeft.

naar mijn mening ja.

[justice strike]

matty___ schreef op donderdag 26 juli 2012 @ 13:53:
[...]

naar mijn mening ja.

Ok dat is goed om te weten. Ik weet wel, volgende keer ga ik voor mini atx. Dit mini itx bord is wat restrictief. Had nog eigenlijk wel een pci slot en wellicht meerdere pci-e aansluitingen gehad zodat ik nog een netwerk kaart oid erop kan zetten.

enfin, huidige setup is ook niet slecht, alleen sub optimaal.

[Verwijderd]

@SenH:
1) 4K optimalisatie geldt alleen voor 4K sector disks. Voor normale disks maakt de hoeveelheid niet uit
2) dat kan uiteraard, maar je mag eigenlijk geen schijven mixen in dezelfde vdev. In een andere vdev is prima.
3) Of SLOG en L2ARC nodig is, moet je zelf bepalen. Weet wel dat je niet je hele SSD wilt gebruiken, dus van de 36GiB kun je 22GiB gebruiken ofzo. 10GiB voor boot, 10GiB voor L2ARC en 2GiB voor SLOG. Dat zou een redelijke setup zijn.
4) je weet dat een Areca controller een no-go is voor ZFS? Als dit je setup wordt, is het Areca die de eindverantwoordelijkheid over je data heeft; niet ZFS.

@CurlyMo: je metingen zijn een beetje off. Bijvoorbeeld:

Laten we voor het gemak even het gemiddelde nemen tussen het idle en actieve verbruik:

Samsung HD204UI: 5w
Samsung M8: 1,5w

De Samsung F4EG zit normaliter op 4W idle met 6W bij sequential I/O
De Samsung M8 1TB zit normaliter op 0,58W idle met 2,5W bij sequential I/O

Kortom, zijn je cjifers wel eerlijk gekozen? Ik vind dat je de 3,5" schijf wel erg bevoordeeld, omdat je de 2,5" bijna drie keer zijn idle waarde laat draaien.

Laten we uitgaan van 95% idle en 5% continu sequential I/O; best ruim genomen nog voor een thuis NAS want eigenlijk is het 99,5% idle ofzo. Maargoed, dan krijgen we:

Samsung F4EG = 95% is 4W en 5% is 6W = 4,1W gemiddeld
Samsung M8 = 95% is 0,58W en 5% is 2,5W = 0,676W gemiddeld

Dus, laten we nu jouw formule eens overnieuw uitrekenen.

Kosten van één schijf 24/7 per jaar bij een energieprijs van 0,22 is:
Samsung HD204UI: ((4,1 * 24 * 365) / (1000)) * 0,22 = +/- 7,90 euro
Samsung M8: ((0,676 * 24 * 365) / (1000)) * 0,22 = +/- 1,30 euro

Energieprijs voor een RAIDZ2 van 4TB:
Samsung HD204U: 4 * 7,90 = 31,60 euro
Samsung M8: 6 * 1,30 = 7,8 euro

De aanschafprijs:

Samsung HD204U: 4 * 95 = 380 euro
Samsung M8: 6 * 87 = 522 euro

Kosten na één jaar incl. energie:

Samsung HD204U: 380 + 31,60 = 411,60 euro
Samsung M8: 522 + 7,8 = 529,80 euro

Hoeveel moeten je schijven meegaan totdat je het verschil gaat merken:

380 + 31,6X = 522 + 7,8X
31,6X = 142 + 7,8X
23,8X = 142
X = 5,966

Kortom 6 jaar is het break-even point. Maar je hebt natuurlijk ook praktische voordelen uit kleinere schijven. Persoonlijk heb ik een Brazos mini-SAS met 2 HDDs en 2 SSDs die 24/7 aanstaat, zodat mijn grote fileservers gewoon uit kunnen. Dat scheelt ook enorm veel stroom omdat anders mijn grote servers hadden moeten draaien. De notebookschijven zijn heerlijk koel, stil en klein. Ik heb er thans nog geen spijt van.

Alleen vervelend dat de APM instelling verloren gaat na stroomverlies; je moet elke keer APM instellen om headparking uit te schakelen.

[NIK0]

@CiPHER
Inmiddels zijn we een weekje verder en is er weer het eea gebeurd.
De NFS services draaien prima als datastore voor m'n ESXi machine.
Het ISCSI verhaal is geheel anders gelopen.
De 2X2TB Seagate ST2000DM001 mirror zoals we die eerder hadden opgezet heb ik via iscsi doorgegeven aan een Windows VM.
Op zich prima totdat ik er data naartoe ging kopieren. Na 2 GB "hing" alles zo'n beetje tot op een punt dat ik de nexenta vm moest rebooten.

Zoeken op het Nexenta forum gaf als tip om in ESXi VAAI te disablen wat ik heb gedaan:
http://kb.vmware.com/kb/1033665

Daarna opnieuw de kopieeractie gestart van m'n fysieke nas naar m'n windows 2008 vm en dat ging op zich prima. 850 GB gekopieerd rond de 85/95 MB/s!

De volgende dag wilde ik vanaf mijn pc een .mkv kopieren en wederom verslikte nexenta zich. Door snel te cancellen bleef alles nu gelukkig wel op.
ESXi gaf lekkere warnings af:
2012-07-24T17:32:21.538Z cpu1:2049)WARNING: ScsiDeviceIO: 1218: Device naa.600144f0c52383000000500928190001 performance has deteriorated. I/O latency increased from average value of 177139 microseconds to 3637169 microseconds.
2012-07-24T17:32:23.136Z cpu1:121479)ScsiDeviceIO: 1198: Device naa.600144f0c52383000000500928190001 performance has improved. I/O latency reduced from 3637169 microseconds to 722304 microseconds.
2012-07-24T17:32:26.562Z cpu0:2052)WARNING: ScsiDeviceIO: 1218: Device naa.600144f0c52383000000500928190001 performance has deteriorated. I/O latency increased from average value of 177178 microseconds to 3881406 microseconds.
2012-07-24T17:32:43.797Z cpu2:121481)WARNING: ScsiDeviceIO: 1218: Device naa.600144f0c52383000000500928190001 performance has deteriorated. I/O latency increased from average value of 177271 microseconds to 8444857 microseconds.
2012-07-24T17:32:44.050Z cpu1:120958)ScsiDeviceIO: 1198: Device naa.600144f0c52383000000500928190001 performance has improved. I/O latency reduced from 8444857 microseconds to 1679669 microseconds.
2012-07-24T17:33:44.438Z cpu1:119821)WARNING: NMP: nmpDeviceTaskMgmt:2210:Attempt to issue lun reset on device naa.600144f0c52383000000500928190001. This will clear any SCSI-2 reservations on the device.
2012-07-24T17:33:46.930Z cpu3:2126)VSCSI: 2763: Retry 0 on handle 8209 still in progress after 2 seconds
Gehele log is hier te vinden:
http://pastebin.com/GRy9vA4n

Daarna nog de een setting speciaal voor sata disken geprobeerd in Nexenta (Syszfsvdevmaxpending = 1 default=10) kopieren ging wel maar ik ben het vertrouwen in iscsi een beetje kwijt.
Toen ben ik gaan kijken naar mogelijkheid om de CIFS server van Nexenta te gebruiken. Een beetje mee gespeeld en wat testen gedaan.

De zfsguru benchmark gaf dit:


In workgroup mode, een folder aangemaakt en daarna data gekopieerd
Vanaf mijn fysieke nas (HP ML110 G5 met OS op SSD een lokale Seagate 1TB drive)

Dus niet in de buurt van de 85-95 MB/s die ik had met iscsi

Vanaf mijn virtuele nas (welke staat op de NFS share bestaande uit een 3 way mirror kreeg ik deze resultaten


VRAGEN:
- Kloppen de writespeeds van 50 MB/s voor een 2x2 TB mirror met 7200rpm disks..?
- Is dit een limiet van nexenta, CIFS, netwerk, disken?

Ik zit er sterk over te denken om over te stappen naar een OI/Napp-IT combinatie maar ik blijf fan van de appliance mode van nexenta (ookal begint de lijst met zaken die zuigen in nexenta steeds meer te groeien )
Ben benieuwd of OI icm Napp-IT ook een redelijke appliance is of dat je elke week packages moet upgraden om de zaken aan de gang te houden. (ervaringen welkom) Ik ben puur op zoek naar een virtueel zfs san/nas

[sloth]

Ik ben me wat aan het inlezen over ZFS, copies en data bescherming.

Begrijp ik het volgende goed?

Indien je uitgaat van een single disk opstelling is deze disk je vdev. Op deze vdev kan je een zpool creëren, met per zpool zoveel filesystems als je wilt. Per filesystem kan je dan zaken als copies=x, compression=x etc.meegeven. De gebruikte ruimte per filesystem wordt pas ingenomen nadat je er data op geplaatst hebt.

Een voorbeeld:

Een 2TB disk. Dit is de vdev.
Op deze vdev maak je een pool /test
Zpool /test heeft vervolgens volgende filesystems:

• FS /test/belangrijk (copies=3)
• FS /test/share
• FS /test/logs (compression=gzip)

Op /test/belangrijk plaats je backups, en hier worden telkens 3 copies van gemaakt verspreid over de hele vdev. Indien je 10GB plaatst ben je dus ook 30GB van de plaats op je vdev kwijt.

/test/share zijn mediabestanden. Deze nemen gewoon dezelfde plaats in als altijd. 50GB blijft 50GB.

Ik plaats wat grote logbestanden van 1GB op /test/logs. Door de gzip compressie nemen ze slechts 200MB capaciteit in.

In totaal heb je dan 61GB (10+50+1) aan data op je vdev geplaatst, die 82,2GB ruimte inneemt (30+50+0,2).

[justice strike]

NIK0 schreef op donderdag 26 juli 2012 @ 14:10:
@CiPHER
Inmiddels zijn we een weekje verder en is er weer het eea gebeurd.
De NFS services draaien prima als datastore voor m'n ESXi machine.
Het ISCSI verhaal is geheel anders gelopen.
De 2X2TB Seagate ST2000DM001 mirror zoals we die eerder hadden opgezet heb ik via iscsi doorgegeven aan een Windows VM.
Op zich prima totdat ik er data naartoe ging kopieren. Na 2 GB "hing" alles zo'n beetje tot op een punt dat ik de nexenta vm moest rebooten.

Zoeken op het Nexenta forum gaf als tip om in ESXi VAAI te disablen wat ik heb gedaan:
http://kb.vmware.com/kb/1033665

Daarna opnieuw de kopieeractie gestart van m'n fysieke nas naar m'n windows 2008 vm en dat ging op zich prima. 850 GB gekopieerd rond de 85/95 MB/s!

De volgende dag wilde ik vanaf mijn pc een .mkv kopieren en wederom verslikte nexenta zich. Door snel te cancellen bleef alles nu gelukkig wel op.
ESXi gaf lekkere warnings af:
2012-07-24T17:32:21.538Z cpu1:2049)WARNING: ScsiDeviceIO: 1218: Device naa.600144f0c52383000000500928190001 performance has deteriorated. I/O latency increased from average value of 177139 microseconds to 3637169 microseconds.
2012-07-24T17:32:23.136Z cpu1:121479)ScsiDeviceIO: 1198: Device naa.600144f0c52383000000500928190001 performance has improved. I/O latency reduced from 3637169 microseconds to 722304 microseconds.
2012-07-24T17:32:26.562Z cpu0:2052)WARNING: ScsiDeviceIO: 1218: Device naa.600144f0c52383000000500928190001 performance has deteriorated. I/O latency increased from average value of 177178 microseconds to 3881406 microseconds.
2012-07-24T17:32:43.797Z cpu2:121481)WARNING: ScsiDeviceIO: 1218: Device naa.600144f0c52383000000500928190001 performance has deteriorated. I/O latency increased from average value of 177271 microseconds to 8444857 microseconds.
2012-07-24T17:32:44.050Z cpu1:120958)ScsiDeviceIO: 1198: Device naa.600144f0c52383000000500928190001 performance has improved. I/O latency reduced from 8444857 microseconds to 1679669 microseconds.
2012-07-24T17:33:44.438Z cpu1:119821)WARNING: NMP: nmpDeviceTaskMgmt:2210:Attempt to issue lun reset on device naa.600144f0c52383000000500928190001. This will clear any SCSI-2 reservations on the device.
2012-07-24T17:33:46.930Z cpu3:2126)VSCSI: 2763: Retry 0 on handle 8209 still in progress after 2 seconds
Gehele log is hier te vinden:
http://pastebin.com/GRy9vA4n

Daarna nog de een setting speciaal voor sata disken geprobeerd in Nexenta (Syszfsvdevmaxpending = 1 default=10) kopieren ging wel maar ik ben het vertrouwen in iscsi een beetje kwijt.
Toen ben ik gaan kijken naar mogelijkheid om de CIFS server van Nexenta te gebruiken. Een beetje mee gespeeld en wat testen gedaan.

De zfsguru benchmark gaf dit:
[afbeelding]

In workgroup mode, een folder aangemaakt en daarna data gekopieerd
Vanaf mijn fysieke nas (HP ML110 G5 met OS op SSD een lokale Seagate 1TB drive)
[afbeelding]
Dus niet in de buurt van de 85-95 MB/s die ik had met iscsi

Vanaf mijn virtuele nas (welke staat op de NFS share bestaande uit een 3 way mirror kreeg ik deze resultaten
[afbeelding]

VRAGEN:
- Waarom kan ik via CIFS maar met 50 MB/s kopieren? (hoor ik snellere speeds te krijgen via CIFS..?)
- Is dit een limiet van nexenta, CIFS, netwerk?

Ik zit er sterk over te denken om over te stappen naar een OI/Napp-IT combinatie maar ik blijf fan van de appliance mode van nexenta (ookal begint de lijst met zaken die zuigen in nexenta steeds meer te groeien )
Ben benieuwd of OI icm Napp-IT ook een redelijke appliance is of dat je elke week packages moet upgraden om de zaken aan de gang te houden. (ervaringen welkom) Ik ben puur op zoek naar een virtueel zfs san/nas

Ik had ansich hetzelfde probleem. Uiteindelijk ben ik tot de conclusie gekomen dat dit een probleem is met de netwerkkaart. Deze valt iedere keer uit waardoor de max throughput wel gigabit is, maar de gemiddelden worden erg naar beneden getrokken.

Ook moet je goed kijken in de logs of de ACS mode goed ingesteld staat (writethrough dacht ik) en dat je systeem AIO ondersteund (dat doet Freebsd bijv niet standaard, en bij mij was het nog een probleem zelfs na het loaden van de kld)

[CurlyMo]

Verwijderd schreef op donderdag 26 juli 2012 @ 14:05:
@CurlyMo: je metingen zijn een beetje off. Bijvoorbeeld:

Kortom, zijn je cjifers wel eerlijk gekozen? Ik vind dat je de 3,5" schijf wel erg bevoordeeld, omdat je de 2,5" bijna drie keer zijn idle waarde laat draaien.

Mijn bronnen:
http://www.storagereview.com/samsung_spinpoint_m8_review
http://www.storagereview....point_f4eg_review_hd204ui

En zoals gezegd, daarvan gewoon even voor het gemak 50% idle en 50% activiteit genomen. Iedereen kan natuurlijk mijn verhaal even herberekenen op zijn eigen situatie.

[Kristofferson]

Verwijderd schreef op donderdag 26 juli 2012 @ 14:05:
@SenH:
4) je weet dat een Areca controller een no-go is voor ZFS? Als dit je setup wordt, is het Areca die de eindverantwoordelijkheid over je data heeft; niet ZFS.

Die Areca 1320 is toch een "domme" SAS Host Adapter, zit geen RAID functionaliteit op. Waarom zou deze niet met ZFS werken?
http://www.areca.com.tw/products/sasnoneraid6g.htm

Gebruikte chip is Marvell 88SE9480
Zie hier bij 8ports -> http://blog.zorinaq.com/?e=10

[Verwijderd]

Dat is apart, want ik gebruik dezelfde bronnen. 0,58W idle voor de Samsung M8 en 4W voor de Samsung F4EG.

50% activiteit voor een 24/7 NAS? Dat is totaal onrealistisch. Misschien als je elke nacht een scrub doet ofzo dat je aan dat soort getallen komt. 5% is al onrealistisch hoog voor een doorsnee 24/7 NAS. Minder dan 1% is normaal.

@SenH: hm je controller is inderdaad een HBA. Maar weet wel dat Marvell wel om slechte chips/drivers bekend staat. Het werkt prima onder Windows, maar onder andere OS moet je oppassen. FreeBSD en Marvell chips hebben een lange geschiedenis van problemen. FreeBSD devs klagen ook regelmatig over de slechte documentatie waardoor zijn geen goed stabiele drivers kunnen maken.

Volgens dit bericht zou je controller ook niet werken of althans problemen geven:
http://lists.freebsd.org/.../2012-January/065610.html

Kortom, wees voorzichtig met afwijkende controllers. Onder mainstream OS werkt het allemaal, maar voor ZFS kun je maar beter breed ondersteunde hardware hebben. Dat is ook de reden dat LSI zo populair is. Behalve dat die gewoon veel beter spul maken dan een bedrijfje als Marvell, wordt LSI ook door alle OS ondersteund (Solaris, BSD, Linux, Windows). Dat maakt het vaak dé keuze voor een ZFS setup zodat je niet gebonden bent aan één platform omdat je hardware alleen maar met dat platform redelijk werkt. Dat zou zonde zijn.

Dat gezegd, sommige Marvell chips die vroeger brak werkten, werken nu zonder crashes op mijn box.

[ Voor 63% gewijzigd door Verwijderd op 26-07-2012 14:25 ]

[CurlyMo]

Wat details:

sloth schreef op donderdag 26 juli 2012 @ 14:13:
Een 2TB disk. Dit is de vdev.
Op deze vdev maak je een pool test
Zpool test heeft vervolgens volgende filesystems:

• FS /test/belangrijk (copies=3)
• FS /test/share
• FS /test/logs (compression=gzip)

[NIK0]

justice strike schreef op donderdag 26 juli 2012 @ 14:15:
[...]

Ik had ansich hetzelfde probleem. Uiteindelijk ben ik tot de conclusie gekomen dat dit een probleem is met de netwerkkaart. Deze valt iedere keer uit waardoor de max throughput wel gigabit is, maar de gemiddelden worden erg naar beneden getrokken.

Ook moet je goed kijken in de logs of de ACS mode goed ingesteld staat (writethrough dacht ik) en dat je systeem AIO ondersteund (dat doet Freebsd bijv niet standaard, en bij mij was het nog een probleem zelfs na het loaden van de kld)

VRAGEN:
- Kloppen de writespeeds van 50 MB/s voor een 2x2 TB mirror met 7200rpm disks..?
- Is dit een limiet van nexenta, CIFS, netwerk, disken?

Ik zit er sterk over te denken om over te stappen naar een OI/Napp-IT combinatie maar ik blijf fan van de appliance mode van nexenta (ookal begint de lijst met zaken die zuigen in nexenta steeds meer te groeien )
Ben benieuwd of OI icm Napp-IT ook een redelijke appliance is of dat je elke week packages moet upgraden om de zaken aan de gang te houden. (ervaringen welkom) Ik ben puur op zoek naar een virtueel zfs san/nas


Ik draai de nexenta doos op een virtuele machine dus uitvallen van nics zou gelogd moeten worden.

De properties van mijn share


Sync = ACS mode..?

Enig idee waar ik in Nexenta AIO support kan nakijken..? (geen idee waar dat voor is overigens but willing to learn)

[ Voor 26% gewijzigd door NIK0 op 26-07-2012 14:29 ]

[justice strike]

NIK0 schreef op donderdag 26 juli 2012 @ 14:26:
[...]

Ik draai de nexenta doos op een virtuele machine dus uitvallen van nics zou gelogd moeten worden.

De properties van mijn share
[afbeelding]

Sync = ACS mode..?

Enig idee waar ik in Nexenta AIO support kan nakijken..? (geen idee waar dat voor is overigens but willing to learn)

sorry moet acl zijn niet acs. Met uitvallen van nics bedoel ik dat de driver crashed. Lijkt me niet dat je virtual machine dat merkt. Ik zie het niet eens in de freebsd logs van de machine waar dat het geval is.

(ik noem het een crash, maar het is een zichtbare dip in de throughput die herhaaldelijk voorkomt. Ik had begrepen dat freebsd in zo'n geval de driver opnieuw laad.

[NIK0]

justice strike schreef op donderdag 26 juli 2012 @ 14:31:
[...]

sorry moet acl zijn niet acs. Met uitvallen van nics bedoel ik dat de driver crashed. Lijkt me niet dat je virtual machine dat merkt. Ik zie het niet eens in de freebsd logs van de machine waar dat het geval is.

(ik noem het een crash, maar het is een zichtbare dip in de throughput die herhaaldelijk voorkomt. Ik had begrepen dat freebsd in zo'n geval de driver opnieuw laad.

Zal nog ns een kopieer actie opstarten en kijken of ik een screen kan krijgen van het transfer verloop.

[CurlyMo]

Verwijderd schreef op donderdag 26 juli 2012 @ 14:19:
Dat is apart, want ik gebruik dezelfde bronnen. 0,58W idle voor de Samsung M8 en 4W voor de Samsung F4EG.

50% activiteit voor een 24/7 NAS? Dat is totaal onrealistisch. Misschien als je elke nacht een scrub doet ofzo dat je aan dat soort getallen komt. 5% is al onrealistisch hoog voor een doorsnee 24/7 NAS. Minder dan 1% is normaal.

@SenH: hm je controller is inderdaad een HBA. Maar weet wel dat Marvell wel om slechte chips/drivers bekend staat. Het werkt prima onder Windows, maar onder andere OS moet je oppassen. FreeBSD en Marvell chips hebben een lange geschiedenis van problemen. FreeBSD devs klagen ook regelmatig over de slechte documentatie waardoor zijn geen goed stabiele drivers kunnen maken.

Volgens dit bericht zou je controller ook niet werken of althans problemen geven:
http://lists.freebsd.org/.../2012-January/065610.html

Kortom, wees voorzichtig met afwijkende controllers. Onder mainstream OS werkt het allemaal, maar voor ZFS kun je maar beter breed ondersteunde hardware hebben. Dat is ook de reden dat LSI zo populair is. Behalve dat die gewoon veel beter spul maken dan een bedrijfje als Marvell, wordt LSI ook door alle OS ondersteund (Solaris, BSD, Linux, Windows). Dat maakt het vaak dé keuze voor een ZFS setup zodat je niet gebonden bent aan één platform omdat je hardware alleen maar met dat platform redelijk werkt. Dat zou zonde zijn.

Dat gezegd, sommige Marvell chips die vroeger brak werkten, werken nu zonder crashes op mijn box.

Jouw berekening is was net zo goed als de mijne, het verschil zat hem alleen in de percentages die je kiest voor activiteit vs idle

De berekening laat vooral zien dat het geen zin heeft om 2.5" inch schijven te nemen om er uiteindelijke aanschaf + energie kosten voordeliger uit te zijn. Was dit kantelpunt ruim binnen de 5 jaar geweest, dan was het een ander verhaal. Dit zou pas interessant zijn in het theoretische geval waarbij je je 2.5" schijven 4 jaar lang uit laat staan, nadat je er data op hebt gezet

[Verwijderd]

Nouja wel eerlijk blijven; want als je de 2,5" schijf een verbruik drie maal hoger dan zijn idle opgeeft, is dat wel erg nadelig. Als de notebookschijven 1,5 watt versus 4 watt waren, was het natuurlijk niet het overwegen waard. Maar 0,58w versus 4W is toch al een groter verschil.

Daarnaast is het dus in het voordeel van de 3,5" schijf als je het percentage 100% load opschroeft, bijvoorbeeld van 50% van de tijd naar 100% van de tijd, heb je een enorm groot voordeel gegeven aan de Samsung F4EG. Voor de 2,5" schijf is idle juist erg belangrijk. Kortom, je eerlijke vergelijking vind ik het niet; de Samsung F4EG krijgt op twee vlakken oneerlijk en onrealistisch veel voordeel.

En ik blijf erbij dat 50% duty cycle voor een 24/7 NAS zéér uitzonderlijk is en zeker niet valt onder een typische thuis NAS. Voor dit soort cornercases is de Samsung M8 een worst-case-scenario. Slechter kan eigenlijk niet.

[ Voor 14% gewijzigd door Verwijderd op 26-07-2012 14:39 ]

[justice strike]

Verwijderd schreef op donderdag 26 juli 2012 @ 14:37:
Nouja wel eerlijk blijven; want als je de 2,5" schijf een verbruik drie maal hoger dan zijn idle opgeeft, is dat wel erg nadelig. Als de notebookschijven 1,5 watt versus 4 watt waren, was het natuurlijk niet het overwegen waard. Maar 0,58w versus 4W is toch al een groter verschil.

Daarnaast is het dus in het voordeel van de 3,5" schijf als je het percentage 100% load opschroeft, bijvoorbeeld van 50% van de tijd naar 100% van de tijd, heb je een enorm groot voordeel gegeven aan de Samsung F4EG. Voor de 2,5" schijf is idle juist erg belangrijk. Kortom, je eerlijke vergelijking vind ik het niet; de Samsung F4EG krijgt op twee vlakken oneerlijk en onrealistisch veel voordeel.

En ik blijf erbij dat 50% duty cycle voor een 24/7 NAS zéér uitzonderlijk is en zeker niet valt onder een typische thuis NAS. Voor dit soort cornercases is de Samsung M8 een worst-case-scenario. Slechter kan eigenlijk niet.

je kunt ook de stelling leggen dat je een 3.5 inch hd moet vergelijken met 3 2.5 inch hd''s (3*1 tb 2.5 vs 1*3tb 3.5inch)

Want ik denk wel dat je sneller voor grotere capaciteit hdd''s gaat ipv meerdere kleinere als je voor 3.5 inch gaat.

[NIK0]

justice strike schreef op donderdag 26 juli 2012 @ 14:31:
[...]

sorry moet acl zijn niet acs. Met uitvallen van nics bedoel ik dat de driver crashed. Lijkt me niet dat je virtual machine dat merkt. Ik zie het niet eens in de freebsd logs van de machine waar dat het geval is.

(ik noem het een crash, maar het is een zichtbare dip in de throughput die herhaaldelijk voorkomt. Ik had begrepen dat freebsd in zo'n geval de driver opnieuw laad.

You might be on to something, kopieeractie gaat een tijd goed met 50MB/s en dan stort het in op het eind.


Je zei dat jij hetzelfde issue had. Heb je dat kunnen tackelen en zo ja hoe..?

[Verwijderd]

De vergelijking was RAID-Z2 van 4TB netto opslag.

Voor 2,5" 1TB is dat dus 6 disks (6-2 = 4 * 1TB = 4TB)
Voor 3,5" 2TB is dat dus 4 disks (4-2 = 2 * 2TB = 4TB)
Voor 3,5" 3TB is dat ook 4 disks ..
Voor 3,5" 4TB is dat maar 3 disks (3-2 = 1 * 4TB = 4TB)

Grotere capaciteit disks is eigenlijk juist onhandig omdat je daar moeilijk heel veel van kunt kopen en zo een lage redundancy overhead te krijgen, zoals 20 of 25% bij RAID-Z2. Een mirror van twee disks kan nog wel, maar een mirror is geen RAID-Z2.

Die 1TB notebookschijfjes vond ik juist wel een fijne grootte hebben. Heb je er 20 van kun je een mooie RAID-Z3 maken bijvoorbeeld. Doordat je er zoveel hebt kun je lage overhead krijgen en toch goede bescherming. Bovendien is het realistisch om 20 notebookschijven aan te sturen; qua ruimte en koeling gaat dat prima lukken. Het probleem is alleen dat notebookschijven per gigabyte zeker twee keer zo duur zijn. En dat verschil is eigenlijk te groot. 1,5 keer zo duur dan zou het voor meer mensen het overwegen waard zijn, denk ik.

NIK0 schreef op donderdag 26 juli 2012 @ 14:47:
[...]
You might be on to something, kopieeractie gaat een tijd goed met 50MB/s en dan stort het in op het eind.
[afbeelding]

Je zei dat jij hetzelfde issue had. Heb je dat kunnen tackelen en zo ja hoe..?

Jullie hebben last van te grote transaction groups. Tijdens het wegschrijven van de txg stort je netwerkthroughput in. Je zult je txg settings moeten tweaken, zoals de txg kleiner maken (64MiB hard limit) zodat je vaker kleinere transaction groups gaat committen.

[ Voor 23% gewijzigd door Verwijderd op 26-07-2012 14:50 ]

[justice strike]

NIK0 schreef op donderdag 26 juli 2012 @ 14:47:
[...]


You might be on to something, kopieeractie gaat een tijd goed met 50MB/s en dan stort het in op het eind.
[afbeelding]

Je zei dat jij hetzelfde issue had. Heb je dat kunnen tackelen en zo ja hoe..?

nee, niet kunnen tackelen omdat het een driver issue is. Enige oplossing die ik gevonden heb is... gebruik een intel kaart.

[CurlyMo]

Verwijderd schreef op donderdag 26 juli 2012 @ 14:37:
Nouja wel eerlijk blijven; want als je de 2,5" schijf een verbruik drie maal hoger dan zijn idle opgeeft, is dat wel erg nadelig. Als de notebookschijven 1,5 watt versus 4 watt waren, was het natuurlijk niet het overwegen waard. Maar 0,58w versus 4W is toch al een groter verschil.

Dat klopt, maar dat scheelt effectief maar 1 jaar tussen jouw berekening en de mijne. Ik vind het verschil dus nog steeds miniem. Pas als dit verschil onder de 5 jaar zou hebben opgetreden dan was het inderdaad het overwegen waard geweest.

Daarnaast is het dus in het voordeel van de 3,5" schijf als je het percentage 100% load opschroeft, bijvoorbeeld van 50% van de tijd naar 100% van de tijd, heb je een enorm groot voordeel gegeven aan de Samsung F4EG. Voor de 2,5" schijf is idle juist erg belangrijk. Kortom, je eerlijke vergelijking vind ik het niet; de Samsung F4EG krijgt op twee vlakken oneerlijk en onrealistisch veel voordeel.

En ik blijf erbij dat 50% duty cycle voor een 24/7 NAS zéér uitzonderlijk is en zeker niet valt onder een typische thuis NAS. Voor dit soort cornercases is de Samsung M8 een worst-case-scenario. Slechter kan eigenlijk niet.

Klopt, maar ook wanneer we het andersom bekijken en de Samsung HD's de worst-case-scenario geven, maakt het nog steeds weinig verschil. Laten we het geval nemen dat de M8 3 jaar lang uit staan en de HD's 3 jaar lang onder 100% load draaien, dan ligt het kantelpunt pas op +/- 2,8 jaar.

Je ziet dus wel dat het verschil pas in dit soort (zwaar onrealistische) scenario's interessant wordt. Welke percentages je ook neemt, de conclusie blijft dus hetzelfde.

[sloth]

CurlyMo schreef op donderdag 26 juli 2012 @ 14:19:
Wat details:

[...]

Lijkt me dat hier iets niet goed gegaan is?

[CurlyMo]

sloth schreef op donderdag 26 juli 2012 @ 14:50:
[...]


Lijkt me dat hier iets niet goed gegaan is?

Jawel Mijn aanpassingen zijn dik gedrukt, moeilijk te zien. Daarom ook "details" .

[sloth]

nu zie ik het pas.. ik pas m'n post gelijk even aan.

Klopt mijn redenering verder?

[NIK0]

justice strike schreef op donderdag 26 juli 2012 @ 14:49:
[...]

nee, niet kunnen tackelen omdat het een driver issue is. Enige oplossing die ik gevonden heb is... gebruik een intel kaart.

Ik heb alleen maar intel kaarten
Intel 82571EB (HP NIC)

De onboard kaart is een realtek maar die gebruik ik voor internet niet voor GB zaken.

Die kaarten worden in nexenta gezien als een E1000 kaart, ik zou nog kunnen proberen om te zien of ik die naar een VMXNet 3 kaart kan krijgen..
Maar hoe hobbel jij nu verder met je NAS ook met 50 MB/s en dan instortend of ben je overgestapt naar wat anders..?

[ Voor 26% gewijzigd door NIK0 op 26-07-2012 14:56 ]

[CurlyMo]

sloth schreef op donderdag 26 juli 2012 @ 14:54:
nu zie ik het pas.. ik pas m'n post gelijk even aan.

Klopt mijn redenering verder?

Dat laat ik aan CiPHER over

[justice strike]

Verwijderd schreef op donderdag 26 juli 2012 @ 14:48:
De vergelijking was RAID-Z2 van 4TB netto opslag.

Voor 2,5" 1TB is dat dus 6 disks (6-2 = 4 * 1TB = 4TB)
Voor 3,5" 2TB is dat dus 4 disks (4-2 = 2 * 2TB = 4TB)
Voor 3,5" 3TB is dat ook 4 disks ..
Voor 3,5" 4TB is dat maar 3 disks (3-2 = 1 * 4TB = 4TB)

Grotere capaciteit disks is eigenlijk juist onhandig omdat je daar moeilijk heel veel van kunt kopen en zo een lage redundancy overhead te krijgen, zoals 20 of 25% bij RAID-Z2. Een mirror van twee disks kan nog wel, maar een mirror is geen RAID-Z2.

Die 1TB notebookschijfjes vond ik juist wel een fijne grootte hebben. Heb je er 20 van kun je een mooie RAID-Z3 maken bijvoorbeeld. Doordat je er zoveel hebt kun je lage overhead krijgen en toch goede bescherming. Bovendien is het realistisch om 20 notebookschijven aan te sturen; qua ruimte en koeling gaat dat prima lukken. Het probleem is alleen dat notebookschijven per gigabyte zeker twee keer zo duur zijn. En dat verschil is eigenlijk te groot. 1,5 keer zo duur dan zou het voor meer mensen het overwegen waard zijn, denk ik.

zo kan ik de berekening ook maken. Ik vind het een beetje een scheve vergelijking. Andersom

6tb schijf raidz2

3.5 inch 3tb schijven == 4 schijven
2.5 inch 1tb schijven == 12 schijven

dat is nogal een behoorlijk verschil in het aantal schijven dat je nodig hebt.

[Verwijderd]

CurlyMo schreef op donderdag 26 juli 2012 @ 14:50:
[...]

Dat klopt, maar dat scheelt effectief maar 1 jaar tussen jouw berekening en de mijne. Ik vind het verschil dus nog steeds miniem. Pas als dit verschil onder de 5 jaar zou hebben opgetreden dan was het inderdaad het overwegen waard geweest.

Als het doel is puur geld besparen op stroomkosten heb je gelijk. Maar je krijgt meer voordelen. Stel je gaat uit van 2,5 jaar. Dan heb je dus de helft terugverdient. Dus op dat moment zijn de notebook HDDs nog steeds duurder dan de desktop HDDs. Máár al die tijd heb je wel veel makkelijker spinup gehad, en doordat je notebook HDDs hebt ipv desktop kun je een PicoPSU blijven gebruiken ipv te moeten switchen naar ATX voeding.

Kortom, als je ook de overige voordelen erbij betrekt kunnen notebook HDDs wel interessant worden. Zeker voor het doel waarvoor ik ze heb aangeschaft: een ultra low power NAS die echt 24/7 beschikbaar is en waardoor de grote fileservers uit kunnen. De voordelen van ruimte, vibraties, spinup, warmte enzovoorts moet je ook meetellen. Puur voor winst op stroomkosten is het niet voldoende, zoals je zelf ook zegt. Maar mijn punt is dat dat niet de enige reden hoeft te zijn, en in combinatie met andere redenen kun je nog steeds voor de notebook HDDs gaan.

6tb schijf raidz2

3.5 inch 3tb schijven == 4 schijven
2.5 inch 1tb schijven == 12 schijven

Die 12 schijven moet 8 schijven zijn, toch?

En ja mensen, je kunt alle berekeningen zo verdraaien dat het heel gunstig wordt voor A of juist gunstig voor B. Maar het gaat mij om de realistische scenario's.

[ Voor 10% gewijzigd door Verwijderd op 26-07-2012 14:59 ]

[justice strike]

Verwijderd schreef op donderdag 26 juli 2012 @ 14:48:
Jullie hebben last van te grote transaction groups. Tijdens het wegschrijven van de txg stort je netwerkthroughput in. Je zult je txg settings moeten tweaken, zoals de txg kleiner maken (64MiB hard limit) zodat je vaker kleinere transaction groups gaat committen.

Is het mogelijk deze waarde (vfs.zfs.write_limit_override ) aan te passen zonder dat je een reboot hiervoor moet initialiseren?

[justice strike]

Verwijderd schreef op donderdag 26 juli 2012 @ 14:55:
[...]

Als het doel is puur geld besparen op stroomkosten heb je gelijk. Maar je krijgt meer voordelen. Stel je gaat uit van 2,5 jaar. Dan heb je dus de helft terugverdient. Dus op dat moment zijn de notebook HDDs nog steeds duurder dan de desktop HDDs. Máár al die tijd heb je wel veel makkelijker spinup gehad, en doordat je notebook HDDs hebt ipv desktop kun je een PicoPSU blijven gebruiken ipv te moeten switchen naar ATX voeding.

Kortom, als je ook de overige voordelen erbij betrekt kunnen notebook HDDs wel interessant worden. Zeker voor het doel waarvoor ik ze heb aangeschaft: een ultra low power NAS die echt 24/7 beschikbaar is en waardoor de grote fileservers uit kunnen. De voordelen van ruimte, vibraties, spinup, warmte enzovoorts moet je ook meetellen. Puur voor winst op stroomkosten is het niet voldoende, zoals je zelf ook zegt. Maar mijn punt is dat dat niet de enige reden hoeft te zijn, en in combinatie met andere redenen kun je nog steeds voor de notebook HDDs gaan.


[...]

Die 12 schijven moet 8 schijven zijn, toch?

En ja mensen, je kunt alle berekeningen zo verdraaien dat het heel gunstig wordt voor A of juist gunstig voor B. Maar het gaat mij om de realistische scenario's.

Hoezo 8? gaan toch 3 1tb schijven in een 3tb schijf?.

Je vind 3*3.5 schijven niet realistisch?

[Verwijderd]

Nee alles in je /boot/loader.conf wordt bij het booten ingesteld. Achteraf kun je dat op een draaiend systeem niet meer aanpassen. Stel je voor dat je even opgeeft maxmem=1GB dan zou direct alle extra RAM moeten verdwijnen? Ik kan me voorstellen dat dit instellingen zijn die vanaf het booten moeten worden ingesteld, en achteraf niet meer gewijzigd mogen worden.

[justice strike]

Verwijderd schreef op donderdag 26 juli 2012 @ 15:02:
Nee alles in je /boot/loader.conf wordt bij het booten ingesteld. Achteraf kun je dat op een draaiend systeem niet meer aanpassen. Stel je voor dat je even opgeeft maxmem=1GB dan zou direct alle extra RAM moeten verdwijnen? Ik kan me voorstellen dat dit instellingen zijn die vanaf het booten moeten worden ingesteld, en achteraf niet meer gewijzigd mogen worden.

ok. En je geeft aan als startpunt 64mb? want dan ga ik dat zo even uitproberen. Het kopieren gaat niet heel snel namelijk

[Verwijderd]

Ik quote:

6tb schijf raidz2

3.5 inch 3tb schijven == 4 schijven
2.5 inch 1tb schijven == 12 schijven

12 1TB schijven in een RAID-Z2 = 10TB bruikbare opslag
8 1TB schijven in een RAID-Z2 = 6TB bruikbare opslag

Het ging je om 6TB bruikbare opslag met RAID-Z2, dan kom je dus op 8 schijven uit en niet 12. Toch?

[ Voor 4% gewijzigd door Verwijderd op 26-07-2012 15:04 ]

[NIK0]

justice strike schreef op donderdag 26 juli 2012 @ 14:59:
[...]


Is het mogelijk deze waarde (vfs.zfs.write_limit_override ) aan te passen zonder dat je een reboot hiervoor moet initialiseren?

In Nexenta nergens een loader.conf te vinden

[justice strike]

Verwijderd schreef op donderdag 26 juli 2012 @ 15:04:
Ik quote:

[...]


12 1TB schijven in een RAID-Z2 = 10TB bruikbare opslag
8 1TB schijven in een RAID-Z2 = 6TB bruikbare opslag

Het ging je om 6TB bruikbare opslag met RAID-Z2, dan kom je dus op 8 schijven uit en niet 12. Toch?

ah zo. Dat klopt idd.Maar je moet ook rekening houden dat hoe meer schijven je in een array hebt hoe meer redundancy je nodig hebt om een failure te kunnen opvangen. Daar was een simpele formule voor. Enfin dat is een theoretische discussie.

[justice strike]

NIK0 schreef op donderdag 26 juli 2012 @ 15:04:
[...]

In Nexenta nergens een loader.conf te vinden

ook niet in /boot of /etc?

[NIK0]

justice strike schreef op donderdag 26 juli 2012 @ 15:07:
[...]

ook niet in /boot of /etc?

root@nexenta:/boot/solaris# cd ..
root@nexenta:/boot# ls
acpi grub solaris solaris.xpm.gz x86.miniroot-safe


root@nexenta:/boot# find / -name loader.conf
root@nexenta:/boot#

[matty___]

Verwijderd schreef op donderdag 26 juli 2012 @ 15:02:
Nee alles in je /boot/loader.conf wordt bij het booten ingesteld. Achteraf kun je dat op een draaiend systeem niet meer aanpassen. Stel je voor dat je even opgeeft maxmem=1GB dan zou direct alle extra RAM moeten verdwijnen? Ik kan me voorstellen dat dit instellingen zijn die vanaf het booten moeten worden ingesteld, en achteraf niet meer gewijzigd mogen worden.

wat raar is want in 8 kon je deze waarde at runtime aanpassen.

[Verwijderd]

Weet je dat zeker? In elk geval voor 9-STABLE:

# sysctl vfs.zfs.write_limit_override
vfs.zfs.write_limit_override: 0
# sysctl vfs.zfs.write_limit_override=128m
sysctl: oid 'vfs.zfs.write_limit_override' is a read only tunable
sysctl: Tunable values are set in /boot/loader.conf

[ Voor 9% gewijzigd door Verwijderd op 26-07-2012 15:26 ]

[matty___]

Verwijderd schreef op donderdag 26 juli 2012 @ 15:25:
Weet je dat zeker? In elk geval voor 9-STABLE:

# sysctl vfs.zfs.write_limit_override
vfs.zfs.write_limit_override: 0
# sysctl vfs.zfs.write_limit_override=128m
sysctl: oid 'vfs.zfs.write_limit_override' is a read only tunable
sysctl: Tunable values are set in /boot/loader.conf

dat weet ik maar ik weet zeker dat de voorloper van deze je wel at runtime kon aanpassen.
hij heet ook anders in 8

[NIK0]

Kan iig niets vinden over loader.conf in Nexenta (misschien moet ik 'm gewoon aanmaken?)
Heb de vraag ook nog gedropt op het nexenta irc kanaal maar dat is roepen in de woestijn daarzo..

@CiPHER, kan ook mijn probleem icm ISCSI hiermee te maken hebben..?
(icm met de errors zoals hier beschreven: NIK0 in "Het grote ZFS topic" )

[ Voor 32% gewijzigd door NIK0 op 26-07-2012 15:43 ]

[Verwijderd]

nostradamus99: haal je niet Nexenta en ZFSguru door elkaar? Bovenstaand geldt voor FreeBSD platform, Solaris platform is weer heel anders. Wellicht dat bijvoorbeeld gila kan vertellen hoe je de transaction groups onder Solaris platform kunt temmen.

En ik lees je post nog eens terug maar ik zie een ZFSguru benchmark maar je praat verder alleen over Nexenta? Ik snap niet goed wat je setup nu is. Ook zie ik je benchmarks als je pool 0% gevuld is; hoe kan dat, waar staan je iSCSI images dan?

[CurlyMo]

justice strike schreef op donderdag 26 juli 2012 @ 14:55:
[...]


zo kan ik de berekening ook maken. Ik vind het een beetje een scheve vergelijking. Andersom

6tb schijf raidz2

3.5 inch 3tb schijven == 4 schijven
2.5 inch 1tb schijven == 12 schijven

dat is nogal een behoorlijk verschil in het aantal schijven dat je nodig hebt.

WD30EZRX = 6W gemiddeld
Samsung M8 = 95% is 0,58W en 5% is 2,5W = 0,676W gemiddeld

Kosten van één schijf 24/7 per jaar bij een energieprijs van 0,22 is:
WD30EZRX: ((6 * 24 * 365) / (1000)) * 0,22 = +/- 11,5 euro
Samsung M8: ((0,676 * 24 * 365) / (1000)) * 0,22 = +/- 1,30 euro

Energieprijs voor een RAIDZ2 van 4TB:
WD30EZRX: 4 * 11,5 = 46 euro
Samsung M8: 8 * 1,30 = 10,4 euro

De aanschafprijs:

WD30EZRX: 4 * 145 = 580 euro
Samsung M8: 8 * 87 = 696 euro

Kosten na één jaar incl. energie:

WD30EZRX: 580 + 46 = 626 euro
Samsung M8: 696 + 10,4 = 533,40 euro

Hoelang moeten je schijven meegaan totdat je het verschil gaat merken:

696 + 10,4X = 580 + 46X
116 + 10,4X = 46x
116 = 35,6X
X = 3,2

In dit geval wordt het wel interessant om voor 2.5" hdd's te gaan mits je de prijs van een eventuele aparte controller om al die schijven aan te sluiten niet meerekent

[NIK0]

Verwijderd schreef op donderdag 26 juli 2012 @ 16:05:
nostradamus99: haal je niet Nexenta en ZFSguru door elkaar? Bovenstaand geldt voor FreeBSD platform, Solaris platform is weer heel anders. Wellicht dat bijvoorbeeld gila kan vertellen hoe je de transaction groups onder Solaris platform kunt temmen.

En ik lees je post nog eens terug maar ik zie een ZFSguru benchmark maar je praat verder alleen over Nexenta? Ik snap niet goed wat je setup nu is. Ook zie ik je benchmarks als je pool 0% gevuld is; hoe kan dat, waar staan je iSCSI images dan?

Ja sorry voor de confusion..
ik draai nexenta...ik heb zfsguru gebruikt om m'n pool onder nexenta te krijgen met ashift=12 (gelukt dankzij jouw hulp vorige week!)
Toen ik zfsguru aan het gebruiken was heb ik gelijk die benchmark maar even gebruikt om een benchmark te krijgen.

Die pool is idd 0% dat WAS m'n iscsi pool maar aangezien ik daar geen vertrouwen meer in had heb ik die leeggemaakt ben ik aan de slag gegaan met de CIFS server van Nexenta.

Wellicht dat bijvoorbeeld gila kan vertellen hoe je de transaction groups onder Solaris platform kunt temmen.

@Gila gaarne..!
EDIT:
Geen idee dat dit bij Solaris totaal anders zou zijn dan onder BSD..?
zfs_write_limit_override

EDIT2:
@justice strike En alles opgelost nu,,.?

[ Voor 8% gewijzigd door NIK0 op 26-07-2012 20:52 ]

[Wouter.S]

Niet dat ik opdringerig wil zijn hoor CiPHER, maar zit de release van het nieuwe ZFSGuru image er nog in voor vandaag of moet ik nog een dagje doorbijten ? Hetnieuwe moederbord voor mijn nas is vandaag aangekomen dus het zou een mooi moment zijn om naast de hardware ook onder de motorkap ook even bij te sleutelen

[Verwijderd]

Als je deze nacht meerekent...

Maar de compilatie draait nu al een tijdje. Ik verwacht dat deze rond 2 uur 's nachts klaar is. Dan moet ik nog kijken of alle wijzigingen die ik in de tussentijd heb aangebracht aan diverse scripts allemaal goed werken. Dus tel er zeker een uur bij op. Daarna uploaden en dat gaat ook nog een tijd duren.

Dus tja.. ik ga hem wel vannacht releasen, maar concreet betekent dit dat je er pas morgenvroeg wat aan hebt omdat je hem dan kunt downloaden (wel van snelle 100mbit link).

@nostra: dank voor je herinnering, dat had ik even nodig.
Het punt is, als je random read en write doet via iSCSI moet je wel zorgen dat je back-end storage snel genoeg is. Als die iSCSI images op HDD array staan en zeker als dat RAID-Z is, moet je oppassen. Dit probleem kun je grotendeels wegnemen met L2ARC en eventueel SLOG voor random writes. Dat laatste is wellicht overbodig als je sync=disabled instelt en dus alle writes write-back zullen zijn. Dit heeft wel het risico van filesystem inconsistency (niet ZFS fs maar het fs wat op de iSCSI images staat; dus de guest fs) bij stroomuitval van de ZFS host.
Hardeschijven moet je niet meerdere dingen tegelijk laten doen of excessief laten seeken; dan gaat je performance extreem traag worden. Maar misschien was dat wel niet je enige probleem...

[NIK0]

Verwijderd schreef op donderdag 26 juli 2012 @ 23:28:
Als je deze nacht meerekent...

Maar de compilatie draait nu al een tijdje. Ik verwacht dat deze rond 2 uur 's nachts klaar is. Dan moet ik nog kijken of alle wijzigingen die ik in de tussentijd heb aangebracht aan diverse scripts allemaal goed werken. Dus tel er zeker een uur bij op. Daarna uploaden en dat gaat ook nog een tijd duren.

Dus tja.. ik ga hem wel vannacht releasen, maar concreet betekent dit dat je er pas morgenvroeg wat aan hebt omdat je hem dan kunt downloaden (wel van snelle 100mbit link).

@nostra: dank voor je herinnering, dat had ik even nodig.
Het punt is, als je random read en write doet via iSCSI moet je wel zorgen dat je back-end storage snel genoeg is. Als die iSCSI images op HDD array staan en zeker als dat RAID-Z is, moet je oppassen. Dit probleem kun je grotendeels wegnemen met L2ARC en eventueel SLOG voor random writes. Dat laatste is wellicht overbodig als je sync=disabled instelt en dus alle writes write-back zullen zijn. Dit heeft wel het risico van filesystem inconsistency (niet ZFS fs maar het fs wat op de iSCSI images staat; dus de guest fs) bij stroomuitval van de ZFS host.
Hardeschijven moet je niet meerdere dingen tegelijk laten doen of excessief laten seeken; dan gaat je performance extreem traag worden. Maar misschien was dat wel niet je enige probleem...

Het was mijn bad met al dat extra ZFS-Guru werk verwacht ik ook nog dat je snapt wat ik heb draaien.
Vooralsnog heb ik alles in mirror draaien, geen RAID-Z (al weet ik dat je daar grote fan van bent ).

Sync disabled is weloverwogen keuze, ik heb een dikke APC ups erachter hangen dus stroomuitval ben ik minder angstig voor.

Die 3way mirror is puur Storage voor VM's. Die mirror met 2x2TB is dedicated voor mn NAS-needs. Ik hoeft echt geen topsnelheden maar er moet toch meer dan 50 MB/s uit te halen zijn. Ik lees dat de basis waarop Nexenta gebouwd is toch wel erg oud is dus ik zit te overwegen om naar Open Indiana over te stappen icm Napp-IT totdat v4 uitkomt van Nexenta (Wanneer dat ook moge zijn ) .

Die setting waar jij het eerder over had:
(zfs_write_limit_override)
moet gezet worden in het bestand /etc/system. Ik ga er denk ik vooralsnog even niet mee door aangezien het feit dat wanneer ik onder OI ook slechte resultaten krijg er wellicht iets anders aan de hand is..

LOSSE VRAAG:
ik weet dat veel mensen hier een IBM M1015 hebben, doen jullie daar nog iets aan qua extra cooling..?

[FireDrunk]

Over de koeling, nee, mijn beide M1015's worden niet extra gekoeld (zitten in verschillende machines.

[deludi]

Hoi Cipher,

Ben aan het twijfelen tussen oi+napp-it of zfsguru voor een produktie omgeving.
Is zfsguru daar al geschikt voor?

Korte toelichting:

Ik wil tweetal gekoppelde storage servers inrichten voor windows vm's, filedata en backupdata.
Wil ze het liefst koppelen met een snelle interconnect zoals ib met mellanox kaarten.
Heb al een deel van de hardware aangeschaft (alles x2):
norco rpc-4216 case
seasonic voeding
supermicro mainboard X9SCM-F
Intel Xeon e3-1220l
32GB memory (4 x 8GB)
IBM serveraid m1015 (3 stuks geflashed naar IT)
Hotswap bays voor de 5,25 sloten (6 SSD's per 5,25 bay)

SSD's worden waarschijnlijk samsung 830's
Over de hdd's ben ik nog aan het denken...

[ Voor 69% gewijzigd door deludi op 27-07-2012 12:29 ]

[FireDrunk]

Niet om voor CiPHER te antwoorden, maar nee, eigenlijk niet.
Het FreeBSD stuk waar ZFSguru op draait is prima voor productie, en ook ZFS is prima in een productieomgeving te gebruiken. Maar ik zou niet je productieproces af laten hangen van ZFSguru.

Hoewel het een leuke tool is om snel dingen te kunnen doen die je misschien wil doen, is het nog te veranderlijk om in productie gebruikt te worden naar mijn idee. Ook vind ik dat er nog te weinig documentatie is.

En het belangrijkste, er is nul officiele support. (CiPHER is goed, maar heeft ook niet altijd tijd natuurlijk )
En Jason is foetsie...

[deludi]

Ok duidelijk antwoord.
Gea van napp-it biedt wel support (is natuurlijk ook alleen...)

[FireDrunk]

Je kan je natuurlijk afvragen in hoeverre je support nodig hebt van Napp-IT en ZFSGuru op het moment dat je alleen de webinterface gebruikt (en dus de installatie zelf doet).

Aan de andere kant, hoe krijg je FreeBSD support? Dat kan je ook niet kopen volgens mij...

[deludi]

Klopt,

Ik wil de servers redelijk standaard inrichten (en tegelijk goed documenteren) en het beheer volledig via de webinterface doen.
Voordeel van ZFS is dat de hdd-sets redelijk overdraagbaar zijn naar andere systemen (in geval van afstorten van server)(heb al wel spares aangeschaft van vrijwel alle componenten).
Ben niet van plan om veel updates te doen, vind het veiliger om er tzt nieuwe servers naast te zetten en de data over te zetten...

[matty___]

FireDrunk schreef op vrijdag 27 juli 2012 @ 11:53:
Je kan je natuurlijk afvragen in hoeverre je support nodig hebt van Napp-IT en ZFSGuru op het moment dat je alleen de webinterface gebruikt (en dus de installatie zelf doet).

Aan de andere kant, hoe krijg je FreeBSD support? Dat kan je ook niet kopen volgens mij...

en daar komt freenas 8 om de hoek kijken. Volgens mij kun je bij ix systems wel support kopen

[FireDrunk]

Je wil geen updates doen, maar wel een webinterfaces die er voor gemaakt is om... jawel... updates te doen?
Wat wil je wel en niet updaten dan?

Want als het alleen maar een bak veilige storage is kan je ook zonder webinterface af.

Installeren, update, vdev aanmaken, sharen, uitloggen en naar huis

[deludi]

Is er inderdaad ook nog.
Ik heb freenas 8 een maand of 2 geleden geinstalleerd.
Ging erg soepel op een hp n36l met 8GB.
Heb wel veel geklaag gelezen van freenas 7 gebruikers dat freenas 8 meer resources zou gebruiken.
Met bovengenoemde hardware heb ik daar denk ik geen last van.
Ga contact met ze opnemen.

P.S. heb ook gekeken naar Nexenta, viel echter af omdat dat snel erg duur wordt....

[FireDrunk]

Als je een simpele supported omgeving wil, is FreeNAS denk ik the-way-to-go.

[deludi]

FireDrunk schreef op vrijdag 27 juli 2012 @ 12:56:
Je wil geen updates doen, maar wel een webinterfaces die er voor gemaakt is om... jawel... updates te doen?
Wat wil je wel en niet updaten dan?

Want als het alleen maar een bak veilige storage is kan je ook zonder webinterface af.

Installeren, update, vdev aanmaken, sharen, uitloggen en naar huis

Is geen kwestie van niet willen...
Ben gewoon voorzichtig met produktie machines.

[ Voor 72% gewijzigd door deludi op 27-07-2012 13:02 ]

[matty___]

deludi schreef op vrijdag 27 juli 2012 @ 12:58:
Is geen kwestie van niet willen...
Ben gewoon voorzichtig met produktie machines.

waarvoor denk je het webgui nodig te hebben? De vdev config of het vaak aanpassen van de shares?

[Ultraman]

FireDrunk schreef op vrijdag 27 juli 2012 @ 11:53:
Aan de andere kant, hoe krijg je FreeBSD support? Dat kan je ook niet kopen volgens mij...

Hangt er van af wat voor support je nodig hebt.
Er zijn zeker wel partijen die wat voor je kunnen betekenen. Ik werk er zelfs voor een die dat kan en doet.

[deludi]

matty___ schreef op vrijdag 27 juli 2012 @ 12:59:
[...]

waarvoor denk je het webgui nodig te hebben? De vdev config of het vaak aanpassen van de shares?

met name voor het toevoegen van shares

[Sleepie]

FireDrunk schreef op vrijdag 27 juli 2012 @ 12:57:
Als je een simpele supported omgeving wil, is FreeNAS denk ik the-way-to-go.

Misschien is Nexentastor een optie. Bij mijn weten leveren die toch goede support?
Moet wel toegeven dat ik er nooit echt naar gekeken heb en het vooral van naam ken

[wjn]

Sleepie schreef op vrijdag 27 juli 2012 @ 14:32:
[...]

Misschien is Nexentastor een optie. Bij mijn weten leveren die toch goede support?
Moet wel toegeven dat ik er nooit echt naar gekeken heb en het vooral van naam ken

Toevallig ben ik met iets dergelijks bezig. Nexentastor is erg duur als je support wilt, $ 10.000,= ben je zomaar kwijt voor een HA cluster.

[Sleepie]

wjn schreef op vrijdag 27 juli 2012 @ 14:37:
Toevallig ben ik met iets dergelijks bezig. Nexentastor is erg duur als je support wilt, $ 10.000,= ben je zomaar kwijt voor een HA cluster.

Ik zit nu even te kijken op die webpagina van ze.
ENTERPRISE PLATINUM EDITION 0008TB $4,185.00
ENTERPRISE PLATINUM EDITION 0032TB $10,425.00

Ben ik de enige die dit gewoon geldklopperij vindt? Om de prijs van het aantal TB af te laten hangen?
Of je nu 8 of 32 TB hebt ... de technology erachter is exact hetzelfde, waarom zou de support dan opeen 2.5 keer zo duur moeten zijn?

Of zie ik nog iets over het hoofd?

[FireDrunk]

Omdat je dat dan kan betalen? Geld vragen naar vermogen is vrij normaal hoor...
Net als afrekenen voor support bij VMware, dat gaat ook per host...

[Sleepie]

Per host vind ik toch nog net weer iets anders, maar goed dat wordt aardig offtopic dan.
Hoe dan ook, Nexentastor is inderdaad goed aan de prijs (duurder dan ik verwacht had in ieder geval).

[wjn]

Sleepie schreef op vrijdag 27 juli 2012 @ 14:48:
[...]

Ik zit nu even te kijken op die webpagina van ze.
ENTERPRISE PLATINUM EDITION 0008TB $4,185.00
ENTERPRISE PLATINUM EDITION 0032TB $10,425.00

Ben ik de enige die dit gewoon geldklopperij vindt? Om de prijs van het aantal TB af te laten hangen?
Of je nu 8 of 32 TB hebt ... de technology erachter is exact hetzelfde, waarom zou de support dan opeen 2.5 keer zo duur moeten zijn?

Of zie ik nog iets over het hoofd?

Normalerwijze: Meer storage = meer clients = meer storingen / support vragen.

[FireDrunk]

Dat ligt er maar weer aan... Als je alleen maar statische data levert en alle clients op exact dezelfde manier ontsluit, dan maakt het weer geen bal uit.

Diversiteit in configuratie maakt problemen, niet de hoeveelheden.
Dat zou betekenen dat Apache helemaal gek word, omdat ze miljarden clients hebben (Browsers )

[Hakker]

OK Q waar kan ik instelling dat zfsguru met een whitelist werkt ipv vanuit de netwerk. ik kan namelijk wel op de console komen maar niet op de webinterface omdat die dus op een andere range zit

[Verwijderd]

Update: ZFSguru system image en LiveCD's zijn bezig met uploaden, duurt nog uren dus wees geduldig!

deludi schreef op vrijdag 27 juli 2012 @ 11:03:
Hoi Cipher,

Ben aan het twijfelen tussen oi+napp-it of zfsguru voor een produktie omgeving.
Is zfsguru daar al geschikt voor?

Ligt eraan welke verwachtingen je hebt. Als ik bovenstaand verhaal lees, gaat het wellicht om een serieus bedrijf wat duizenden euro's wilt spenderen aan support omdat hun business belangrijk (genoeg) is.

Maar er zit ook nog wat tussen thuisgebruik en enterprise. MKB, kleinzakelijk of hoe je het wilt noemen. Die hebben vaak andere eisen dan zowel thuisgebruikers als enterprise. Die willen geen dure support, maar wel goede producten die stabiel en degelijk zijn. Denk aan de talloze zzp'ers in ons land.

Voor die doelgroep kan ZFSguru net als andere 'open source' appliances interessant zijn. Ik wil ook opmerken dat velen nog steeds ZFSguru draaien zelfs nadat Jason al maandenlang zijn support had gestaakt. De interface is qua basisfunctionaliteit wel onderhand af en dat levert dus een bruikbaar product op ook al verandert er niets. Een ander voorbeeld is ZFS zelf; versies boven de 28 zullen we voorlopig niet zien, maar al blijft het hierbij dan blijft het een heel mooi filesystem.

Maar als je echt antwoord op je vraag wilt: ik denk dat het niet zozeer uitmaakt wat je kiest, zolang je maar in het begin heel goed test. Daarna zijn alle 'updates' of 'veranderingen' die je doet potentiëel gevaarlijk. Het liefst maak je een backup van de (systeem-)configuratie zoals die is op het moment dat alles werkt. Pas na uitvoerig testen ga je over tot in gebruikname, zeker wetende wat je moet doen bij schijfuitval en andere zaken. Kortom: zorg dat je niet afhankelijk wordt van support!

Dat is dus een andere filosofie dan FireDrunk. Je zult zelf moeten oordelen in welke gebruiksklasse jij valt en wat je behoeftes nu precies zijn en hoeveel je daarvoor wilt spenderen.

Hakker schreef op vrijdag 27 juli 2012 @ 18:00:
OK Q waar kan ik instelling dat zfsguru met een whitelist werkt ipv vanuit de netwerk. ik kan namelijk wel op de console komen maar niet op de webinterface omdat die dus op een andere range zit

ZFSguru werkt al met een whitelist, maar volgens mij doe je iets verkeerd? Als je puur de livecd hebt geboot dan kun ja vanaf alle lokale IP adressen toegang krijgen. Lokaal is gestandaardiseerd als 10.x.x.x, 192.168.x.x en nog iets met 176 wat ik nooit gebruik. Vanaf die IP adressen heb je toegang, niet vanaf 'internet' IP adressen. Kan het zijn dat je een onofficiëel IP adres gebruikt?

Anyhow, als je eenmaal de welcome wizard hebt doorlopen kun je alles in preferences -> access control instellen. Inclusief IP whitelists.

[Hakker]

probleem is dus dat ik dus een internet ip adres hier heb ook al zit de bak 2 meter bij mij vandaan.

[Verwijderd]

Stel hem dan even statisch in op een lokaal IP of is dat heel lastig? Wat jij wilt is natuurlijk uitdrukkelijk out-of-the-box verboden vanwege veiligheidsredenen. Je hoort lokaal je NAS te benaderen, in elk geval de eerste keer.

[Verwijderd]

Nieuwe ZFSguru LiveCD met 9.1-002 system image + veel services

/me is blij!

Kleine hint: zorg dat je genoeg RAM hebt! 4GiB voor medium en 6GiB voor heavy. En laat weten hoe hij gaat!

[victorb]

Cool CiPHER is je image 1.2 TB

[Verwijderd]

Oh shit.. vergeten mijn pr0n eraf te halen

[victorb]

Snel ff downloaden dan voor dat die offline gaat

[blobber]

Goed werk Cipher!
Ik ga hem zo meteen eens ff proberen

[EnerQi]

* EnerQi is bezig met downloaden van de nieuwe versie

CiPHER, was het misschien niet makkelijker geweest om het even op usenet/torrent te gooien? Ik kan me voorstellen dat de server het nu zwaar gaat krijgen doordat iedereen deze versie wil uitproberen.

[FireDrunk]

Waarom is de Normal er nog niet? Die is nog aan het uploaden?

[Verwijderd]

Bij deze geüpload, bedenk wel dat je voorlopig nog alleen de services van cdrom kunt plukken.

En FireDrunk, dit is nog niet 'jouw' CLANG enabled build. Die wil ik dit weekend gaan bakken zodat je VMXNET3 nog eens kunt proberen.

@EnerQi: server is 100 megabit, dus zou opzich wel moeten trekken. Sommigen downloaden met 5MB/s kan ik zien; dat is wel tof.

[ Voor 22% gewijzigd door Verwijderd op 28-07-2012 11:45 ]

[EnerQi]

Hmmm van die 5 MB/s mag ik alleen maar dromen . Ik denk dat mijn trage downloadsnelheid meer aan mezelf ligt

[Verwijderd]

Zijn nu wel meer mensen die downloaden (8 ofzo). Ik weet ook niet precies hoe snel het gaat; ik kan het niet gezamenlijk zien alleen per download.
Maar in minder dan 8 uur nu al 16 gigabyte erdoor gestouwd. Tikt natuurlijk lekker aan als mensen nu ook die 1.2GB iso gaan downloaden.

En zie die 1.2GB livecd meer als een 'demo' van wat er nu mogelijk is met services, dankzij al het werk aan de build scripts. Nieuwe services waar ik ook nog aan dacht: X-vlc (vlc media player), X-nvidia-drivers (binary nVidia) en X-amd-drivers (binary ATi/AMD). Ook X-wine kan nuttig zijn. Met de binary drivers krijg je 3D acceleratie. Wellicht kun je die ook weer doorgeven aan Virtualbox, al ben ik erg benieuwd of dat zomaar werkt op BSD. Voordeel hierdoor is dat je virtualbox guest ook 3D acceleratie van je host GPU heeft, zij het met wat verlies/vertaalslag maar dat stelt je wel in staat om Win7 met Aero te draaien enzo.

[FireDrunk]

Verwijderd schreef op zaterdag 28 juli 2012 @ 11:45:
En FireDrunk, dit is nog niet 'jouw' CLANG enabled build. Die wil ik dit weekend gaan bakken zodat je VMXNET3 nog eens kunt proberen.

Is dat er niet los in te bouwen?

[Verwijderd]

Nee de kernel moest toch met clang gecompiled worden? Waarom weet ik niet, maar misschien dat diegene die de patch heeft geschreven om VMXNET3 weer met FreeBSD 9+ te laten werken zelf zo'n clang kernel had en het daarom niet met de normale kernel werkt. Ik gok maar wat hoor.

Maar in elk geval moet buildkernel en buildworld beide met /etc/src.conf aanpassingen gecompileerd worden, waarbij de CLANG compiler wordt ingezet. Meer info: http://wiki.freebsd.org/BuildingFreeBSDWithClang

[FireDrunk]

aha, dus alleen de kernel, niet world zelf

[Verwijderd]

Kernel + World. World is dus alle utilities zoals ssh enzo. Daarnaast kun je clang ook enablen in /etc/make.conf dan wordt CLANG ook gebruikt om ports mee te compileren in de portstree. Maar dat laatste is zeer experimenteel; zeker niet alle ports werken nog met clang. Bovendien zou clang op dit moment nog aardig langzamer zijn dan gcc. Bedenk wel dat FreeBSD 'vast zit' aan een oude gcc versie, dus de verschillen zullen minder groot zijn dan een moderne gcc versus clang zoals meestal op Phoronix wordt getest.

Maargoed, het gaat om dat die kernel zo gecompiled is want dat kun je later niet zelf doen. Als jij met clang ports wilt builden kun je dit stukje in je /etc/make.conf zetten (voor alleen make buildworld / buildkernel doe je dat enkel in /etc/src.conf dat gebruiken ports niet):

code:

CC=clang
CXX=clang++
CPP=clang-cpp