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.

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.

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.

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

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?

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.

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-look-at-enterprise-perfo...

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.

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