Kontrollerkort för ESXi

Jag har faktiskt använt just detta kort till en ZFS-snurra som körde openindiana. Detta iSCSI-san presenterades sen till ett par HP proliant DL165 G7 (dubbla 12core AMD) som körde ESXi och agerade host till diverse maskiner (över 20st).

Fick ut sinnesstörd prestanda från vanliga 7200-diskar. Visserligen med SSD Raid0 som skrivcache, men fort gick det!

Nu var det ett drygt år sen jag joddlade med den maskinen, men du gör ju ingen raid när du kör ZFS, använd JBOD (som kortet ska klara) och gör dina volymer så istället.

ZFS är väldigt känsligt för fel men reparerar automatiskt. Detta slöar dock ner prestandan lite, men med det kortet kommer det gå undan. Vi hade väldigt r/w-intensiva applikationer så därav en SSD-raid0 som skrivcache.

vill bara poängtera att raid0 sannerligen inte lämpar sig för skriv-cache. större risk att någon av diskarna failar och då har du förlorat det som skulle skrivas. skrivcache bör alltid vara speglad om en av diskarna skulle dö.

"Sinnesstörd prestanda" är aldrig fel. Kommer du ihåg ungefär hur den var konfad? Hur många diskar? Hade ni SSD som cache? Hur mycket prestanda fick du ut, ungefär? Vore kul att bygga något liknande hemma, med "sinnesstörd prestanda"!


Och ja, det kortet är bra. Det är ett LSI kort och de korten rekommenderas för Solaris + ZFS och antagligen även FreeBSD. LSI är "seriösa" lagringskort så kan man köpa ett sånt kort billigt, så ska man absolut göra det! Men det finns ett lowend kort som heter IBM M1015 som faktiskt använder samma LSI 2008 chipset, och de kan man köpa på Ebay för 80 USD. Men det kortet du nämner, tror jag är lite mera highend?

Kortet bör flashas till IT-mode och sen kan du göra pass-through i ESXi till OpenIndiana/Solaris/FreeBSD/etc. Då körs automatiskt JBOD mode, tror jag.

Men det är bara filen som håller på att skrivas man riskerar förlora? Finns någon rollback-funktion i nyare versioner av ZFS för att rädda volymen om skrivcachen pajar har jag för mig. Å andra sidan kan väl det vara allvarligt nog att förlora dessa filer i och för sig.

jo, sant. men meningen är ju i de flesta fall att man inte vill att en applikation ska gå ner och då är RAID0 jäkligt dumt.

Vi körde ett par OCZ i Raid0 i början men dom höll c:a 2 resp. 4 veckor. Inteldiskarna snurrade på i över ett år innan jag lämnade företaget.
Raid0 körde vi bara för att det var en testmiljö där datan inte var så viktig. Vi hade batteribackup på kontrollernkotet med 512MB ram också.


Diskarna satt i ett Lian-Li chassi där LSI-kortet satt. 8st 2TB och 2st PATAdiskar för systemet. Raid0-diskarna kördes på moderkortets raid.
Vi betalade i runda slängar 4000kr exkl. moms från Dustin, vet inte om det är dyrt eller inte, men prestandan tycker jag var värd det. Kommer inte ihåg exakt vilka skriv/läshastigheter vi låg på men över 100MB/s vågar jag nog påstå att det var
Och jag flashade kortet till IT-mode ja

Allt som finns i cachen ryker ju, har inte koll på hur mycket som köades faktiskt.

100MB/s räknas väl inte som sinnesstörd prestanda? Eller har jag fel? Jag menar, min spindle med 4 st konsumentdiskar (2TB styck) kommer ju upp i runt 200MB/s i skrivhastighet. Och det är utan ZIL eller ARC på SSD(er).

Edit: Inte för att jag vill motsäga mig dig men jag tror du kommer ihåg lite för snålt

Det här var ju massor av små I/O-intensiva diskoperationer, inte sekvensiella läsningar av ISOs

Ojoj, sorry. Såg nu vad det handlade om, my bad.

Läste någonstans att det kan vara bra att göra en ganska liten partition för ZIL. Det behövs bara tillräckligt mycket utrymme för att cacha skrivningar den tid det tar mellan två commits till de mekaniska diskarna. Nu vet jag inte hur ofta det sker commits men säg att det är var 5:e sekund och att gigabitnätverket matar på med 120 MB/s så blir det ju bara 1,2 GB utrymme som krävs. OK, ta lite extra för eventuella lokala skrivningar på servern men säg att 2 GB kan räcka ganska långt för ZIL.

Då skulle det kunna gå att förlänga livslängden även med en billig konsument-SSD genom att endast partitionera 2GB av kanske 120 GB för ZIL. Resten av utrymmet låter man vara opartitionerat vilket gör att SSD-diskens inbyggda "wear-leveling" kan utjämna slitaget över diskens minnesceller så att istället för att gå sönder efter 2 veckor så håller den i 2-3 år.

Stämmer denna teori?

Jag tror 8GB är mer lämpligt än 2GB för ZIL (dvs ZFS skrivlogg).

Du menar att man lägger ZIL på en extern 8GB disk? Eller hur menar du? Varför ska man lägga ZIL på en annan disk?

Det är ganska vanligt att lägga ZIL på ett par eller flera snabba SSD:s.

Ja alltså en SSD med snabb skrivprestanda. Sedan menar jag att om man partitionerar den till en liten del av totala storleken och lämnar resten av utrymmet oanvänt så är det en stor mängd "oanvända" minnesceller som SSD-disken kan köra intern "wear-leveling" på och på så sätt förlänga livslängden och göra det möjligt att köra billigare SSD-typer istället för enterprise diskar. Hela meningen med en "slog" är väl att det ska ligga på en separat disk.

8 GB bör räcka i uppåt en minut om man kör 1 Gbit/s nätverk. Men man kanske använder lagringen lokalt också och inte bara via nätverket. Men säg att SSD-disken har en maximal skrivprestanda på 500 MB/s då skulle 8 GB räcka för 16 sekunders kontinuerlig skrivning i maxfart. Men behövs det verkligen så mycket i praktiken? Beror väl på hur prylarna används antar jag. För en hemmaserver som används mest via 1 Gbit/s nätverk är nog 2-4 GB mer lagom storlek.

http://constantin.glez.de/blog/2011/...y-ssds-and-zfs

Här har Anandtech kollat på hur länge en SSD disk förväntas hålla. Det kanske är av intresse på detta temat.
http://www.anandtech.com/show/5518/a...-of-intel-ssds

mvh Z

Bra länkar! Den första länken förklarar att man bör ha srivcache motsvarande 10 sekunders skrivningar (2 stycken commits) och det lär ju aldrig kunna bli mer än SSD-diskens maximala skrivprestanda. Så om jag flyttar min intel 320 på 120 GB till filservern så får den en maximal skrivprestanda på 130 MB/s (enligt intels specifikation) och detta multiplicerat med 10 sekunder ger alltså 1,3 GB. Men med en intel 520 som har maximalt 520 MB/s skrivhastighet så skulle man kunna behöva upp till 5,2 GB som mest. Men är det inte komprimerbar data så blir det väl sämre hastighet på en sådan SSD.

Googlade lite:
http://hardforum.com/showthread.php?t=1577141
Hela den där tråden på HardForum är intressant.
Min slutsats är att med dagens SSD-diskar så räcker det med 2-4 GB ZIL.
Intel 320 verkar vara en bra SSD för ändmålet, den har ju superkondensator och hyfsad livslängd. För 1 Gbit/s så vill man ha minst 120 MB/s och då behöver man minst 120 GB stor intel 320 SSD för att nå den hastigheten. Den kommer att räcka länge eftersom den bara behöver 1,3 GB av utrymmet för 10 sekunders skrivcache. Enligt Anandtechs test räcker ju en stor SSD längre eftersom det blir fler minnesceller i reserv att slita på.

Kan man anta att 2 GB workload av 120 GB borde ge sisådär 15000 TB skrivning innan den dör? Med 120 MB/s kontinuerlig skrivning över gigabit-nätverk skulle den hålla i sisådär 4 år (tiden det tar att skriva 15000 TB med 120 MB/s). Nu lär man väl inte skriva så intensivt i praktiken så den räcker nog tillräckligt länge.

Normalt så ligger ju ZIL på zpoolen. Men om man lägger det separat på en SSD, så minskar fragmenteringen. Jag har funderat på att skaffa en 64-128GB SSD och partitionera den med 8GB ZIL och resten som L2ARC. Men jag vet inte om jag kommer göra så....

Vad säger ni?

Fullt möjligt, men hur prestandan blir är oklart.

Edit: Överlag så är både dedikerad ZIL och L2ARC ganska overkill för dom flesta. Vill man testa och labba så kan det väl vara skoj men jag tror inte gemene man ser någon större skillnad på prestanda.

Syftet är mest för att inte fragmentera poolen. Om man har en dedikerad disk till ZIL, så skrivs inte ZIL till zpoolen.

Så man skulle kunna använda en mekanisk disk till ZIL som alternativ och ändå tjäna prestanda på det?

Nej, en mekanisk kommer inte duga.

"The device used to host the ZIL is known as the SLOG. Ultimately, the IOPS of the SLOG are a bottleneck for the zpool: changes must first be made to the ZIL, then copied to the zpool, then committed. If the SLOG can't keep up with the zpool, the aggregate performance will decrease. If performance decreases enough, ZFS will (if I understand correctly) abandon the dedicated SLOG."

Läs mera: http://hardforum.com/showthread.php?t=1591181

Precis. SLOGen måste ha mycket lägre latens för att det ska bli snabbare. Idealet är RAM diskar, t.ex. Zeus diskar.

Men jag funderade på att minska fragmenteringen. Då funkar ju en vanlig HDD bra för det. En SSD är ju även snabbare än en HDD, så man skulle ju få snabbare och mindre fragmentering.

http://mail.opensolaris.org/pipermai...ly/052088.html

"There's no extra fragmentation, with or without slog. Because in either case, the sync write hits some dedicated and recyclable disk blocks, and then it becomes async and coalesced with all the other async writes. The layout and/or fragmentation characteristics of the permanent TXG to be written to the pool is exactly the same either way."

Ok, så det verkar som att SLOG är på bara vissa disk blocks, som är dedikerade för just det ändamålet? Bra.