Onderwerp: Reden om geen SSD te gebruiken voor server

Oorspronkelijk geplaatst door Yourwebhoster

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

Oorspronkelijk geplaatst door Yourwebhoster

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.

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.

Oorspronkelijk geplaatst door Cakkie

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.

Oorspronkelijk geplaatst door Cakkie

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.

Waarom random writes bij sommige SSDs veel langzamer zijn dan sequential writes heb ik ook nooit helemaal begrepen.

Oorspronkelijk geplaatst door Wido

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.

Oorspronkelijk geplaatst door Wido

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?

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

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

Code:

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:



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.

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 ?

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.

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.

Oorspronkelijk geplaatst door The-BosS

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?

Oorspronkelijk geplaatst door Yourwebhoster

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.

Oorspronkelijk geplaatst door Yourwebhoster

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.

Oorspronkelijk geplaatst door Mikey

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.