Onderwerp: Reden om geen SSD te gebruiken voor server

Oorspronkelijk geplaatst door SebastiaanStok

"Partitioneer niet meer dan 90% van de SSD"
Kan je dit misschien toelichten?

Als er iets kaduuk gaat zal de SSD de overige 10% gebruiken om blokken te herstellen Enterprise SSD's hebben wat meer reserve blokken dan de cheap ass dingetjes dus dit is met name bij de goedkopere modelletjes aan te raden. Hiermee gaan je SSD's weer wat langer mee, enige nadeel is dat je 10% minder ruimte hebt.

Oorspronkelijk geplaatst door SebastiaanStok

"Partitioneer niet meer dan 90% van de SSD"
Kan je dit misschien toelichten?

Zoals al wordt aangegeven heeft de SSD dan meer reserve cellen.

Deze worden door de wear-leveling in de SSD gebruikt om de writes zo evenredig te verspreiden.

Een ander aspect is dat bij een schrijfactie een cel eerst moet worden gewist alvorens je deze kan beschrijven.

Als je reserve cellen hebt kan de write naar een leegstaande cel gaan waarna de oude cel ophet gemakje gewist kan worden.

SSD's zijn technisch gezien echt een hele nieuwe tak van sport :-)

Nou zoals ook wido aangeeft gaan ssd echt niet zomaar kapot. Het probleem wat eerder werd aangegeven was dat ze iid nogal uit het niets kapot kunnen gaan. Echter dit zijn maar sporadische problemen (HD's gaan bij mij vaak ook kapot voordat ze kapot zouden moeten gaan). Dit komt vrijwel nooit omdat de SSD helemaal op is. Misschien was die kans groter met oudere ssd's, maar met wearlevelling valt dat allemaal reuze mee.

Je moet dan dus wel ontzettende pech hebben als je ssd's allebei voortijdig en ook nog een gelijktijdig sterven. Bij een eventuele failure maakt het feit dat ze snel zijn en relatief klein, juist dat je weer snel met een backup zit. Een 2 TB HDD kan wel ff duren voor hij weer opnieuw gebouwd is.


Wat wel interessant is is dit artikel:
http://www.tomshardware.com/reviews/...rate,2923.html

Let's put everything we've explored into some rational perspective. Here is what we know about hard drives from the two cited studies.

MTBF tells you nothing about reliability.
The annualized failure rate (AFR) is higher than what manufacturers claim.
Drives do not have a tendency to fail during the first year of use. Failure rates steadily increase with age.
SMART is not a reliable warning system for impending failure detection.
The failure rates of “enterprise” and “consumer” drives are very much similar.
The failure of one drive in an array increases the likelihood of another drive failure.
Temperature has a minor effect on failure rates.

Thanks to Softlayer's 5000+-drive operation, we know that some of those points also apply to SSDs. As we saw in the published studies, hard drive failure rates are affected by controllers, firmware, and interfaces (SAS versus SATA). If it's true that write endurance doesn't play a role in random drive failures and that vendors use compute-quality NAND in MLC- and SLC-based products, then we'd expect enterprise-class SSDs to be no more reliable than consumer offerings.

Dus write failures komen niet vaak voor. Ook lijken de cijfers tot nu tot beter voor ssd's dan voor HDD's qua betrouwbaarheid. Al met al is er niet echt een gegronde reden om banger te zijn met ssd's dan met HDD's.
Goede raid en backups zijn altijd een must.

Oorspronkelijk geplaatst door Yourwebhoster

Als er iets kaduuk gaat zal de SSD de overige 10% gebruiken om blokken te herstellen

Oorspronkelijk geplaatst door Wido

Zoals al wordt aangegeven heeft de SSD dan meer reserve cellen.

Jullie schrijven allebei dat de 10% die niet gepartitioneerd wordt, als reserve capaciteit gebruikt gaat worden. Wat ik mij echter afvraag is hoe de SSD "weet" dat die blokken beschikbaar zijn voor reserve capactiteit. Immers, de gebruiker kan besluiten om eerst een partitie aan te maken van xx%, deze in gebruik te nemen, en later nog een partitie aan te maken van de rest van de capaciteit... Als de ongebruikte blokken gebruikt zijn door de SSD controller om probleem blokken te "vervangen", dan heb je dus opeens minder capaciteit beschikbaar.
Dit vereist allemaal heel veel intelligentie van de controllers, in samenwerking met de OS drivers. Volgens mij worden de SSD's gewoon gezien als een "reguliere" HDD door het OS. Wel met wat extra "opties". Maar ik verwacht niet dat het OS aan de SSD controller zit te vertellen welke blokken beschikbaar _kunnen_ wezen als reserve capaciteit....
Indien iemand een technische onderbouwing van een fabrikant heeft, dan wil ik dat graag lezen, aangezien ik erg benieuwd ben hoe de "samenwerking" verloopt tussen SSD en OS voor deze ongebruikte blokken....

Oorspronkelijk geplaatst door Paul Z.

Jullie schrijven allebei dat de 10% die niet gepartitioneerd wordt, als reserve capaciteit gebruikt gaat worden. Wat ik mij echter afvraag is hoe de SSD "weet" dat die blokken beschikbaar zijn voor reserve capactiteit. Immers, de gebruiker kan besluiten om eerst een partitie aan te maken van xx%, deze in gebruik te nemen, en later nog een partitie aan te maken van de rest van de capaciteit... Als de ongebruikte blokken gebruikt zijn door de SSD controller om probleem blokken te "vervangen", dan heb je dus opeens minder capaciteit beschikbaar.
Dit vereist allemaal heel veel intelligentie van de controllers, in samenwerking met de OS drivers. Volgens mij worden de SSD's gewoon gezien als een "reguliere" HDD door het OS. Wel met wat extra "opties". Maar ik verwacht niet dat het OS aan de SSD controller zit te vertellen welke blokken beschikbaar _kunnen_ wezen als reserve capaciteit....
Indien iemand een technische onderbouwing van een fabrikant heeft, dan wil ik dat graag lezen, aangezien ik erg benieuwd ben hoe de "samenwerking" verloopt tussen SSD en OS voor deze ongebruikte blokken....

Een SSD weet welke blokken er leeg zijn, als hij de fabriek uit komt is alles leeg. Spreek je vanaf het begin die laatste 10% nooit aan, dán kan de SSD optimaal zijn werk blijven doen.

Als jij dus ooit wel schrijft naar die laatste 10%, dan kan de SSD die cellen inderdaad niet meer gebruiken als reserve cellen.

Daar komt echter TRIM/ATA DISCARD om de hoek zetten. Onder Linux kan je sinds het 2.6.34 gebruik maken van EXT4 met discard support.

Op een MySQL server bij ons:

/dev/sdb1 on /mnt/mysql type ext4 (rw,errors=remount-ro,discard)

Het EXT4 filesystem zal nu tegen de SSD zeggen: "Hey, dat blok daarzo, die heb ik niet nodig! Mag je opruimen en andere leuke dingen mee doen"

De SSD kan dan vervolgens die cellen weer leeg maken (Denk er aan dat de "erase" van een cel het langste duurt), waarna deze weer beschikbaar zijn.

Om een gebruikte SSD helemaal naar zijn beginstaat terug te krijgen moet je een "ATA SECURE ERASE" uitvoeren, de SSD reset zichzelf dan helemaal en brengt alle cellen terug naar NULL.

Let wel op, ik heb deze ervaring alleen op gedaan met de Intel SSD's, vanaf de X25-M|E tot aan de 300, 500 en 700 serie.

TRIM/DISCARD support gaat overigens ook héél leuk worden met SAN's. Nu kan je wel thin provisioning doen, maar op termijn groeit je LUN toch altijd door, omdat de SAN geen weet heeft van bestanden die verwijderd zijn.

Er wordt nu aan allerlei kanten gewerkt om deze support ook in onder ander Qemu, QCOW2, iSCSI en nog meer zaken te implementeren. Als al die lagen dan op termijn ook de DISCARD commando's netjes doorgeven, kan dat heel veel ruimte gaan schelen op SAN's.

In LVM en MDADM wordt er ook gewerkt aan DISCARD ondersteuning, geeft dan nog 1.5 jaar zou ik zeggen. Gewoon lekker software RAID draaien op die SSD's, performance wise prima te doen en ook qua stabiliteit.

Oorspronkelijk geplaatst door Wido

In LVM en MDADM wordt er ook gewerkt aan DISCARD ondersteuning, geeft dan nog 1.5 jaar zou ik zeggen. Gewoon lekker software RAID draaien op die SSD's, performance wise prima te doen en ook qua stabiliteit.

Is dit dan ook gelijk de enige oplossing om trim en discard werkend te krijgen in raid opstelling. Of werkt dit ook achter hardware matige raid ?

Oorspronkelijk geplaatst door Mikey

Is dit dan ook gelijk de enige oplossing om trim en discard werkend te krijgen in raid opstelling. Of werkt dit ook achter hardware matige raid ?

Dat is dan afhankelijk van de fabrikant. Als 3Ware, LSI of Areca het zouden implementeren in hun RAID controllers, dan kan het in theorie gewoon werken.

De controller krijgt van het OS het DISCARD commando door en die moet daarna uitvogelen wat hij door stuurt naar de SSD's toe.

Het kan dus werken, maar tot nu toe heb ik geen enkele fabrikant gehoord over het daadwerkelijk implementeren.

Oorspronkelijk geplaatst door Paul Z.

Jullie schrijven allebei dat de 10% die niet gepartitioneerd wordt, als reserve capaciteit gebruikt gaat worden. Wat ik mij echter afvraag is hoe de SSD "weet" dat die blokken beschikbaar zijn voor reserve capactiteit. Immers, de gebruiker kan besluiten om eerst een partitie aan te maken van xx%, deze in gebruik te nemen, en later nog een partitie aan te maken van de rest van de capaciteit... Als de ongebruikte blokken gebruikt zijn door de SSD controller om probleem blokken te "vervangen", dan heb je dus opeens minder capaciteit beschikbaar.

Neem aan dat je dan gewoon een write error krijgt op het moment dat je die capaciteit later alsnog wilt gaan gebruiken, en dat niet kan omdat blokjes stuk zijn.


Intel heeft een white paper over onder-partitioneren: http://cache-www.intel.com/cd/00/00/...555_459555.pdf

Kort samengevat: je kan met een ATA commando de capaciteit van de schijf lager instellen.

Of je kan simpelweg minder partitioneren, zodat de blokjes met hoge adressen nooit aangesproken worden.
Heb je dat in het verleden wel al gedaan, en wil je het besturingssysteem opnieuw installeren dan moet je het eerst het secure erase commando gebruiken om de schijf en mapping tabbellen echt leeg te maken.

Oorspronkelijk geplaatst door Mikey

Is dit dan ook gelijk de enige oplossing om trim en discard werkend te krijgen in raid opstelling. Of werkt dit ook achter hardware matige raid ?

Probleem is dat voor goede RAID ondersteuning het noodzakelijk is dat ook de RAID laag een lijstje bij gaat houden met welke blokken vrij zijn.
En zo geavanceerd zijn de meeste RAID implementies niet.
Geloof dat alleen LVM mirroring/striping dat op dit moment goed doet, en zelfs mdadm niet.


Schijven zijn niet verplicht om iets met het DISCARD commando te doen, en de inhoud van een blok waarop een DISCARD commando is uitgevoerd is undefined.
Stel je hebt twee schijven van verschillende fabrikanten en daar bouw je een RAID-1 van.
Indien de controller simpelweg het DISCARD commando naar beide schijven zou sturen, kan dit het gevolg hebben dat als je de gegevens van beide schijven terug gaat lezen deze niet meer gelijk is.
En als je de array dan gaat resyncen zal hij onnodige correcties gaan uitvoeren om de inhoud wel weer gelijk te krijgen.

Wido; Bedankt voor je uitleg. Weer wat opgestoken over SSD's.. Ik ga eens kijken naar die Intel SSD's

Oorspronkelijk geplaatst door maxnet

Neem aan dat je dan gewoon een write error krijgt op het moment dat je die capaciteit later alsnog wilt gaan gebruiken, en dat niet kan omdat blokjes stuk zijn.


Intel heeft een white paper over onder-partitioneren: http://cache-www.intel.com/cd/00/00/...555_459555.pdf

Kort samengevat: je kan met een ATA commando de capaciteit van de schijf lager instellen.

Of je kan simpelweg minder partitioneren, zodat de blokjes met hoge adressen nooit aangesproken worden.
Heb je dat in het verleden wel al gedaan, en wil je het besturingssysteem opnieuw installeren dan moet je het eerst het secure erase commando gebruiken om de schijf en mapping tabbellen echt leeg te maken.

En dat kende ik nog niet! Net even getest met hdparm, werkt top!

Mijn 80GB SSD is nu nog maar 64GB Dit is vooral handig bij SSD's die je wil inzetten in een ZPOOL als ZIL. Koop een 100GB SSD en verklein hem naar 32GB, dan blijft hij lekker snel en gaat lang mee.

Oorspronkelijk geplaatst door Wido

Zoals al wordt aangegeven heeft de SSD dan meer reserve cellen.

Deze worden door de wear-leveling in de SSD gebruikt om de writes zo evenredig te verspreiden.

Wordt dit door de controller in de SSD schijf gedaan? Heeft iedere SSD schijf dit standaard ingebouwd, of verschilt dat per merk/type?

Goede tips in ieder geval!

Oorspronkelijk geplaatst door Wido

Inderdaad, wij zetten SSD's ZONDER RAID in, dit omdat RAID controllers soms meer kapot maken dat je lief is, zoals zaken maskeren voor het OS die het OS/Filesystem wil weten.

Wel software RAID, of ook niet?

Oorspronkelijk geplaatst door Apoc

Wordt dit door de controller in de SSD schijf gedaan? Heeft iedere SSD schijf dit standaard ingebouwd, of verschilt dat per merk/type?

Goede tips in ieder geval!

Dat ligt aan de controller en firmware van de betreffende SSD.

De Intel SSD's doen dit in ieder geval wel, pages/cellen die niet in gebruik zijn door data worden door de SSD gebruikt om writes evenredig te spreiden over cellen.

Oorspronkelijk geplaatst door Apoc

Wel software RAID, of ook niet?

In het geval van die database servers ook geen software RAID.

Er zijn wel systemen waar we SSD's in RAID hebben, maar ik wacht nog liever totdat mdadm TRIM ondersteund, zodat we optimaal gebruik van de SSD's hebben.

Ah ok dan. Ik ben momenteel bezig met een ontwerp voor een HA database cluster, maar dan zou het zo te horen dus beter zijn om meer kleine nodes in te zetten met ieder 1 SSD, dan een lager aantal met meerdere SSDs. Het grote nadeel is dan wel weer dat de licentiekosten voor de clustering software, per node zijn.