PDA

Bekijk Volledige Versie : Reden om geen SSD te gebruiken voor server



Crush
23/11/11, 16:26
Mijn servers zijn alweer 5 jaar oud dus ik vond het tijd om wat rond te gaan kijken voor nieuwe zuinigere en snellere servers (wat je snel krijgt wanneer je het vergelijk met 5 jaar oude servers).

Nu ben ik aan het twijfelen of ik een SSD- of SATA-schijf zal nemen. Ongeacht wat ik kies zal het in RAID 1 komen te draaien. Het gaat tussen:

* Intel® 320 Series, 40GB
* Western Digital 250GB, SATA II, 64MB, 7200rpm

Voordelen SSD:

* 80% zuiniger
* sneller

Nadelen SSD:

* maximaal aantal schrijfacties
* minder GB voor zelfde prijs

Nu hoef je het niet om de prijs te doen omdat de SATA maar 2 euro goedkoper is. Daarnaast is het voor een webserver welke nu ook maar 5GB ruimte gebruikt en niet veel schrijfacties heeft.

Zie ik iets over het hoofd waarom ik geen SSD zou nemen voor een server?

rensariens
23/11/11, 16:35
Nee. Zou zelf overigens voor de 120GB variant gaan, maar weet niet of dat binnen je budget valt. 120GB is stuk sneller, vooral met writes. Alle intel schijven zijn volgens mij betrouwbaarder dan de ouderwetse disks, dus daar zou ik me geen zorgen om maken.

systemdeveloper
23/11/11, 16:36
Neu, gewoon lekker ssd pakken.

Al is er 1 risico.... het kan verslavend werken waardoor je later ongelukkig wordt met sata...

Yourwebhoster
23/11/11, 16:58
Voeg ff aan de plus IOPS en response tijden toe. Geloof mij (en systemdeveloper) als je er eenmaal mee gewerkt hebt dan wil je niet anders;)

Ricardo Persoon
23/11/11, 17:06
Over het maximale aantal writes hoef je je echt geen zorgen te maken, zeker niet op een webserver. Vooral de extra IOps zijn voor een webserver een zegen. En zoals hierboven al genoemd, je wilt echt niet anders meer als je eenmaal aan de SSD's bent, en met de huidige bedragen die je neertelt voor de normale HDD's is het ook al een stuk interessanter. De wat grotere modellen in de 320 series zijn inderdaad wat sneller.

Rez
23/11/11, 19:15
Nadeel ssd: de overige hardware wordt de bottleneck ;)

SebastiaanStok
23/11/11, 21:10
Als je de mogelijkheid hebt kan je een combinatie van kiezen. Het OS op de SSD, en data op een grote harddisk.
Ik ben zelf sinds twee weken de gelukkige (privé) eigenaar van een SSD, en ik ben dol op dat ding!

Programma's starten razend snel, en Windows is binnen 20 seconde gestart.
Oké is wel S-ATAIII, dus dat verschild ook wel. Maar echt zalig.

Dat ik voor de data nog een 'oude' S-ATAII 360GB heb maakt voor de snelheid niets uit.

40GB is overigens wel erg klein, voor Windows is het zo wie zo te klein en ook voor Linux wil je liever meer hebben.
Kleine opmerking hierover. Het is echt aan te raden een systeem versie te nemen met trim support.
Zonder trim support ben je nergens!

En bij Linux is het aan te raden om een andere block-size in te stellen die gelijk staat aan de cluster grote van je disk.

http://opentechnow.blogspot.com/2010/02/linux-ssd-optimization-guide.html
http://www.zdnet.com/blog/perlow/geek-sheet-a-tweakers-guide-to-solid-state-drives-ssds-and-linux/9190
http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux

Bij Windows MOET je alleen de defragmentatie uitschakelen, en accesstime.
Verder dan dit valt er eigenlijk niet te tweaken.
http://nl.hardware.info/reviews/1635/workshop-tune-je-ssd!

Crush
25/11/11, 10:24
Iedereen bedankt voor de tips. Heb even de specs van 80GB vergeleken met de 40GB versie en daarbij is er een groot verschil te zien in IOPS. Wellicht iets meer investering maar dan heb ik het wel gelijk goed, hoewel ik twijfel of het voor een webserver verschil uitmaakt tussen de twee. Voor een database server is het natuurlijk een ander verhaal.

Mikey
25/11/11, 10:56
Ik heb het hele ssd verhaal afgelopen tijd niet gevolgd. Maar de eerste vraag die in me opkomt ; trim support icm hardware raid ?

chielsen
25/11/11, 11:37
Ook al heb je het nog niet meteen nodig, het is altijd fijn wat meer te hebben. Is die 5GB ook al incl OS?
Verder heb je nog dat als je meer vrije ruimte hebt de SSD sneller blijft. Ook zal je minder snel de limiet van schrijfacties bereiken.

almar
25/11/11, 13:34
Ik heb het hele ssd verhaal afgelopen tijd niet gevolgd. Maar de eerste vraag die in me opkomt ; trim support icm hardware raid ?

Dit vraag ik mij ook af. Ik las laatst ergens dat alleen de allerduurste SSD's TRIM kunnen uitschakelen en daarmee hardware RAID ondersteunen, maar ik kan het nergens meer terug halen.

cj0
25/11/11, 14:27
Zie ik iets over het hoofd waarom ik geen SSD zou nemen voor een server?

1. SSD's vallen eerder volledig uit dan roterende schijven (is onze ervaring, kortom meer reizen naar het datacentrum om drives te vervangen)
2. Als SSD's uitvallen, dan lukt het niet om ook nog maar iets van die kapotte drive te lezen (d.w.z. geen koelkast/vrieskast methodes en/of speciale utilities die nog data kunnen lezen).

Wido
25/11/11, 14:30
1. SSD's vallen eerder volledig uit dan roterende schijven (is onze ervaring, kortom meer reizen naar het datacentrum om drives te vervangen)
2. Als SSD's uitvallen, dan lukt het niet om ook nog maar iets van die kapotte drive te lezen (d.w.z. geen koelkast/vrieskast methodes en/of speciale utilities die nog data kunnen lezen).

Wij hebben nog geen uitval gezien met SSD's. Gebruiken enkel Intel SSD's, werken perfect, al ruim 2 jaar nu.

Yourwebhoster
25/11/11, 14:33
Ik heb het hele ssd verhaal afgelopen tijd niet gevolgd. Maar de eerste vraag die in me opkomt ; trim support icm hardware raid ?

Aanrader is om niet de gehele schijf te formatteren maar 10% ongebruikt te laten. Dit kan gebruikt worden voor uitvallende delen als je goedkopere SSD's hebt, enterprise SSD's hebben meer reserve blokken om op terug te vallen. Trim heeft hardware raid zo ver ik weet niet.

Pantsy
25/11/11, 14:36
Ik zie nergens nadelen voorbij komen bijvoorbeeld dat SSD onvoorspelbaar is met het uitvallen van schijven (er is geen meet techniek voor), ik zou dit never nooit gebruiken op een live omgeving. Voor caching is het echt prima, voor het opslaan van bestanden totaal niet, het OS is disputabel door de snelle opstart/response tijden. Wanneer je veel IO doet dan heb je grote kans dat de levens verwachting een stuk korter is dan word voorgeschoteld. Veel hosting bedrijven zijn niet tevreden met SSD disks, ze gaan te snel kapot, zijn op, of vertonen kuren waardoor je performance problemen krijgt.

Waarom kies je geen SAS? en dan de 15K variant, grote kans dat je hier heel erg tevreden mee gaat zijn en er geen spijt van hebt op korte termijn. SAS disks zijn helemaal niet duur, zeker niet wanneer je deze vergelijkt met de enterprise SSD disks.

chielsen
25/11/11, 14:55
SAS, ook al heb je 15k, gaat je nooit de performance leveren van SSD schijven. Qua betrouwbaarheid heb je wel wat meer zorgen idd, maar met een goede raid opstelling zou dat geen probleem zijn. Ook met een HD kan je opeens met een dode schijf zitten.

Vreemd trouwens dat je over de korte termijn praat. Ik zou kijkend naar de korte termijn juist voor een SSD gaan (als je dat al van plan was). De eventuele nadelen die je noemt treden namelijk vaak pas op op de langere termijn.

Mikey
25/11/11, 15:17
SAS, ook al heb je 15k, gaat je nooit de performance leveren van SSD schijven. Qua betrouwbaarheid heb je wel wat meer zorgen idd, maar met een goede raid opstelling zou dat geen probleem zijn. Ook met een HD kan je opeens met een dode schijf zitten.

Vreemd trouwens dat je over de korte termijn praat. Ik zou kijkend naar de korte termijn juist voor een SSD gaan (als je dat al van plan was). De eventuele nadelen die je noemt treden namelijk vaak pas op op de langere termijn.

Maar is het niet zo dat door de raid opstelling je juist op een punt komt waarbij beide schijven kort na elkaar de geest geven. Aangezien beide ssd's op dezelfde manier benaderd worden met schrijf acties, lopen de cycles ook gelijkmatig af. Maw. 2 ssd's van hetzelfde merk en type kunnen ook nagenoeg gelijktijdig ermee stoppen.

Yourwebhoster
25/11/11, 15:32
Maar is het niet zo dat door de raid opstelling je juist op een punt komt waarbij beide schijven kort na elkaar de geest geven. Aangezien beide ssd's op dezelfde manier benaderd worden met schrijf acties, lopen de cycles ook gelijkmatig af. Maw. 2 ssd's van hetzelfde merk en type kunnen ook nagenoeg gelijktijdig ermee stoppen.

Gewoon net zoals bij normale schijven een deel van een nieuwe batch en een deel die al langer in gebruik is? Schijven uit dezelfde batch is soms vragen om problemen, sommigen gaan nog verder en combineren verschillende merken.

Cakkie
25/11/11, 15:35
En daar heb je ook nog de hot spares voor, toch? (en dan nog die cold-spare in de kast) Het zou al moeten lukken dat 2 schijven op echt exact hetzelfde moment sterven...

Yourwebhoster
25/11/11, 15:37
En daar heb je ook nog de hot spares voor, toch? (en dan nog die cold-spare in de kast)
Als exact evenveel writes uitgevoerd worden gok ik dat ze min of meer tegelijk danwel in een korte tijdspanne dood gaan. Beter voorkomen dan genezen, als beide disks uitvallen ben je gegarandeerd meer kwijt om het te herstellen.

Mikey
25/11/11, 15:56
Als exact evenveel writes uitgevoerd worden gok ik dat ze min of meer tegelijk danwel in een korte tijdspanne dood gaan. Beter voorkomen dan genezen, als beide disks uitvallen ben je gegarandeerd meer kwijt om het te herstellen.

Normaal wordt een hot-spare pas ingezet als er een de array uitgezet wordt. Dan volgt automatisch een rebuild.

Yourwebhoster
25/11/11, 16:04
Normaal wordt een hot-spare pas ingezet als er een de array uitgezet wordt. Dan volgt automatisch een rebuild.
Ik heb het over de actieve schijven, het moge duidelijk zijn wat een hotspare is maar als één van de actieve schijven uitvalt > hot spare > rebuilden maar als tijdens het rebuilden bijvb de andere actieve schijf kapot gaat dan heb je er nog niks aan in de meeste gevallen.

Mikey
25/11/11, 16:16
Precies hetgeen wat ik dus aankaart. Ik weet niet hoe de rest erover denkt, maar ik voel er niets voor om een server op te gaan leveren met 2 ssd's waarbij er een al draaiuren heeft gehad, met de wetenschap dat je een ssd hebt waarvan je zeker dus weet dat je daarvoor terug mag komen. Sterker nog, je kan er dus een stikker op plakken "Deze eerst"

Misschien dat ik verwend ben, maar met enterprise sas heb je dit soort fratsen in ieder geval niet.

Yourwebhoster
25/11/11, 16:23
Precies hetgeen wat ik dus aankaart. Ik weet niet hoe de rest erover denkt, maar ik voel er niets voor om een server op te gaan leveren met 2 ssd's waarbij er een al draaiuren heeft gehad, met de wetenschap dat je een ssd hebt waarvan je zeker dus weet dat je daarvoor terug mag komen. Sterker nog, je kan er dus een stikker op plakken "Deze eerst"

Misschien dat ik verwend ben, maar met enterprise sas heb je dit soort fratsen in ieder geval niet.
Je moet het opwegen tegen wat je nodig hebt. SSD's zijn geweldig met IOPS en response tijden die gewoon niet te vergelijken zijn. Heb je het niet nodig, SAS. Heb je het wel nodig of mogelijk later, SSD. Ik weet niet meer waar ik het gelezen heb, maar geloof dat als je constant 20 MBps zou schrijven dat de SSD 1.5 jaar mee kan gaan. Je moet het dus niet kiezen omdat je het leuk vind maar omdat je het nodig hebt. Shared zou ik op traditionele disks a 7200RPM plaatsen samen met een SSD als cache (als je aan SSD wilt beginnen). Met een SSD als cache haal je niet constant gelijke performance maar je gaat wel stukken vooruit tov alleen traditionele disks.

Zie voor meer info http://blog.open-e.com/what-you-can-expect-from-ssd-2/

Mikey
25/11/11, 17:05
Mij heb je het woord leuk niet in de mond horen nemen.....

Wij doen alleen iets, als iets goed is. We zullen ook achter de aangedragen oplossing moeten staan als hoogwaardig kwalitatief en betrouwbaar. Als ik vooraf zou weten dat de disks met 1,5 jaar eruit moeten, dan komen hier geen ssd's.

Als ik overigens alle nodes sum, dan is 20mb write rate er niet zomaar. De reads liggen een grote factor hoger. Dat zou dus inhouden dat het afschrijvingstermijn van 5 jaar ook goed te halen valt, helemaal als je de array extend naar meer schijven. Tevens zou de raid10 eis die we stellen bij sas kunnen komen te vervallen en daarlangs raid5 voor ssd's. Zal hier begin 2012 eens naar kijken of we een jbod aan de vtrak toevoegen met enkel ssd disks. Ga me aankomende tijd maar er eens verder in verdiepen.

Tot nu toe zie ik nog een hoop beren op de weg, zeker op langer termijn.

Yourwebhoster
25/11/11, 17:34
Mij heb je het woord leuk niet in de mond horen nemen.....

Wij doen alleen iets, als iets goed is. We zullen ook achter de aangedragen oplossing moeten staan als hoogwaardig kwalitatief en betrouwbaar. Als ik vooraf zou weten dat de disks met 1,5 jaar eruit moeten, dan komen hier geen ssd's.

Als ik overigens alle nodes sum, dan is 20mb write rate er niet zomaar. De reads liggen een grote factor hoger. Dat zou dus inhouden dat het afschrijvingstermijn van 5 jaar ook goed te halen valt, helemaal als je de array extend naar meer schijven. Tevens zou de raid10 eis die we stellen bij sas kunnen komen te vervallen en daarlangs raid5 voor ssd's. Zal hier begin 2012 eens naar kijken of we een jbod aan de vtrak toevoegen met enkel ssd disks. Ga me aankomende tijd maar er eens verder in verdiepen.

Tot nu toe zie ik nog een hoop beren op de weg, zeker op langer termijn.

Sorry haalde het doorelkaar met een topic over hw voor shared hosting->|

Mikey
25/11/11, 19:59
Sorry haalde het doorelkaar met een topic over hw voor shared hosting->|

Dat topic had ik ook gezien, was dat niet de topic waar ook huis tuin en keuken oplossingen gegeven werden :stuart:

Yourwebhoster
25/11/11, 20:08
Dat topic had ik ook gezien, was dat niet de topic waar ook huis tuin en keuken oplossingen gegeven werden :stuart:
niet echt:http://www.webhostingtalk.nl/hardware/170952-welke-hardware-gebruiken-jullie-voor-shared-webhosting-omgeving.html

Werd ook een vraag gedaan over SSD vandaar de verwarring denk ik. Als dat soort spul huis tuin en keuken zou zijn zouden we een hoop minder zorgen hebben I guess:lovewht:

Wido
25/11/11, 20:24
Inmiddels gebruiken wij de Intel SSD's al meer dan 2 jaar, bijna 3 inmiddels (echt net toen ze uit kwamen kochten we ze).

Waar moet je nu op letten?

* Gebruik een kernel met TRIM support
* Gebruik ext4
* Zorg dat je je partities aligned met de pagesize van de SSD
* Gebruik noatime
* Partitioneer niet meer dan 90% van de SSD

Vooral TRIM is van belang, zo kan de garbage collector (wear leveling) van de SSD het beste zijn werk te doen.

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.

Een MLC SSD kan je 10.000 keer beschrijven, dan is de cel kapot, maar kan je hem nog wel lezen.

Stel, je hebt een 80GB SSD die met 70MB/sec kan schrijven, bij een 80GB SSD kan je dus 781TB schrijven alvorens de SSD kapot is.

Zou je 24/7 met 70MB/sec schrijven, dan is de SSD na 135 dagen op. Schrijf je continue met 35MB/sec, dan duurt het al 270 dagen.

Je moet wel héél veel I/O doen wil je gemiddeld gezien over 24 uur 35MB/sec schrijven naar een SSD, dan heb je een serieuze applicatie aan het werk.

De wear leveling in de SSD zorgt er voor dat writes uit kunnen worden gespreid over de cellen heen, daarvoor is de TRIM functie van de SSD's ook erg handig.

Wij hebben echt al tientallen SSD's in productie draaien, geen problemen mee.

SebastiaanStok
25/11/11, 21:17
"Partitioneer niet meer dan 90% van de SSD"
Kan je dit misschien toelichten? :)

Yourwebhoster
25/11/11, 21:20
"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.

Wido
25/11/11, 22:04
"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 :-)

chielsen
26/11/11, 01:25
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/ssd-reliability-failure-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.

Paul Z.
26/11/11, 14:22
Als er iets kaduuk gaat zal de SSD de overige 10% gebruiken om blokken te herstellen:)

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....

Wido
26/11/11, 15:14
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.

Mikey
26/11/11, 15:20
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 ?

Wido
26/11/11, 16:43
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.

maxnet
28/11/11, 13:00
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/45/95/459555_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.

maxnet
28/11/11, 13:24
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.

Paul Z.
28/11/11, 13:39
Wido; Bedankt voor je uitleg. Weer wat opgestoken over SSD's.. Ik ga eens kijken naar die Intel SSD's :)

Wido
28/11/11, 14:14
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/45/95/459555_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.

Apoc
28/11/11, 15:53
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! :)

Apoc
28/11/11, 15:55
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?

Wido
28/11/11, 15:55
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.


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.

Apoc
28/11/11, 16:10
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.

Apoc
28/11/11, 16:50
Intel heeft een white paper over onder-partitioneren: http://cache-www.intel.com/cd/00/00/45/95/459555_459555.pdf

Hm, maar als ik die charts goed begrijp, is het dus zinvol om nog aanzienlijk meer dan die eerder genoemde 10% vrij te laten:

160GB (=Geen spare): 1400 IOPS
144GB (= -10% spare): 3500 IOPS (= 250% performance)
96GB (= -40% spare): 8300 IOPS (= 593% performance)

Als ik het dus niet verkeerd begrijp, krijg je door 40% capaciteit in te leveren: bijna 6x zo veel IOPS en 5 keer zo veel levensduur. Dat is nogal wat.

Volgens diezelfde logica, zou dan wel de performance langzaam achteruit moeten gaan na verloop van tijd (omdat er dan steeds meer cellen kapot gaan en er dus netto steeds minder spare overblijft).


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.

Kun je die secure erase ook enkel op een bepaald deel van de schijf uitvoeren?

dicktump
28/11/11, 16:53
Secure Erase doe je altijd op de gehele schijf. Is nog vrij eenvoudig te doen ook, gewoon een hdparm optie en je hele SSD is leeg :)

Wido
28/11/11, 17:06
Hm, maar als ik die charts goed begrijp, is het dus zinvol om nog aanzienlijk meer dan die eerder genoemde 10% vrij te laten:

160GB (=Geen spare): 1400 IOPS
144GB (= -10% spare): 3500 IOPS (= 250% performance)
96GB (= -40% spare): 8300 IOPS (= 593% performance)

Als ik het dus niet verkeerd begrijp, krijg je door 40% capaciteit in te leveren: bijna 6x zo veel IOPS en 5 keer zo veel levensduur. Dat is nogal wat.

Volgens diezelfde logica, zou dan wel de performance langzaam achteruit moeten gaan na verloop van tijd (omdat er dan steeds meer cellen kapot gaan en er dus netto steeds minder spare overblijft).Nogmaals, 10.000 writes ben je niet zo maar doorheen, dan moet je echt heel hard aan het stressen zijn.

Het onderpartitioneren komt op het zelfde neer, wij gebruiken vaak maar 80% van de SSD's, maar het truukje met de capacity verkleinen dmv hdparm is wel erg leuk.

Apoc
28/11/11, 17:12
Nogmaals, 10.000 writes ben je niet zo maar doorheen, dan moet je echt heel hard aan het stressen zijn.

Ik zei ook na verloop van tijd ;) Je moet er toch rekening mee houden dat er een punt is waarop dat gebeurd, tenzij je op een gegeven moment schijven uit faseert. Op zich is het teruglopen van je performance dus ook een goede methode om een grove inschatting te maken van hoe de cellen van je SSD er voor staan.

Mikey
28/11/11, 17:32
Volgens diezelfde logica, zou dan wel de performance langzaam achteruit moeten gaan na verloop van tijd (omdat er dan steeds meer cellen kapot gaan en er dus netto steeds minder spare overblijft).


Op papier klinkt dat aannemelijk, in de praktijk niet te doen (lijkt mij). Wanneer je performance problemen hebt schaal je op, vergroot je je array etc etc. Ook groei van websites kunnen zorgen dat je deze inschatting als niet accuraat kunt beschouwen.

maxnet
28/11/11, 17:57
Secure Erase doe je altijd op de gehele schijf. Is nog vrij eenvoudig te doen ook, gewoon een hdparm optie en je hele SSD is leeg :)

Helaas niet op elke server even eenvoudig.
Sommige BIOS'en blokkeren de schijf daartegen bij het opstarten (status "frozen" in hdparm)

Om dat te omzeilen moet je dan eerst het systeem laten booten, en vervolgens even de stroom van de schijf halen.
Niet zo praktisch als de server al in het DC hangt, en je dacht remote even een nieuw OS er op te kunnen zetten... :(

dicktump
28/11/11, 18:22
Helaas niet op elke server even eenvoudig.
Sommige BIOS'en blokkeren de schijf daartegen bij het opstarten (status "frozen" in hdparm)

Om dat te omzeilen moet je dan eerst het systeem laten booten, en vervolgens even de stroom van de schijf halen.
Niet zo praktisch als de server al in het DC hangt, en je dacht remote even een nieuw OS er op te kunnen zetten... :(
Ja klopt, dat is wel erg irritant. Soms helpt het om het systeem in slaapstand te gooien en 'm dan weer wakker te maken. Dat kan nog wel op afstand vaak, zeker als er een IPMI/DRAC/ILO/whatever beschikbaar is.

Apoc
28/11/11, 18:39
Op papier klinkt dat aannemelijk, in de praktijk niet te doen (lijkt mij). Wanneer je performance problemen hebt schaal je op, vergroot je je array etc etc. Ook groei van websites kunnen zorgen dat je deze inschatting als niet accuraat kunt beschouwen.

Als jij eens in de zoveel tijd de IOPS meet (en uiteraard moet je dan ook een oogje houden op hoeveel IOPS er door de overige processen gebruikt wordt), kun je denk ik toch wel een redelijke indicatie maken. Stel je hebt in eerste instantie 8000 IOPS en 2 jaar later heb je onder soortgelijke omstandigheden 4000 IOPS, terwijl je in eerste instantie 40% spare had aangehouden, dan kun je er toch wel vanuit gaan dat van die 40% nog max 10-20% over is. Dat is dan weliswaar geen accurate of gedetailleerde schatting, maar het geeft je toch een grove indicatie over hoe je er nu voor staat en of je al dan niet actie zou moeten ondernemen.

N.B. ik had het niet over een situatie waarin je performance problemen ervaart, maar over een normale situatie waarin je zou willen weten hoe je disks er ongeveer voor staan.

Mikey
28/11/11, 19:27
Mij iets te omslachtig en zeker niet accuraat genoeg om daar je klanten en productie omgeving aan op te hangen. Maar goed ieder zijn eigen methodiek ;)

Apoc
28/11/11, 20:36
Mij iets te omslachtig en zeker niet accuraat genoeg om daar je klanten en productie omgeving aan op te hangen. Maar goed ieder zijn eigen methodiek ;)

Heb jij een andere methodiek waarmee je een indicatie van de levensduur kunt maken dan?

Mikey
28/11/11, 21:00
Heb jij een andere methodiek waarmee je een indicatie van de levensduur kunt maken dan?

Zolang er geen tools voor zijn die dit accuraat kunnen live in een array is er geen methodiek. Dikke vinger werk, en gokken op basis van een benchmark.... Tja veel plezier ermee. Ik laat die methodiek in ieder geval aan mij voorbij gaan. En ga alvast glimlachen als die methode toch niet zo succesvol blijkt te zijn achteraf :)

mind
28/11/11, 22:31
Kan je dat bij een Intel niet gewoon via SMART er uit vissen?

http://download.intel.com/support/ssdc/hpssd/sb/intel_ssd_toolbox_user_guide.pdf

E8 – Available Reserved Space
This attribute reports the number of reserve blocks remaining. The attribute value begins at 100 (64h), which indicates that the reserved space is 100 percent available. The threshold value for this attribute is 10 percent availability, which indicates that the drive is close to its end of life. Use the Normalized value for this attribute.

Is volgens mij aardig wat je wil weten.

Mikey
29/11/11, 00:19
Ik was in mijn leeswerk al wat tooltjes etc etc tegen gekomen. Maar als ik vanuit onze eigen situatie kijken kunnen we hier niets mee. Als ze eenmaal in de san in de array zitten kunnen we de disken niet meer los aanspreken. Ik denk dat het voor ons gewoon te vroeg is om naar ssd's uit te kijken. De fabrikanten zullen met verschillende storage bouwers en raid boeren eerst fatsoenlijk monitoring etc etc moeten integreren. Maar ik zal de ontwikkeling in ieder geval goed in de gaten houden. De eerste enclosure die goed kan monitoren zou zeer zeker de moeite waard zijn.

Cakkie
29/11/11, 11:48
Waar komt die snelheidswinst eigenlijk vandaan? Is dat gewoon omdat hij een grotere pool available cells heeft om op te schrijven en dus meer mogelijkheden heeft om alles sequencieel weg te schrijven (=minder overhead?), of komt dat ergens anders vandaan? Bij short-stripen van een normale HD is daar een zeer logische verklaring voor (hogere snelheid, kleinere afstand van de heads), maar bij SSD's kan ik niet meteen een uitleg vinden voor het verschil tussen sequential en random access.

Yourwebhoster
29/11/11, 11:53
Waar komt die snelheidswinst eigenlijk vandaan? Is dat gewoon omdat hij een grotere pool available cells heeft om op te schrijven en dus meer mogelijkheden heeft om alles sequencieel weg te schrijven (=minder overhead?), of komt dat ergens anders vandaan? Bij short-stripen van een normale HD is daar een zeer logische verklaring voor (hogere snelheid, kleinere afstand van de heads), maar bij SSD's kan ik niet meteen een uitleg vinden voor het verschil tussen sequential en random access.
Ik denk dat je eerst moet uitzoeken wat een SSD is en wat de werking ervan is (http://nl.wikipedia.org/wiki/Solid-state_drive). Dan snap je het wel, het is niet te vergelijken met traditionele schijven.

t.bloo
29/11/11, 12:15
Dan snap je het wel, het is niet te vergelijken met traditionele schijven.

Daarom snappen Cakkie en ik dus niet waarom sequential zoveel sneller blijft als random...

Cakkie
29/11/11, 13:00
Ik denk dat je eerst moet uitzoeken wat een SSD is en wat de werking ervan is (http://nl.wikipedia.org/wiki/Solid-state_drive). Dan snap je het wel, het is niet te vergelijken met traditionele schijven.Leg mij dan eens uit waarom dat is? Met betrekking tot sequencieel tot random staat er in het door jou aangedragen artikel enkel "Gegevens kunnen - maakt niet uit waar ze zijn opgeslagen - altijd even snel gezocht worden". Met betrekking tot writes staat er enkel wat over trim, maar over de relatie tussen trim en de hoeveelheid beschikbare cellen wordt niets gezegd, en aangezien de bedoeling van trim net is om deze operaties op voorhand uit te voeren, zie ik ook niet meteen hoe dit de schrijfsnelheid bij grotere aantallen beschikbare cellen zou beinvloeden (tenzij je echt met extreem lage aantallen zou werken en trim gewoon nog niet voldoende cellen heeft vrijgemaakt). Het artikeltje van Intel stelt eingelijk gewoon dat het zo is, maar is heel vaag over waarom dit is, vandaar dus mijn vraag.

Yourwebhoster
29/11/11, 13:41
Leg mij dan eens uit waarom dat is? Met betrekking tot sequencieel tot random staat er in het door jou aangedragen artikel enkel "Gegevens kunnen - maakt niet uit waar ze zijn opgeslagen - altijd even snel gezocht worden". Met betrekking tot writes staat er enkel wat over trim, maar over de relatie tussen trim en de hoeveelheid beschikbare cellen wordt niets gezegd, en aangezien de bedoeling van trim net is om deze operaties op voorhand uit te voeren, zie ik ook niet meteen hoe dit de schrijfsnelheid bij grotere aantallen beschikbare cellen zou beinvloeden (tenzij je echt met extreem lage aantallen zou werken en trim gewoon nog niet voldoende cellen heeft vrijgemaakt). Het artikeltje van Intel stelt eingelijk gewoon dat het zo is, maar is heel vaag over waarom dit is, vandaar dus mijn vraag.
Heb blijkbaar daar over heen gelezen, dacht dat het ging om de snelheid/access time die zoveel beter was.

Wido
29/11/11, 15:08
Leg mij dan eens uit waarom dat is? Met betrekking tot sequencieel tot random staat er in het door jou aangedragen artikel enkel "Gegevens kunnen - maakt niet uit waar ze zijn opgeslagen - altijd even snel gezocht worden". Met betrekking tot writes staat er enkel wat over trim, maar over de relatie tussen trim en de hoeveelheid beschikbare cellen wordt niets gezegd, en aangezien de bedoeling van trim net is om deze operaties op voorhand uit te voeren, zie ik ook niet meteen hoe dit de schrijfsnelheid bij grotere aantallen beschikbare cellen zou beinvloeden (tenzij je echt met extreem lage aantallen zou werken en trim gewoon nog niet voldoende cellen heeft vrijgemaakt). Het artikeltje van Intel stelt eingelijk gewoon dat het zo is, maar is heel vaag over waarom dit is, vandaar dus mijn vraag.Je hebt te maken met de erase tijd van een SSD, maar ook de interne page size.

Een SSD bestaat intern uit pages, groepen van cellen bij elkaar. Deze pages zijn 256kb groot (vaak!), maar zodra je één bit in deze page wil veranderen moet je de gehele page herprogrammeren.

Het herprogrammeren gaat:
1. Contents lezen
2. Page erasen
3. Nieuwe content schrijven

Vooral stap 2 duurt het langste, als er reserve pages zijn kan de nieuwe content direct worden geschreven in een leeg staande page, waarna de oude page op de achtergrond kan worden gewist.

Ga je random I/O's doen dan moet je heel veel pages herschrijven en dat kost veel tijd.

maxnet
29/11/11, 15:29
Waarom random writes bij sommige SSDs veel langzamer zijn dan sequential writes heb ik ook nooit helemaal begrepen.




Ga je random I/O's doen dan moet je heel veel pages herschrijven en dat kost veel tijd.

Hanteren SSDs geen copy-on-write systeem vergelijkbaar met ZFS waarbij wijzigingen niet op de oorspronkelijke page gedaan worden, maar achter elkaar op een nieuwe page gezet worden?

Dan zou alleen de mapping (virtuele sector 123 staat nu niet meer op fysieke page 456 maar op 678) aangepast hoeven te worden.

Apoc
29/11/11, 15:30
Je hebt te maken met de erase tijd van een SSD, maar ook de interne page size.

Een SSD bestaat intern uit pages, groepen van cellen bij elkaar. Deze pages zijn 256kb groot (vaak!), maar zodra je één bit in deze page wil veranderen moet je de gehele page herprogrammeren.

Het herprogrammeren gaat:
1. Contents lezen
2. Page erasen
3. Nieuwe content schrijven

Vooral stap 2 duurt het langste, als er reserve pages zijn kan de nieuwe content direct worden geschreven in een leeg staande page, waarna de oude page op de achtergrond kan worden gewist.

Ga je random I/O's doen dan moet je heel veel pages herschrijven en dat kost veel tijd.

Wido: maar wanneer je (>256kb data) naar meerdere achtereenvolgende pages schrijft, gaat dat sneller dan wanneer je naar willekeurige pages schrijft. Althans - dat is wat ik begreep. Hoe komt dat dan?

Cakkie
29/11/11, 15:56
@wido: dat maakt het al wat duidelijker, maar brengt ook weer wat vragen met zich mee. Als bij het herschrijven van 1 cell de hele page herschreven moet worden, wil dat dan ook niet zeggen dat elke cell in een page even veel keer beschreven is (en dus theoretisch rond hetzelfde moment de geest zou geven).

De sequential vs random kan ik dan wel begrijpen. Een file van 1MB heeft dan 4 pages nodig om weg te schrijven, waar bij een random dit hoger kan liggen. Er van uit gaande dat een SSD zijn gegevens stiped over de verschillende chips, is de kans groter bij meer pages dat er op dezelfde chip geschreven moet worden en dat kan dan niet concurrent. Meer beschikbare cells/pages wil dan ook zeggen dat er meer kans is om dit zo optimaal mogelijk te kunnen doen. (dat maak ik er dan van, niet technisch onderbouwd)

Mikey
12/12/11, 18:49
Ik heb in ieder geval een manier gevonden om drives individueel te counten op read, write en total. Ik kon dit al op array niveau maar nooit echt gekeken door de mibs heen of dit ook per drive kan



Name/OID: raidv4PhydrvStatsDataTransferred.1.11; Value (Counter64): 34617289728
Name/OID: raidv4PhydrvStatsDataTransferred.1.12; Value (Counter64): 34613740544
Name/OID: raidv4PhydrvStatsReadDataTransferred.1.11; Value (Counter64): 6177792
Name/OID: raidv4PhydrvStatsReadDataTransferred.1.12; Value (Counter64): 7880704
Name/OID: raidv4PhydrvStatsWriteDataTransferred.1.11; Value (Counter64): 34611111936
Name/OID: raidv4PhydrvStatsWriteDataTransferred.1.12; Value (Counter64): 34605859840


Voor een array had ik in nagios al verschillende stats:
9941


Ik ga hier in ieder geval in het nieuwe jaar met een nieuw sybsysteem mee stoeien. Aan de write stats zou ik dus kunnen bepalen of ik een groep ssd's ga vervangen of niet.

Rubra
12/12/11, 20:54
Ik loop al een tijdje te dubben of ik mijn Zabbix en Observium servers zou moeten gaan uitrusten met SSD's.

Qua IOPS gaat het waarschijnlijk een verademing zijn. Ik heb de beslissing nog niet genomen, dus ik blijf dit draadje nog even volgen.

Heeft iemand hier al ervaring mee btw ?

Apoc
12/12/11, 21:29
Ik heb het nog niet heel uitgebreid getest, maar wel een monitoring server op een SSD draaien, en dat loopt als de brandweer. Dat kan zeker de moeite waard zijn. Is ook vrij logisch, want in een beetje monitoring omgeving heb je natuurlijk al snel te maken met zeer veel reads en writes.

The-BosS
12/12/11, 22:24
Van observium weet ik dat ze zelf aanraden om ramdisks te gebruiken (die na x aantal tijd op hd backupen) in plaats van ssd's, omdat rrd nogal wat raar in elkaar zit en niet echt een update doet maar de volledige file update. Dit merk je trouwens ook als je een nieuwe rrd file aanmaakt dat die direct xxxMB groot is, bij ssd's moet je dus de volledige rrd file herschijven en dat zou voor de levensduur van een ssd's wel eens parten kunnen spelen. De vraag is natuurlijk ook wat je allemaal monitored en hoeveel devices, als je bvb syslog etc ook doet dan kan ssd hiervoor wel eens duur worden als je bvb 5GB aan logs per dag hebt.

Yourwebhoster
12/12/11, 22:53
Van observium weet ik dat ze zelf aanraden om ramdisks te gebruiken (die na x aantal tijd op hd backupen) in plaats van ssd's, omdat rrd nogal wat raar in elkaar zit en niet echt een update doet maar de volledige file update. Dit merk je trouwens ook als je een nieuwe rrd file aanmaakt dat die direct xxxMB groot is, bij ssd's moet je dus de volledige rrd file herschijven en dat zou voor de levensduur van een ssd's wel eens parten kunnen spelen. De vraag is natuurlijk ook wat je allemaal monitored en hoeveel devices, als je bvb syslog etc ook doet dan kan ssd hiervoor wel eens duur worden als je bvb 5GB aan logs per dag hebt.
Wat als je server plotseling uitvalt? Dan ben je die data dus gewoon kwijt, sommigen vinden het niet cruciaal maar je hebt soms te maken met management die cijfertjes willen. Wat is dan de oplossing?

The-BosS
13/12/11, 00:25
Wat als je server plotseling uitvalt? Dan ben je die data dus gewoon kwijt, sommigen vinden het niet cruciaal maar je hebt soms te maken met management die cijfertjes willen. Wat is dan de oplossing?

Je kunt zelf instellen om de hoeveel tijd je je ramdisk wegschijft naar de hd, als je dat 1 maal per uur doet is het niet echt een ramp als je een uurtje kwijt bent aan rrd grafiekjes. En als het management het dan toch zo cruciaal vindt dan voer je je monitoring toch gewoon redundant uit.

Mikey
13/12/11, 00:55
Wat als je server plotseling uitvalt? Dan ben je die data dus gewoon kwijt, sommigen vinden het niet cruciaal maar je hebt soms te maken met management die cijfertjes willen. Wat is dan de oplossing?

Partijen die zich druk maken over cijfertjes, zijn gewend om te betalen voor de cijfertjes en maken zich in de regel absoluut niet meer druk om de portemonnee. Maw al zet je er 5 neer, niemand die zich daar druk over maakt.

Yourwebhoster
13/12/11, 08:50
Partijen die zich druk maken over cijfertjes, zijn gewend om te betalen voor de cijfertjes en maken zich in de regel absoluut niet meer druk om de portemonnee. Maw al zet je er 5 neer, niemand die zich daar druk over maakt.
Daar vergis je je toch sterk in. Het management wilt graag dat alles binnen de limieten stelt anders moeten maatregelen genomen worden om de gewenste resultaat (lees uptime/beschikbaarheid) te kunnen halen. Ik zal geen voorbeelden noemen, maar die cijfers zijn in sommige gevallen belangrijker dan je denkt.

Mikey
13/12/11, 11:28
Daar vergis je je toch sterk in. Het management wilt graag dat alles binnen de limieten stelt anders moeten maatregelen genomen worden om de gewenste resultaat (lees uptime/beschikbaarheid) te kunnen halen. Ik zal geen voorbeelden noemen, maar die cijfers zijn in sommige gevallen belangrijker dan je denkt.

Lees nou nog eens een keer goed wat er staat. Ik schrijf nergens dat ik me vergis in hoe belangrijk men het vind. We hadden het over monitoring en het uitvallen ervan. Wanneer men de cijfertjes zo belangrijk vind, vind men het ook totaal niet erg als er uit verschillende hoeken gemonitord gaat worden. Waarbij je dus de eventuele uitval van een satellite gewoon op kan vangen door de andere satellites. Dus nogmaals; als er veel waarde gehecht wordt aan cijfertjes en rapportages dan wil men hier ook voor betalen.

Yourwebhoster
13/12/11, 11:41
Lees nou nog eens een keer goed wat er staat. Ik schrijf nergens dat ik me vergis in hoe belangrijk men het vind. We hadden het over monitoring en het uitvallen ervan. Wanneer men de cijfertjes zo belangrijk vind, vind men het ook totaal niet erg als er uit verschillende hoeken gemonitord gaat worden. Waarbij je dus de eventuele uitval van een satellite gewoon op kan vangen door de andere satellites. Dus nogmaals; als er veel waarde gehecht wordt aan cijfertjes en rapportages dan wil men hier ook voor betalen.
excuus.

Lite-On
16/12/11, 00:09
Ik gebruik zelf al voor langere tijd SSDs zijn mijn servers. Zeer tevreden over!
Levensduur m.b.t SSD's is in mijn ogen iets waar tegenwoordig eigenlijk niet meer naar gekeken hoeft te worden. In een database cluster draai ik nu al +/- 3 jaar lang een paar OCZ schijfjes van 60GB (ja, de oude Vertex 2 serie welke nog geen rotte controller heeft welke wel te vinden is in hedendaagse OCZ Vertex SSDs ;-) ). Wordt enorm veel I/O op los gelaten (vrijwel continu 50MB/s+ aan write), en nog altijd werken deze SSD's goed (smart logs zijn tevens nog helemaal schoon).
Een gemiddelde server doet bij lange na niet zoveel I/O als dit zware SQL clustertje ;-) Al met al maak ik me niet meer druk om de levensduur, er worden maar weinig servers voor 10 jaar of langer gebruikt - tegen die tijd is het gros van de machines al weer gerecycled ;-).
Tevens zijn moderne SSD's veel beter als SSD's van elke jaren terug - de levensduur van de cellen (full erase cycles) is flink vooruit gegaan, maar ook de controllers zijn beter ontworpen waardoor geheugen cellen efficiënter gebruikt worden en daardoor langer mee gaan.

In de start post van dit topic werkt gesproken over een Intel 320 serie SSD. Mijn advies (gebaseerd op eigen ervaring) is om niet te beginnen aan deze SSD's. Vergeleken met concurrentie zijn de SSD's kwa prijs/kwaliteit niet aantrekkelijk - performance is belabberd vergeleken met vergelijkbare SSD's van bijvoorbeeld Crucial.

Zelfs heb ik 1,5 week geleden een paar nieuwe 512GB SSD's besteld. Na veel research uitgekomen op de Samsung 830 SSD.
Ter vergelijking; een Intel 320GB 512GB SSD is de helft trager kwa IOPS + seq. speed t.o.v de Samsung, en ook nog eens een paar honderd euro duurder.
De Samsung 830GB SSD heeft in mijn ogen een zeer goede prijs/kwaliteit verhouding - een snellere SSD (in deze prijsklasse) ben ik op dit moment niet tegengekomen.
Deze SSD's (256GB / 512GB) hebben de volgende specs:
Seq. read: 520MB/s
Seq. write: 400MB/s
Random IOPS: 80.000
Random IOPS: 36.000
De opgegeven read/write speeds worden hier ook daadwerkelijk gehaald :)

Voorheen gebruikte ik voornamelijk Crucial M4s. Ook over deze SSD's ben ik zeer tevreden, echter toch de overstap gemaakt naar de Samsung 830. De Samsung is iets sneller, en het 512GB exemplaar was "slechts" 3 tientjes meer :)
De huidige OCZ Vertexen (en volgens mij ook nog een paar andere modellen) worden nog altijd geleverd met een brakke controller, en staan er bekend om dat deze soms naar de eerste paar dagen al kapot gaan - niet aan beginnen dus :)

SAS15k schijven, no thanks - SSD's doen het hier een stuk beter, zowel kwa performance als levensduur.
Voor mensen welke nog zitten te twijfelen over de levensduur/betrouwbaarheid - lees eens wat reviews, grootste onzin tegenwoordig ;-)

Apoc
16/12/11, 13:03
Levensduur m.b.t SSD's is in mijn ogen iets waar tegenwoordig eigenlijk niet meer naar gekeken hoeft te worden.

Dat is bijna hetzelfde als stellen dat omdat een server al jaren niet gehackt is, beveiliging overbodig is.


Voor mensen welke nog zitten te twijfelen over de levensduur/betrouwbaarheid - lees eens wat reviews, grootste onzin tegenwoordig ;-)

Wat jij hier stelt is juist de grootste onzin. Levensduur is juist bij SSDs relevant, omdat elke cell maar een X aantal keer beschreven/herbeschreven kan worden. Tuurlijk zal het lang goed gaan, maar het is uitdrukkelijk belangrijk om een oogje te houden op de levensduur.

maxnet
16/12/11, 14:10
Levensduur is juist bij SSDs relevant, omdat elke cell maar een X aantal keer beschreven/herbeschreven kan worden.

Aantal keer dat je ze kan beschrijven is een theoretisch iets.

Je kan het ook anders zien.
Volgens de hardware.fr RMA cijfers (http://www.hardware.fr/articles/843-6/disques-durs.html) ligt het RMA percentage van een grote Franse webshop voor Intel SSDs op 0.1% en dat van WD schijven op 2%
Zou dus juist bij reguliere schijven op moeten letten dat je ze niet te zwaar belast en genoeg redudantie hebt.
Die gaan misschien niet in theorie, maar in de praktijk 20x zo vaak stuk. :)

Ramon Fincken
16/12/11, 14:13
Aantal keer dat je ze kan beschrijven is een theoretisch iets.

Je kan het ook anders zien.
Volgens de hardware.fr RMA cijfers (http://www.hardware.fr/articles/843-6/disques-durs.html) ligt het RMA percentage van een grote Franse webshop voor Intel SSDs op 0.1% en dat van WD schijven op 2%
Zou dus juist bij reguliere schijven op moeten letten dat je ze niet te zwaar belast en genoeg redudantie hebt.
Die gaan misschien niet in theorie, maar in de praktijk 20x zo vaak stuk. :)


eh... op welke leeftijd van de schijven?

Bovendien klopt je cijfer quote geheel niet. In die RMA cijfers staat nergens 0.1 percent, het komt alleen als commentaar van iemand langs.

maxnet
16/12/11, 14:21
Bovendien klopt je cijfer quote geheel niet. In die RMA cijfers staat nergens 0.1 percent, het komt alleen als commentaar van iemand langs.

Pagina verder gekeken?



Les SSD

- Intel 0,1% (contre 0,3%)


(over OCZ zullen we het maar niet hebben :))

Ramon Fincken
16/12/11, 14:28
Grumbl .. link dan ook even naar normale HDDs en SSD .. mijn Frans is slecht en ik zocht dus op je 0.1 percent op de pagina ..

hoe dan ook .. blijft de vraag staan .. hoe-oud zijn al die schijven gemiddeld voor de naar RMA gaan? Direct? of al gebruikt?

maxnet
16/12/11, 14:35
hoe dan ook .. blijft de vraag staan .. hoe-oud zijn al die schijven gemiddeld voor de naar RMA gaan? Direct? of al gebruikt?

Onderzoek gaat om producten die binnen een jaar stuk gingen.



Les taux de retour rapportés concernent les pièces vendues entre le 1er octobre 2010 et le 1er avril 2011, pour des retours crées avant octobre 2011, soit 6 mois à 1 an de fonctionnement.

Ramon Fincken
16/12/11, 14:36
Thanks voor de opheldering! Ik was wellicht wat te snel.

Apoc
16/12/11, 15:05
Aantal keer dat je ze kan beschrijven is een theoretisch iets.

Je kan het ook anders zien.
Volgens de hardware.fr RMA cijfers (http://www.hardware.fr/articles/843-6/disques-durs.html) ligt het RMA percentage van een grote Franse webshop voor Intel SSDs op 0.1% en dat van WD schijven op 2%
Zou dus juist bij reguliere schijven op moeten letten dat je ze niet te zwaar belast en genoeg redudantie hebt.
Die gaan misschien niet in theorie, maar in de praktijk 20x zo vaak stuk. :)

Dat zijn uiteraard nogal onzinnige cijfertjes. Het merendeel van die SSDs is nog niet heel lang in gebruik. Ze zijn nog zeker niet lang genoeg in de markt om er een op feiten gebaseerde conclusie uit te trekken.

Apoc
16/12/11, 15:06
Onderzoek gaat om producten die binnen een jaar stuk gingen.

Hetgeen dus vrij weinig over de levensduur zegt.

Wido
16/12/11, 15:28
Dat zijn uiteraard nogal onzinnige cijfertjes. Het merendeel van die SSDs is nog niet heel lang in gebruik. Ze zijn nog zeker niet lang genoeg in de markt om er een op feiten gebaseerde conclusie uit te trekken.Ik kan hier nog aan toevoegen dat wij de Intel SSD's nu al meerdere jaren (sinds 2009) in gebruik hebben en nog geen ENKELE uitval hebben gezien of iets in de trand van data corruptie.

Lite-On
16/12/11, 16:09
Ik kan hier nog aan toevoegen dat wij de Intel SSD's nu al meerdere jaren (sinds 2009) in gebruik hebben en nog geen ENKELE uitval hebben gezien of iets in de trand van data corruptie.

Juist, en hier in diverse DB / Web / Monitoring servers al jaren SSD's waar ik gewoon super over te spreken ben.
In een zware DB cluster welke ik enkele post al had genoemd had ik eerlijk gezegd verwacht dat er wel een SSD na 3 jaar zware I/O de geest zou hebben gegeven, maar dat is toch heden niet het geval.

Wanneer je een GOEDE (dus geen budget brol) neemt waar een GOEDE controller inzit (waaronder Intel, Crucial, Samsung) heb je er jaren plezier van - zelfs wanneer je alleen maar write acties op dat ding los laat.
Hedendaagse OCZ SSD's met een Sandforce controller moet je vermijden - deze staan bekend om de hoge uitval.
Tijdens mijn research van 1,5 week kwam ik nog een interessant artikel tegen - dit was een vrij oud artikel (2008), en ging over de eerste Intel X25-E SSD's. Daarin was een rekensom te vinden m.b.t wear levelling:

If we combine all the factors that Intel says affect solid-state drive longevity, we come up with the following formula for cycling:
Cycles = (Host writes) * (Write amplification factor) * (Wear leveling factor) / (Drive capacity)

With write amplification and wear leveling efficiency factors of 1.1, and 20GB of write-erase requests per day for five years, we should only burn through 1380 cycles on the X25-E Extreme.
The same workload on what Intel defines as a "traditional" SSD, with a write amplification factor of 20 and a wear-leveling efficiency of three, consumes more than 68,000 cycles.
We don't want to rely too much on Intel's likely pessimistic assessment of the wear leveling efficiency and write amplification factors of other solid-state drives,
but other SSD makers haven't been able to give us equivalent numbers of their own.The X25-E Extreme's expected lifespan will, of course,
depend on how many gigabytes of write-erase operations are thrown at it. Even with 100GB of write-erase per day, it'll take more than 72 years to burn through the drive.
Couple that with the Extreme's two-million-hour Mean Time Between Failures (MTBF) rating, and one can probably expect the drive to last.


Bron: http://techreport.com/articles.x/15931 (interessant artikel, zeker de moeite waard om eens door te nemen)
100GB full erase cycles, en dat voor 72 jaar. Zeg dat een ssd 10 jaar mee gaat, dan kun je alsnog 700GB data per dag wegschrijven op zo'n X25-E uit de eerste batch :)
Vergeet daarbij niet dat de degelijke / high end SSD's welke momenteel op de markt zijn betere controllers (betere efficiëntie van geheugen cellen gebruik) en geheugen cellen hebben (ik las laatst dat deze met een factor 10 verbeterd zijn kwa full erase cycles, of dat daadwerkelijk in productie zo is blijft natuurlijk de vraag - maar het zal ongetwijfeld een stuk beter zijn dan 4 jaar geleden)

Bij de meeste SSD's kun je in de SMART status ook uitlezen in welke staat deze verkeerd (Wear Levelling).
Mocht er alsnog een cel kapot gaan wordt deze automatisch "uitgeschakeld" - een degelijke SSD heeft altijd wel een aantal reserve cellen las ik in een review.

Mijn ervaring met SSD's is vele malen beter als SAS schijven. Zowel kwa performance als betrouwbaarheid. Ik heb het wat dat betreft helemaal gehad met SAS schijven :)

systemdeveloper
16/12/11, 16:23
Mijn enige probleem met ssd's is geweest dat bij een stroomstoring een paar 'dood' leken en niet meer herkend werden door de (goede) controller.
Thuis aangesloten op esata en ding bleek gewoon goed te zijn.
Overigens was dat wel die rotzooi van ocz (imho kun je dat geld beter omzetten in bier).

Een intel is hier in 2-3 jaar nog niet kapot gegaan. Als ik zo even kijk verstoken de ssd db servers gem. rond de 40mbit.
Dus voorlopig ben ik nog wel happy met die dingetjes.

maxnet
16/12/11, 18:13
Dat zijn uiteraard nogal onzinnige cijfertjes. Het merendeel van die SSDs is nog niet heel lang in gebruik. Ze zijn nog zeker niet lang genoeg in de markt om er een op feiten gebaseerde conclusie uit te trekken.

Dat SSDs pas een jaar of vier gemeengoed zijn klopt.

Maar in hoeverre zijn de normale harde schijven die vandaag in de winkel liggen, te vergelijken met die van een paar jaar terug?
Kan me zo voorstellen dat om de dichtheid te krijgen die je nu hebt (denk aan 1,5 TB in een 2.5" form factor), men op dat vlak ook wat nieuwere technieken gebruikt.
En dat ook die technieken niet zonder risico op dataverlies zijn.


Bovendien kan je de levensduur van een SSD eenvoudig testen door er meer naar toe te schrijven dan je onder normaal gebruik zou doen.
Iets dat bij een bewegende delen schijf minder makkelijk gaat.
Kan moeilijk het toerental wat opvoeren...

Apoc
19/12/11, 13:08
Klopt allemaal helemaal.. ik stelde enkel dat het onzin is om te stellen dat het onnodig is om de levensduur van SSDs in de gaten te houden (zoals Lite-on stelde). Daarmee impliceer ik verder niets.

Paul Z.
31/12/11, 18:21
Heeft iemand wel eens getest met deze kaarten: http://www.ramsan.com/products/pcie-storage/ramsan-70 ? Ik heb geen idee wat ze kosten (zal wel een heleboel wezen!) maar ik ben gewoon benieuwd wat de "real life" ervaringen zijn...

pcman
02/01/12, 09:06
Iemand ervaring met deze raid kaart?
http://www.lsi.com/channel/products/storagecomponents/Pages/MegaRAIDSAS9265-8i.aspx
Deze zouden vooral voor ssd interresant zijn

maxnet
02/01/12, 15:41
Heeft iemand wel eens getest met deze kaarten: http://www.ramsan.com/products/pcie-storage/ramsan-70 ? Ik heb geen idee wat ze kosten (zal wel een heleboel wezen!) maar ik ben gewoon benieuwd wat de "real life" ervaringen zijn...

Begrepen dat de vanaf prijs rond de 10k ligt.
En da's meteen het probleem van dit soort oplossingen.
Doordat deze stevig geprijst zijn, is de oplage waarschijnlijk niet al te hoog.

Heb daarom liever een "consumenten" product waar er een miljoen van verkocht zijn, en er daardoor een grotere kans is dat alle firmware bugs ondertussen wel gevonden en opgelost zijn, dan iets waar een "enterprise" stickertje op zit.

maxnet
02/01/12, 15:43
Iemand ervaring met deze raid kaart?
http://www.lsi.com/channel/products/storagecomponents/Pages/MegaRAIDSAS9265-8i.aspx
Deze zouden vooral voor ssd interresant zijn

Heb het idee dat dit meer marketing praat is.

Staat nergens dat ie TRIM doet.
Alleen dat ie een spare gaat gebruiken op het moment dat de SMART aangeeft dat de schijf het gaat begeven:



MegaRAID controllers are built on the proven MegaRAID stack and include numerous features to support high reliability and data protection. These features include SSD Guard™ technology that automatically copies data from a drive with potential to fail to a designated spare or newly inserted drive. A predictive failure event notification, or S.M.A.R.T command, automatically initiates this rebuild to preserve the data on an SSD whose health or performance falls below par.


Dat zouden ze bij reguliere schijven ook wel eens mogen doen.... :)

DDX
02/01/12, 16:22
Iemand ervaring met SSD als cache op de dell H700/H800 controllers (of LSI waar het origineel vandaan komt?) :

http://lonesysadmin.net/2011/06/01/dell-ssd-cachecade-and-h700h800-controllers/

koendejonge
24/01/12, 00:53
Heeft iemand wel eens getest met deze kaarten: http://www.ramsan.com/products/pcie-storage/ramsan-70 ? Ik heb geen idee wat ze kosten (zal wel een heleboel wezen!) maar ik ben gewoon benieuwd wat de "real life" ervaringen zijn...

Dan is de ddrdrive http://www.ddrdrive.com een stuk aantrekkelijker geprijst en als je die dan neemt in combinatie met een paar 400GB STEC ZeusIOPS enterprise SSD drives en je gebruikt een ZFS gebaseerde oplossing, bijvoorbeeld Nexenta of OpenIndiana, dan heb je voor een fractie van de prijs meer IOPS en meer capaciteit.

Die ramsan kaarten zijn met name interessant als je een echt heel IOPS-vretende applicatie hebt die echt veel geld oplevert en toch 450GB of 900GB aan continue te-updaten informatie hebt. Dat zijn dus typisch transactieverwerkende systemen in de financiele wereld en dat is dan ook precies waarop die kaart getarget is. Als je met een aandelenhandelend systeem miljoenen kunt verdienen door sneller transacties te doen en waarschijnlijkheidsberekeningen te maken, dan is 10K+ euro/dollar voor een paar van die kaarten geen enkel probleem.

Voor hostingtoepassingen is dit waarschijnlijk niet interessant genoeg. Meestal kun je de load namelijk eenvoudig verdelen over meerdere systemen en dan geef je die 10K+ euro/dollar liever uit aan wat meer verschillende systemen lijkt me.