Reden om geen SSD te gebruiken voor server

Citaat:

---

Oorspronkelijk geplaatst door maxnet

Intel heeft een white paper over onder-partitioneren: http://cache-www.intel.com/cd/00/00/...555_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).

Citaat:

---

Oorspronkelijk geplaatst door maxnet

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?

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 :)

Citaat:

---

Oorspronkelijk geplaatst door Apoc

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.

Citaat:

---

Oorspronkelijk geplaatst door Wido

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.

Citaat:

---

Oorspronkelijk geplaatst door Apoc

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.

Citaat:

---

Oorspronkelijk geplaatst door dicktump

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

Citaat:

---

Oorspronkelijk geplaatst door maxnet

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.

Citaat:

---

Oorspronkelijk geplaatst door Mikey

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.

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 ;)

Citaat:

---

Oorspronkelijk geplaatst door Mikey

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?

Citaat:

---

Oorspronkelijk geplaatst door Apoc

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 :)

Kan je dat bij een Intel niet gewoon via SMART er uit vissen?

http://download.intel.com/support/ss...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.

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.

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.

Citaat:

---

Oorspronkelijk geplaatst door Cakkie

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. Dan snap je het wel, het is niet te vergelijken met traditionele schijven.