SSD op basis van DDR Ram (Ala Gigabyte i-RAM)

[Snow_King]

Hallo,

Voor een specifiek stuk software heb ik een logdrive nodig die snel is, héél snel, echter heb ik maar ongeveer 200MB tot maximaal 1GB aan opslag nodig.

Het gaat hier om een distributed filesystem wat zijn journal hier in bij moet werken, wegschrijven moet daarom héél snel gaan. Verlies van een journal is niet gewenst, maar ivm het distributed karakter is het geen ramp.

Een Areca RAID controller heeft bijvoorbeeld een stukje RAM aan boord wat door een BBU veilig wordt gesteld, maar ik ben op zoek naar zoiets los (mooiste is als het in een 2.5" drive zit).

Gigabyte heeft enkele jaren terug de iRam gemaakt, een PCI kaart die je moet SATA kan aansluiten en waar je tot 4GB aan DDR op kon zetten, zoiets zoek ik, maar dan in een kleiner formaat (Waar bijv SO-DIMM op gaat).

Waarom geen ramdrive? Het is namelijk wel wenselijk om na een reboot de data nog te hebben, ook wil ik dmv van een batterij tot maximaal 2 uur de data kunnen bewaren mocht de stroom uitvallen.

Tegenwoordig lijkt echter alles en iedereen over te stappen op SSD's, maar die passen in dit beeld niet goed genoeg:

- MLC SSD's zijn te snel defect en schrijven te langzaam
- SLD SSD's zijn te duur voor deze toepassing (Ik heb ook maar maximaal 1GB opslag nodig)

Mooiste zou zijn:
- 2.5" format
- Plaats voor een SO-DIMM
- Kleine batterij voor backup

Iemand enig idee of zoiets uberhaupt bestaat?

[TERW_DAN]

Waar wordt het ding op aangesloten? Als dat bijv een PATAconnector is, dan kom je toch niet boven de 133MB/s uit bijv, dus hebben hele snelle RAMdrives niet zo heel veel nut.

[Snow_King]

Terw_Dan schreef op maandag 20 december 2010 @ 12:43:
Waar wordt het ding op aangesloten? Als dat bijv een PATAconnector is, dan kom je toch niet boven de 133MB/s uit bijv, dus hebben hele snelle RAMdrives niet zo heel veel nut.

Het zal S-ATA worden, die bandbreedte is voor mij prima. Het gaat om de vele random writes van zéér kleine blocksizes die gaan plaats vinden.

De Enterprise SLC SSD's komen wel goed uit de bus qua performance, maar die zijn helaas te duur (enkele honderden euro's) en ook te groot (in opslag).

Vanwege het distributed karakter heb ik er dus veel nodig.

[SMSfreakie]

het is niet mogelijk om een CF kaart ( snelste variant ) in te zetten bij toeval? (met de juiste bridgechip naar SATA er achter?

[joppybt]

Snow_King schreef op maandag 20 december 2010 @ 12:47:
[...]
Het zal S-ATA worden, die bandbreedte is voor mij prima. Het gaat om de vele random writes van zéér kleine blocksizes die gaan plaats vinden.

Eerst heb je het over een 'logdrive' en nu heb je het over random writes. Alle logdrives (logfiles) die ik ken schrijven sequentieel aan het einde van het bestand.

Kun je ook iets specifieker zijn wat jij 'héél snel' noemt. Zonder concrete getallen kan natuurlijk niemand je adviseren.

Tenslotte: is verlies van de laatste paar seconde mogelijk wel acceptabel? Dan kan het advies ook anders worden.

[Snow_King]

joppybt schreef op maandag 20 december 2010 @ 13:50:
[...]

Eerst heb je het over een 'logdrive' en nu heb je het over random writes. Alle logdrives (logfiles) die ik ken schrijven sequentieel aan het einde van het bestand.

Kun je ook iets specifieker zijn wat jij 'héél snel' noemt. Zonder concrete getallen kan natuurlijk niemand je adviseren.

Tenslotte: is verlies van de laatste paar seconde mogelijk wel acceptabel? Dan kan het advies ook anders worden.

Ik heb het eigenlijk meer over een journal van een distributed filesystem, in dit geval Ceph.

Hier hebben de OSD's (Object Store Daemons) een journal waar zij hun laatste consistente staat in bij houden. Normaliter mag je journal bij een FS niet verloren gaan, anders heb je een groot probleem, maar vanwege het distributed karakter kan het in bepaalde situaties wel acceptabel zijn.

Om de schrijf acties naar de OSD zo snel mogelijk te houden wil je een héél snel journal hebben. De grootte van deze writes kunnen echter varieëren.

Doordat writes altijd naar meerdere OSD's gaan is het acceptabel dat een bepaalde OSD zijn journal kwijt raakt, een andere heeft namelijk die write ook ontvangen.

Ik heb nu wat getest met tmpfs journals en dat werkt zoals ik het zou willen snel genoeg. Een Intel X25-M SSD houdt het werkt bijvoorbeeld niet bij.

In die orde zoek ik het dus, een zo laag mogelijke write-latency, waar het niet om de honderden MB's/sec gaat. De machines zelf hebben maar een Gbit uplink, die moeten ze zonder problemen kunnen bijhouden, maar dan wel op een kleine blocksize.

Mijn excuses als ik mezelf niet helemaal duidelijk heb gemaakt, hoop dat het nu wel het geval is

[ Voor 7% gewijzigd door Snow_King op 20-12-2010 13:58 ]

[maratropa]

Maar een OCZ revodrive 2 bijv dan? Die is wel wat rapper dan een x25m?

[Snow_King]

maratropa schreef op maandag 20 december 2010 @ 14:01:
Maar een OCZ revodrive 2 bijv dan? Die is wel wat rapper dan een x25m?

Probleem is wel, dit is ook een MLC SSD. De servers waar de SSD in zou gaan draaien 24/7 en ook onder een flinke load, naar mijn berekeningen ben ik dan met een krap jaar door de 10.000 writes van alle cellen heen.

Ook daar weer, een MLC SSD is toch wat te traag met schrijven, vanwege de gehele page niet opnieuw geprogrammeerd moet worden.

Een stukje DDR achter een S-ATA poort met een batterij is al voldoende.

[maratropa]

Maar is een oude IRAM dan niet voldoende? Waarom moet het nog kleiner zijn?

Dus eigenlijk wil je zoiets:

http://www.pcper.com/arti...aid=704&type=expert&pid=1

http://www.ddrdrive.com/

1500E in 2009

[ Voor 11% gewijzigd door maratropa op 20-12-2010 14:21 ]

[Klunssmurf]

Dure oplossing voor maar max. 1GB : http://www.hyperossystems.co.uk/

Dan zou je nog kunnen kijken voor een gebruikte Cenatek Rocket Drive (PCI en DDR1)

Maar aangezien je niet echt veel capacateit nodig hebt....waarom reserveer je niet een gedeelte van het werkheugen om daar een Ramdrive te maken?

[Snow_King]

maratropa schreef op maandag 20 december 2010 @ 14:19:
Maar is een oude IRAM dan niet voldoende? Waarom moet het nog kleiner zijn?

Dus eigenlijk wil je zoiets:

http://www.pcper.com/arti...aid=704&type=expert&pid=1

http://www.ddrdrive.com/

1500E in 2009

De oude iRam lijkt niet meer verkocht te worden? Ik kom alleen nog maar oude reviews tegen en tweede hands dingen op eBay en Amazon.

En DDR drive heeft er SLC NAND bij, wat in mijn situatie niet nodig is.

De iRam was bijvoorbeeld prima betaalbaar en bood ook goede prestaties.

Klunssmurf schreef op maandag 20 december 2010 @ 14:20:Maar aangezien je niet echt veel capacateit nodig hebt....waarom reserveer je niet een gedeelte van het werkheugen om daar een Ramdrive te maken?

Ik heb het na een reboot ook nog nodig, dus alleen een ramdrive gaat niet voldoende zijn. Een batterij moet de data nog in het DDR houden.

Die HyperDrive is opzich wat ik zoek, alleen is die al weer duurder dan een X25-E SSD van Intel.

[leonbong]

Als je toch maar 1GB nodig hebt, koop dan gewoon een momentusXT daar zit 4GB SLC cache op.
Maak alleen een 4GB partitie en hij optimaliseert vanzelf zodat alles uit de cache wordt gedaan.

Is relatief goedkoop.

Laat maar toch niet zo'n goed idee.

[ Voor 9% gewijzigd door leonbong op 20-12-2010 16:22 ]

[manzonderdas]

Acard ANS9010B ?

kan je op cf backuppen, tot 48 GB DDR2.

wel prijzig helaas

[Femme]

Aangezien je een slc ssd van een paar honderd euro al te duur vind ik zou ik niet teveel hoop houden dat je ergens voor een lagere prijs een oplossing kunt vinden met een battery backup en RAM. Een BBU voor een raidcontroller kost vaak al meer dan 100 euro.

Ik vind het ook wel knap dat je constateert dat mlc-ssd's onvoldoende presteren en niet betrouwbaar genoeg zijn terwijl je dit blijkbaar niet hebt getest. Slc-geheugen is geen garantie voor hoge prestaties. De controller speelt een veel grotere rol.

Hoe groter de capaciteit van een ssd, hoe langer hij zal meegaan (bij een gelijkblijvend aantal schrijfacties). Een ssd met een capaciteit groter dan 1GB is dus wel degelijk nuttig voor jouw toepassing.

[analog_]

Beetje knullige oplossing maar is een ram drive (letterlijk) niet een oplossing. Je zegt zelf dat data consistency in principe geen issue is aangezien dat toch wordt opgevangen en eventueel kan je zelf het startup/shutdown script aanpassen zodat het weggeschreven wordt (200MB moet wel lukken in een paar seconden). Voeg een UPS toe en je hebt je x-uur data consistency.

I mean, RAM is dirty cheap all considered.

edit: Had dus over die ene zin in je TS gelezen *grmbl*. Overigens zou ik het nog overwegen als je FS daar tegen kan, soms is het misbruiken van data consistency algoritmes een betere oplossing (lees: goedkoper) dan het overal 100% willen houden. Dit zou je best natuurlijk met een studie bewijzen.

[ Voor 38% gewijzigd door analog_ op 20-12-2010 17:14 ]

[Snow_King]

Femme schreef op maandag 20 december 2010 @ 17:01:
Aangezien je een slc ssd van een paar honderd euro al te duur vind ik zou ik niet teveel hoop houden dat je ergens voor een lagere prijs een oplossing kunt vinden met een battery backup en RAM. Een BBU voor een raidcontroller kost vaak al meer dan 100 euro.

Niet direct te duur, maar aangezien het om een grote omgeving zal gaan met enkele honderden nodes, kan de prijs zo flink oplopen.

Ik vind het ook wel knap dat je constateert dat mlc-ssd's onvoldoende presteren en niet betrouwbaar genoeg zijn terwijl je dit blijkbaar niet hebt getest. Slc-geheugen is geen garantie voor hoge prestaties. De controller speelt een veel grotere rol.

Jawel, ik heb intensief met de X25-M getest, maar deze bood te weinig schrijf performance, de SSD bleek hier niet snel genoeg te zijn voor de journaling.

Hoe groter de capaciteit van een ssd, hoe langer hij zal meegaan (bij een gelijkblijvend aantal schrijfacties). Een ssd met een capaciteit groter dan 1GB is dus wel degelijk nuttig voor jouw toepassing.

Klopt, ik heb daarom van de X25-M ook slechts 4GB gebruikt, waar de andere 76GB helemaal vrij bleef voor de interne wear leveling.

Het hele verhaal komt inderdaad in een datacenter te draaien, daar is dus gewoon een UPS aanwezig die het geheel veilig maakt, maar toch, als de UPS een hick geeft (wat wel eens kan gebeuren), dan ben ik op AL mijn nodes de journal kwijt, dán heb ik wel een probleem.

Een DDR2/3 reepje achter een S-ATA poort zou de meest ideale optie zijn, maar wat er nu op de markt is, is voor mij overkill, terwijl het prachtige producten zijn.

[Black_Adder]

Snow_King schreef op maandag 20 december 2010 @ 18:39:
[...]
Niet direct te duur, maar aangezien het om een grote omgeving zal gaan met enkele honderden nodes, kan de prijs zo flink oplopen.


[...]
Jawel, ik heb intensief met de X25-M getest, maar deze bood te weinig schrijf performance, de SSD bleek hier niet snel genoeg te zijn voor de journaling.


[...]
Klopt, ik heb daarom van de X25-M ook slechts 4GB gebruikt, waar de andere 76GB helemaal vrij bleef voor de interne wear leveling.

Het hele verhaal komt inderdaad in een datacenter te draaien, daar is dus gewoon een UPS aanwezig die het geheel veilig maakt, maar toch, als de UPS een hick geeft (wat wel eens kan gebeuren), dan ben ik op AL mijn nodes de journal kwijt, dán heb ik wel een probleem.

Een DDR2/3 reepje achter een S-ATA poort zou de meest ideale optie zijn, maar wat er nu op de markt is, is voor mij overkill, terwijl het prachtige producten zijn.

Een intel X25-M staat nu juist niet bekend om zijn geweldige write speeds. Heb je al eens gedacht aan een SSD die wel snelle writes heeft zoals een OCZ Vertex 2 of een Corsair F60. Verder zou het handig zijn als je met meer concrete informatie komt. Zoals bijvoorbeeld welke snelheden je wel nodig hebt.

[Snow_King]

Black_Adder schreef op maandag 20 december 2010 @ 22:54:
[...]


Een intel X25-M staat nu juist niet bekend om zijn geweldige write speeds. Heb je al eens gedacht aan een SSD die wel snelle writes heeft zoals een OCZ Vertex 2 of een Corsair F60. Verder zou het handig zijn als je met meer concrete informatie komt. Zoals bijvoorbeeld welke snelheden je wel nodig hebt.

Oh, wat ik juist in de tests zie is dat de X25-M sneller is met schrijven dan de gemiddelde SSD.

De schrijfsnelheden die ik nodig heb zijn rond de Gbit, dat is de snelheid waarmee de data maximaal binnen komt, echter komt er vervolgens metadata bij die ook moet worden weggeschreven, een sustained write van 150MB/sec is dus geen raar getal.

Dat zal echter niet op een hele grote blocksize gaan plaats vinden, dat zal varieëren, maar ook zullen het nog eens veel random writes gaan zijn (Waar het nooit meer dan 1GB aan data gaat zijn).

[Admiral Freebee]

Een X25-M is relatief traag in lineair schrijven, maar wel erg snel met random reads en writes. Er zijn wel andere SSD's die goed scoren op zowel het lineair als random schrijven.

[Verwijderd]

150MB/s write doen nog maar weinig SSDs; de Sandforce modellen doen eigenlijk rond de 100MB/s en dankzij compressie kunnen ze hoger halen; tot 250MB/s als je nulletjes en andere onzin-data schrijft. Maar ga uit van ietsje hoger dan de échte fysieke writesnelheden; 120MB/s ofzo gemiddeld.

SSDs zijn ook een zeer slechte keuze voor sequential write performance; HDDs zijn veel logischer voor dit type workload. SSDs dien je in te zetten voor Random I/O niet voor workloads die vrijwel uitsluitend sequentiëel zijn. Natuurlijk heb je ook andere voordelen zoals stroomverbruik, vibraties, geluidsproductie en betrouwbaarheid; maar voor je euro krijg je maar heel weinig terug met zo'n setup boven een conventionele HDD setup. Eén 5400rpm HDD is qua sequential write sneller dan bijna alle SSDs; de Crucial C300 uitgezonderd. De sandforce modellen hebben in het echt zo'n 100MB/s write; net als de laatste Intel G2 160GB. De Intel G3 zou aan 160MB/s-200MB/s sequential write zitten.

[The Lord]

Ik zou zelf denken aan een Fusion-io ioDrive.

Wel SSD techniek, maar voor meer cycles en sneller. En duurder .

[Snow_King]

The Lord schreef op dinsdag 21 december 2010 @ 17:26:
Ik zou zelf denken aan een Fusion-io ioDrive.

Wel SSD techniek, maar voor meer cycles en sneller. En duurder .

Leuk ding, maar helaas een beetje te duur voor dit doel.

Een HDD als logdrive? Mja, het zijn niet alleen sequentieële writes, het is een journal/log, daar komen ook random writes bij doordat er meerdere processen tegelijk aan het schrijven zijn naar dat journal.

Maar wat ik dus eigenlijk zoek, een stukje DDR achter een S-ATA poort met een batterij lijkt niet echt te bestaan?

[ajhaverkamp]

IDE en snelheid onbekend (en Chinese kwaliteit)

[Q]

Snow_King schreef op maandag 20 december 2010 @ 12:47:
[...]
De Enterprise SLC SSD's komen wel goed uit de bus qua performance, maar die zijn helaas te duur (enkele honderden euro's) en ook te groot (in opslag).

- Om hoeveel SSD's gaat het dan eigenlijk? Dus hoeveel systemen gaat je filesystem cluster omvatten?

- Waarom niet gewoon 2 hele goedkope MLC drives in RAID1?

Om wat voor DFS gaat het eigenlijk?

[ Voor 6% gewijzigd door Q op 22-12-2010 12:39 ]

[Snow_King]

Q schreef op woensdag 22 december 2010 @ 12:39:
[...]


- Om hoeveel SSD's gaat het dan eigenlijk? Dus hoeveel systemen gaat je filesystem cluster omvatten?

- Waarom niet gewoon 2 hele goedkope MLC drives in RAID1?

Om wat voor DFS gaat het eigenlijk?

Het zou al snel om enkele honderden nodes gaan. Het DFS waar ik het voor wil gebruiken is Ceph.

Je bedoeld twee MLC SSD's in RAID-0? Dat is ook nog een mogelijkheid inderdaad.

[raymondw]

Heb in het verleden wel wel wat dingen getest, maar was in mijn geval niet super denderend
Spul is het archief ingegaan aangezien het zelfs niet eens LVT was destijds...
http://www.dealextreme.com/details.dx/sku.17790
http://www.dealextreme.com/details.dx/sku.14362
http://www.dealextreme.com/details.dx/sku.18013
Op basis van RAM heb ik een aantal jaar niet echt iets leuks meer gezien.

Uiteindelijk gekozen voor een OS R1 op HW met BBU en een SSD er aan als JBOD/R0 (72hr BBU)
Dat was voor mijn case destijds de snelste oplossing, en de SSD's lijken het nog steeds redelijk te doen.