Zuinige ESXi Server

[|sWORDs|]

tvwes schreef op maandag 27 februari 2017 @ 14:56:
Help ik mis het nog steeds. Je poste plots een benchmark erbij maar nog steeds staat er dat optie 1 afvalt. Valt het technisch af of vind je het niet wenselijk? Als je het niet wenselijk vind waarom dan wel optie 3?

Optie 1 kan toch prima en is toch niet wezenlijk anders dan optie 3. Het verschil is of een reguliere OS installatie of dmv veel gehack dat bootblock. En ja je moet altijd ergens je vmx kwijt. En dat kan inderdaad alleen op een datastore. Maar die komt er toch gewoon in optie 1?

Doorgestreepte tekst is wat niet meer van toepassing is? Uitleg staat er achter.

De benchmark stond er al voor ik jouw opmerking zag, ik heb daarna alleen de tekst nog verder uitgebreid en dat stukje doorgestreept.

[ Voor 8% gewijzigd door |sWORDs| op 27-02-2017 15:03 ]

[CurlyMo]

tvwes schreef op maandag 27 februari 2017 @ 14:10:
[...]
[list=1]
• De USB datastore met daarop voldoende bootcode om de AHCI controller te kunnen benaderen alsmede ZFS.

Precies dit. Ubuntu doet het zo, volgens mij FreeBSD ook. In Ubuntu heb je de initramfs wat een pre-boot is waarna je van elk mogelijke (en ondersteunde) locatie kan booten (NFS, andere disk, sd kaart enz.) Ik heb zelf ook eens een volledig draaiend Linux OS gemaakt in een initramfs als vermaak. In FreeBSD kan je aan je bootloader laten weten welke ZFS locatie hij moet gebruiken en ik weet niet beter dan dat die ook op een andere schijf kan staan.

tvwes schreef op maandag 27 februari 2017 @ 14:10:
[...]
Misschien vergis ik me hierin en is dit een feature die wel in moderne OS installers zit maar ik heb het nog nooit gezien.

Dus ja, het is allemaal vrij standaard tegenwoordig en Ubuntu gebruikt het ook altijd.

[ Voor 19% gewijzigd door CurlyMo op 27-02-2017 15:14 ]

[Beninho]

Ik ben me aan het oriënteren op virtualisatie met ESxi. Ik heb in het topic Het grote thuis-virtualisatie topic een aantal goede voorbeelden voorbij zien komen.

Op dit moment draai ik
een Ubuntu 14.04 ZFS NAS op een AMD-E350 platform met allerlei applicaties. Daar hoef ik niet op te gaan virtualiseren, want dat gaan huilen worden.

Nu overweeg ik om een barebone te kopen a la, zie wensen lijstje hieronder.

#	Product	Prijs	Subtotaal
1	Asus VivoMini UN65H-M108M	€ 409,-	€ 409,-
1	Asus VivoMini UN65H-M227M	€ 376,31	€ 376,31
1	Asus VivoMini UN65U-BM010M	€ 531,19	€ 531,19
Bekijk collectie Importeer producten		Totaal	€ 1.316,50

Mijn doel;
1. controle en gemak. Wanneer ik nu tijdens een installatie en aanpassing iets verprust, gaat dat vaak verder dan die ene applicatie die niet meer draait. Ik wil sneller kunnen schakelen.
2. Veiligheid. Ik ben van plan om bepaalde VM's aan het web te hangen voor toegang van buitenaf. Door het te compartimenteren scherm ik bepaalde zaken af.
3. Kennis op doen op gebied van virtualisatie.
4. Fun

Waarvoor ik een VM wil draaien;

• Sabnzbd, nzbdrone, couchpotato, headphones aka. downloadserver
• Plexmediaserver
• TVheadend voor dvb-c
• Subsonic
• Fileserver (nextcloud, seafile o.i.d.)
• DNS
• Backup van en naar 2 locatie

De NAS blijft dan draaien en wordt gebruikt waarvoor hij bedoeld is. Opslag. Ik kan e.a. vastknopen met NFS of Samba.

In de nabije toekomst wil ik graag ook domotica regelen vanuit een VM. Is dit realistisch wat ik hier schets of een volkomen overtrokken setup voor de doelstelling?

Wat betreft hardware, schetste ik hierboven een NUC. Dit kan natuurlijk ook een zelfbouw systeem zijn. Is een i-3 of zelf een pricewatch: Intel Celeron G3900 Boxed voldoende voor dit werk?

[tvwes]

Ik ben bekend met de diverse boot processen. Vandaar dat ik je voorstel ook niet afwijs want technisch kan het prima. Mijn zorg is of de installer en updater hiermee overweg kunnen. Wat ik al schreef ik ben niet bekend met alle installers maar ben deze feature nog niet tegen gekomen. Ik zal zo meteen eens even kijken.

[|sWORDs|]

Beninho schreef op maandag 27 februari 2017 @ 15:20:
Ik ben me aan het oriënteren op virtualisatie met ESxi. Ik heb in het topic Het grote thuis-virtualisatie topic een aantal goede voorbeelden voorbij zien komen.

Op dit moment draai ik
een Ubuntu 14.04 ZFS NAS op een AMD-E350 platform met allerlei applicaties. Daar hoef ik niet op te gaan virtualiseren, want dat gaan huilen worden.

Nu overweeg ik om een barebone te kopen a la, zie wensen lijstje hieronder.

#	Product	Prijs	Subtotaal
1	Asus VivoMini UN65H-M108M	€ 409,-	€ 409,-
1	Asus VivoMini UN65H-M227M	€ 376,31	€ 376,31
1	Asus VivoMini UN65U-BM010M	€ 531,19	€ 531,19
Bekijk collectie Importeer producten		Totaal	€ 1.316,50

Mijn doel;
1. controle en gemak. Wanneer ik nu tijdens een installatie en aanpassing iets verprust, gaat dat vaak verder dan die ene applicatie die niet meer draait. Ik wil sneller kunnen schakelen.
2. Veiligheid. Ik ben van plan om bepaalde VM's aan het web te hangen voor toegang van buitenaf. Door het te compartimenteren scherm ik bepaalde zaken af.
3. Kennis op doen op gebied van virtualisatie.
4. Fun

Waarvoor ik een VM wil draaien;

• Sabnzbd, nzbdrone, couchpotato, headphones aka. downloadserver
• Plexmediaserver
• TVheadend voor dvb-c
• Subsonic
• Fileserver (nextcloud, seafile o.i.d.)
• DNS
• Backup van en naar 2 locatie

De NAS blijft dan draaien en wordt gebruikt waarvoor hij bedoeld is. Opslag. Ik kan e.a. vastknopen met NFS of Samba.

In de nabije toekomst wil ik graag ook domotica regelen vanuit een VM. Is dit realistisch wat ik hier schets of een volkomen overtrokken setup voor de doelstelling?

Wat betreft hardware, schetste ik hierboven een NUC. Dit kan natuurlijk ook een zelfbouw systeem zijn. Is een i-3 of zelf een pricewatch: Intel Celeron G3900 Boxed voldoende voor dit werk?

De verschillen tussen die machines zijn enorm klein. Het zijn allemaal dual core met hyperthreading machines. De i5 voegt een turbo toe, de i7 een hogere base/turbo clock en is in dit geval een "generatie" nieuwer, maar eigenlijk voor ESXi identiek aan de 6500u. De Gigabyte Brix is net wat goedkoper, kan meer geheugen aan en is beschikbaar met twee NICs. pricewatch: Gigabyte BRIX GB-BSi3HAL-6100 (rev. 1.0)

Samba is mogelijk naar een VM, maar niet naar ESXi als datastore (NFS/iSCSI).

Zie vanaf hier iemand die vrijwel het zelfde doet met een Celeron (Ook 2.3GHz, geen HT/Turbo): zeroday in "Het grote ESXi/vSphere Topic" na een beetje optimaliseren ging dat volgens mij goed, echter zou ik toch een quad core aanraden.

[ Voor 4% gewijzigd door |sWORDs| op 27-02-2017 15:49 ]

[Martiveen]

Beninho schreef op maandag 27 februari 2017 @ 15:20:
Ik ben me aan het oriënteren op virtualisatie met ESxi. Ik heb in het topic Het grote thuis-virtualisatie topic een aantal goede voorbeelden voorbij zien komen.

Op dit moment draai ik
een Ubuntu 14.04 ZFS NAS op een AMD-E350 platform met allerlei applicaties. Daar hoef ik niet op te gaan virtualiseren, want dat gaan huilen worden.

Nu overweeg ik om een barebone te kopen a la, zie wensen lijstje hieronder.

#	Product	Prijs	Subtotaal
1	Asus VivoMini UN65H-M108M	€ 409,-	€ 409,-
1	Asus VivoMini UN65H-M227M	€ 376,31	€ 376,31
1	Asus VivoMini UN65U-BM010M	€ 531,19	€ 531,19
Bekijk collectie Importeer producten		Totaal	€ 1.316,50

Mijn doel;
1. controle en gemak. Wanneer ik nu tijdens een installatie en aanpassing iets verprust, gaat dat vaak verder dan die ene applicatie die niet meer draait. Ik wil sneller kunnen schakelen.
2. Veiligheid. Ik ben van plan om bepaalde VM's aan het web te hangen voor toegang van buitenaf. Door het te compartimenteren scherm ik bepaalde zaken af.
3. Kennis op doen op gebied van virtualisatie.
4. Fun

Waarvoor ik een VM wil draaien;

• Sabnzbd, nzbdrone, couchpotato, headphones aka. downloadserver
• Plexmediaserver
• TVheadend voor dvb-c
• Subsonic
• Fileserver (nextcloud, seafile o.i.d.)
• DNS
• Backup van en naar 2 locatie

De NAS blijft dan draaien en wordt gebruikt waarvoor hij bedoeld is. Opslag. Ik kan e.a. vastknopen met NFS of Samba.

In de nabije toekomst wil ik graag ook domotica regelen vanuit een VM. Is dit realistisch wat ik hier schets of een volkomen overtrokken setup voor de doelstelling?

Wat betreft hardware, schetste ik hierboven een NUC. Dit kan natuurlijk ook een zelfbouw systeem zijn. Is een i-3 of zelf een pricewatch: Intel Celeron G3900 Boxed voldoende voor dit werk?

Zelf gebruik ik voor zoiets de pricewatch: ASRock DeskMini 110. Kan je zelf een cpu uitzoeken. Is verder ruimte voor een m2 ssd en 2x 2,5" disk

[FireDrunk]

tvwes schreef op maandag 27 februari 2017 @ 15:21:
Ik ben bekend met de diverse boot processen. Vandaar dat ik je voorstel ook niet afwijs want technisch kan het prima. Mijn zorg is of de installer en updater hiermee overweg kunnen. Wat ik al schreef ik ben niet bekend met alle installers maar ben deze feature nog niet tegen gekomen. Ik zal zo meteen eens even kijken.

En die zorg deel ik met je. Ik ben heel erg goed bekend met de diverse bootprocessen en bijbehorende updates (ik heb ze allemaal zelf wel eens gebouwd, van Grub Static UEFI, tot Fedora met Luks encrypted BTRFS). En wat je zegt klopt volledig.

Dus @CurlyMo, pas op met wat je aan aparte boot config wil doen, soms moet updaten, en je hebt best kans dat daardoor je bootcode overschreven (zou) moet(en) worden.

Wat je kan proberen:
Maak een VM aan, geef deze via VT-d je 2 schijven. Tijdens de installer van BSD laat je deze de complete default uitvoeren voor een Root-on-ZFS mirror.

Pak een USB stick(of maak een minimale vmdk aan) en geef die door, zet daar een GPT partitietabel op met een FAT32 UEFI System Partition op, zet daar een grug-static UEFI bootloader op (bootx64.uefi moet hij heten, in het mapje EFI, mocht je daar nog meer van willen weten, DM maar).

Die grub-static compileer je zodat hij FreeBSD chainload vanaf een van je VT-d partities, daar zijn wel guides over te vinden.

Dan heb je dus een originele FreeBSD installatie, welke gewoon zichzelf keurig kan updaten, maar er alleen een Grub-Static voor die zorgt dat je van een via VT-d doorgegeven controller kan booten.

In theorie kan je dan zelfs (in geval van nood) de machine (zonder tussenkomst van ESXi) laten booten van de SSD's. Die zijn immers gewoon nog standaard.

_{Wel een leuke usecase om zelf eens te proberen, zal eens kijken of ik dat binnenkort zelf eens kan proberen}

[ Voor 4% gewijzigd door FireDrunk op 27-02-2017 16:20 ]

[tvwes]

@FireDrunk bedankt voor deze zeer beknopte guide. Ik had het in mijn hoofd wel een eind goed, maar durfde het niet aan de specifieke blokjes en handelingen te benoemen.

[tvwes]

|sWORDs| schreef op maandag 27 februari 2017 @ 12:37:
[...]

Ik had het over een derde SSD als boot/USB op de ASmedia. Ik schrik nogal als ik 808 IOPS zie, tenopzichte van mijn 1.500.000 IOPS (3x Samsung 950 512GB + 3x Intel 750 400GB + Intel 750 1.2TB) of de 47000 IOPS van een eenvoudige SATA SSD datastore.

Het is natuurlijk helemaal prachtig en zeer benijdenswaardig al jouw NVME geweld.
Ik benadrukken dat ik niet jouw keuzes veroordeel want dat is aan jouw. En persoonlijk vind ik het allemaal prachtig.
Wat ik niet wil is dat het beeld ontstaat van "zo weinig iops? Nee Henk, dan gaat je ESXi servertje natuurlijk nooit lekker draaien" en dat we nu allemaal voor de 1.500.000 iops moeten gaan want anders ....

Ook moeten we wel appels met appels vergelijken. Je vergelijkt een NFS datastore met daarachter een enkele ZFS mirror ZONDER SLOG met het gecombineerde aantal iops van al je devices zonder enige context of specificatie.
Om te beginnen noem je geen block size. Je noemt niet of het om reads of writes gaat. Je noemt niet hoe deze storage is geconfigureerd, zijn het lokale datastores? Worden ze via VT-d doorgegeven aan een VM? etc Hoe heb je dit gemeten?
Je had ook de resultaten van mijn enkele pauper NVME kunnen noemen, namelijk meer dan 100000. Dat is lokaal. Of de versie met SLOG kunnen aanhalen.
Meet crystaldiskmark die 1.500.000 iops in een VM? Ik ben erg benieuwd hoeveel iops er over blijven als je dit via NFS aanbiedt. En wat blijft erover als jij dit vanaf ZFS met een NFS export aanbiedt?
Om het nog een klein beetje ontopic te houden, al die NVME devices zijn verschrikkelijke stroomvreters. Die intel 750 1.2TB van jouw verbruikt 22Watt tijdens schrijven. Ik heb bewust voor SATA gekozen om het juist zo zuinig mogelijk te maken, Een bewuste tradeoff, maar niet een die tot een onwerkbaar systeem leidde.
Ik heb een grote groep gebruikers (lees familie) die vaak meerdere devices hebben en heel veel via mijn ESXi server doen. Tel daarbij de dvr, monitoring, wifi controller etc Vandaar dat dat ding nooit idled. En veel ontwikkel werk, zoals de zfs test suite die dagen kan duren. En dat allemaal tegelijk op dat servertje met die paar iops. Maar heb ik echt te klagen over iops? Niet echt.

Een ESXi datastore op een ZFS based NFS export ZONDER SLOG is geen fijne ervaring en volkomen begrijpelijk dat gebruikers daar over klagen. Maar met een SLOG werkt dit prima en met een NVME SLOG nog veel beter. Vele tienduizenden vSphere omgevingen draaien naar volle tevredenheid op een datastore van een ZFS based NFS export. Ja ik ken use cases die 1.500.000 iops kunnen gebruiken, maar niet thuis. Ook kom je in de exotische hardware terecht om dit te transporteren. Ik heb veel IB ervaring. Zelfs met 56GB IB denk ik dat je nog niet zoveel 4K iops kan transporteren.

---

Beste lezers,

Ik ben razend benieuwd naar de usecase van iemand die thuis 1.500.000 iops nodig heeft (in zn ESXi server).
Of iemand die tegen de beperking aanloopt van een enkele NVME disk (in zn ESXi server)

Als mensen beperkingen van hun storage voor hun thuis ESXi server zouden kunnen benoemen dan ben ik daar zeer in geintereseerd. Het is ook nuttig voor de NAS BBG die in de steigers staat.
Ik ben vooral benieuwd naar iops beperkingen.
Misschien heb je te weinig storage capaciteit
Misschien heb je te weinig bandbreedte. Maar is je transport dan niet de beperkende factor.
Misschien is je CPU te traag.

Post alleen realistische use cases aub.
Niet dat je VM niet snel genoeg start. Maar loop je na het booten ergens tegenaan? Bijvoorbeeld je newsleecher staat alleen maar te wachten op je storage. Zoeken naar een mailtje in je email server duurt te lang.

[|sWORDs|]

tvwes schreef op maandag 27 februari 2017 @ 16:38:
[...]
Wat ik niet wil is dat het beeld ontstaat van "zo weinig iops? Nee Henk, dan gaat je ESXi servertje natuurlijk nooit lekker draaien" en dat we nu allemaal voor de 1.500.000 iops moeten gaan want anders ....

Je mist het punt en dat was niet de NVMe score, maar het dat een enkele SATA SSD met 47K IOPS en een QD van 31 de bottleneck van je omgeving kan zijn. Om mijn collega te quoten over queuedepth: "The one which stands out the most is the queue depth of the SATA device, only a queue depth of 32 and you can imagine this can once again become a “choking point”. I think it is safe to say that for ANY environment NL-SAS is the way to go and SATA should be avoided when possible."
In other words, when it comes to queue depth: spent a couple of extra bucks and go big… you don’t want to choke your own environment to death!"

Het ging over het gebruiken van ZFS mirror zonder SLOG, welke ik vergelijk met een enkele van die SSD's als local datastore. 808 IOPS vs 47K IOPS.

tvwes schreef op maandag 27 februari 2017 @ 16:38:
Om te beginnen noem je geen block size. Je noemt niet of het om reads of writes gaat. Je noemt niet hoe deze storage is geconfigureerd, zijn het lokale datastores? Worden ze via VT-d doorgegeven aan een VM? etc Hoe heb je dit gemeten?

4K writes op Q64T4 voor NVMe, voor SATA Q32T1, PVSCSI met een thin disk.

tvwes schreef op maandag 27 februari 2017 @ 16:38:
Meet crystaldiskmark die 1.500.000 iops in een VM?

Dit en het andere topic staan vol met screenshots, dit is natuurlijk per datastore en niet in totaal, al zou ik ze in één machine kunnen stoppen en een software RAID aan kunnen maken, maar waarom zou je dat willen?
1/7:


En waarom ga je er vanuit dat er ook maar iets serieus was aan de 1.5M IOPS (Waar in dit of het andere topic zie je mij iemand aanraden om meer dan één NVMe disk te nemen voor iets anders dan VSAN?), los van dat het wel ongeveer klopt? De enige reden waarom ik 6+ NVMe drives heb is dat ik drie hosts heb en de hardware wil hebben voor een VSAN (heeft een cache en een capacity drive nodig), daarnaast had ik de 1.2TB al liggen, maar niet de portemonnee om overal een 1.2TB in te stoppen.

tvwes schreef op maandag 27 februari 2017 @ 16:38:
Vele tienduizenden vSphere omgevingen draaien naar volle tevredenheid op een datastore van een ZFS based NFS export.

Ik kom ze naast labs niet tegen (zie zelfs geen vragen over omgevingen met ZFS), maar misschien dat deze bij SDDC vaker voorkomen.

tvwes schreef op maandag 27 februari 2017 @ 16:38:
[...]
Beste lezers,

[...]

Deze draai ik graag om. Waarom zou je ZFS als datastore gebruiken en de degradatie voor lief nemen als je ook local storage kunt gebruiken met een enkele host en backups naar ZFS of BTRFS kunt maken. Dat was mijn eigenlijke punt, betere performance en minimaal dezelfde zekerheid.

Hoeveel IOPS je nodig hebt ligt helemaal aan wat je doet, ik denk dat ik (maar kun je hier wel van privé spreken?) met 100K IOPS prima uit de voeten zou kunnen, maar dat is ook ongeveer wat ik zou halen met VSAN op de zes NVMe disks. De 6600 IOPS van jouw mirror met slog zou hier niet voldoende zijn, maar de performance van dezelfde schijven als local storage wel.
Maar misschien kan ik met mijn storage en ZFS wel de gewenste performance halen en alle andere voordelen, als je een goed idee hebt hou ik me aanbevolen.

[ Voor 99% gewijzigd door |sWORDs| op 27-02-2017 18:25 ]

[CurlyMo]

FireDrunk schreef op maandag 27 februari 2017 @ 16:18:Wat je kan proberen:
Maak een VM aan, geef deze via VT-d je 2 schijven. Tijdens de installer van BSD laat je deze de complete default uitvoeren voor een Root-on-ZFS mirror.

Waarom VT-d schijven. IK kan toch gewoon elke type schijven proberen voor het experiment.

Wat ik ga proberen is:
1. 2 virtuele schijven toevoegen aan een FreeBSD VM.
2. ZFS-on-root installeren in een ZFS mirror met een oudere FreeBSD versie en ZFS v28 (als dat laatste lukt).
3. Een derde virtuele schijf toevoegen aan de VM.
4. De basis ZFS-on-root installatie herhalen op de derde schijf.
5. De bootopties van de laatste schijf aanpassen zodat die boot van de eerste mirror.

6. FreeBSD upgrade uitvoeren.
7. ZFS upgrade uitvoeren.

8. Kijken of het geheel nog boot.

[|sWORDs|]

CurlyMo schreef op maandag 27 februari 2017 @ 18:51:
[...]

Waarom VT-d schijven. IK kan toch gewoon elke type schijven proberen voor het experiment.

Wat ik ga proberen is:
1. 2 virtuele schijven toevoegen aan een FreeBSD VM.
2. ZFS-on-root installeren in een ZFS mirror met een oudere FreeBSD versie en ZFS v28 (als dat laatste lukt).
3. Een derde virtuele schijf toevoegen aan de VM.
4. De basis ZFS-on-root installatie herhalen op de derde schijf.
5. De bootopties van de laatste schijf aanpassen zodat die boot van de eerste mirror.

6. FreeBSD upgrade uitvoeren.
7. ZFS upgrade uitvoeren.

8. Kijken of het geheel nog boot.

Ik zou voor het geval dat wel disk.enableuuid op de vmx zetten.

[FireDrunk]

@CurlyMo In theorie heb je gelijk, maar hoe weet je zeker dat je niet de bootcode van de tweede en/of derde schijven gebruikt. Omdat je geen 'kapot' boot process hebt zoals bij VT-d, is het vrij lastig om zeker te weten dat je niet de normale boot gebruikt.

Maar in theorie kan je het wel testen, gewoon kijken of je Grub ziet (als je het met grub gaat proberen, FreeBSD's eigen bootloader zou in theorie ook wel kunnen).

[CurlyMo]

FireDrunk schreef op maandag 27 februari 2017 @ 19:58:
@CurlyMo In theorie heb je gelijk, maar hoe weet je zeker dat je niet de bootcode van de tweede en/of derde schijven gebruikt. Omdat je geen 'kapot' boot process hebt zoals bij VT-d, is het vrij lastig om zeker te weten dat je niet de normale boot gebruikt.

Maar in theorie kan je het wel testen, gewoon kijken of je Grub ziet (als je het met grub gaat proberen, FreeBSD's eigen bootloader zou in theorie ook wel kunnen).

Stappen gevolgd zoals voorgesteld. Eerste pool heet zroot, tweede pool heet zboot. Daarna boot volgorde in VM bios aangepast naar zboot. Daarna nog een reboot zodat ik weet dat ik zboot boot. Daarna in zboot de /boot/loader.conf het volgende aangepast:

code:

vfs.root.mountfrom="zfs:zroot/ROOT/default"

Daarna in zroot de /boot/loader.conf aangepast naar:

code:

vfs.root.mountfrom="zfs:zboot/ROOT/default"

Als ik dus boot vanaf de zroot mirror, dan zou hij moeten vervolgen naar de zboot pool en visa versa. Zo weet ik zeker dat ik vanaf de juiste schijf boot. Nu boot hij dus netjes vanaf zboot verder in zroot.

Nu nog even een freebsd-update proberen.

[FireDrunk]

Cool! Klinkt als echt een super mooie simpele oplossing! Nog veel simpeler dan mijn idee voor grub-static!

[hans_lenze]

Bah, wil ESXi updaten naar 6.5a maar ik denk dat m'n USB stick weer eens gaar is.

code:

2017-02-27T19:34:33.270Z cpu8:457766)FSS: 7948: Mounting fs visorfs (4303ae66a7b0) with -o 0,200,0,0,0,755,vibtransaction on file descriptor 4303b5d35360
2017-02-27T19:34:40.093Z cpu4:457770)FSS: 8106: Unmounting file descriptor 4303b5d35540
2017-02-27T19:34:40.093Z cpu4:457770)VisorFSRam: 983: inode 660074174894645120
2017-02-27T19:34:40.093Z cpu4:457770)VisorFSRam: 1000: ramdisk vibtransaction
2017-02-27T19:34:40.093Z cpu4:457770)VisorFSRam: 1165: for ramdisk vibtransaction
2017-02-27T19:37:52.880Z cpu8:67795)VFAT: 4592: Failed to get object 36 type 2 uuid 57710b97-0c5444a8-f380-0cc47ac4a6f6 cnum 0 dindex fffffffecdate 0 ctime 0 MS 0 :No connection

Durf ik het ding te herstarten of zal ik hem lekker door laten draaien en gebruiken tot ie crashed?

Edit: stuk

[ Voor 3% gewijzigd door hans_lenze op 27-02-2017 20:51 ]

[Beninho]

|sWORDs| schreef op maandag 27 februari 2017 @ 15:34:
[...]

De verschillen tussen die machines zijn enorm klein. Het zijn allemaal dual core met hyperthreading machines. De i5 voegt een turbo toe, de i7 een hogere base/turbo clock en is in dit geval een "generatie" nieuwer, maar eigenlijk voor ESXi identiek aan de 6500u. De Gigabyte Brix is net wat goedkoper, kan meer geheugen aan en is beschikbaar met twee NICs. pricewatch: Gigabyte BRIX GB-BSi3HAL-6100 (rev. 1.0)

Samba is mogelijk naar een VM, maar niet naar ESXi als datastore (NFS/iSCSI).

Zie vanaf hier iemand die vrijwel het zelfde doet met een Celeron (Ook 2.3GHz, geen HT/Turbo): zeroday in "Het grote ESXi/vSphere Topic" na een beetje optimaliseren ging dat volgens mij goed, echter zou ik toch een quad core aanraden.

Thanks voor je antwoord. NFS is wel mogelijk toch in ESXi? Die ASRock DeskMini 110 die @Martiveen doorgaf is ook wel interessant, dan kan ik een quadcore inleggen. . Wat zijn jullie ervaringen met het voltrekken van de gigabit lijn? Zal niet snel gebeuren volgens mij, met het gebruik wat ik voor ogen heb. Dan zou ik die 2e NIC niet nodig hebben..

[|sWORDs|]

Beninho schreef op maandag 27 februari 2017 @ 20:46:
[...]


Thanks voor je antwoord. NFS is wel mogelijk toch in ESXi? Die ASRock DeskMini 110 die @Martiveen doorgaf is ook wel interessant, dan kan ik een quadcore inleggen. . Wat zijn jullie ervaringen met het voltrekken van de gigabit lijn? Zal niet snel gebeuren volgens mij, met het gebruik wat ik voor ogen heb. Dan zou ik die 2e NIC niet nodig hebben..

Als je het voor storage (VM datastore) gaat gebruiken dan trek je gigabit zo vol, wat voor NAS heb je?

[Beninho]

|sWORDs| schreef op maandag 27 februari 2017 @ 20:59:
[...]

Als je het voor storage (VM datastore) gaat gebruiken dan trek je gigabit zo vol, wat voor NAS heb je?

Ik heb een zelfbouw NAS (ubuntu 16.04) gebaseerd op een pricewatch: Asus E35M1-I met zes 2tb schijven in raidz2 (zfs). De nas heeft naast de eigen Realtek NIC en een extra pricewatch: Intel Gigabit CT Desktop Adapter

[ Voor 6% gewijzigd door Beninho op 27-02-2017 21:10 ]

[|sWORDs|]

Beninho schreef op maandag 27 februari 2017 @ 21:09:
[...]


Ik heb een zelfbouw NAS (ubuntu 16.04) gebaseerd op een pricewatch: Asus E35M1-I met zes 2tb schijven in raidz2 (zfs). De nas heeft naast de eigen Realtek NIC en een extra pricewatch: Intel Gigabit CT Desktop Adapter

Misschien als je de zwaarste VM's op lokale storage zet? Spinning disks, gigabit, ZFS en sabnzbd + overige VMs lijkt me geen goede combi.

[Beninho]

|sWORDs| schreef op maandag 27 februari 2017 @ 21:18:
[...]

Misschien als je de zwaarste VM's op lokale storage zet? Spinning disks, gigabit, ZFS en sabnzbd + overige VMs lijkt me geen goede combi.

Ja zoiets ben ik ook van plan. Ik had er nog niet aan gedacht dat ik de VM's ook extern, in de NAS zou kunnen draaien. Maar dan vraag ik me net als jij af, of dan de performance voldoende zou zijn. Ook zonder dubbele NIC vrees ik dat de zfs pool en beperkte processor snelheid van de nas de bottlenek gaan zijn.

Lokaal zou ik natuurlijk al die 'kleine' VM's op een SSD kunnen laten werken.

[|sWORDs|]

Beninho schreef op maandag 27 februari 2017 @ 21:27:
[...]


Ja zoiets ben ik ook van plan. Ik had er nog niet aan gedacht dat ik de VM's ook extern, in de NAS zou kunnen draaien. Maar dan vraag ik me net als jij af, of dan de performance voldoende zou zijn. Ook zonder dubbele NIC vrees ik dat de zfs pool en beperkte processor snelheid van de nas de bottlenek gaan zijn.

Lokaal zou ik natuurlijk al die 'kleine' VM's op een SSD kunnen laten werken.

Dat gaat prima werken. Locale SSD voor de VM's en de NAS voor documenten, één of twee NICs maakt dan weinig uit.

[CurlyMo]

FireDrunk schreef op maandag 27 februari 2017 @ 20:33:
Cool! Klinkt als echt een super mooie simpele oplossing! Nog veel simpeler dan mijn idee voor grub-static!

Dat moeilijke gedoe ook altijd van die techneuten

freebsd-update gedraaid. Dat gaat niet zonder slag of stoot. FreeBSD boot wel, maar niet lekker. Kernel mismatch. Je kan natuurlijk zboot zelf booten en updaten, maar je kan hem ook updaten vanaf zroot. Dat scheelt weer een grote installatie van zboot. FreeBSD updaten gaat namelijk niet met 1GB pool. Door deze methode kan je echt een minimale installatie doen.

Dat laatste is wat ik heb gedaan (misschien is niet alles nodig, maar dit werkte):

code:

zpool import -R /mnt zboot
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad0
cp -R /mnt/boot /mnt/boot-old
cp -R /boot /mnt
dd if=/dev/da1p1 of=/dev/da0p1

Daarna boot alles perfect naar FreeBSD 11 (vanaf FreeBSD 10.1).

[tvwes]

CurlyMo schreef op maandag 27 februari 2017 @ 22:27:
[...]

Dat moeilijke gedoe ook altijd van die techneuten

freebsd-update gedraaid. Dat gaat niet zonder slag of stoot. FreeBSD boot wel, maar niet lekker. Kernel mismatch. Je kan natuurlijk zboot zelf booten en updaten, maar je kan hem ook updaten vanaf zroot. Dat scheelt weer een grote installatie van zboot. FreeBSD updaten gaat namelijk niet met 1GB pool. Door deze methode kan je echt een minimale installatie doen.

Dat laatste is wat ik heb gedaan (misschien is niet alles nodig, maar dit werkte):

code:

zpool import -R /mnt zboot
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad0
cp -R /mnt/boot /mnt/boot-old
cp -R /boot /mnt
dd if=/dev/da1p1 of=/dev/da0p1

Daarna boot alles perfect naar FreeBSD 11 (vanaf FreeBSD 10.1).

Heel goed gedaan! Maar wat ik al eerder schreef: helemaal plug en play is dit verre van. Als de OS ontwikkelaar iets wijzigt in het installatie of update proces zit je weer met de gebakken peren.

Maar goed je hebt het voor elkaar. Dus dan zijn we nu aangekomen bij de USB controllers volgens mij. Je hebt er drie maar hebt er slechts eentje nodig voor je datastore met je boot blockje. En dat kan een EHCI (USB2) controller zijn. De andere kan je doorgeven met VT-d aan 1 of 2 VM's.
Alleen, ik begin in herhaling te vallen, moet je eerst je routing van de usb poorten weten. Je mag van mij best met trial-and-error vanuit esxi uitvogelen welke poort bij welke controller hoort. Maar even windows booten en dat tooltje starten lijkt me makkelijker.
Je ESXi weer starten en de usbarbitrator uitzetten. Dan stickje erin en datastore maken.
En dan kan je het proces herhalen met een nieuw VM die een klein vmdk'tje heeft op de usbdatastore en de rest op de ssd's.

Je bent er bijna. Probeer als het even kan even mooi stappenplan op te schrijven.
Ik zit alleen nog na te denken over de swapfile van de VM. Als je het geheugen van je VM locked, wat zowieso beter is voor deze specifieke VM ivm de ARC van ZFS, dan krijg je een .vswp file van 0 bytes op je usbstick ipv je hele ram. Mischien weet @|sWORDs| een betere oplossing.

[|sWORDs|]

Nee, reserve all memory is voor zo ver ik weet de beste oplossing. Ik ben al tijden aan het zoeken of ik geen swap zonder reservering kan doen, maar heb nog niets gevonden.

[CurlyMo]

tvwes schreef op maandag 27 februari 2017 @ 23:54:
[...]
Heel goed gedaan! Maar wat ik al eerder schreef: helemaal plug en play is dit verre van. Als de OS ontwikkelaar iets wijzigt in het installatie of update proces zit je weer met de gebakken peren.

Dat is altijd zo. Maar wat ik doe is gewoon standaard FreeBSD. Bootcode kopieer ik nu letterlijk van schijf 2 naar schijf 1 en het is maar 1 boot parameter aanpassen. Wat nu handig is, is dat je altijd direct van schijf 2 kan booten zonder ESXi. De bootcode op schijf 2 blijft namelijk gewoon in tact. Je gebruikt hem alleen niet.

Alleen, ik begin in herhaling te vallen, moet je eerst je routing van de usb poorten weten.

Je hoeft je niet te herhalen. Ik neem vooral de tijd

Je mag van mij best met trial-and-error vanuit esxi uitvogelen welke poort bij welke controller hoort.

Gisteren heeft het me nog geen 5 minuten gekost om even een usb stick in elke beschikbare poort te stoppen en lsusb te draaien. Dan zie ik dat alle poorten achter op het moederbord aan dezelfde controller hangen. Ik heb nu geen kabels voor de mogelijke andere usb controllers dus daar moet ik nog even op wachten.

Ik zit alleen nog na te denken over de swapfile van de VM. Als je het geheugen van je VM locked, wat zowieso beter is voor deze specifieke VM ivm de ARC van ZFS, dan krijg je een .vswp file van 0 bytes op je usbstick ipv je hele ram. Mischien weet @|sWORDs| een betere oplossing.

Lijkt me inderdaad logisch.

[FireDrunk]

@CurlyMo / @|sWORDs| Heeft een van jullie eigenlijk getest of je van een via VT-d doorgegeven USB controller kan booten?

[CurlyMo]

FireDrunk schreef op dinsdag 28 februari 2017 @ 08:06:
@CurlyMo / @|sWORDs| Heeft een van jullie eigenlijk getest of je van een via VT-d doorgegeven USB controller kan booten?

Nee, nog geen kabels voor.

[tvwes]

FireDrunk schreef op dinsdag 28 februari 2017 @ 08:06:
@CurlyMo / @|sWORDs| Heeft een van jullie eigenlijk getest of je van een via VT-d doorgegeven USB controller kan booten?

Geen antwoord op je vraag, maar de AHCI controller kan je niet booten. Daarom denk ik ook niet van USB. Ik kan het helaas niet testen want ik heb maar een enkele USB controller en daar boot ESXi van en ik kan mijn systeem niet offline nemen.

Diegene die het wil testen en ook maar 1 USB controller heeft zou ESXi op een SATA disk kunnen installeren en daarvan booten. En vervolgens de USB controller via VT-d doorgeven aan een vm. Iso toewijzen aan de cdrom. En booten..
Nu zal de OS installer netjes booten en vermoedelijk ook de usb stick vinden en het OS daar willen installeren. Maar na de reboot niet willen booten. Dat gebeurde bij mij met AHCI en hier bij FreeNAS met iemand die precies dit met USB probeerde
Waarom? De VMware bios heeft geen code om deze controllers te starten. Alleen hun eigen ide etc. Hoogstens dat een HBA met een option ROM via int 13 kan booten.

[tvwes]

CurlyMo schreef op dinsdag 28 februari 2017 @ 07:10:
[...]

Je hoeft je niet te herhalen. Ik neem vooral de tijd

Nou ik vind dat je in een hoog tempo met succes resultaten doorkomt.

[...]
Gisteren heeft het me nog geen 5 minuten gekost om even een usb stick in elke beschikbare poort te stoppen en lsusb te draaien. Dan zie ik dat alle poorten achter op het moederbord aan dezelfde controller hangen. Ik heb nu geen kabels voor de mogelijke andere usb controllers dus daar moet ik nog even op wachten.
[...]

Dat is niet wat ik verwachte. Dus die twee USB2 poorten links zitten op dezelfde controller als de USB3 poorten. En zal jij dus moeten zien dat alleen de xHCI controller werd gebruikt. Of niet?
Misschien dat onboard er nog een EHCI controller zit aangesloten.

Lijkt me inderdaad logisch.

Het is niet altijd makkelijk in te schatten hoeveel kennis iemand heeft...

[CurlyMo]

tvwes schreef op dinsdag 28 februari 2017 @ 09:38:
[...]

Nou ik vind dat je in een hoog tempo met succes resultaten doorkomt.

Klopt, voor wat ik binnen de mogelijkheden heb wel. Mijn Data VM ombouwen neem ik iets meer tijd voor. Het opzetten van een test VM voor dit doeleind kan tijdens de thee.

Dat is niet wat ik verwachte. Dus die twee USB2 poorten links zitten op dezelfde controller als de USB3 poorten. En zal jij dus moeten zien dat alleen de xHCI controller werd gebruikt. Of niet?
Misschien dat onboard er nog een EHCI controller zit aangesloten.

Ik dacht het wel, maar dat klinkt inderdaad niet logisch. Ik zal vanavond nog eens proberen. Gisteravond ben ik vooral op gevoel de USB poorten langsgegaan.

Het is niet altijd makkelijk in te schatten hoeveel kennis iemand heeft...

Klopt, ik denk denk ik iets sneller out-of-the-box. Vandaar dat mijn oplossingen soms simpelweg onmogelijk zijn of soms simpelweg heel simpel. En als iets heel simpel blijkt te zijn, dan heb je dat ook simpel getest. Zoals een lsusb met een wisselend usb stickje.

[CurlyMo]

tvwes schreef op dinsdag 28 februari 2017 @ 09:38:
Dat is niet wat ik verwachte. Dus die twee USB2 poorten links zitten op dezelfde controller als de USB3 poorten. En zal jij dus moeten zien dat alleen de xHCI controller werd gebruikt. Of niet?
Misschien dat onboard er nog een EHCI controller zit aangesloten.

Nog even gechecked en het is toch zo.

[tvwes]

CurlyMo schreef op dinsdag 28 februari 2017 @ 19:48:
[...]

Nog even gechecked en het is toch zo.

Ik heb het ook nog even gechecked en vermoedelijk is het inderdaad zo.
Als we in de datasheet van jouw chipset kijken.Dan staat de samenvatting op pagina 44.

• xHCI USB controller provides support for up to 14 USB ports, of which six can be
• configured as SuperSpeed USB 3.0 ports.
• Two legacy EHCI USB controllers each provides a USB debug port

Dus ja het klopt dat jij drie controllers ziet. Ja het klopt dat waar jij stick je ook in prikt je altijd via de xHCI controller gaat. Maar het had best gekund dat die xHCI controller alleen maar USB3 leverde.

Nu is dit allemaal prachtig maar gaat het wel betekenen dat als je toch een USB datastore maakt je geen USB meer hebt voor je VM's. Als je wel USB voor je VM's wilt dan zal je de ASmedia toch moeten houden evt met een extra SSD (die heel klein mag zijn).

[CurlyMo]

Oftewel, ik heb twee USB controllers, want beide controllers gaan via de xHCI controller? Waardoor ik geen externe HDD kan doorgeven aan mijn Data VM en ook via de software matige weg omdat ik de usb aansturing van ESXi uitzet.

Edit:
Wat ik me nu bedenk is dat ik ook de huidige ASMedia kan verplaatsen naar de m-sata onder het moederbord. Dit is tevens een mini-pcie poort. Dan ga ik alsnog efficiënt om met mijn poorten

Dan een vraag over SSD's. Nu gebruik ik 2 MX100 128GB. Ga ik veel winst boeken als ik deze vervang door twee MX300 525GB of zelfs één Intel 600p 512GB. Ik zie dat de IOPS flink oplopen tussen die schijven en mijn huidige SSD, maar ga je dat goed merken in de praktijk wat betreft slog, l2arc en NFS?

[ Voor 78% gewijzigd door CurlyMo op 01-03-2017 09:40 ]

[FireDrunk]

CurlyMo schreef op woensdag 1 maart 2017 @ 09:33:
Oftewel, ik heb twee USB controllers, want beide controllers gaan via de xHCI controller? Waardoor ik geen externe HDD kan doorgeven aan mijn Data VM en ook via de software matige weg omdat ik de usb aansturing van ESXi uitzet.

Kan je eens een screenshot posten van je Passthrough overzicht? Want ik kan moeilijk geloven dat al je USB poorten op 1 'controller' zitten. Wat ik wel kan geloven is dat ze op 1 PCIe Root poort zitten.

Edit:
Wat ik me nu bedenk is dat ik ook de huidige ASMedia kan verplaatsen naar de m-sata onder het moederbord. Dit is tevens een mini-pcie poort. Dan ga ik alsnog efficiënt om met mijn poorten

Dan een vraag over SSD's. Nu gebruik ik 2 MX100 128GB. Ga ik veel winst boeken als ik deze vervang door twee MX300 525GB of zelfs één Intel 600p 512GB. Ik zie dat de IOPS flink oplopen tussen die schijven en mijn huidige SSD, maar ga je dat goed merken in de praktijk wat betreft slog, l2arc en NFS?

Nee, merk je waarschijnlijk niets van. Als je dat wil weten, moet je naar benchmarks kijken, die QD1T1 Write tests doen (want dat is SLOG). De writes die je ziet zijn zeer waarschijnlijk L2ARC writes, dat kan aardig oplopen. Als je op een groot volume veel verloop hebt, gaat ZFS al heel snel 'oude' L2ARC pages evicten en vervangen met nieuwere.

Als alle data in je L2ARC oud is, gaat hij nog steeds de oudste data steeds vervangen met nieuwe data die net binnenkomt. Het is niet zo dat data pas in L2ARC komt als het meer dan een paar keer is opgevraagd.

Je kan de writes naar L2ARC overigens vrij goed tunen.

Edit:
Even opgezocht: De MX100 doet ~68MB/s random Write QD1, de MX300 doet 126MB/s random Write QD1.
Je zou het dus wel iets kunnen merken, maar of het veel is betwijfel ik. De waardes die ik opgezocht heb zijn AS-SSD QD1 4K Random Write. Maar AS-SSD schrijft volgens mij geen pure random data, waardoor de tests een beetje lastig te lezen is in mijn optiek.

(Ter vergelijking, een Intel 750 400GB doet 200MB/s random Write QD1, en een 1.2TB model 293MB/s QD1.)

Als je het dus hebt over pure slog, kan een NVMe SSD 50% sneller zijn dan een MX300. En een MX300 kan weer 60-85% sneller zijn dan een MX100.

_{Enige kanttekening is dat ik vrij oude benchmarks heb gebruikt van de MX100, in de tussentijd kan met firmware updates die benchmark ook wel wat verbetered zijn.}

[ Voor 19% gewijzigd door FireDrunk op 01-03-2017 10:25 ]

[|sWORDs|]

CurlyMo schreef op dinsdag 28 februari 2017 @ 19:48:
[...]

Nog even gechecked en het is toch zo.

Misschien kun je in de BIOS nog wat aanpassen, post eventueel even een foto. Ik geloof dat bij mijn C216 dat ook zo was, bij de ene stand kwam alles onder "één controller", bij de andere kwamen de USB 2 poorten op een losse controller.

CurlyMo schreef op woensdag 1 maart 2017 @ 09:33:
[...]

Dan een vraag over SSD's. Nu gebruik ik 2 MX100 128GB. Ga ik veel winst boeken als ik deze vervang door twee MX300 525GB of zelfs één Intel 600p 512GB. Ik zie dat de IOPS flink oplopen tussen die schijven en mijn huidige SSD, maar ga je dat goed merken in de praktijk wat betreft slog, l2arc en NFS?

Als je erg veel continue writes hebt dan kan een MX300 sneller zijn dan een 600p (15462 vs 14310 IOPS sustained) en zou een Samsung 850 Pro (44365 IOPS sustained) of EVO (30106 IOPS sustained) een betere keuze kunnen zijn, met bursts en qua latency is de 600p enorm veel sneller (47875 vs 17448 QD1 en 114828 vs 83780 QD32) dan de MX300.

4K write popular 400-525GB SSD's:

Drive (Vendor/Model)	QD1 Burst (IOPS)	QD32 Burst (IOPS)	Burst (m)	Half Burst (m)	QD32 Sustained (IOPS)	Latency (ms)	Price (euro per GB)
Intel 600p	47875	114828	5	1	14310	0.025	0.32
Crucial MX300	17448	83780	5	1	15462	0.050	0.27
Samsung 950 Pro	49225	103016	3	2	25779	0.024	0.73
Samsung 850 EVO	26725	91567	0.5	0.25	30106	0.028	0.33
Samsung 850 Pro	21114	93147	2	1	44365	0.028	0.48
Samsung 960 EVO	57925	318638	5	4	53376	0.018	0.47
Samsung 960 Pro	59032	302691	3	2	107161	0.017	0.66
Intel 750	58894	168903	>30	>30	168422	0.016	0.83

Waarbij de Intel 750 wel een burst heeft, echter is dit pas zichtbaar bij een QD van 64 of hoger en meerdere threads (dan 261000 burst).

Best prijs/prestatie/capaciteit:
Writes: Intel 750
Reads: 960 EVO
Mixed: 960 Pro

Best prijs/prestatie/capaciteit onder de 200 euro:
Writes: 850 EVO
Reads: Intel 600p
Mixed: Intel 600p

[ Voor 111% gewijzigd door |sWORDs| op 01-03-2017 15:09 ]

[tvwes]

FireDrunk schreef op woensdag 1 maart 2017 @ 10:12:
[...]

Kan je eens een screenshot posten van je Passthrough overzicht? Want ik kan moeilijk geloven dat al je USB poorten op 1 'controller' zitten. Wat ik wel kan geloven is dat ze op 1 PCIe Root poort zitten.

Dat had hij al gedaan, CurlyMo schreef op zondag 26 februari 2017 @ 20:15



Als we verder in de datasheet lezen, op pagina 48, dan komen de addressen overeen met de screenshot.

Dus er zijn denk ik echt wel drie controllers. Maar blijkbaar worden de poorten (8+6) op de een of andere manier onder controle gebracht van de XHCI controller. In de datasheet staat ook dat de xHCI "up to 14" USB2 poorten heeft. Maar helemaal duidelijk is het niet.

Misschien kan je in de bios wat rommelen zoals @|sWORDs| voorstelt.

[...]

Nee, merk je waarschijnlijk niets van. Als je dat wil weten, moet je naar benchmarks kijken, die QD1T1 Write tests doen (want dat is SLOG). De writes die je ziet zijn zeer waarschijnlijk L2ARC writes, dat kan aardig oplopen. Als je op een groot volume veel verloop hebt, gaat ZFS al heel snel 'oude' L2ARC pages evicten en vervangen met nieuwere.

Als alle data in je L2ARC oud is, gaat hij nog steeds de oudste data steeds vervangen met nieuwe data die net binnenkomt. Het is niet zo dat data pas in L2ARC komt als het meer dan een paar keer is opgevraagd.

Je kan de writes naar L2ARC overigens vrij goed tunen.

[tvwes]

FireDrunk schreef op woensdag 1 maart 2017 @ 10:12:
Nee, merk je waarschijnlijk niets van. Als je dat wil weten, moet je naar benchmarks kijken, die QD1T1 Write tests doen (want dat is SLOG). De writes die je ziet zijn zeer waarschijnlijk L2ARC writes, dat kan aardig oplopen. Als je op een groot volume veel verloop hebt, gaat ZFS al heel snel 'oude' L2ARC pages evicten en vervangen met nieuwere.

Als alle data in je L2ARC oud is, gaat hij nog steeds de oudste data steeds vervangen met nieuwe data die net binnenkomt. Het is niet zo dat data pas in L2ARC komt als het meer dan een paar keer is opgevraagd.

Je kan de writes naar L2ARC overigens vrij goed tunen.

Edit:
Even opgezocht: De MX100 doet ~68MB/s random Write QD1, de MX300 doet 126MB/s random Write QD1.
Je zou het dus wel iets kunnen merken, maar of het veel is betwijfel ik. De waardes die ik opgezocht heb zijn AS-SSD QD1 4K Random Write. Maar AS-SSD schrijft volgens mij geen pure random data, waardoor de tests een beetje lastig te lezen is in mijn optiek.

(Ter vergelijking, een Intel 750 400GB doet 200MB/s random Write QD1, en een 1.2TB model 293MB/s QD1.)

Als je het dus hebt over pure slog, kan een NVMe SSD 50% sneller zijn dan een MX300. En een MX300 kan weer 60-85% sneller zijn dan een MX100.

_{Enige kanttekening is dat ik vrij oude benchmarks heb gebruikt van de MX100, in de tussentijd kan met firmware updates die benchmark ook wel wat verbetered zijn.}

Ik denk dat het verschil tussen een NVME en SATA SSD SLOG veel groter is. Mijn ervaring is dat de lage latency het echte verschil maakt. De NVME doet de write in usecs ipv in msecs bij SATA. De SLOG moet alleen maar zo snel mogelijk antwoorden dat de write heeft plaatsgevonden. Hoeveel IOPS je dan nodig hebt maakt hier (op tweakers) al snel niet uit.

Voor een ieder die wil weten wat een SLOG evt aan snelheid winst oplevert:

# zfs set sync=disabled mypool/dataset

Beter dan dit kan je performance niet worden. Alles hierna is een andere bottleneck.

[FireDrunk]

Correct, maar dat is als het goed is gewoon zichtbaar bij de benchmarks. Bij een QD1 test is de absolute response tijd (waar jij het over hebt) de grootste bottleneck inderdaad.

Het is gewoon heel lastig te benchen. De huis-tuin-en-keuken benchmarks houden helemaal geen rekening met het gedrag wat SLOG/ZFS vertoond, waardoor het heel lastig is om een educated guess te doen.

[CurlyMo]

De vraag wat betreft de USB controllers is wat mij betreft of bij het doorgeven van de ECHI #1 of #2 niet ook xHCI meekomt, zoals sommige hier hadden met de onboard controller en de ASMedia 1061. Anders zie ik geen concrete problemen.

De slog benchmarken heb ik al eens gedaan door via NFS gcc uit te pakken met slog, mirrored slog, zonder slog en zonder sync. Ik zal dat vanavond eens posten.

[|sWORDs|]

FireDrunk schreef op woensdag 1 maart 2017 @ 11:15:
Correct, maar dat is als het goed is gewoon zichtbaar bij de benchmarks. Bij een QD1 test is de absolute response tijd (waar jij het over hebt) de grootste bottleneck inderdaad.

Het is gewoon heel lastig te benchen. De huis-tuin-en-keuken benchmarks houden helemaal geen rekening met het gedrag wat SLOG/ZFS vertoond, waardoor het heel lastig is om een educated guess te doen.

Ik denk dat wel een aardige inschatting te maken is welke drive het meest geschikt is:

Drive (Vendor/Model)	QD1 Sustained (IOPS)	Latency (ms)	Price (euro per GB)
Intel 600p	14310	0.25	0.32
Crucial MX300	15462	0.5	0.27
Samsung 850 Pro	21114	0.28	0.48
Samsung 950 Pro	25779	0.24	0.73
Samsung 850 EVO	26725	0.28	0.33
Samsung 960 EVO	53376	0.18	0.47
Intel 750	58894	0.16	0.83
Samsung 960 Pro	59032	0.17	0.66

De enige vraag is hoe zwaar je de prijs, IOPS en ms laat wegen. Als ik alles even zwaar weeg kom ik op:

Drive	Score
Crucial MX300	114533
Samsung 950 Pro	147140
Samsung 850 Pro	157098
Intel 600p	178875
Samsung 850 EVO	289232
Intel 750	443479
Samsung 960 Pro	526132
Samsung 960 EVO	630922

Overall: 960 EVO
Onder de 200 euro: 850 EVO

[ Voor 71% gewijzigd door |sWORDs| op 01-03-2017 15:53 ]

[FireDrunk]

Daar is alleen 1 maar. Niet alle SSDs honoreren de SYNC requests even correct. Samsung staat er om bekend om zich niet 100% aan SYNC writes te houden, en een klein beetje te smokkelen.

(Dat is een verhaal dat de ronde deed bij de eerste EVO's volgens mij, dus het kan verouderde informatie zijn).

Intel is met zijn 320 en DC series altijd super sterk geweest in het keurig aan de regels houden van de SYNC writes. De Intel 520 en 530 series weer wat minder, en van de 600p weet ik het eerlijk gezegd niet.

De Intel 750 zal zich zeer waarschijnlijk net als de DC/P counterparts goed gedragen.

Just so you know

[|sWORDs|]

FireDrunk schreef op woensdag 1 maart 2017 @ 16:07:
Daar is alleen 1 maar. Niet alle SSDs honoreren de SYNC requests even correct. Samsung staat er om bekend om zich niet 100% aan SYNC writes te houden, en een klein beetje te smokkelen.

(Dat is een verhaal dat de ronde deed bij de eerste EVO's volgens mij, dus het kan verouderde informatie zijn).

Intel is met zijn 320 en DC series altijd super sterk geweest in het keurig aan de regels houden van de SYNC writes. De Intel 520 en 530 series weer wat minder, en van de 600p weet ik het eerlijk gezegd niet.

De Intel 750 zal zich zeer waarschijnlijk net als de DC/P counterparts goed gedragen.

Just so you know

Ik zit al een paar dagen te kijken wat ik zal doen, ik vind het wel leuk om een weekendje met ZFS te spelen.
Ben er alleen nog niet uit wat ik met Toshiba 4x 4TB 7200RPM consumer grade, 2x Samsung 843T 480GB, 3x Intel 750 400GB, 3x Samsung 950 512GB, 1x Intel 750 1.2TB, 1x Sandisk X400 512GB en 1x Toshiba 4TB 7200rpm "enterprise grade" nou wel en niet zou moeten gebruiken en waarvoor.

[CurlyMo]

FireDrunk schreef op woensdag 1 maart 2017 @ 16:07:
Daar is alleen 1 maar. Niet alle SSDs honoreren de SYNC requests even correct. Samsung staat er om bekend om zich niet 100% aan SYNC writes te houden, en een klein beetje te smokkelen.

(Dat is een verhaal dat de ronde deed bij de eerste EVO's volgens mij, dus het kan verouderde informatie zijn).

Intel is met zijn 320 en DC series altijd super sterk geweest in het keurig aan de regels houden van de SYNC writes. De Intel 520 en 530 series weer wat minder, en van de 600p weet ik het eerlijk gezegd niet.

De Intel 750 zal zich zeer waarschijnlijk net als de DC/P counterparts goed gedragen.

Just so you know

De Samsungs stonden op mijn lijstje maar precies hierom heb ik ze er vanaf gehaald.

Oftewel, dit advies:

FireDrunk schreef op vrijdag 14 oktober 2016 @ 11:13:
[...]


Persoonlijk vertrouw ik een single Intel 750 meer als SLOG dan twee Samsung's in RAID. Dit komt omdat de Intel ingebouwde stroomverliesbescherming heeft, en de Samsung's niet (dat is voorbestemd aan de enterprise modellen).

De kans dat je Samsung's de SLOG daadwerkelijk goed opvangen is dus kleiner bij stroomverlies dan bij de Intel.

Als het gaat om uitval van een individuele SSD zal de Samsung het waarschijnlijk wel gewoon goed doen.

Desalniettemin, ik zou Samsung's niet zomaar als SLOG gebruiken, maar dat is mijn persoonlijke mening.
Dat komt vooral omdat Samsung erg, erg agressief in DRAM cached op zijn SSD's.

[ Voor 32% gewijzigd door CurlyMo op 01-03-2017 16:46 ]

[FireDrunk]

Als je een leuke deal wil: op eBay staan zeer regelmtig Intel DC36xx series voor een mooi prijsje. Perfect voor SLOG.

Zoiets: http://m.ebay.com/itm/NEW...-/222425427806?nav=SEARCH

[ Voor 36% gewijzigd door FireDrunk op 01-03-2017 18:38 ]

[tvwes]

CurlyMo schreef op woensdag 1 maart 2017 @ 11:23:
De vraag wat betreft de USB controllers is wat mij betreft of bij het doorgeven van de ECHI #1 of #2 niet ook xHCI meekomt, zoals sommige hier hadden met de onboard controller en de ASMedia 1061. Anders zie ik geen concrete problemen.

Ik kom er niet uit met de datasheet. Als jij zegt dat als je een USB2 device aansluit je dit op de xHCI controller ziet verschijnen dan betwijfel ik of als je dat xHCI device via passthrough doorgeeft zo'n achter gebleven EHCI controller ooit een device aan ESXi laat zien. Je zal het gewoon moeten testen. Met je bootblock had je ook heel snel succes!

De slog benchmarken heb ik al eens gedaan door via NFS gcc uit te pakken met slog, mirrored slog, zonder slog en zonder sync. Ik zal dat vanavond eens posten.

Ik ben benieuwd.

[CurlyMo]

tvwes schreef op woensdag 1 maart 2017 @ 18:47:
Ik ben benieuwd.

code:

slog    sync    nfs
1       X           1m56.264s
1                   1m30.579s   SLOG not being used
0       X           23m6.864s
0                   1m30.605s
2*      X           2m7.834s
2       X           2m3.119s

1       X       X   2m4.550s
1               X               SLOG not being used
0       X       X
0               X   1m46.335s
2*      X       X   2m8.498s
2       X       X   2m2.767s
4k      x       x   2m17.670s

*Mirrored

- SLOG, additional SSD's used as ZFS log device. Either zero, 1 or 2 (in mirror or striped).
- Sync, are ZFS synced writes enabled.
- NFS, is the unpacking done through a NFS share or directly on the drive themselves.

Laatste idee (als alles werkt):
1. ASMedia uit de mini-pcie halen.
2. Een mini-pcie naar pcie adapter kopen.
3. 2x M.2 naar pcie kaarten kopen en 2x M.2 SSD kopen en in passthrough zetten naar NAS.
4. Overige 2 SSD's ander doel voor vinden.
5. Hopen dat ik de datastore op USB krijg en overige USB plannen kan uitwerken.

6. Als laatste moet de ASMedia naar de m-sata poort onder het moederbord voor mirrored offsite backup voor familielid bij mij.

De M.2 SSD's gebruiken als FreeBSD install, datastore, SLOG en L2ARC.

Node 304 heeft 2 pci sloten, maar waarvan de mini-itx formfactor er maar één gebruikt. Ik zou dus prima een tweede kunnen creëren via een mini-pcie naar pcie kaart.



Als dat volgens niet tot een master mini-itx build leidt weet ik het ook niet meer

FireDrunk schreef op woensdag 1 maart 2017 @ 18:32:
Als je een leuke deal wil: op eBay staan zeer regelmtig Intel DC36xx series voor een mooi prijsje. Perfect voor SLOG.

Zoiets: http://m.ebay.com/itm/NEW...-/222425427806?nav=SEARCH

Dan blijft de vraag wat te doen met Samsung's en SLOG?

[ Voor 3% gewijzigd door CurlyMo op 01-03-2017 19:16 ]

[tvwes]

We dwalen wel wat af aangaande de SLOG's.
Heel belangrijk bij een SLOG is wat @FireDrunk al schreef

FireDrunk schreef op woensdag 1 maart 2017 @ 16:07:
kort samengevat je wilt geen drive die liegt.

Daar is alleen 1 maar. Niet alle SSDs honoreren de SYNC requests even correct. Samsung staat er om bekend om zich niet 100% aan SYNC writes te houden, en een klein beetje te smokkelen.

maar ook de powerloss protection.
Dat is de elektronica die ervoor zorgt dat alle writes die bevestigd zijn door de drive uiteindelijk ook echt op stabiele storage komen. Al die SSD's hebben diverse volatile buffers (zoals DRAM) waarin zich nog data bevind. Als er een reset of powerloss plaatsvind mag die data niet verloren gaan. Drives die dit hebben kan je herkennen aan een supercap of een hele rij gewone condensatoren op de pcb. Er zijn bijna geen consumenten drives die dit hebben. Alleen de intel 320 en de MX200 sata's en de intel 750 NVME komen zo snel in mij op.
Hierna zijn het alleen de echte enterprise SSD's zoals de intel DC serie die dit allemaal goed voorelkaar hebben. Er zijn ook andere enterprise SSD's maar die zijn niet te vinden in de pricewatch.

Laatste belangrijke aspect van een SLOG device is de hoeveelheid dat die het ding voor zijn kiezen krijgt. En dat kan behoorlijk zijn. Dat is endurance of TBW of DWPD, hoeveel kan je minimaal schrijven voordat het ding stuk gaat volgens de fabrikant. Dit is bij consumenten SSD's veel lager dan bij enterprise SSD's.

Zelf heb ik een Samsung SM863a gekozen als SLOG en die is goed voor 1728GB elke dat 5 jaar lang. Niet zo snel maar wel heel zuinig en voldoet aan alle bovenstaande eissen. (Dat is 3.6 DWPD)
De intel DC S3610 heb ik als dataschijven. Net zo prima alleen iets minder endurance , 3 DWPD.

Al dit endurance gedoe is prachtig maar wie schrijft er 5 jaar 24uur per dag 200mbit vol continue naar z'n storage thuis? Als je een stabiele omgeving hebt waarbij je ESXi server gewoon altijd zn werk doet dan kan je van te voren meten hoeveel je schrijft en op basis daarvan bepalen wat je nodig hebt.

[CurlyMo]

Ik ken het SLOG verhaal. De vraag welke SSD's uitermate geschikt zijn voor SLOG is een andere dan welke niet geschikt zijn voor SLOG. Over de Samsungs blijft onduidelijkheid in dit topic.

Ook zie ik in het lijsje van @|sWORDs| geen Intel DC schijven.

Ook vraag ik me af hoe de Samsungs in dit lijstje zouden terugkomen, of de Intel 600p die boven de 100.000 IOPS doen.

[tvwes]

CurlyMo schreef op woensdag 1 maart 2017 @ 20:28:
Ik ken het SLOG verhaal. De vraag welke SSD's uitermate geschikt zijn voor SLOG is een andere dan welke niet geschikt zijn voor SLOG. Over de Samsungs blijft onduidelijkheid in dit topic.

Ook zie ik in het lijsje van @|sWORDs| geen Intel DC schijven.

Ook vraag ik me af hoe de Samsungs in dit lijstje zouden terugkomen, of de Intel 600p die boven de 100.000 IOPS doen.
[afbeelding]

Ik heb zo'n 600p maar ben er helemaal niet over te spreken. Al is het NVME 1.2 het ding heeft geen extra feature. Dat het geen enterprise is moge duidelijk zijn en dat je het beter niet als SLOG moet inzetten ook. Maar ik heb het als losse scratch datastore. Natuurlijk is het allemaal snel maar de performance is zeer variabel. Regelmatig zie ik het ding volledig instorten van 100K soms wel tot 1K en het duurt een tijd voor het weer uit z'n powersave mode is. Ander prijskaartje dan de intel 750 of DC serie dat dan weer wel.

[tvwes]

CurlyMo schreef op woensdag 1 maart 2017 @ 19:15:
[...]

code:

slog    sync    nfs
1       X           1m56.264s
1                   1m30.579s   SLOG not being used
0       X           23m6.864s
0                   1m30.605s
2*      X           2m7.834s
2       X           2m3.119s

1       X       X   2m4.550s
1               X               SLOG not being used
0       X       X
0               X   1m46.335s
2*      X       X   2m8.498s
2       X       X   2m2.767s
4k      x       x   2m17.670s

*Mirrored

- SLOG, additional SSD's used as ZFS log device. Either zero, 1 or 2 (in mirror or striped).
- Sync, are ZFS synced writes enabled.
- NFS, is the unpacking done through a NFS share or directly on the drive themselves.

Leuk en geheel verwacht. Met welke hardware (drives vooral ) en in welke (zfs) configuratie had je dit getest?
Hoe waren die twee SLOG's geconfigureerd? En wat is die 4K meting onderaan?

Laatste idee (als alles werkt):
1. ASMedia uit de mini-pcie halen.
2. Een mini-pcie naar pcie adapter kopen.
3. 2x M.2 naar pcie kaarten kopen en 2x M.2 SSD kopen en in passthrough zetten naar NAS.
4. Overige 2 SSD's ander doel voor vinden.
5. Hopen dat ik de datastore op USB krijg en overige USB plannen kan uitwerken.

6. Als laatste moet de ASMedia naar de m-sata poort onder het moederbord voor mirrored offsite backup voor familielid bij mij.

1. Dat kan.
2. Zo'n kabeltje met aan het einde een PCIe x1 connector? Dat kan, probeer eentje te nemen met een extra voeding (zo'n 3.5 floppy connector) Dit ivm de grote energie behoefte van NVME.
3. Dat kan ook.
4. Je kan goed out-of -the box denken toch? Zie beneden voor een suggestie
5. Daar heb ik mijn mening al over gegeven.
6. Dat gaat NIET werken. Al is het fysiek het zelfde type connector. Er komt aan de onderkant alleen maar een enkel sata kanaal door. Je kan dus niet je ASmedia daar plaatsen. Wel het zoveelste adaptertje om een gewone sata poort ervan te maken.

De M.2 SSD's gebruiken als FreeBSD install, datastore, SLOG en L2ARC.

Daar zou ik nog even over nadenken. Deze config is niet bepaald best-practice. Ik ga ervan uit dat je het combineert met harddisken zoals ik. Dan is het te begrijpen. Je SLOG maakt dan zeker veel verschil. Maar combineer niet je SLOG en je DATA op hetzelfde device. Je maakt het alleen maar onnodig ingewikkeld. In combinatie met harddisken is het te begrijpen maar nog steeds niet ideaal (een SLOG delen met andere functies) En die L2ARC is leuk voor speciale gevallen maar voor thuis is het vaak zonde van je storage. Ik zie nu met arc_summary.pl zo'n 40% echte daadwerkelijk hits uit mijn ram ARC van 6GB komen. En die vm's werken echt prima. Een losse sata l2arc is te overwegen, maar je beperkte ruimte op je NVME's zou ik alleen voor data gebruiken.

Maar dat is mijn mening en jij kan allerlei voor jouw goede redenen hebben (die ik niet ken) waarom je zoiets wel zou willen.

[...]


Dan blijft de vraag wat te doen met Samsung's en SLOG?

Bijvoorbeeld inzetten als L2ARC

[|sWORDs|]

tvwes schreef op woensdag 1 maart 2017 @ 20:36:
[...]

Ik heb zo'n 600p maar ben er helemaal niet over te spreken. Al is het NVME 1.2 het ding heeft geen extra feature. Dat het geen enterprise is moge duidelijk zijn en dat je het beter niet als SLOG moet inzetten ook. Maar ik heb het als losse scratch datastore. Natuurlijk is het allemaal snel maar de performance is zeer variabel. Regelmatig zie ik het ding volledig instorten van 100K soms wel tot 1K en het duurt een tijd voor het weer uit z'n powersave mode is. Ander prijskaartje dan de intel 750 of DC serie dat dan weer wel.

Dat zie je in de reviews ook, garbage collection springt er meteen in en na de burst zakt hij vrij ver in.



De 750 heeft een super controller, maar zoals we in onze PM sessie zagen heeft Intel de extra functies er niet in zitten (maar zitten deze wel in de P3700?).

code:

/opt/intel/isdct/isdct create -namespace -intelssd 0 size =  204800

- Intel SSD 750 Series CVCQ51300038400CGN -

Status : Device does not support this command set.

Mogelijk zijn de Optanes ideale SLOG disks, maar hebben deze caps? Een P4800X als SLOG gebruiken lijkt me dan weer een flinke verspilling.

Ook vraag ik me af of de 843T niet best aardige SLOG disks zouden zijn, maar hebben die het probleem wat @FireDrunk aankaartte ook?

[ Voor 3% gewijzigd door |sWORDs| op 01-03-2017 20:54 ]

[tvwes]

|sWORDs| schreef op woensdag 1 maart 2017 @ 15:16:
[...]

Ik denk dat wel een aardige inschatting te maken is welke drive het meest geschikt is:

Drive (Vendor/Model)	QD1 Sustained (IOPS)	Latency (ms)	Price (euro per GB)
Intel 600p	14310	0.25	0.32
Crucial MX300	15462	0.5	0.27
Samsung 850 Pro	21114	0.28	0.48
Samsung 950 Pro	25779	0.24	0.73
Samsung 850 EVO	26725	0.28	0.33
Samsung 960 EVO	53376	0.18	0.47
Intel 750	58894	0.16	0.83
Samsung 960 Pro	59032	0.17	0.66

De enige vraag is hoe zwaar je de prijs, IOPS en ms laat wegen. Als ik alles even zwaar weeg kom ik op:

Drive	Score
Crucial MX300	114533
Samsung 950 Pro	147140
Samsung 850 Pro	157098
Intel 600p	178875
Samsung 850 EVO	289232
Intel 750	443479
Samsung 960 Pro	526132
Samsung 960 EVO	630922

Overall: 960 EVO
Onder de 200 euro: 850 EVO

Maar dit is niet eerlijk vergelijken. Je kan niet zomaar zo'n ranking maken, het is misleidend als er nog andere zaken verschillen dan alleen de IOPS. En zeker bij een SLOG, vind ik, moet er bepaalde features in zitten en anders valt de drive gewoon af hoe snel het ook is.
Alleen de intel 750 heeft powerloss protection en doet echt een sync als daarom gevraagd wordt. De rest is een andere klasse, misschien snel, misschien goedkoop maar zeker niet allemaal even betrouwbaar.
Ik zal zo'n mx300 bestellen en vergelijken met de 600p. Dat is een leuke test. Twee instappers met dezelfde iops alleen heeft de een de helft aan latency.

[|sWORDs|]

tvwes schreef op woensdag 1 maart 2017 @ 20:48:
[...]

Maar dit is niet eerlijk vergelijken. Je kan niet zomaar zo'n ranking maken, het is misleidend als er nog andere zaken verschillen dan alleen de IOPS. En zeker bij een SLOG, vind ik, moet er bepaalde features in zitten en anders valt de drive gewoon af hoe snel het ook is.
Alleen de intel 750 heeft powerloss protection en doet echt een sync als daarom gevraagd wordt. De rest is een andere klasse, misschien snel, misschien goedkoop maar zeker niet allemaal even betrouwbaar.
Ik zal zo'n mx300 bestellen en vergelijken met de 600p. Dat is een leuke test. Twee instappers met dezelfde iops alleen heeft de een de helft aan latency.

Ook niet te vergelijken, de burst snelheid van de 600p is aanzienlijk hoger, dan zou je dus eerst een paar minuten vol moeten schrijven en dan direct de benchmark starten. Misleidend zou ik het niet noemen, aan de hand van de eigenschappen in de eerste lijst moet een redelijke vergelijking te maken zijn, zeker als we van twee van de schijven de prestaties als SLOG kunnen vinden.

|sWORDs| schreef op woensdag 1 maart 2017 @ 10:19:
[...]
4K write popular 400-525GB SSD's:

Drive (Vendor/Model)	QD1 Burst (IOPS)	QD32 Burst (IOPS)	Burst (m)	Half Burst (m)	QD32 Sustained (IOPS)	Latency (ms)	Price (euro per GB)
Intel 600p	47875	114828	5	1	14310	0.025	0.32
Crucial MX300	17448	83780	5	1	15462	0.050	0.27
Samsung 950 Pro	49225	103016	3	2	25779	0.024	0.73
Samsung 850 EVO	26725	91567	0.5	0.25	30106	0.028	0.33
Samsung 850 Pro	21114	93147	2	1	44365	0.028	0.48
Samsung 960 EVO	57925	318638	5	4	53376	0.018	0.47
Samsung 960 Pro	59032	302691	3	2	107161	0.017	0.66
Intel 750	58894	168903	>30	>30	168422	0.016	0.83

Waarbij de Intel 750 wel een burst heeft, echter is dit pas zichtbaar bij een QD van 64 of hoger en meerdere threads (dan 261000 burst).

Ik vind het jammer dat ik eigenlijk geen schijven heb die ik redelijk naast de 750's kan zetten om een leuke test te maken. Heb je een goed idee qua schijf configuratie met de lijst ik gepost heb?

|sWORDs| schreef op woensdag 1 maart 2017 @ 16:10:
[...]

4x Toshiba 4TB 7200RPM consumer grade
2x Samsung 843T 480GB
3x Intel 750 400GB
3x Samsung 950 512GB
1x Intel 750 1.2TB
1x Sandisk X400 512GB
1x Toshiba 4TB 7200rpm "enterprise grade"

[ Voor 63% gewijzigd door |sWORDs| op 01-03-2017 21:01 ]

[tvwes]

|sWORDs| schreef op woensdag 1 maart 2017 @ 20:48:
[...]

Dat zie je in de reviews ook, garbage collection springt er meteen in en na de burst zakt hij vrij ver in. De 750 heeft een super controller, maar zoals we in onze PM sessie zagen heeft Intel de extra functies er niet in zitten (maar zitten deze wel in de P3700?).

code:

/opt/intel/isdct/isdct create -namespace -intelssd 0 size =  204800

- Intel SSD 750 Series CVCQ51300038400CGN -

Status : Device does not support this command set.

Ja maar mijn verzoek om die functies zijn zulke speciale gevallen dat de 750 nog steeds als simpele SLOG heel goed voldoet.

Mogelijk zijn de Optanes ideale SLOG disks, maar hebben deze caps? Een P4800X als SLOG gebruiken lijkt me dan weer een flinke verspilling.

We weten de prijs nog niet. En spectaculair veel sneller dan de huidige zijn ze ook niet. Maar wel een hele grote endurance als ik het zo snel even las. Daarnaast zaten er ook nog wat andere leuke zaken in als variabele sector size etc. Prima SLOG lijkt me.

Ook vraag ik me af of de 843T niet best aardige SLOG disks zouden zijn, maar hebben die het probleem wat @FireDrunk aankaartte ook?

De 843T is ook qua specs een beetje vergelijkbaar met die SM863a van mij. Al is die 843T nog wat ouder. Volgens mij liegen ze niet, ik ben ze in diverse oem systemen tegengekomen. Allebij niet de snelste SLOG's maar wel betrouwbaar, constante performance en gaan lang mee.

[|sWORDs|]

tvwes schreef op woensdag 1 maart 2017 @ 21:05:
[...]

We weten de prijs nog niet. En spectaculair veel sneller dan de huidige zijn ze ook niet. Maar wel een hele grote endurance als ik het zo snel even las. Daarnaast zaten er ook nog wat andere leuke zaken in als variabele sector size etc. Prima SLOG lijkt me.

[...]

Bij de Optane zal de vraag zijn hoe sustained de IOPS zijn. Maar 120K 4K write IOPS op een 32GB drive is best indrukwekkend, net als 0.01ms read/write latency.
Bij de P4800X zal de prijs (gokje > 4 euro per GB) doorslaggevend gaan zijn, echter 500K 4K write IOPS write en 0.01ms read/write latency vind ik best wat, daarnaast zou het op lagere queuedepths een stuk beter moeten zijn. Maar het zijn inderdaad nog niet de n machten van 10 verbetering waar Intel het oorspronkelijk over had.

CurlyMo schreef op woensdag 1 maart 2017 @ 20:28:
Ook zie ik in het lijsje van @|sWORDs| geen Intel DC schijven.

Als ik al betrouwbare en vergelijkbare reviews zou kunnen vinden dan is het nog appels met peren, een 80GB DC S3700 of een 400GB Intel 750. Er is al zoveel verschil, ik wilde de groottes in dezelfde orde houden.
Een 200GB S3700 op QD32 doet zo'n 50K burst en 37K sustained.
4K write popular 400-525GB SSD's:

Drive (Vendor/Model)	QD1 Burst (IOPS)	QD32 Burst (IOPS)	Burst (m)	Half Burst (m)	QD32 Sustained (IOPS)	Latency (ms)	Price (euro per GB)
Intel DC S3500 480GB	18171	62979	38	37	43231	?	0.72
Intel DC S3700 800GB	19666	59998	30	28	47124	?	1.02

Maar deze drives hebben niet hun steady state na een half uur, ze blijven doorzakken tot 12K na zes uur. Maar thuis ga je natuurlijk nooit zes uur lang alleen maar schrijven.

[ Voor 44% gewijzigd door |sWORDs| op 01-03-2017 21:48 ]

[Blankinho]

Ik ben me de afgelopen tijd aan het inlezen voor de aanschaf van een energiezuinige ESX server. Nu zie ik hier redelijk veel langskomen waar ik me verder in kan verdiepen maar ik kom buiten de configuraties en wat jullie nu op deze servers draaien.

Ik ben me aan het oriënteren met de volgende requirements waarbij productie (24/7 aanstaat en lab puur ter studie/testen aan zal staan);

- Energiezuinig
- Formaat (meterkast)
- Instapmodel dus niet al te duur maar wel voldoende capaciteit voor komende 3 jaar
- ESXI
- Productie VM’s:
o Ubiquiti Controller (max 2gb)
o Xpenology VM (max 4gb)
o Download VM (max 4gb)
o PFSense
- Lab VM’s
o Bluecoat (4gb)
o F5 (minimaal 6gb)
o Splunk
o Iets met beveiligingscamera’s

Nu werk ik al jaren in de IT maar ben ik de laatste jaren buiten wat Server ESX zaken op het werk vooral bezig met netwerk/security en zit ik dus totaal niet meer in de MOBO / CPU's.
Als ik met bovenstaande "eisen" werk dan twijfel ik tussen een "medium" server (I3 processor) en een "mini" (Pentium G4xxx processor)...

Ik maak me geen zorgen om de inrichting maar ik heb te weinig recente ervaring met zelfbouw hardware dat ik twijfel wat voor mij nu fit for future hardware is om de komende jaren wat functies/rollen op te kunnen hosten.

Iemand wat tips en/of ervaringen die gedeeld kunnen worden? Ik heb in mijn wenslijst een aantal configuraties staan

[CurlyMo]

Dus concluderend is het verstandiger om Intel DC's te nemen om daarmee de MX100 te vervangen. Wanneer het niet anders kan, de MX100 gebruiken voor datastorage voor ESXi. Wanneer ik die USB werkend krijg, de DC's in passthrough zetten en een deel gebruiken voor SLOG, een deel voor de FreeBSD ZFS VM, en een deel voor de datastorage van de andere VM's. De daadwerkelijke data komt dan op de HDD's te staan in een RAIDZ2 (4x).

L2ARC laten zitten.

[tvwes]

Blankinho schreef op woensdag 1 maart 2017 @ 21:25:
Ik ben me de afgelopen tijd aan het inlezen voor de aanschaf van een energiezuinige ESX server. Nu zie ik hier redelijk veel langskomen waar ik me verder in kan verdiepen maar ik kom buiten de configuraties en wat jullie nu op deze servers draaien.

Ik ben me aan het oriënteren met de volgende requirements waarbij productie (24/7 aanstaat en lab puur ter studie/testen aan zal staan);

- Energiezuinig
- Formaat (meterkast)
- Instapmodel dus niet al te duur maar wel voldoende capaciteit voor komende 3 jaar
- ESXI
- Productie VM’s:
o Ubiquiti Controller (max 2gb)
o Xpenology VM (max 4gb)
o Download VM (max 4gb)
o PFSense
- Lab VM’s
o Bluecoat (4gb)
o F5 (minimaal 6gb)
o Splunk
o Iets met beveiligingscamera’s

Nu werk ik al jaren in de IT maar ben ik de laatste jaren buiten wat Server ESX zaken op het werk vooral bezig met netwerk/security en zit ik dus totaal niet meer in de MOBO / CPU's.
Als ik met bovenstaande "eisen" werk dan twijfel ik tussen een "medium" server (I3 processor) en een "mini" (Pentium G4xxx processor)...

Ik maak me geen zorgen om de inrichting maar ik heb te weinig recente ervaring met zelfbouw hardware dat ik twijfel wat voor mij nu fit for future hardware is om de komende jaren wat functies/rollen op te kunnen hosten.

Iemand wat tips en/of ervaringen die gedeeld kunnen worden? Ik heb in mijn wenslijst een aantal configuraties staan

Ik heb een paar pagina's terug geadviseerd tegen plaatsing in de meterkast. Als er wat gebeurt door oververhitting ben jij aansprakelijk. Als je dat ding op zolder, van mij part bij de CV ketel, zet en er ebeurt wat is er niets aan de hand. Ik kan de schade van een afgebrande woning niet even zelf aftikken.
Ook heb ik een paar pagina's terug, volgens mij op 412, een uitgebreide post over een prima zuinige server gedaan. Houd alleen rekening met het feit dat ik overal enterprise schijven heb gebruikt en dat je daar ook andere voor kan nemen. Aangaande je vraag over de CPU, ik zou niet onder de i3 gaan voor een ESXi server. Zeker niet met al jouw vm's. Mijn config is zeker niet over de top maar bied voldoende uitbreidings en upgrade mogelijkheden om er minstens 5 jaar plezier van te hebben.

Hele belangrijke vraag is: wie levert de storage voor je ESXi machine? Een externe NAS? Een interne VM NAS? ESXi zelf?

[|sWORDs|]

tvwes schreef op woensdag 1 maart 2017 @ 21:39:
[...]
Aangaande je vraag over de CPU, ik zou niet onder de i3 gaan voor een ESXi server.
[...]

De Pentium G46xx serie (of G4560) is eigenlijk een i3, het is een dual core met HT: http://ark.intel.com/compare/97460,90729

[ Voor 58% gewijzigd door |sWORDs| op 02-03-2017 12:20 ]

[FireDrunk]

CurlyMo schreef op woensdag 1 maart 2017 @ 21:34:
Dus concluderend is het verstandiger om Intel DC's te nemen om daarmee de MX100 te vervangen. Wanneer het niet anders kan, de MX100 gebruiken voor datastorage voor ESXi. Wanneer ik die USB werkend krijg, de DC's in passthrough zetten en een deel gebruiken voor SLOG, een deel voor de FreeBSD ZFS VM, en een deel voor de datastorage van de andere VM's. De daadwerkelijke data komt dan op de HDD's te staan in een RAIDZ2 (4x).

L2ARC laten zitten.

Ik zou persoonlijk SLOG en de VM's waar de SLOG voor is niet mixen. Dan moet de SSD steeds switchen tussen SLOG writes en de daadwerkelijke writes voor de VM.

SLOG/ZIL is geen cache, het is een Intent LOG, daar gaan de writes naar toe die blocking zijn voor het reorderen van andere async writes. Er wordt nooit van gelezen en de writes zijn altijd QD1 Sync. Als je SLOG dus druk is, gaat dat sterke performance drops opleveren in je VM performance. Hoe drukker je VM's hoe drukker je SLOG, hoe meer last je er van hebt. Ze heffen elkaar een beetje op.

Mijn eerlijke mening, jij bent erg goed in scripting, dus waarom niet gewoon goed snapshots + (offsite) backups maken, en gewoon SYNC uitzetten? De kans op powerloss is vrij klein, en met goede backups kan je best wat hebben.

Bedenk ook dat als je sync writes uit zet, je ZFS pool nog steeds niet zomaar stuk is, enige risico is dat je een paar seconden data kan verliezen.

EDIT: bijna vergeten,

|sWORDs| schreef op woensdag 1 maart 2017 @ 20:48:
[...]
Ook vraag ik me af of de 843T niet best aardige SLOG disks zouden zijn, maar hebben die het probleem wat @FireDrunk aankaartte ook?

Helemaal correct, die 843T heeft wel powerloss protection,waardoor aggresief in DRAM cachen niet zo erg is. Dat maakt ze geschikt voor SLOG

[ Voor 12% gewijzigd door FireDrunk op 02-03-2017 08:16 ]

[CurlyMo]

FireDrunk schreef op donderdag 2 maart 2017 @ 07:51:
[...]


Ik zou persoonlijk SLOG en de VM's waar de SLOG voor is niet mixen. Dan moet de SSD steeds switchen tussen SLOG writes en de daadwerkelijke writes voor de VM.

SLOG/ZIL is geen cache, het is een Intent LOG, daar gaan de writes naar toe die blocking zijn voor het reorderen van andere async writes. Er wordt nooit van gelezen en de writes zijn altijd QD1 Sync. Als je SLOG dus druk is, gaat dat sterke performance drops opleveren in je VM performance. Hoe drukker je VM's hoe drukker je SLOG, hoe meer last je er van hebt. Ze heffen elkaar een beetje op.

Dit vind ik een goed verhaal. Zo had ik het inderdaad nog niet bekeken. Eigenlijk is er dus vrijwel nooit een goede reden om een SLOG SSD te combineren met andere doelen? Terwijl er juist vaak is gezegd dat je prima SLOG en je ZFS root op dezelfde SSD kan draaien zonder daadwerkelijk prestatie verlies. Dat strookt niet echt met dit verhaal.

Mijn eerlijke mening, jij bent erg goed in scripting, dus waarom niet gewoon goed snapshots + (offsite) backups maken, en gewoon SYNC uitzetten? De kans op powerloss is vrij klein, en met goede backups kan je best wat hebben.

Bedenk ook dat als je sync writes uit zet, je ZFS pool nog steeds niet zomaar stuk is, enige risico is dat je een paar seconden data kan verliezen.

Concluderend is het het beste om:
1. 1 of 2 Intel DC's te kopen voor SLOG (in passthrough).
Mits mijn USB verhaal werkt:
2.1 Mijn MX100 gebruiken voor ZFS-on-root en VM's via NFS (in passthrough). Sync kan uitgezet worden, maar ik draai dan toch al van SSD's.
Als mijn USB verhaal niet werkt:
2.2 Eén van mijn MX100 gebruiken voor puur alleen ESXi datastorage en niks anders en backups regelen.

[|sWORDs|]

FireDrunk schreef op donderdag 2 maart 2017 @ 07:51:
[...]

Helemaal correct, die 843T heeft wel powerloss protection,waardoor aggresief in DRAM cachen niet zo erg is. Dat maakt ze geschikt voor SLOG

Dus met mijn disks:
Data - RAIDZ van de 4x 4TB's met een mirror van twee 843T's als SLOG en 400GB Intel 750 als L2ARC
VM's - 1.2TB Intel 750 met mirror van twee 400GB Intel 750's als SLOG
Backups - 4TB "enterprise grade"

Voelt wel een beetje als een verspilling van de 400GB 750's, misschien de 3x 512GB Samsung 950's als data disks met een enkele 750 als SLOG en geen L2ARC? En de de 4x4TB met een mirror van twee 843T's als SLOG voor backups?

[ Voor 12% gewijzigd door |sWORDs| op 02-03-2017 09:24 ]

[sjnelle]

tvwes schreef op woensdag 1 maart 2017 @ 21:39:
[...]


Ook heb ik een paar pagina's terug, volgens mij op 412, een uitgebreide post over een prima zuinige server gedaan. Houd alleen rekening met het feit dat ik overal enterprise schijven heb gebruikt en dat je daar ook andere voor kan nemen.

Vraag tvwes wat draai jij voor machines hierop lijkt me een interessante configuratie.

[CurlyMo]

Het is overigens niet makkelijk om QD1 write benchmarks te vinden.

[|sWORDs|]

CurlyMo schreef op donderdag 2 maart 2017 @ 09:36:
Het is overigens niet makkelijk om QD1 write benchmarks te vinden.

Hardware.info heeft ze van alle geteste disks op de "Iometer: 4k random read/write" pagina, vierde plaatje van boven (3e tabel).







Maar dit is wel burst, eigenlijk moet je ook nog op de "Continutests - Steady State Performance" pagina kijken.



Waarde maal 256 (1024 Megabyte -> Kilobyte / 4 Size) en de laagste van de twee nemen. De waarde kan nooit hoger dan de burst zijn en de hogere queuedepth gaat niets opleveren als je maar met een QD van 1 schrijft. Voorbeeld de 256GB Samsung SM951 (NVMe), burst QD1 = 50791 IOPS, maar continu QD32 is 102,4MB/s of te wel 26214 IOPS. Ook moet je eigenlijk kijken hoelang de burst is, als dit langer is dan je ooit zult schrijven dan maakt de steady state weer niet uit, etc. Maar de consumer drives (Hier reken ik de 750 niet onder, die heeft een enterprise controller) storten allemaal na 1-7 minuten in en komen ook niet echt meer terug tot de schijf een paar minuten rust gehad heeft.



Hebben we het nou niet over een SLOG schijf, maar over een lokale datastore dan is de database simulatie test het best om naar te kijken (komt het meest overeen met IO pattern van meerdere VM's):

[ Voor 121% gewijzigd door |sWORDs| op 02-03-2017 10:48 ]

[Blankinho]

tvwes schreef op woensdag 1 maart 2017 @ 21:39:
[...]

Ik heb een paar pagina's terug geadviseerd tegen plaatsing in de meterkast. Als er wat gebeurt door oververhitting ben jij aansprakelijk. Als je dat ding op zolder, van mij part bij de CV ketel, zet en er ebeurt wat is er niets aan de hand. Ik kan de schade van een afgebrande woning niet even zelf aftikken.
Ook heb ik een paar pagina's terug, volgens mij op 412, een uitgebreide post over een prima zuinige server gedaan. Houd alleen rekening met het feit dat ik overal enterprise schijven heb gebruikt en dat je daar ook andere voor kan nemen. Aangaande je vraag over de CPU, ik zou niet onder de i3 gaan voor een ESXi server. Zeker niet met al jouw vm's. Mijn config is zeker niet over de top maar bied voldoende uitbreidings en upgrade mogelijkheden om er minstens 5 jaar plezier van te hebben.

Hele belangrijke vraag is: wie levert de storage voor je ESXi machine? Een externe NAS? Een interne VM NAS? ESXi zelf?

Vwb Server wel/niet in de meterkast daar heb je zeker een punt en ondanks dat ik dit weet altijd goed om mijn keuze hierin te heroverwegen. Ga ik dus zeker ook doen want je hebt een goed punt op het gebied van oververhitting en mogelijke schade tov verzekeraar.

Je post op pagina 412 is behoorlijk uitgebreid en interessant maar hier is voor mij de keuze v.w.b. hardware nog niet duidelijker op geworden. Ik ga er de komende dagen even verder goed in verdiepen en dan mogelijk een opzet config hier posten om op te schieten. Hierin zal ik jouw input ook meenemen vanuit je post.

Voor wat betreft storage ben ik op dit moment van plan om het vanuit een lokale SSD als datastore aan te bieden. De xpenology machine zal hierin zeker niets in gaan betekenen als ik op een later moment iets met freenas of anders wil gaan doen dan zal ik me daarin gaan verdiepen. Voor mij is het nu vooral belangrijk om weer een nieuwe ESX server binnen mijn netwerk te hangen en van daaruit weer mee te kunnen spelen.

Heb naast mijn werk een deeltijd HBO-studie gedaan dus buiten werkspielerij en HBO had ik geen tijd meer voor knutselen. Nu is die HBO-studie klaar en hiermee dus ook weer de tijd voor spielerij..

[tvwes]

Blankinho schreef op donderdag 2 maart 2017 @ 10:52:
[...]


Vwb Server wel/niet in de meterkast daar heb je zeker een punt en ondanks dat ik dit weet altijd goed om mijn keuze hierin te heroverwegen. Ga ik dus zeker ook doen want je hebt een goed punt op het gebied van oververhitting en mogelijke schade tov verzekeraar.

Je moet dat risico zelf inschatten. Misschien heb je wel een hele grote en koele meterkast en kan je daar zo'n apparaat in kwijt. Maar het mag niet en ik kan bij schade dat niet zo even betalen. Dus (zeker omdat het voor de hobby is) zou ik het ergens anders zetten.

Je post op pagina 412 is behoorlijk uitgebreid en interessant maar hier is voor mij de keuze v.w.b. hardware nog niet duidelijker op geworden. Ik ga er de komende dagen even verder goed in verdiepen en dan mogelijk een opzet config hier posten om op te schieten. Hierin zal ik jouw input ook meenemen vanuit je post.

Als je wilt experimenteren zou ik niet zo snel naar mijn systeem kijken. Die server van mij is een productie machine waar ik in principe de komende paar jaar niet meer aan ga zitten rommelen. Dat ding moet betrouwbaar zijn werk doen en dat kost helaas wat. Als je gewoon lekker wat wilt romelen en het allemaal niet uitmaakt of het ding een paar dagen stuk is. Dan zou ik veel goedkopere onderdelen er in zetten.

Voor wat betreft storage ben ik op dit moment van plan om het vanuit een lokale SSD als datastore aan te bieden. De xpenology machine zal hierin zeker niets in gaan betekenen als ik op een later moment iets met freenas of anders wil gaan doen dan zal ik me daarin gaan verdiepen. Voor mij is het nu vooral belangrijk om weer een nieuwe ESX server binnen mijn netwerk te hangen en van daaruit weer mee te kunnen spelen.

Als je alleen lokale storage hebt, weet je dat als er een disk kapot gaat je je data kwijt bent? Dat hoeft geen probleem te zijn. Als je een werkende backup hebt is er al een hoop schade beperkt. Maar voor een email server betekent het dat je bijna zeker email kwijt bent. Weer een risico wat jij voor jouw situatie moet inschatten. Lokaal is wel heel snel.

Heb naast mijn werk een deeltijd HBO-studie gedaan dus buiten werkspielerij en HBO had ik geen tijd meer voor knutselen. Nu is die HBO-studie klaar en hiermee dus ook weer de tijd voor spielerij..

Gefeliciteerd met het afronden je opleiding.

[FireDrunk]

CurlyMo schreef op donderdag 2 maart 2017 @ 09:09:
[...]

Dit vind ik een goed verhaal. Zo had ik het inderdaad nog niet bekeken. Eigenlijk is er dus vrijwel nooit een goede reden om een SLOG SSD te combineren met andere doelen?
Terwijl er juist vaak is gezegd dat je prima SLOG en je ZFS root op dezelfde SSD kan draaien zonder daadwerkelijk prestatie verlies. Dat strookt niet echt met dit verhaal.

Let goed op het nuance verschil wat ik maakte. Je kan je SLOG beter niet op de SSD(s) zetten waar je ook de VM's op zet die die SLOG gebruiken. Een 'simpel' root FS voor je Host OS, wat geen barst uitvoert is een heel ander verhaal. Een FreeBSD installatie die alleen maar wat NFS/iSCSI configs bevat en verder je data uit ZFS leest, kan prima op dezelfde SSD's.

L2ARC en SLOG combineren kan in theorie ook, als je specifiek bepaalde filesystems uitsluit L2ARC (dat kan je tunen). Dus stel je deelt de L2ARC en SLOG op 1 grote array waar meerdere filesystems op staan, dan kan het zijn dat je je VM array uitsluit voor L2ARC maar wel SLOG laat gebruiken. Andersom kan je je Media volume uitsluiten voor SLOG (sync = disabled) maar wel lol laten hebben van L2ARC (voor bijvoorbeeld indexering van Kodi, ik noem maar een zijspoor).

Als je dan ook zorgt dat je geen gigantische Media operaties doet icm drukke VM belasting, zou je ze in theorie in 'goede' cohesie naast elkaar kunnen draaien. Maar ik zou het afraden voor iemand die niet precies weet wat hij/zij doet.

[...]
Concluderend is het het beste om:
1. 1 of 2 Intel DC's te kopen voor SLOG (in passthrough).
Mits mijn USB verhaal werkt:
2.1 Mijn MX100 gebruiken voor ZFS-on-root en VM's via NFS (in passthrough). Sync kan uitgezet worden, maar ik draai dan toch al van SSD's.
Als mijn USB verhaal niet werkt:
2.2 Eén van mijn MX100 gebruiken voor puur alleen ESXi datastorage en niks anders en backups regelen.

Klinkt prima!

[iMars]

CurlyMo schreef op woensdag 1 maart 2017 @ 19:15:
[...]

code:

slog    sync    nfs
1       X           1m56.264s
1                   1m30.579s   SLOG not being used
0       X           23m6.864s
0                   1m30.605s
2*      X           2m7.834s
2       X           2m3.119s

1       X       X   2m4.550s
1               X               SLOG not being used
0       X       X
0               X   1m46.335s
2*      X       X   2m8.498s
2       X       X   2m2.767s
4k      x       x   2m17.670s

*Mirrored

- SLOG, additional SSD's used as ZFS log device. Either zero, 1 or 2 (in mirror or striped).
- Sync, are ZFS synced writes enabled.
- NFS, is the unpacking done through a NFS share or directly on the drive themselves.

Laatste idee (als alles werkt):
1. ASMedia uit de mini-pcie halen.
2. Een mini-pcie naar pcie adapter kopen.
3. 2x M.2 naar pcie kaarten kopen en 2x M.2 SSD kopen en in passthrough zetten naar NAS.
4. Overige 2 SSD's ander doel voor vinden.
5. Hopen dat ik de datastore op USB krijg en overige USB plannen kan uitwerken.

6. Als laatste moet de ASMedia naar de m-sata poort onder het moederbord voor mirrored offsite backup voor familielid bij mij.

De M.2 SSD's gebruiken als FreeBSD install, datastore, SLOG en L2ARC.

Node 304 heeft 2 pci sloten, maar waarvan de mini-itx formfactor er maar één gebruikt. Ik zou dus prima een tweede kunnen creëren via een mini-pcie naar pcie kaart.

[afbeelding]

Als dat volgens niet tot een master mini-itx build leidt weet ik het ook niet meer


[...]


Dan blijft de vraag wat te doen met Samsung's en SLOG?

Vraagje over deze behuizing; Ik zie dat er standaard 6 disks in passen. Kan er met een beetje aanpaswerk of herindeling misschien ook 8x 3,5" in? Ik ben opzoek naar een mooi, compact en betaalbare behuizing waarin 8x 3,5" + 1 2,5" ssd kan.

Als ik naar de foto's kijk pricewatch: Fractal Design Node 304 Zwart lijkt het er wel op dat het kan.

[Snippo]

Ik heb een snelle vraag die hier denk ik het beste beantwoord kan worden:
Gaat een i5-7500 CPU werken in een Supermicro X11SSL-F?

Officieel wordt het blijkbaar niet ondersteund (alleen i3), maar ik denk zelf dat dit komt omdat de i3 serie de enige serie is die onder een TDP van 80W blijft. De i5-7500 heeft een TDP van 65W, dus dat zou geen probleem moeten zijn.

Ik heb hier beide nu liggen namelijk, en hoorde pas achteraf dat eigenlijk alleen de i3 serie wordt ondersteund. Nu blijkt er echter ook een oud BIOS op te staan waardoor het uberhaupt nog niet werkt, maar voordat ik een OOB licentie aanschaf zou het wel fijn zijn om te weten of het uiteindelijk wel gaat werken. Op internet krijg ik verder weinig gevonden, waarschijnlijk omdat de meeste mensen beter opletten op wat ze aanschaffen .

[FireDrunk]

@|sWORDs| Ik ben er nog niet helemaal uit of die aligned Random Write benchmarks een goed beeld geven. (en dan hebben we het dus vooral over de benchmarks van Hardware.info).

Ik kan namelijk niet goed inschatten wat in dit opzicht aligned bij hun betekend. In theorie zou een QD1 write nooit aligned en/of unaligned kunnen zijn, het is er immers maar 1, dus of je nou 1 write doet op LBA sector 0, en dan op sector 3 miljoen, het is toch QD1, dus je wacht op het resultaat van write 1.

Doe je QD2 of meer is het wel weer interresant, omdat de writes dan in de zelfde Page (Kleine LBA space) of zelfde Plane (Middelgrote LBA space) of zelfde "array" (gigantische LBA space) (Bij Crucial heet het RAIN) kunnen vallen.

Dat beinvloed de test nogal.

|sWORDs| schreef op donderdag 2 maart 2017 @ 09:19:
[...]

Dus met mijn disks:
Data - RAIDZ van de 4x 4TB's met een mirror van twee 843T's als SLOG en 400GB Intel 750 als L2ARC
VM's - 1.2TB Intel 750 met mirror van twee 400GB Intel 750's als SLOG
Backups - 4TB "enterprise grade"

Voelt wel een beetje als een verspilling van de 400GB 750's, misschien de 3x 512GB Samsung 950's als data disks met een enkele 750 als SLOG en geen L2ARC? En de de 4x4TB met een mirror van twee 843T's als SLOG voor backups?

400GB 750's inzetten als SLOG is inderdaad doodzonde, de vuistregel is geloof ik 8 keer je maximale transaction group size. En dan praat je in extreme gevallen (1GB/s op je array doen, maal 8 seconden) dus over 8GB aan slog... En zelfs dat haal je eigenlijk nooit.

Voorbeeldje: een ZFS SLOG optimized ssd:
pricewatch: HGST ZeusRAM 8GB

Snippo schreef op donderdag 2 maart 2017 @ 11:30:
Ik heb een snelle vraag die hier denk ik het beste beantwoord kan worden:
Gaat een i5-7500 CPU werken in een Supermicro X11SSL-F?

Officieel wordt het blijkbaar niet ondersteund (alleen i3), maar ik denk zelf dat dit komt omdat de i3 serie de enige serie is die onder een TDP van 80W blijft. De i5-7500 heeft een TDP van 65W, dus dat zou geen probleem moeten zijn.

Ik heb hier beide nu liggen namelijk, en hoorde pas achteraf dat eigenlijk alleen de i3 serie wordt ondersteund. Nu blijkt er echter ook een oud BIOS op te staan waardoor het uberhaupt nog niet werkt, maar voordat ik een OOB licentie aanschaf zou het wel fijn zijn om te weten of het uiteindelijk wel gaat werken. Op internet krijg ik verder weinig gevonden, waarschijnlijk omdat de meeste mensen beter opletten op wat ze aanschaffen .

Die wordt niet ondersteund omdat het bord gemaakt is voor ECC (vanwege C232 chipset) en de i5 doet geen ECC.

Als je non ECC geheugen gebruikt, zou het technisch kunnen werken, maar daar is het bord, en het chipset niet voor bedoeld.

[ Voor 63% gewijzigd door FireDrunk op 02-03-2017 11:49 ]

[Snippo]

@FireDrunk
Ik gebruik geen ECC geheugen en ik begrijp dat dat niet gebruikelijk is, maar het Supermicro moederbord was één van de weinige die aan mijn eisen voldeed (genoeg SATA poorten, twee NIC's).
Daarnaast leek me het wel een mooie instap in de Supermicro producten. Ik heb er nog weinig kaas van gegeten, maar het lijkt me wel interessant om te leren.

Ik heb dus in de pricewatch gezocht naar een moederbord met een 1151 socket die aan die eisen voldeed, maar daar staat dus niet bij dat alleen i3's worden ondersteund .

[|sWORDs|]

Snippo schreef op donderdag 2 maart 2017 @ 11:55:
@FireDrunk
Ik gebruik geen ECC geheugen en ik begrijp dat dat niet gebruikelijk is, maar het Supermicro moederbord was één van de weinige die aan mijn eisen voldeed (genoeg SATA poorten, twee NIC's).
Daarnaast leek me het wel een mooie instap in de Supermicro producten. Ik heb er nog weinig kaas van gegeten, maar het lijkt me wel interessant om te leren.

Ik heb dus in de pricewatch gezocht naar een moederbord met een 1151 socket die aan die eisen voldeed, maar daar staat dus niet bij dat alleen i3's worden ondersteund .

Sommige Celerons/Pentiums hebben ook ECC, en als je een i5/i7 wil is er meestal wel een matching Xeon E3 te vinden.
Of een i5/i7 werkt is de vraag, andersom werkt het niet meer sinds Skylake.

[ Voor 4% gewijzigd door |sWORDs| op 02-03-2017 12:09 ]

[CurlyMo]

iMars schreef op donderdag 2 maart 2017 @ 11:17:
[...]

Vraagje over deze behuizing; Ik zie dat er standaard 6 disks in passen. Kan er met een beetje aanpaswerk of herindeling misschien ook 8x 3,5" in? Ik ben opzoek naar een mooi, compact en betaalbare behuizing waarin 8x 3,5" + 1 2,5" ssd kan.

Als ik naar de foto's kijk pricewatch: Fractal Design Node 304 Zwart lijkt het er wel op dat het kan.

Nee, je kan naar de Node 804 kijken.

FireDrunk schreef op donderdag 2 maart 2017 @ 11:15:
[...]
Je kan je SLOG beter niet op de SSD(s) zetten waar je ook de VM's op zet die die SLOG gebruiken.

Terechte aanvulling. Die had ik gemist. Al mijn data staat op RAIDZ2 4x HDD. Mijn OS op SSD's. Het OS zelf doet vrijwel nooit iets betekenisvol. Alles gebeurt direct op mijn RAIDZ2 NFS share. Dan kan je dus wel prima je OS en je SLOG op dezelfde SSD zetten.

[ Voor 28% gewijzigd door CurlyMo op 02-03-2017 12:11 ]

[Snippo]

|sWORDs| schreef op donderdag 2 maart 2017 @ 12:02:
[...]

Sommige Celerons/Pentiums hebben ook ECC, en als je een i5/i7 wil is er meestal wel een matching Xeon E3 te vinden.
Of een i5/i7 werkt is de vraag, andersom werkt het niet meer sinds Skylake.

Ik heb niet het idee dat ik ECC nodig heb dus vandaar de keuze voor een i5.
Maar of dat nu een goed idee is of niet, mijn vraag is dus of het gaat werken .

Ik was ook niet per se op zoek naar een Supermicro/server moederbord, maar deze kwam 'op mijn pad'. Daarnaast heb ik het moederbord en CPU al, dus een andere keuze maken gaat ook niet meer.

[ Voor 6% gewijzigd door Snippo op 02-03-2017 12:16 ]

[|sWORDs|]

Snippo schreef op donderdag 2 maart 2017 @ 12:15:
[...]

Ik heb niet het idee dat ik ECC nodig heb dus vandaar de keuze voor een i5.
Maar of dat nu een goed idee is of niet, mijn vraag is dus of het gaat werken .

Ik was ook niet per se op zoek naar een Supermicro/server moederbord, maar deze kwam 'op mijn pad'. Daarnaast heb ik het moederbord en CPU al, dus een andere keuze maken gaat ook niet meer.

Mocht het echt niet werken zou je de i5 in V&A kunnen zetten en voor een E3 kunnen gaan, of WKoA indien dat (nog) kan.

[Snippo]

Helaas, het was een zakelijke aankoop dus dat gaat helaas niet. Ik ga de gok maar nemen en een OOB licentie aanschaffen om het BIOS te updaten en kijken of het werkt.

Ik zie overigens nu pas dat er ook Xeon's zijn met Intel graphics. Dat was voor mij ook een vereiste dus heb eigenlijk niet eens naar Xeon's gekeken (naast het feit dat ik geen reden zag om uberhaupt voor Xeon te gaan).

[FireDrunk]

Xeon's zijn ook eigenlijk niets anders dan veredelde (veel te dure) i5's met ECC support.

[tvwes]

FireDrunk schreef op donderdag 2 maart 2017 @ 11:46:
@|sWORDs| Ik ben er nog niet helemaal uit of die aligned Random Write benchmarks een goed beeld geven. (en dan hebben we het dus vooral over de benchmarks van Hardware.info).

Ik kan namelijk niet goed inschatten wat in dit opzicht aligned bij hun betekend. In theorie zou een QD1 write nooit aligned en/of unaligned kunnen zijn, het is er immers maar 1, dus of je nou 1 write doet op LBA sector 0, en dan op sector 3 miljoen, het is toch QD1, dus je wacht op het resultaat van write 1.

Doe je QD2 of meer is het wel weer interresant, omdat de writes dan in de zelfde Page (Kleine LBA space) of zelfde Plane (Middelgrote LBA space) of zelfde "array" (gigantische LBA space) (Bij Crucial heet het RAIN) kunnen vallen.

Dat beinvloed de test nogal.


[...]

Ik weet het niet zeker, maar bedoelen zij met aligned niet op modulo 8 LBA bij 512 bytes/sector. Dat je mooi 4K pages schrijft op modulo 8 LBA addressen?

400GB 750's inzetten als SLOG is inderdaad doodzonde, de vuistregel is geloof ik 8 keer je maximale transaction group size. En dan praat je in extreme gevallen (1GB/s op je array doen, maal 8 seconden) dus over 8GB aan slog... En zelfs dat haal je eigenlijk nooit.

Dat is te kort door de bocht. Je hebt helemaal gelijk dat je maar heel weinig nodig hebt voor een SLOG. Maar de reden dat overal SLOGs van honderen GB's of zelfs een TB worden geplaatst is de endurance van je NAND chips. Je kan je cellen maar zoveel keer wissen en dan is het gedaan met je SSD. Omdat je alleen maar schrijft kan het best snel gaan met de levensduur van de SSD. Een kleine 32GB drive is dan ook in de kortste keren versleten.
Bij een SLOG moet je naar hele andere eigenschappen kijken van een device. De bruto opslag capaciteit en de netto opslag behoefte zijn twee zaken die volkomen niet relevant zijn bij een SLOG. Alles meer dan 8GB (net als je ZeusRAM voorbeeld) is al goed. De endurance, niet liegen, powerloss protection en QoS zijn de zaken die echt tellen, los van de performance.

Voorbeeldje: een ZFS SLOG optimized ssd:
pricewatch: HGST ZeusRAM 8GB

De ZeusRAM is geen goede vergelijking omdat het ding onverslijtbaar DRAM gebruikt. En alleen in nood de inhoud naar flash schrijft.

[|sWORDs|]

FireDrunk schreef op donderdag 2 maart 2017 @ 12:39:
Xeon's zijn ook eigenlijk niets anders dan veredelde (veel te dure) i5's met ECC support.

Dat is niet helemaal eerlijk:
Een 1225 v5 is een i5 6500 met iets hogere clocks en ECC support, prijs is +10%.
Een 1245 v5 is een i7 6700 met iets hogere clocks (behalve turbo die is iets lager) en ECC support, prijs is -6%.

Intel heeft niet voor niets Xeon's op desktop borden uitgeschakeld, ze waren best interessant.

[FireDrunk]

|sWORDs| schreef op donderdag 2 maart 2017 @ 12:45:
[...]

Dat is niet helemaal eerlijk:
Een 1225 v5 is een i5 6500 met iets hogere clocks en ECC support, prijs is +10%.
Een 1245 v5 is een i7 6700 met iets hogere clocks (behalve turbo die is iets lager) en ECC support, prijs is -6%.

Intel heeft niet voor niets Xeon's op desktop borden uitgeschakeld, ze waren best interessant.

http://ark.intel.com/compare/88196,88173,88184,88168

Ok ok, het is niet veel te duur, maar wel duurder. Persoonlijk vind ik het hele geneuzel rondom ECC chipsets en ECC CPU's klets.

Intel moet gewoon ECC support op alle CPU's open zetten, en differentiëren met andere features.
Dat we andere/betere/duurdere chipsets nodig hebben voor dual socket systemen kan ik nog inkomen, maar nu zijn het letterlijk dezelfde wafers met wat cherry picked CPU's waar ze de ECC flag op enablen.

Dat is gewoon uitmelken van de markt..

offtopic:
Het schijnt dat AMD Ryzen ECC slikt

/rant

[ Voor 3% gewijzigd door FireDrunk op 02-03-2017 12:58 ]

[FireDrunk]

tvwes schreef op donderdag 2 maart 2017 @ 12:43:
[...]

Ik weet het niet zeker, maar bedoelen zij met aligned niet op modulo 8 LBA bij 512 bytes/sector. Dat je mooi 4K pages schrijft op modulo 8 LBA addressen?

Uh, die snap ik niet, waarom zou het uitmaken of je schrijft naar een LBA modulo 8 sector? Als je 4k schrijft wat over de bounds van de page loopt bedoel je? Dus 2k in de ene page, en 2k in een volgende?

Dat zou wel erg uit maken voor de benchmark, ik ga ervanuit dat de latency voor het schrijven van 1 page substantieel lager is dan die van het schrijven van 2 pages.

[...]

Dat is te kort door de bocht. Je hebt helemaal gelijk dat je maar heel weinig nodig hebt voor een SLOG. Maar de reden dat overal SLOGs van honderen GB's of zelfs een TB worden geplaatst is de endurance van je NAND chips. Je kan je cellen maar zoveel keer wissen en dan is het gedaan met je SSD. Omdat je alleen maar schrijft kan het best snel gaan met de levensduur van de SSD. Een kleine 32GB drive is dan ook in de kortste keren versleten.
Bij een SLOG moet je naar hele andere eigenschappen kijken van een device. De bruto opslag capaciteit en de netto opslag behoefte zijn twee zaken die volkomen niet relevant zijn bij een SLOG. Alles meer dan 8GB (net als je ZeusRAM voorbeeld) is al goed. De endurance, niet liegen, powerloss protection en QoS zijn de zaken die echt tellen, los van de performance.

Mwoh, ik ben daar eerlijk gezegd wel een beetje overheen gegroeid. NAND slijt, dat is zeker. Maar het slijt ook weer niet ZO hard dat je meteen je SSD om zeep helpt. SLOG is ook stevig qua writes, maar het is ook weer niet alsof je terrabytes aan data er op gaat zetten. Het is QD1T1 he, niet QD256T16... Dat maakt nogal uit

Je hebt wel gelijk dat je nooit een consumenten SSD van 8GB zou moeten gebruiken, dat zal zeker stuk gaan. Maar ik ben er van overtuigd dat zo'n 80GB Intel DC Series S3xxx series SSD het jaren zo niet decennia uithoudt als SLOG.

[...]

De ZeusRAM is geen goede vergelijking omdat het ding onverslijtbaar DRAM gebruikt. En alleen in nood de inhoud naar flash schrijft.

Correct, het was ook meer een vergelijking qua absolute grootte, niet qua kwaliteit van de SSD.

[CurlyMo]

Wat ik dan toch opvallend vind aan de hardware.info lijst is het volgende (QD1 random writes):
Intel DC S3500 480GB: 18.171 IOps
Intel DC S3700 800GB: 19.666 IOps
Intel 750 400GB PCIe: 58.894 IOps
Intel 600p 512GB: 47.875 IOps
Crucial MX300 275GB: 17.443 IOps
Crucial MX100 128GB: 38.971 IOps (dat lijkt me niet te kloppen)
Samsung 960 EVO 512GB: 57.925 IOps

Dan zou de MX300 helemaal niet zo'n verkeerde keus zijn ten opzichte van de DC S3500, terwijl die laatste toch als SLOG SSD bekend staat. Ik snap het allemaal niet meer zo Ook de 600p lijkt een aantrekkelijke keuze, maar daar was @tvwes dan weer geen fan van.

[|sWORDs|]

FireDrunk schreef op donderdag 2 maart 2017 @ 12:51:
[...]


http://ark.intel.com/compare/88196,88173,88184,88168

Ok ok, het is niet veel te duur, maar wel duurder. Persoonlijk vind ik het hele geneuzel rondom ECC chipsets en ECC CPU's klets.

Intel moet gewoon ECC support op alle CPU's open zetten, en differentiëren met andere features.
Dat we andere/betere/duurdere chipsets nodig hebben voor dual socket systemen kan ik nog inkomen, maar nu zijn het letterlijk dezelfde wafers met wat cherry picked CPU's waar ze de ECC flag op enablen.

Dat is gewoon uitmelken van de markt..

offtopic:
Het schijnt dat AMD Ryzen ECC slikt

/rant

Eigenlijk is het niet duurder, de speed bump van de 1225 zou normaal gesproken binnen een CPU lijn meer dan 10% kosten. De 1245 is zelfs goedkoper!
Wat ik schandalig vind is de prijzen die je betaald voor 100MHz meer binnen een CPU lijn.

Toch kun je als je goed shopt wel voor erg weinig geld klaar zijn:
G4560 dual core met HT en ECC op 3.5GHz: 59 euro.

De eerst volgende echte grote stap zou de 1225 v5 zijn, echter alleen qua threads, single threaded performance vrijwel identiek. Volgende stap de 1245 v5, dan de 1541, dan de E5, etc.

CPU	single	multi	cores	threads	base	turbo	cache	ECC	Generatie	TDP	prijs
Celeron G3900	1866	3550	2	2	2.8	2.8	3	Ja	Skylake	51	38
Pentium G4560	2008	5084	2	4	3.5	3.5	3	Ja	Kaby Lake	54	59
i3 6100	2104	5456	2	4	3.7	3.7	3	Ja	Skylake	51	114
i3 7100	2227	5958	2	4	3.9	3.9	3	Nee	Kaby Lake	51	119
Xeon E3-1225 v5	2031	7661	4	4	3.3	3.7	8	Ja	Skylake	80	244
Xeon E3-1245 v5	2164	10322	4	8	3.5	3.9	8	Ja	Skylake	80	322
Xeon D-1541	1499	11333	8	16	2.1	2.7	12	Ja	Broadwell	45	636
Xeon E5-2620 v4	1556	11369	8	16	2.1	3.0	20	Ja	Broadwell	85	459

Alhoewel ik wel vind dat HT in deze testen veel te zwaar weegt. Ik zou single * cores * Amdahl's law (+10% met HT) verwachten en dan zelfs nog ietsje lager vanwege de single core turbo. Dan krijg je zoiets:

CPU	single	multi	prijs	single/euro	multi/euro
Celeron G3900	1866	3639	38	49	96
Pentium G4560	2008	4307	59	34	73
i3 6100	2104	4513	114	18	40
i3 7100	2227	4777	119	19	40
Xeon E3-1225 v5	2031	6948	244	8	28
Xeon E3-1245 v5	2164	8106	322	7	25
Xeon D-1541	1499	9580	636	2	15
Xeon E5-2620 v4	1556	11297	459	3	25

offtopic:
AMD Ryzen: Nog twee uurtjes en dan gaan we zien hoe goed ze wel of niet zijn!

[ Voor 37% gewijzigd door |sWORDs| op 02-03-2017 17:18 ]

[FireDrunk]

CurlyMo schreef op donderdag 2 maart 2017 @ 13:11:
Wat ik dan toch opvallend vind aan de hardware.info lijst is het volgende (QD1 random writes):
Intel DC S3500 480GB: 18.171 IOps
Intel DC S3700 800GB: 19.666 IOps
Intel 750 400GB PCIe: 58.894 IOps
Intel 600p 512GB: 47.875 IOps
Crucial MX300 275GB: 17.443 IOps
Crucial MX100 128GB: 38.971 IOps (dat lijkt me niet te kloppen)
Samsung 960 EVO 512GB: 57.925 IOps

Dan zou de MX300 helemaal niet zo'n verkeerde keus zijn ten opzichte van de DC S3500, terwijl die laatste toch als SLOG SSD bekend staat. Ik snap het allemaal niet meer zo Ook de 600p lijkt een aantrekkelijke keuze, maar daar was @tvwes dan weer geen fan van.

Ik wist wel dat de MX300 geen hoogvlieger was qua pure benches, maar vooral bij mixed workloads beter zou zijn. Wat veel fabrikanten doen is optimaliseren voor benchmarks, dus: Puur Sequentieel Read/Write, Puur random Read/Write en wat spelen met de Queue depth.

Wat Crucial (heeeeeel goed) in mijn ogen doet, is kijken naar de optimale mixed workload. Daardoor komen ze iets lager in benchmarks terecht, maar is de real-world benchmark vaak (in verhouding) hoog.

De MX300 is overigens niet perse sneller dan de MX100 hoor, hij is alleen nieuwer. De controller is iets sneller, maar het geheugen is op een kleiner procede gemaakt, en dus (vaak) iets trager.

Hier zie je de mixed workload verschillen:
http://www.anandtech.com/...microns-3d-nand-arrives/8
En hier zie je dat de steady state van een Crucial SSD wel wat mager is.
https://nl.hardware.info/...-steady-state-performance

Daar ga je het verschil zien met de Intel SSD's (exact wat @|sWORDs| dus zei, je moet SLOG's vergelijk met steady state performance benchmarks)

[tvwes]

FireDrunk schreef op donderdag 2 maart 2017 @ 12:56:
[...]

Uh, die snap ik niet, waarom zou het uitmaken of je schrijft naar een LBA modulo 8 sector? Als je 4k schrijft wat over de bounds van de page loopt bedoel je? Dus 2k in de ene page, en 2k in een volgende?

Omdat je je dan in je SSD 2 pages moet updaten ipv 1 als je aligned zou schrijven. (Dit alles uitgaande van 4K pages en 512bytes/(sector of LBA addres) )
Hier nog een publicatie van Intel over de probleem
Het speelt niet alleen bij SSD's, maar ook bij een lun op een SAN kan dit een duidelijk verschil uitmaken.

Dat zou wel erg uit maken voor de benchmark, ik ga ervanuit dat de latency voor het schrijven van 1 page substantieel lager is dan die van het schrijven van 2 pages.
[...]

Bij misalignment moet je twee pages updaten ipv 1 daarom maakt het echt wel wat uit.

Mwoh, ik ben daar eerlijk gezegd wel een beetje overheen gegroeid. NAND slijt, dat is zeker. Maar het slijt ook weer niet ZO hard dat je meteen je SSD om zeep helpt. SLOG is ook stevig qua writes, maar het is ook weer niet alsof je terrabytes aan data er op gaat zetten. Het is QD1T1 he, niet QD256T16... Dat maakt nogal uit

Je hebt wel gelijk dat je nooit een consumenten SSD van 8GB zou moeten gebruiken, dat zal zeker stuk gaan. Maar ik ben er van overtuigd dat zo'n 80GB Intel DC Series S3xxx series SSD het jaren zo niet decennia uithoudt als SLOG.

Zo goed als iedere SSD uit de DC serie zal bijna niemand hier weten te verslijten binnen een paar jaar tijdens gebruik als SLOG. Dat ben ik met je eens, maar een SSD uit de DC serie heeft wel een veel hogere endurance (en voldoet wel aan alle SLOG eisen) dan een consumenten SSD van vergelijkbare capaciteit (die ook nog eens niet voldoen aan de SLOG eisen)

Ik weet niet helemaal of je dit zo bedoelde maar ik ben het met je eens dat gebruikers (hier en ook zakelijk) hun gebruik volledig overschatten. Bijna iedereen gaat ervan uit dat ze TB per jaar wegschrijven (door hun VM's om het nog een klein beetje ontopic te houden) Maar de praktijk is vaak dat het reuze meevalt en dat je inderdaad, zoals als jij terecht aangeeft, veel te veel endurance hebt gekocht.
Ik heb hele goede analytics en historische data. Ik kan precies zien wat mijn daadwerkelijke storage behoeften zijn en op basis daarvan een device selecteren. Wat dus niet over-qualified en daarmee te duur is.

[FireDrunk]

Volgens mij zijn we het wel met elkaar eens. Vandaar ook vaak mijn advies om Enterprise SSD's te kopen voor ZIL/SLOG boven Samsung SSD's.

Nou zijn Samsung SSD's wel weer super goed qua endurance. Kijk maar eens naar de idiote tests die o.a. hardware.info heeft gedaan om de write endurance te testen. Dat is hilarisch, een 840Pro gaf pas de geest bij 2PB ofzo?

[|sWORDs|]

FireDrunk schreef op donderdag 2 maart 2017 @ 14:34:
Volgens mij zijn we het wel met elkaar eens. Vandaar ook vaak mijn advies om Enterprise SSD's te kopen voor ZIL/SLOG boven Samsung SSD's.

Nou zijn Samsung SSD's wel weer super goed qua endurance. Kijk maar eens naar de idiote tests die o.a. hardware.info heeft gedaan om de write endurance te testen. Dat is hilarisch, een 840Pro gaf pas de geest bij 2PB ofzo?

Ik denk niet dat je dit zo generiek mag stellen. De 843 en 840 deden het goed, maar ik zie super veel 950's die als cache drive gebruikt zijn en nu stuk zijn. (Zouden ook temperatuur problemen kunnen zijn.)
Intel P3700/750 zie ik helemaal niet met problemen, maar daar zal de sample rate een stuk lager van zijn.

[ Voor 7% gewijzigd door |sWORDs| op 02-03-2017 14:37 ]

[FireDrunk]

Waar zie je 950's stuk? ben wel beniewd. Ik lees wel wat over (onboard) NVMe drives die te heet worden vanwege slechte koeling/airflow. (heb zelf ook zitten denken aan wat extra koelblokjes, maar achteraf niet gedaan). Ik heb zelf een 950 Pro in mijn desktop.

[|sWORDs|]

FireDrunk schreef op donderdag 2 maart 2017 @ 14:43:
Waar zie je 950's stuk? ben wel beniewd. Ik lees wel wat over (onboard) NVMe drives die te heet worden vanwege slechte koeling/airflow. (heb zelf ook zitten denken aan wat extra koelblokjes, maar achteraf niet gedaan). Ik heb zelf een 950 Pro in mijn desktop.

Heel veel collega's en partners hebben labs, een aantal met 950's en SM951's als cache drive hebben al één of meerdere defecte drives. Een paar daarvan stappen nu over op P3700/750's of 960's.

Edit: Ik zou me in je laptop niet al te druk maken. Ik heb het over gebruik als cache drive. Zelf gebruikte ik ze als capacity drives, nog geen last gehad.

[ Voor 13% gewijzigd door |sWORDs| op 02-03-2017 14:54 ]

[FireDrunk]

Desktop != Laptop

Maar het blijft dus als een paal boven water staan, gebruik enterprise SSD's alleen voor basis VM hosting, Laptop en Desktop gebruik, en geen speciale use-cases als high performance, caching, L2ARC, ZIL/SLOG.

[|sWORDs|]

FireDrunk schreef op donderdag 2 maart 2017 @ 14:57:
Desktop != Laptop

Maar het blijft dus als een paal boven water staan, gebruik enterprise SSD's alleen voor basis VM hosting, Laptop en Desktop gebruik, en geen speciale use-cases als high performance, caching, L2ARC, ZIL/SLOG.

Ik was ook zo druk op refresh te drukken voor Ryzen reviews.

En zoals ik zei klokslag 15:00:
reviews: Ryzen, AM4 en de Zen-architectuur
https://nl.hardware.info/...r-concurrentie-voor-intel

[ Voor 24% gewijzigd door |sWORDs| op 02-03-2017 15:01 ]

[sjnelle]

Zie door bomen bod niet meer.
Ben op zoek naar energie zuinig systeem met meer als 32 gb ivm enkele Windows vms

DC
Sql
Xenapp testen
En enkele Linux doosjes oa home assist

Ik zag op pagina 412 en mooie setup van tvwes maar wellicht beetje overkill.

En nuc is beperkt met de 32gb

[|sWORDs|]

sjnelle schreef op donderdag 2 maart 2017 @ 17:33:
Zie door bomen bod niet meer.
Ben op zoek naar energie zuinig systeem met meer als 32 gb ivm enkele Windows vms

DC
Sql
Xenapp testen
En enkele Linux doosjes oa home assist

Ik zag op pagina 412 en mooie setup van tvwes maar wellicht beetje overkill.

En nuc is beperkt met de 32gb

|sWORDs| schreef op donderdag 2 maart 2017 @ 13:16:
[...]

CPU	single	multi	prijs	single/euro	multi/euro
Celeron G3900	1866	3639	38	49	96
Pentium G4560	2008	4307	59	34	73
i3 6100	2104	4513	114	18	40
i3 7100	2227	4777	119	19	40
Xeon E3-1225 v5	2031	6948	244	8	28
Xeon E3-1245 v5	2164	8106	322	7	25
Xeon D-1541	1499	9580	636	2	15
Xeon E5-2620 v4	1556	11297	459	3	25

Als je dat overkill vind dan pak je toch een van de systemen uit de start post van het andere topic met een G4560 en 64GB?

[ Voor 6% gewijzigd door |sWORDs| op 02-03-2017 17:46 ]

[sjnelle]

Welk andere topic bedoel je precies?

[|sWORDs|]

sjnelle schreef op donderdag 2 maart 2017 @ 17:50:
Welk andere topic bedoel je precies?

Het grote ESXi/vSphere Topic

Zoiets (al zou ik met dit soort bedragen toch naar een Xeon E3-1240 v5 kijken):

#	Product	Prijs	Subtotaal
1	Intel Pentium G4560 Boxed	€ 59,-	€ 59,-
1	Supermicro X11SSM-F (Retail Pack)	€ 225,20	€ 225,20
1	Supermicro 731I-300	€ 105,45	€ 105,45
4	Transcend TS2GLH72V1B	€ 127,-	€ 508,-
1	Intel 750 SSD Half Height PCIe 3.0 x4 400GB	€ 331,50	€ 331,50
Bekijk collectie Importeer producten		Totaal	€ 1.229,15

Of als je meer wil besparen geen server bord, geen Intel 750 (SATA of goedkopere NVMe) en geen ECC:

#	Product	Prijs	Subtotaal
1	Intel Pentium G4560 Boxed	€ 59,-	€ 59,-
1	Gigabyte GA-B150M-D3H	€ 81,95	€ 81,95
1	Antec ISK600M	€ 66,76	€ 66,76
4	Crucial CT2K8G4DFD8213	€ 99,99	€ 399,96
1	Seasonic G-series 360 watt	€ 63,95	€ 63,95
1	Crucial MX300 2,5" 525GB	€ 141,95	€ 141,95
Bekijk collectie Importeer producten		Totaal	€ 813,57

Edit: Xenapp? Zit je dan wel in het goede topic -> Het grote zuinige server topic - deel 2

[ Voor 45% gewijzigd door |sWORDs| op 02-03-2017 18:09 ]

[sjnelle]

Edit: Xenapp? Zit je dan wel in het goede topic -> Het grote zuinige server topic - deel 2

Xenapp is voor test en leer doeleinden nooit veel gebruikers dus virtueel test machine is prima.

Hmm dan is de setup van @tvwes misschien ook niet zo verkeerd.

Storage komt van mijn qnap voor files en vm Storage kan ssd worden.

[ Voor 10% gewijzigd door sjnelle op 02-03-2017 19:26 ]

[sjnelle]

Big iemand leuk voorbeeld van een xeon e3 1240 v5 configuratie

Of toch een G4560

[|sWORDs|]

sjnelle schreef op donderdag 2 maart 2017 @ 19:25:
[...]


Xenapp is voor test en leer doeleinden nooit veel gebruikers dus virtueel test machine is prima.

Hmm dan is de setup van @tvwes misschien ook niet zo verkeerd.

Storage komt van mijn qnap voor files en vm Storage kan ssd worden.

Aah, XenApp op vSphere dus.

sjnelle schreef op vrijdag 3 maart 2017 @ 12:34:
Big iemand leuk voorbeeld van een xeon e3 1240 v5 configuratie

Of toch een G4560

1240 v5 zou gewoon de bovenste config met een andere CPU zijn (+252,50). Voor een schatting van de performance kun je bij de 1245 v5 in het lijstje hierboven kijken (1240 = 1245 - GPU). Voor ESXi zou een 1240 eigenlijk een dubbele G4560 zijn met 33% meer cache.

[ Voor 54% gewijzigd door |sWORDs| op 03-03-2017 12:48 ]