RAID 10 SSD voor database?

[Niemand_Anders]

Binnenkort moet ik een in-house productie database server vervangen. De huidige server is een HP DL380 G5 met 4 146GB SAS drives in RAID 10 aangestuurd door een HP Smart Array 400 controller. De server heeft een Xeon processor welke draait op 2,6Ghz en heeft 16GB geheugen aan boord.

De laatste maanden begint de database server merkbaar trager te worden. Als eerste heb ik uiteraard profiling and tracing gestart op de database zelf. Maar daar kwam weinig uit naar voren. Volgens dan maar Windows zelf profilen. Processor load komt nooit boven de 68% uit en heeft een gemiddelde load (overdag tussen 09.00 en 17.00 uur) van 13%. Daarbuiten zakt de load naar 2 a 3%. MSSQL Server is ingesteld dat deze 1GB (ipv de standaard 128MB) geheugen voor Windows processen behoud. De overige 15GB wordt door de database zelf opgeslokt.

Echter wat opviel bij de hardware profling was dat de disk IO ontzettend hoog was. De database wordt exclusief gebruikt door Analysis Services en Reporting Services.

Nu heb ik zelf thuis een Intel X-25M SSD als bootdrive en ben zeer tevreden met de performance. Via Google ben ik inmiddels (theoretisch) al een aardige export wat betreft SSD drives. Echter een zoektocht op SSD en RAID levert vooral consumenten configuraties op en eigenlijk geen enterprise informatie.

Nu weet ik dat SAS controllers ook SATA drives kunnen aansturen. Een Archief server bij ons heeft al 8 1,5TB SATA drives (in RAID 10 - 2x4 array) met 2 spares. Ik verwacht niet dat 15K SAS drives heel erg veel meer performance zullen opleveren dan de huidige 10K SAS drives.

Daarom gaat momenteel mijn aandacht vooral uit naar SSD disks. SSD drives hebben een vergelijkbaar prijskaartje als de betere SAS drives, echter de performance van zowel lees/schrijf IO als access times zijn vele malen beter. Het enigste nadeel welke ik momenteel kan vinden is de beperkte levensduur van zo'n 10.000 schrijf acties per cel. Een database server heeft bij ons een gemiddelde levensduur van zo'n 1,5 tot 2 jaar.

Windows Server 2008 R2 heeft net als Windows 7 een aantal optimalisaties voor SSD drives (zoals trim) aanboord en alle aanbevelingen welke voor Windows 7 worden gegeven (zoals idle defrag uitschakelen) kan ik ook onder Windows Server 2008 terug vinden, dus ook op dat vlak verwacht ik geen problemen.

In erg veel reviews komen de Corsair P128 en G.Skill Falcon 128 SSD drives als winnaars uit de bus. Helaas heb ik nog geen toestemming gekregen om 4 SSD drives aan te schaffen om een goede test uit te voeren, voornamelijk omdat SSD fabrikanten MTBF blijven communiceren, terwijl dat nergens op slaat bij een SSD drives en dat weet (helaas) zelfs mijn baas. De betrouwbaar van SSD drives wordt momenteel voornamelijk bepaald door de controller en het leveling algoritme welke de schrijf acties zo gelijk mogelijk over alle cellen moeten verdelen.

Nu wil ik dus eigenlijk een RAID 10 array gaan bouwen op basis van 4 SSD drives en 1 drive als (offline) reserve. De opslag capaciteit van 240GB is meer dan voldoende voor de database server. Het ontbreken van hot-swap mogelijkheden is geen probleem omdat vanwege Windows zelf al van tijd tot tijd een herstarten van updates nodig is. Deze downtime kan dan gebruikt worden om eventueel een defecte schrijf te vervangen..

Nu ben ik vooral op zoek naar jullie ervaringen met SSD RAID10 op professional niveau. Dit kan zijn in een server of grafische en video workstations.

[Microkid]

Waarom raid 10? Raid systemen presteren beter naarmate er meer spindels aan hangen. Dus 5 disks in raid 5 lijkt mij een betere oplossing, zeker als je er een aparte raid controller aan hangt (mogelijk met bbu).

[Gé Brander]

Microkid schreef op zaterdag 04 september 2010 @ 19:53:
Waarom raid 10? Raid systemen presteren beter naarmate er meer spindels aan hangen. Dus 5 disks in raid 5 lijkt mij een betere oplossing, zeker als je er een aparte raid controller aan hangt (mogelijk met bbu).

Als je voor een MSSQL database systeem gaat, ga je bij voorkeur geen RAID 5 gebruiken, tenzij het voor 95% leesacties is dat er in de database gebeurt. RAID 5 heeft een grotere overhead vanwege het berekenen van de parity.

Vanuit Microsoft wordt er aangeraden RAID 1 of RAID 10 te gebruiken bij MSSQL.

Indien dat te kostbaar wordt, of je database is vooral lees gerelateerd, kies dan voor de datafiles RAID 5 en voor de logfiles voor RAID 1 of RAID 10.

Check ook de blog van Paul Randal: http://www.sqlskills.com/...aded-log-file-array).aspx

[ Voor 24% gewijzigd door Gé Brander op 04-09-2010 20:03 ]

[alex3305]

Als het een databaseserver betreft zou ik echter eerder gaan kijken naar SLC schijven in plaats van MLC schijven. Persoonlijk gebruik ik vier enterprise SLC disks van Samsung. Deze waren qua nieuwprijs zo'n 500 - 800 euro per stuk (60GB), maar hebben geen last vaan traagheidssyndromen en hebben dus ook geen zaken zoals TRIM nodig.

Zie ook deze overzicht in de Pricewatch voor meer informatie.

[GlowMouse]

c70070540 schreef op zaterdag 04 september 2010 @ 19:56:
[...]

Als je voor een MSSQL database systeem gaat, ga je bij voorkeur geen RAID 5 gebruiken, tenzij het voor 95% leesacties is dat er in de database gebeurt. RAID 5 heeft een grotere overhead vanwege het berekenen van de parity.

Dat plus de grote load op alle disks bij rebuilden.

Check ook de blog van Paul Randal: http://www.sqlskills.com/...aded-log-file-array).aspx

of http://www.ssdperformanceblog.com/

Ik snap niet waarom je voor mlc-drives gaat. Schrijf je weinig?
Hoeveel zin heeft een hotspare eigenlijk bij ssd's? Je zou verwachten dat ze allemaal rond hetzelfde moment sterven omdat alle cellen evenvaak beschreven worden.

[ItsValium]

Je performance zal zeker hopen verbeteren als je over gaat op SSD's, echter een paar opmerkingen: (even een korte opsomming, sommige zaken zijn al aangehaald)

* Kies voor SLC schijven (mlc is echt niet geschikt voor grote productieomgevingen)
* Kies voor RAID 10, zal je performance alleen maar ten goede komen, dan kan je er nog een jaartje extra uit persen ipv te moeten vernieuwen. (RAID5 of 6 is beperkt door controller!)
* Hou er rekening mee dat de SSD's éénmaal ze beginnen te falen allemaal in diezelfde periode aan vervanging toe zijn.
* TRIM mag je (tot op heden) vergeten als je RAID draait, kan misschien in de toekomst nog veranderen (wie heeft een glazen bol?)
* Zorg ervoor dat je infra de snelheden aankan (één gigabit ethernet verbinding zal niet volstaan).

That's it for now...

[voodooless]

Niemand_Anders schreef op zaterdag 04 september 2010 @ 19:48:In erg veel reviews komen de Corsair P128 en G.Skill Falcon 128 SSD drives als winnaars uit de bus.

jmicron en barefoot... Dat zijn echt niet de beste keuzes voor een enterprice SSD en ik kan me ook niet voorstellen dat deze in actuele reviews als beste uit de bus komen.

Er zijn imho maar twee serieuze opties:

* Sandforce 1500 SSD's met SLC flash
* Intel X25-E

Verder: je zei dat de server een hoge IO load heeft. Wat doet ie dan? Veel lezen, of veel schrijven? In het eerste geval zul je waarschijnlijk veel winst halen door er extra memory bij te prikken.

En verder is er natuurlijk nog een catch als je ze in raid gaat zetten: IO belasting is namelijk vrijwel gelijk over alle drives. Dat betekend dat het verslijt van de disks ook ongeveer gelijk zal zijn. Dat betekend dus ook dat de kans heel groot is dat ze tegelijkertijd zullen falen. De spreiding is in ieder geval veel kleiner dan bij draaiende disks. Voor een dergelijke toepassing zou ik dan zeggen: RAID 6 met minimaal een hot spare.

Je kunt ook nog kijken naar de Adaptec controllers die SSD's als cache kunnen gebruiken. In bepaalde gevallen is de winst best aanzienlijk.

[ Voor 29% gewijzigd door voodooless op 04-09-2010 20:57 ]

[Niemand_Anders]

De MLC drives zijn bedoeld om de performance te testen. De P128 kent ook de 'Self Healing' wat neerkomt op een door de drive zelf geregelde trim. De offline spare is bedoeld mocht een drive het zelf begeven. Er is een reden waarom SSD fabrikanten vaak maar twee jaar garantie geven op de SDD's. Als het onderzoek met de MLC drives volgens verwachting verloopt zullen wij later overstappen naar de Intel X25-E drives in een 3x2 RAID array. De LMC drives zullen dan in workstations worden gebruikt als boot drive.

IO bestaat in dit geval voor 60 tot 70% uit lees acties. RAID 5 en vooral RAID 6 array zijn veels te traag. Bij vrijwel alle raid controllers zijn dan niet de schrijven, maar vormen de parity algoritmes de bottleneck. Omdat de server al een controller bevat (waaraan 18 disks kunnen worden gekoppeld) zijn wij niet van plan om een nieuwe controller aan te schaffen.

Wat betreft de snelheden van het netwerk: Zodra de gigabit netwerk controller de bottleneck wordt ben ik een gelukkig man.

[voodooless]

Niemand_Anders schreef op zaterdag 04 september 2010 @ 23:17:
De MLC drives zijn bedoeld om de performance te testen.

Performance testen doe je toch met de disks die je daadwerkelijk gaat gebruiken? Je gaat ook geen test doen met een F1 auto als je weet dat je daarmee de jungle in moet

IO bestaat in dit geval voor 60 tot 70% uit lees acties.

RAM, RAM, RAM

RAID 5 en vooral RAID 6 array zijn veels te traag. Bij vrijwel alle raid controllers zijn dan niet de schrijven, maar vormen de parity algoritmes de bottleneck.

Dat valt wel mee. Die moderne CPU's kunnen enkele GB/sec aan parity data berekenen. Verder is je IO load voor 60% tot 70% lezen. Dan heb je daar geen last van, en zal zo'n array net zo snel zijn als een RAID10.

[N3oC]

Is PCI SSD wat voor je? Deze zijn voor leesactie echt superieur en behoeven geen raid om giga snelheden te halen.. (kost wat maar dan heb je ook wat )

http://tweakers.net/pricewatch/zoeken/?keyword=PCI+SSD

[Gleighton]

Jammer dat je de tweakers pricewatch niet kan sorteren op PCI, want nu met jou zoekterm vielen er een paar ssd's buiten boord, zoals deze http://tweakers.net/price...ssdpx-1rvd0120-120gb.html

[N3oC]

Gleighton schreef op zondag 05 september 2010 @ 17:54:
Jammer dat je de tweakers pricewatch niet kan sorteren op PCI, want nu met jou zoekterm vielen er een paar ssd's buiten boord, zoals deze http://tweakers.net/price...ssdpx-1rvd0120-120gb.html

Het viel mij idd ook op dat je deze kaarten slecht kan vinden, zoekopdracht was meer ter indicatie

[ Voor 30% gewijzigd door N3oC op 05-09-2010 18:01 ]

[Q]

voodooless schreef op zondag 05 september 2010 @ 13:56:

RAM, RAM, RAM

Hoe groot is je database en hoe groot verwacht je dat die wordt?
Stop bijvoorbeeld gewoon 32 ipv 16 GB in die server als de DB 20 GB is.

RAM is goedkoper en sneller? Hoef je niets met disks te doen. Ook geen risico's met slijtage SSD. Ik denk dat dit laatste wel los loopt maar ik wil er niet proefondervindelijk achter komen.

[Femme]

c70070540 schreef op zaterdag 04 september 2010 @ 19:56:
[...]

Als je voor een MSSQL database systeem gaat, ga je bij voorkeur geen RAID 5 gebruiken, tenzij het voor 95% leesacties is dat er in de database gebeurt. RAID 5 heeft een grotere overhead vanwege het berekenen van de parity.

Vanuit Microsoft wordt er aangeraden RAID 1 of RAID 10 te gebruiken bij MSSQL.

Indien dat te kostbaar wordt, of je database is vooral lees gerelateerd, kies dan voor de datafiles RAID 5 en voor de logfiles voor RAID 1 of RAID 10.

Moderne raidcontrollers hebben totaal geen moeite met raid 5. Raid 5 kan beter presteren dan raid 10, hangt af van de workload. Het voordeel van ssd's is dat je geen hoge read latencies hebt in een read-modify-write cyclus. Een snelle write-back cache doet de rest. Gezien de hoge prijs per gigabyte van ssd zou ik zo weinig mogelijk overhead in de opslag aanbrengen.

N3oC schreef op zondag 05 september 2010 @ 17:48:
Is PCI SSD wat voor je? Deze zijn voor leesactie echt superieur en behoeven geen raid om giga snelheden te halen.. (kost wat maar dan heb je ook wat )

http://tweakers.net/pricewatch/zoeken/?keyword=PCI+SSD

De meeste van die zogenaamde pci express ssd's zijn raid-controllers met daarop een paar ssd-pcb's met flashgeheugen. Het enige voordeel ten opzichte van een losse raidcontroller met losse ssd's is dat het minder ruimte inneemt. Je kunt beter losse onderdelen gebruiken zodat je zelf raid-levels kunt kiezen en kunt hotswappen hotpluggen. Zo'n pci express ssd met een aantal ssd-pcb's in raid 0 zonder redundancy is niet iets dat je in een server wilt gebruiken.

[DexterDee]

Ik weet niet wat je budget is, maar voor onze database server heb ik een FusionIO kaart gekocht. De setup draait inmiddels een maand of 9 en ik zou nooit meer terug willen naar onze vorige 6-disk SAS 15k RAID10 oplossing. Redundancy is een probleem natuurlijk, maar dat hebben we opgelost door replicatie op te zetten naar een backup server met een redundante raid diskopstelling met hotspares. (Overigens kun je 2 van deze kaarten ook in RAID gebruiken, maar aangezien één kaart de prijs heeft van een moderne tweedehands middenklasser, is dit niet voor veel mensen/bedrijven weggelegd).

Zo'n FusionIO kaart rent letterlijk rondjes om een Intel X-25M:

Specification	FusionIO Duo	Intel X25-M
NAND Type	SLC (Single Level Cell)	MLC (Multi Level Cell)
Read Bandwidth (64kB)	1.5 GB/s	250 MB/s
Write Bandwidth (64kB)	1.5 GB/s	100 MB/s
Read IOPS (512 Byte)	261,000	35,000
Write IOPS (512 Byte)	262,000	8,600
Mixed IOPS (75/25 r/w)	238,000	onbekend
Access Latency (512 Byte)	26 µs	75 µs

Door de oogverblindende random IO performance kan de database enorm veel actieve clients tegelijk bedienen. Daarnaast zijn er queries waarbij door o.a. index beperkingen een tablescan gedaan moet worden. Deze queries zijn puur en alleen door deze storage van ca. 30 seconden naar minder dan 1 seconde versneld. Een niet-index LIKE search op een tabel van 10 miljoen records is secondenwerk. Het is niet geheel netjes natuurlijk, maar deze kaart is het meest kosteneffectieve middel om "minder geoptimaliseerde" legacy code drastisch te versnellen. Sinds we deze kaart gebruiken is de process list van de database server vrijwel altijd leeg. En dat terwijl er soms pieken zijn van rond de 5000 queries per seconde. We hebben eerder al wat performance gewonnen door de database machine van 24 Gb RAM te voorzien, maar deze upgrade was vele malen effectiever.

[leuk_he]

Het hele trim verhaal is voor databases veel minder relevant: je maakt 1x de datafiles aan en daarna groeit een database niet meer. (geld niet altijd, maar meestal wel).

de tip hierboven om slc ssd te nemen kan de moeite waard zijn. MLC ssd hebben soms (in bepaald situaties) trage schrijf performance. dat wordt zoveel mogelijk ondervangen door caching wat geregeld wordt door de firmware.

Levensduur is zeker de vraag, maar wellicht wordt dat goed afgevangen door een raid. (Wel goed testen, want als een drive door trimacties ofzo niet meer goed reageert kan hij uit de raid vallen???)

Traditionele databases zijn relatief klein en passen makkelijk op een SSD, echter echte datawarehouse databases zul je wellicht enkel critische onderdelen van de database op de SSD zetten.

DexterDee schreef op maandag 06 september 2010 @ 18:29:
De setup draait inmiddels een maand of 9 en ik zou nooit meer terug willen naar onze vorige 6-disk SAS 15k RAID10 oplossing.

Tja, dat is ook een nadeel, je kunt nooit meer terug.

[BCC]

[b][message=34645968,noline]DexterDee schreef op maandag 06 september 2010 @
Check je indexen.

Ik heb in de praktijk vaak te maken met HELE grote databases en correcte indexen zetten is in 99,9% van de gevallen de oplossing. MSSQL heeft een prachtige profile suite die je hier heel goed bij kan helpen. En daarnaast RAM. Onze DB servers draaien standaard tegenwoordig met 64GB Ram.

SSD's zijn alleen maar nuttig als je perfect getunede database nog steeds meer disk-ios nodig heeft dan je server kan serveren en het onmogelijk is om de load over meerdere machines te verdelen.

[ Voor 46% gewijzigd door BCC op 06-09-2010 18:50 ]

[DexterDee]

BCC schreef op maandag 06 september 2010 @ 18:46:
[...]

Ik heb in de praktijk vaak te maken met HELE grote databases en dit is in 99,9% van de gevallen de oplossing. MSSQL heeft een prachtige profile suite die je hier heel goed bij kan helpen.

Wij werken niet met MSSQL maar met MySQL. Die laatste heeft een aantal serieuze beperkingen ten aanzien van het gebruik van indexen, waardoor het niet slechts een kwestie is van "de juiste indexen aanmaken". Soms ontkom je niet aan temp tables / tablescans.

leuk_he schreef op maandag 06 september 2010 @ 18:43:
Tja, dat is ook een nadeel, je kunt nooit meer terug.

Er wordt al gewerkt aan een nieuw platform, zónder deze supersnelle PCI-SSD kaart, maar mét een mooi Database cluster bestaande uit een groepje servers. Niet zo snel, maar véél beter schaalbaar en redundant

[N3oC]

Femme schreef op maandag 06 september 2010 @ 17:51:

[...]


De meeste van die zogenaamde pci express ssd's zijn raid-controllers met daarop een paar ssd-pcb's met flashgeheugen. Het enige voordeel ten opzichte van een losse raidcontroller met losse ssd's is dat het minder ruimte inneemt. Je kunt beter losse onderdelen gebruiken zodat je zelf raid-levels kunt kiezen en kunt hotswappen hotpluggen. Zo'n pci express ssd met een aantal ssd-pcb's in raid 0 zonder redundancy is niet iets dat je in een server wilt gebruiken.

Als je bijvoorbeeld een Oracle SSD white-paper pakt geven zij als oplossing om SSD als caching mechanisme te gebruiken (en nog wat opties) maar nooit om je hele DB er vanaf te laten draaien. Dit omdat SSD zeer hard kan slijten als de writes hoog zijn.

Mijn advies kwam hieruit voort, storage op HDD regelen maar de DB caching vanaf zo'n ssd regelen. Belangrijke data wil je lijkt mij niet volledig op SSD plaatsen wegens de hoge slijtage op deze schijven. (had misschien iets uitgebreider gemogen)

Zo'n PCI SSD kaart heeft als grote voordeel dat je een zeer grote doorvoer snelheid kan halen (700/800 megabyte) maar geen raid hebt waar je schijven hebt die afzonderlijk kunnen falen.

[BCC]

DexterDee schreef op maandag 06 september 2010 @ 18:55:
[...]
Wij werken niet met MSSQL maar met MySQL. Die laatste heeft een aantal serieuze beperkingen ten aanzien van het gebruik van indexen, waardoor het niet slechts een kwestie is van "de juiste indexen aanmaken". Soms ontkom je niet aan temp tables / tablescans.

Wij werken transparant met beide. Over het algemeen weten we net iets meer performance te persen uit MySQL dan MSSQL, maar daarvoor moet de programmeur vaak wel net wat meer werk verzetten. Voor echt complexe zaken zetten we PostgreSQL in. Trager dan MySQL, maar betere executie plans.

Er wordt al gewerkt aan een nieuw platform, zónder deze supersnelle PCI-SSD kaart, maar mét een mooi Database cluster bestaande uit een groepje servers. Niet zo snel, maar véél beter schaalbaar en redundant

Replication slaves is idd vaak een heel eenvoudige manier om je database load omlaag te krijgen. Maar dan moet wel even je software aanpassen. Redundantie met MSSQL is trouwens belachelijk duur.

[ Voor 5% gewijzigd door BCC op 06-09-2010 21:25 ]

[PcDealer]

SQL Reporting Services 3.0 (SQL Server 2008 R2): is dat niet recommended op een losse server client?
http://www.microsoft.com/...3d1a43ae4e33#Requirements

[Niemand_Anders]

Sorry voor de late reactie, maar ben vandaag pas weer begonnen na drie weken vakantie. Onze database is momenteel 116GB groot. Indexen zijn al optimaal (althans een maand geleden), maar aangezien de queries continue licht wijzigen is optimalisatie een ongoing task welke verder gaat dan alleen het verbeteren van de indexen.

Zelfs met de MLC drives gaat dit experiment ruim 1200 euro kosten. Een 64MB SLC drive kost het dubbele van een 128GB MLC drive. Zou ik de test gaan uitvoeren met SLC drives dan moet ik 8 SLC drives gebruiken en dan liggen de kosten op een kleine 5000 euro.. Aangezien de performance van een SLC drive niet viermaal hoger ligt dan een MLC drive, kan ik deze schrijven eigenlijk momenteel niet verantwoorden naar de directie. De drives zullen over een periode van 9 maanden uitvoering getest.. Over 11 maanden (augustus 2011) moet er een nieuwe server komen voor de OLAP database.

RAID controllers hebben inderdaad vrijwel geen problemen om de parity voor SCSI/SAS/SATA drives te berekenen. In een andere machine hebben wij 16 SAS drives zitten en daar beginnen wij al te merken dat de kaart het niet meer zo leuk vind. Omdat ik niet het risico wil lopen dat de RAID controller straks de bottleneck is hou ik het voorlopig op een RAID 0 opstelling.

Voor de duidelijkheid hebben we het hier over een OLAP database en geen OLTP database. Hoewel beide een relationeel model hebben, worden beide database types heel anders gebruikt. De OLAP database wordt door slechts 2 werknemers gebruikt. Alleen omdat de database blijft groeien, zie ik aan de performance logs dat disk io een steeds groter probleem wordt.

Wat betreft disk IO: Het OS staat op een andere schrijf dan de database. De database heeft nu een dedigated 4 146GB drives in RAID 10 opstelling. Het OS (en de swapfile) staan op een 72GB RAID 1 partitie. En waar disk io van array 0 (OS) vrijwel continue op 1 tot 2% ligt, lag de disk io van array 1 (DB) eerder vandaag (rond 15.00 uur) op 62%. Omdat de dodo welke deze server heeft aangeschaft 8 2GB reepjes in de machine heeft laten plaatsen, kan er niets meer bij..

Wel verwacht ik dat als de disk io bottleneck (grotendeels) verholpen is, dat dan inderdaad het geheugen een probleem zal worden.

Nu weet ik dat SSD drives vooral door consumenten worden gebruikt en bij bedrijven als 'cache' schrijf. Uit mijn eigen omgeving ken ik niemand welke bedrijfs kritische data opslaat op SSD drives. En hoewel de betere performance mijn io bottleneck flink zal verminderen, hoor ik ook verhalen dat nog geen enkele SSD drive fabrikant een garantie langer dan drie jaar durft te geven.. Echter op de Cheetah drives krijg ik 5 jaar garantie.. En volgens de specificaties heeft de Cheetah een lagere MTBF. Dus waarom zo'n korte garantie periode. Bij Intel kan ik zelfs al helemaal geen garantie periode voor de X25-E drives vinden..

Dus nogmaals de vraag: Wie gebruikt er SSD in een enterprise omgeving om bedrijfs kritische data op te slaan, in welke toepassings gebied en hoe lang zijn deze al in gebruik? Heb je al ervaring met defecte disks en hoe ging de leverancier om met de garantie voorwaarden? Ofwel wat zijn jullie ervaringen met SSD's?

[voodooless]

Voor je aan SSD's begint: wat zeg je van het idee om er nog wat RAM bij te zetten?

[BCC]

Volgens mij vraagt de TS steeds hetzelfde: RAID 10 SSD voor database. Iedereen zegt nee: cachen in de applicatie, meer ram, betere indexen db cluster of meer schijven. Dus wat wil je nu nog horen?

[ Voor 77% gewijzigd door BCC op 13-09-2010 19:47 ]

[voodooless]

BCC schreef op maandag 13 september 2010 @ 19:42:
Dus wat wil je nu nog horen?

Wat ik wil horen is niet relevant. De TS wil blijkbaar horen dat zijn plan briljant is en dat hij vooral zijn idee moet doorzetten

[_H_G_]

leuk_he schreef op maandag 06 september 2010 @ 18:43:
Het hele trim verhaal is voor databases veel minder relevant: je maakt 1x de datafiles aan en daarna groeit een database niet meer. (geld niet altijd, maar meestal wel).

Dat boeit niet echt. De wearleveller zorgt er wel voor dat writes fysiek op een nieuw plekje komen. Wat ook maar goed is, anders is het zo afgelopen met de SSD.

Hoe komt TS eigenlijk aan 1,5/2 jaar? Uitgegaan van 10,000 writes? Qua garantie gaat bijv. Intel x25-m uit van minder (20GB/dag * 365 dagen * 5 jaar = 36500GB. Nogal een flink verschil t.o.v. 80GB*10,000). Lijkt me ook niet te verantwoorden als je SSDs na een half jaartje uitvallen en je geen garantie krijgt.

Wel interessant topic Ben het zelf ook nog van plan, al gaat het lang niet om zoveel writes.

[Guru Evi]

Ik gebruik SSD's in mijn bedrijfsomgeving sinds kort (6 maand). De Intel X-25-E zijn natuurlijk aan te raden alsook de nieuwe Vertex 2 SAS of de OCZ EX reeks. Natuurlijk wil je je SSD's (en alle andere schijven) in een mirror of een andere RAID configuratie (5 of 6) zetten zodat er eentje kan stuk gaan zonder problemen. Als je veel writes doet ben je altijd beter af met een SLC, een MLC kan nog wel als boot drive.

Als je echt enterprise-level bezig bent en je hebt heel veel IOPS nodig die absoluut weinig downtime kunnen hebben dan kun je beter uitwijken naar de Pliant Lightning (SAS) alhoewel die binnenkomen aan ~$3500 voor 150GB (340MB/s write met 160,000 IOPS). Er zijn ook oplossingen zoals de RamSan die eigenlijk gewoon RAM stickjes zijn met genoeg batterijen om naar disk op te slaan. enkele TB kost gemakkelijk $300,000

[ Voor 10% gewijzigd door Guru Evi op 13-09-2010 21:21 ]

[The Eagle]

BCC schreef op maandag 06 september 2010 @ 18:46:
[...]

Ik heb in de praktijk vaak te maken met HELE grote databases en correcte indexen zetten is in 99,9% van de gevallen de oplossing. MSSQL heeft een prachtige profile suite die je hier heel goed bij kan helpen. En daarnaast RAM. Onze DB servers draaien standaard tegenwoordig met 64GB Ram.

SSD's zijn alleen maar nuttig als je perfect getunede database nog steeds meer disk-ios nodig heeft dan je server kan serveren en het onmogelijk is om de load over meerdere machines te verdelen.

^^^ Met stom

Als je veel IO hebt op die bak (wat op zich logisch is in een OLAP omgeving), dan kom je met de juiste indexen en het regelmatig verversen van statistieken op je data al een heel eind
True, nog steeds moet er veel data ingelezen worden en een SSD zal dat zeker versnellen - maar het ophalen van de data en het naar de aanvrager (SQL client oid sturen) is dan nog steeds de bottleneck. D'r valt of staat heel veel bij je zoekpaden.

Ik zou echt serieus eens beginnen met het een keer verversen van je statistieken op je data. Als er regelmatig een hoop bijgepompt wordt, zijn je stats snel stale. Het DBMS ziet dat en zal daarom een full table scan uitvoern, omdat ie ziet dat dat het snelst is. Helaas moet ie daar idd de volledige tabel voor inladen - en dus ook de hele datafile waar het zaakje in zit. Dus update je stats - en ik denk dat je al een heel stuk performanceverbetering zult hebben.

En verder: Update degenen die de queries schrijven dat ze ook eens kijken wat ze nou precies ophalen. Goed pinpointen van data is ook een vak. Doen ze dat niet ==> heropvoeden die handel

[_H_G_]

The Eagle schreef op maandag 13 september 2010 @ 21:38:
En verder: Update degenen die de queries schrijven dat ze ook eens kijken wat ze nou precies ophalen. Goed pinpointen van data is ook een vak. Doen ze dat niet ==> heropvoeden die handel

Als dat eens kon.. Geef je helemaal gelijk hoor Maar weinig invloed op de brakke database/erp hier. Al gaat het hier vooral om reads, die elke keer weer opnieuw gedaan worden op een supertabel.. (ze gebruiken nog pervasive sql en ze zijn bezig met mssql. Waarschijnlijk ben ik toch beter af met een hoop RAM, al kan kan ik TS goed begrijpen. Zeker als einde van dit jaar SSDs flink in prijs zouden zakken).

[kdekker]

Jaren geleden heb ik een RAID 10 oplossing gehad (apart diskcabinet, 10 disks, verdeelt over 2 SCSI kanalen) met een PERC4 controller. De disks weren ook voor een database gebruikt (niet MSQL). De prestaties vielen me toen tegen.

Oorzaak heb ik niet voor 100% zekerheid weten te achterhalen, maar vermoedelijk was de combinatie van stripe-size in de controller een oorzaak. Deze staat (vaak) default op 64k. Omdat database pages vaak 4k of 8k zijn, en vaak randam I/O hebt, is een strip-size van 64k niet efficient. Toentertijd hadden we geen zin in compleet opnieuw inrichten van de SCSI RAID 10 oplossing, zodat we het maar zo gehouden hebben.

Tegenwoordig heb ik 5 (interne) disks in RAID 5, met een nieuwere controller. De prestaties zijn hier zeker niet slechter. Het feit dat ik geen los disk cabinet nodig had scheelde een flink stuk in prijs. Alleen ben je wel beperkt in het aantal interne disks dat een systeem aankan. Met de huidige 2.5" mode zijn dat er meer dan vroeger met 3.5" schijven. Voor random IO helpt een hogere spindle speed (15k) wel. Ik heb zelf mijn twijfels over de prestaties van 2.5" (meer op gevoel gebasseerd) t.o.v. 3.5". In ieder geval is de prijs per Gb met 3.5" een stuk beter (nog steeds).

Moraal is dat de controller (het aantal IOPS dat de controller aan kan) een stevige rol speelt, de configuratie van de RAID (strip size). Ik heb de indruk dat Dell PERC controllers het afleggen tegen HP Smart Array controllers, maar wellicht spelen historische sentimenten een rol.

Ik heb verder geen ervaring met SSD. Als je een grote database (bijv. enkele 100GB tot wel TB toe) hebt, gaat het wel in de papieren lopen qua prijs. En je hebt een bloedsnelle controller nodig voor de RAID calculaties (speelt met name in RAID5). Ik weet niet of een controller de een rij SSDs bij kan benen.

[Gé Brander]

Bij MSSQL is het over het algemeen zo dat de CPU het drukker krijgt bij overstap naar SSD. Vaak is het met gewone disken zo dat de CPU staat te wachten op de informatie van de disken, dus als die informatie sneller komt, zal de CPU minder lang hoeven te wachten en dus drukker zijn.

Op SQL Pass in Seattle vorig jaar een leuke demo over gezien.

[ Voor 10% gewijzigd door Gé Brander op 14-09-2010 11:09 ]

[BCC]

voodooless schreef op maandag 13 september 2010 @ 20:08:
[...]
Wat ik wil horen is niet relevant. De TS wil blijkbaar horen dat zijn plan briljant is en dat hij vooral zijn idee moet doorzetten

offtopic:
Het was ook bedoeld voor de de TS

[Niemand_Anders]

Vandaag heb ik een SSD uit andere machine gehaald en de machine 8 4GB reepjes gegeven, dus totaal 32GB ram. Resulaat diso io is van 68% naar 54% gegaan. CPU load is licht omhoog gegaan naar 12-16%. Bij eenzelfde test, maar dan met een simpele oudere MLC SSD bracht met slechts 16GB disk io terug naar 28% en ging CPU naar 25-35%. Later heb ik de test herhaald met 32GB ram en toen was disk io nog slechts 12% en een CPU load van 48%. De oudere Corsair Nova 128 drive werd aangesloten aan de P400 controller.

Alleen blijft de levensduur (en vooral de korte garantie periode) van de SSD drives mij dwars zitten. Waarom geven de SSD fabrikanten slechts maximaal 3 jaar garantie? Ik zit er niet op te wachten dat 2,5 jaar later de drives een voor een de geest beginnen te geven. Vandaar ook de vraag wat de ervaringen zijn met SSD drives in bedrijfs kritische omgevingen. De database is hier eigenlijk helemaal niet belangrijk en is alleen de aanleiding geweest waarom ik naar SSD drives aan het kijken ben.

Op internet lees ik eigenlijk alleen maar hoe snel de SSD's drives zijn. Voor alsnog kan ik maar een conclusie trekken: SSD's worden niet of korter dan 2 jaar gebruikt in data centers. Intel, IDC and Gartner verwachten allemaal dat het gebruik van SSD in data centers zal toenemen, maar veel meer dan dat lees ik niet vanuit de 'officiële' kanalen.. Transcent geeft twee jaar en Intel, Seagate, Samsung, OCZ, Kingston en Corsair geven drie jaar garantie. De fabrikanten zoals Pliant welke 5 jaar garantie geven gooien dan ook direct de prijs flink omhoog waardoor deze onbetaal wordt..

Misschien had ik ook beter het database verhaal uit de intro weg kunnen laten, want in plaats van dat ik meer ben te weten gekomen over de betrouwbaarheid van SSD's, is de discussie vooral over de database gegaan.

Dus ik wil vooral weten wie gebruikt SSD's in een bedrijfs omgeving, hoe lang worden ze al gebruikt, in welke toepassingsgebied en ben je in die tijd al problemen tegen gekomen..

[voodooless]

Niemand_Anders schreef op dinsdag 14 september 2010 @ 19:38:
Dus ik wil vooral weten wie gebruikt SSD's in een bedrijfs omgeving, hoe lang worden ze al gebruikt, in welke toepassingsgebied en ben je in die tijd al problemen tegen gekomen..

Oke, suit yourself..

Wij gebruiken twee X25-E's (in raid1) per VMWare machine. Puur zodat er niet nog twee disk in spinnen, en het lekker snel kan opstarten. Verder doen die disks dus niet veel, want voor de rest draait alles op een SAN, vooralsnog zonder SSD.

Voor onze eigen database gebruiken we momenteel een array van 16 SAS disks (db van meer dan 300), en die kunnen de IO load op zich nog wel aan. Echter willen we gezien de mogelijk groei gaan uitbreiden met nog een berg SAS disks, en een stuk of 4 tot 6 Intel X25-E in raid 0 als cache voor de database. Het filesysteem is zo gemaakt dat het tegen mogelijke fouten in de cache array kan, raid 0 is dus geen probleem.

[alex3305]

Op de Intel site over de X25-E staat dat deze schijf zo'n 2 miljoen uur mee moet kunnen gaan voordat deze het begeeft, dat is dus zeker meer dan twee jaar. Weet je zeker dat je wel bij de enterprise schijven hebt gekeken?

[_H_G_]

Niemand_Anders schreef op dinsdag 14 september 2010 @ 19:38:
Op internet lees ik eigenlijk alleen maar hoe snel de SSD's drives zijn. Voor alsnog kan ik maar een conclusie trekken: SSD's worden niet of korter dan 2 jaar gebruikt in data centers. Intel, IDC and Gartner verwachten allemaal dat het gebruik van SSD in data centers zal toenemen, maar veel meer dan dat lees ik niet vanuit de 'officiële' kanalen.. Transcent geeft twee jaar en Intel, Seagate, Samsung, OCZ, Kingston en Corsair geven drie jaar garantie. De fabrikanten zoals Pliant welke 5 jaar garantie geven gooien dan ook direct de prijs flink omhoog waardoor deze onbetaal wordt..

Hoeveel schrijf je nou per dag per disk? Klinkt alsof je het nog over MLC hebt en die garanties zijn voor normaal gebruik, niet voor enterprise gebruik (het verschil kunnen ze zien zodra je m RMA stuurt).

@alex3305: MTBF zegt niet zoveel, zeker niet als het om MLC gaat. Als het moet krijg je zo'n SSD echt wel in een maand of twee kapot. Dan moet je in de datasheet kijken: "32 GB drive supports 1 petabyte of lifetime random writes and 64 GB drive supports 2 petabyte of lifetime random writes."

Als je dit dan gaat vergelijken met de x25-m: "The drive will have a minimum of 5 years of useful life under typical client workloads with up to 20GB of host writes per day."

[ Voor 13% gewijzigd door _H_G_ op 14-09-2010 20:56 ]

[voodooless]

Ik zou zelfs willen zeggen dat MTBF bij SSD's gewoon een onzinnig getal is. Het is namelijk zeer voorspelbaar wanneer een SSD het gaat begeven en dat heeft niks te maken met hoe lang de disk spanning heeft (heel anders dus dan bij een draaiende schijf met bewegende koppen). Met kansberekening heeft dat weinig te maken. Hoe goed je wear leveling ook is, op een gegeven moment zijn je sectoren gewoon gaar en dan is het over en uit.

[ Voor 39% gewijzigd door voodooless op 14-09-2010 21:06 ]

[Q]

Om die reden kun je SSD's als betrouwbaarder zien dan spindels, je weet wanneer ze ongeveer gaan falen en kan daar op anticiperen. De kans dat een solid state device er zomaar plotseling mee kapt lijkt me heel gering. Of die krengen sterven direct bij aankoop, of niet?

[PcDealer]

Een HP schijf in een HP server under warranty is gewoon gedekt gedurende de warranty (tot 5 jaar). Daarnaast is er prefailure warranty indien aangesloten op een HP SmartArry controller.

Voor caching is er tegenwoordig ook nog de HP PCIe IO Accelerators for ProLiant Servers

[ Voor 22% gewijzigd door PcDealer op 15-09-2010 09:28 ]

[voodooless]

Vergeet niet dat die "HP schijf" (of die van Dell, Compellent, Sun, 3PAR, IBM, NetAPP of een van de andere grote jongens) gewoon een Seagate of andere meuk is, die voor minimaal factor 5 t.o.v het zelfde Seagate model verkocht wordt. Je kunt ook zelf van die 5 disks op voorraad leggen voor iedere "HP Disk". Dat gaat ook vast erg lang mee

Anyway, dat is zo bij de grote storage systemen. Bij de wat simpelere servers is de prijsverhouding lang niet zo scheef, maar is de support daarom ook weer wat minder.

[lier]

Misschien heb ik er overheen gelezen...is de server alleen voorzien van 4 disks voor de OS, data en logs ?
Want daar zou ik mee beginnen, drie volumes verdeeld over bijvoorbeeld 8 disks.

Het mooiste zou dan zijn als de controller over meerdere channels beschikt.

[PcDealer]

voodooless schreef op woensdag 15 september 2010 @ 08:44:
Vergeet niet dat die "HP schijf" (of die van Dell, Compellent, Sun, 3PAR, IBM, NetAPP of een van de andere grote jongens) gewoon een Seagate of andere meuk is, die voor minimaal factor 5 t.o.v het zelfde Seagate model verkocht wordt. Je kunt ook zelf van die 5 disks op voorraad leggen voor iedere "HP Disk". Dat gaat ook vast erg lang mee

Probleem is dat de firmware kan afwijken en soms ook de exacte grootte van schijven. Maar goed, ik heb in mijn HP Netserver naast 2 HP parts als bootmirror, ook 4x Maxtor Atlas 10K IV.

[Anoniem: 156408]

Niemand_Anders schreef op maandag 13 september 2010 @ 19:24:
Dus nogmaals de vraag: Wie gebruikt er SSD in een enterprise omgeving om bedrijfs kritische data op te slaan, in welke toepassings gebied en hoe lang zijn deze al in gebruik? Heb je al ervaring met defecte disks en hoe ging de leverancier om met de garantie voorwaarden? Ofwel wat zijn jullie ervaringen met SSD's?

Ik heb pas een bladechassis in productie gezet, met 13 blades waarin elk 3 32GB SSD schijven zitten (raid 1 met hotspare). Hierop draait windows 2008r2 hyper-v. De virtuele machines staat op een iScsi san met 50 1TB SAS schijven.

De SSD schijven die ik gebruik zijn ATP VELOCITY S2 32GB SSD 2,5" SLC's. van de 26 SSD's die dus actief in gebruik zijn, zijn er inmiddels 5 vervangen onder garantie binnen de eerste 3 weken dat ze draaiden. Nu heb ik geen uitval meer. Het lijkt er dus op dat het een slechte batch was.

Garantie was wel zo dat ik gelijk een nieuwe disk kreeg (alleen de levertijd van 3 weken is minder), en de oude kon retourneren.

Dus SSD in produktie... Ja, maar leg zelf wel een paar schijven op voorraad. De prestatiewinst maakt veel goed.

[Q]

Anoniem: 156408 schreef op woensdag 15 september 2010 @ 10:13:
[...]
De virtuele machines staat op een iScsi san met 50 1TB SAS schijven.

Korte vraag:

Is dat SAN 1 grote enclosure, of een server met meerdere 'domme' enclosures via SAS verbonden? Of natuurlijk 2 servers ivm redundancy die weer apart met meerdere disk cabineten zijn verbonden?

[Anoniem: 156408]

SAN is 1 grote enclosure, met 2 raidcontrollers. Extern mogelijkheid tot 6 extra cases met schijven. redundant netwerkkaarten erin. de 2 controllers zijn weer mirror van elkaar.

[Q]

Anoniem: 156408 schreef op donderdag 07 oktober 2010 @ 22:37:
SAN is 1 grote enclosure, met 2 raidcontrollers. Extern mogelijkheid tot 6 extra cases met schijven. redundant netwerkkaarten erin. de 2 controllers zijn weer mirror van elkaar.

Begrijp ik dat de 50 disk enclosure dus 2 sets 1 set per controller van 25 disks hebben oid? Dus je kunt dan zelfs een controller verliezen?