Onderwerp: Ervaring met Nexenta

Wij hebben onze Nexenta omgeving inmiddels draaien (nog niet in productie), maar daar ook gekozen voor de STEC SSD's voor de ZIL, puur vanwege performance redenen.

Wido, semi off-topic,... wat is het toekomstpad van Nexenta nu Opensolaris weggevallen is? Hebben ze daar info over?

Wonko, Nexenta is een van de drijvende krachten achter de Illumos http://blogs.nexenta.org/blog/2010/0...to-do-with-it/

Wido, en anderen:

Wij hebben in ons Nexenta cluster allemaal webservers (10 TB aan files) welke gelezen en geschreven worden, normaal website gebruik, en dit beginnen we te merken in de performance. Wij hebben op dit moment een 160 GB SSD als cache maar willen er dus SSD's bij plaatsen. Nu komt bovenstaande leverancier met de Toshiba suggestie vanwege de 90K IOPS, echter ik ben zelf van mening dat 100 GB aan 90K IOPS teveel van het goede is omdat het maar 100 GB is, als alternatief voor dat bedrag zouden we 3-4 SSD's van 160 GB aan 20K IOPS ieder (Intel's) kunnen plaatsen: meer cache maar minder IOPS.

Wat is jullie mening.. meer cache (GB's) met minder IOPS of weinig cache (GB's) met meer IOPS?

Hoe veel RAM heb je er in zitten bij die 10TB?

Je hebt dus problemen met je random IOps? Volgens mij kan je met dtrace zien hoe veel data er in de L2ARC bij zou moeten, wat echter niet lukt.

Wellicht dat je deze vraag ook bij Nexenta kan neerleggen, daar zitten wel een paar goede ZFS experts.

Mijn gok is toch gewoon een extra 160GB SSD plaatsen, of meerdere, bijna elke SSD is snel genoeg om random read IOps te regelen.

Oorspronkelijk geplaatst door Wido

Hoe veel RAM heb je er in zitten bij die 10TB?

Je hebt dus problemen met je random IOps? Volgens mij kan je met dtrace zien hoe veel data er in de L2ARC bij zou moeten, wat echter niet lukt.

Wellicht dat je deze vraag ook bij Nexenta kan neerleggen, daar zitten wel een paar goede ZFS experts.

Mijn gok is toch gewoon een extra 160GB SSD plaatsen, of meerdere, bijna elke SSD is snel genoeg om random read IOps te regelen.

Probeer anders deze vraag even bij Andy Bennet neer te leggen. Heb je nog wel genoeg vrije slots voor een aantal disks?

Cache is cache, snelheid is belangrijk, niet zozeer de totale capaciteit... In een ZFS is de cache normaal enkel de ZIL, en wordt er dus geen permanente data op gezet.

Ik zou gaan voor IOPS. Bij random write is het IOPS die je wil, niet diskspace.

De vraag is/word inderdaad ook bij Nexenta zelf neergelegd, aantal vrije sloten is geen probleem. Ik zal nog eens dieper in het ZIL verhaal duiken, dat het geen permanente data is, is logisch, maar of je 100 GB snel beschikbaar hebt of 600 GB lijkt mij persoonlijk wel verschil uit te maken, of dit dan tegen 20K of 90K IOPS is lijkt me beide meer dan zat.. hoeveel % van die 90K word nou daadwerkelijk gebruikt?

Ik ga nog eens even googlen, was sowieso benieuwd hoe jullie dit zagen!

Het gaat om lezen, right? Dan heb je niet te maken met de ZIL, maar met je ARC (RAM) en L2ARC.

Heb je al wel een paar SSD's als ZIL? Zo ja, welke? Wij gebruiken daar de STEC ZeusRAM van 8GB, die leveren zo'n 80k write IOps, dat is voor je ZIL wel zo fijn.

Kijk even in je pool overzicht, daar staat bij ons:

mirror groups: 10, caches: 6, logs: 2, spares: 2, devices: 30

We hebben dus 6 caches (L2ARC, 6x160GB) en twee logs (ZIL, 2x8GB).

Als je dus veel lees IOps hebt en daar performance ondervind, dan kan je of je ARC (RAM) uitbreiden of je L2ARC (SSD's).

Zijn het echter allemaal random IOps, dan gaat op een bepaald moment je L2ARC vergroten ook niet meer helpen, want dan zijn alles cold-hits en moet het alsnog van de disk afkomen. Maar wij zien dat ongeveer 30% van alle data ook regelmatig wordt geraadpleegd.

Gebruik je overigens compressie? Dat aanzetten kan je een flinke performance boost opleveren. Hoewel je CPU meer werk te doen heeft, hoeft er minder van de disk te worden gelezen en dat scheelt tijd.

@DutchTSE: Hoeveel RAM heb je er nu inzitten? Extra ram doet het natuurlijk ook goed als cache. En heb je dedup aan of uit staan?

Er zit nu 24 GB aan ram in, extra ram werkt uiteraard altijd goed, maar dan moet het SAN uit en dat geeft downtime. Daarom eerst de SSD's uitbereiden aangezien daar ook winst te behalen is. Wij zijn ooit begonnen met dedup ingeschakeld maar hebben dit uitgezet omdat er helemaal geen performance meer overbleef, vervolgens alle data gevmotioned zodat er nu niets 'gededupped' is.

Onze ZIL doet helemaal niets volgens de disk stats, dit schijnt een bug te zijn in de Intel firmware aldus S3S.. Verder 1x 160 GB als L2ARC en die willen we dus gaan uitbereiden. Onze settings per zvol:

Blocksize: 32K
Compression: off
Checksum: on
Deduplication: off

Ik zou sowieso compression aanzetten ljzb gebruiken, geen gzip.

Dedup heb ik ook slechte ervaringen mee. Het lijkt leuk, maar dat is het meestal niet door alle bijkomende ellende. Even wat zitten lezen over lzjb compressie en dat klinkt inderdaad dan weer wel interessant.
Ik ben verre van een Nexenta expert, maar is het niet zo dat je write cache op je initiators aan hebt staan? Want dan wordt je ZIL niet gebruikt. Dat is bij mij namelijk het geval. Verder is 24gb ook weer niet heel weinig, dus lijkt mij uitbreiding van je ssd wel logisch inderdaad.
En uit interesse, welk merk/type SSD gebruik je als L2ARC device?

Oorspronkelijk geplaatst door hrodenburg

Dedup heb ik ook slechte ervaringen mee. Het lijkt leuk, maar dat is het meestal niet door alle bijkomende ellende. Even wat zitten lezen over lzjb compressie en dat klinkt inderdaad dan weer wel interessant.
Ik ben verre van een Nexenta expert, maar is het niet zo dat je write cache op je initiators aan hebt staan? Want dan wordt je ZIL niet gebruikt. Dat is bij mij namelijk het geval. Verder is 24gb ook weer niet heel weinig, dus lijkt mij uitbreiding van je ssd wel logisch inderdaad.
En uit interesse, welk merk/type SSD gebruik je als L2ARC device?

Welke write-cache bedoel je? Standaard flushed ZFS constant naar de disks, als je daar een ZIL bij hebt, dan levert je dat veel performance op.

Daarom is een snelle ZIL bij ZFS zo belangrijk, om die cache flushes constant te kunnen verwerken.

Ik bedoel de write back cache, wat ook al eerder genoemd is in dit thread.

Oorspronkelijk geplaatst door Powermage

Nope, ik heb er geen statistieken van,
maar in onze setup zagen we in de grafieken dat de ZIL niet gebruikt werd, na wat onderzoek (je komt t ook tegen op de nexenta forums) maar een support case aangemaakt, het is een design keuze om de ZIL bij ISCSI niet te gebruiken wanneer Write Back cache aan staat op het volume, als deze uit staat word de zil gebruikt, maar bij ons was dat langzamer.