RAID icm SSD en Database Cluster

[boner]

Hi,
ik ben nu bezig met het scrhijven van een strategie hoe om moet worden gegaan met nieuwe datacenter inrichtingen. Eén van de zaken die dan de revue passeren is de database, of de databases.

Alle databases die hier draaien zijn redundant uitgevoerd. Dat wil zeggen dat er minimaal 2 en soms meerdere servers in een cluster samenwerken. Dus uitval van een node zal geen impact hebben op de beschikbaarheid van een database.

Als we dan iets dieper graven komen we op het disk-subsysteem uit dat in de machines zit. Standaard is dat elke server in het DC RAIDx 'doet'. In een RAID systeem staan de disks continu te reutelen en is er vrijwel continu activiteit, en ik neem aan ook schrijfactiviteit. Dat is funest voor SSD's. Daar wil je alleen maar schrijven als er ook daadwerkelijk ook iets te schrijven valt.

Dus kwam de gedacht in mij op om voor database clusters machines RAID uit te zetten en alleen maar SSD's aan te bieden. Eventueel wel in RAID0 of RAID1. De redundantie komt dan niet uit de onderdelen maar moet het cluster maar voor zorgen. Als we RAID1 inzetten en een strak wisselschema uitwerken om op tijd de SSD's te verversen krijg je een stabiel en voorspelbaar geheel. Ik denk dat dan de SSD's veel langer mee zullen gaan dan in een RAID5 of hogere opstelling.

Of maak ik nu een grote denkfout (sta ik bekend om )

[Uberprutser]

boner schreef op donderdag 19 september 2019 @ 11:20:
Hi,
Dat is funest voor SSD's.

Dan moet je een RAID controller hebben die SSD aware is en dan heb je die problemen niet.
Een beetje RAID controller die up to date is zal dat zijn.

Voor databases, als je voor RAID gaat, is 10 een aanrader, helaas wel een kostbare als je veel ruimte nodig hebt.

p.s. Dit is een zeer algemeen antwoord omdat ik de rest van je requirements niet ken danwel what on earth je erop gaat draaien anders dan een DB.

[ Voor 22% gewijzigd door Uberprutser op 19-09-2019 11:33 ]

[Rolfie]

boner schreef op donderdag 19 september 2019 @ 11:20:
Als we dan iets dieper graven komen we op het disk-subsysteem uit dat in de machines zit. Standaard is dat elke server in het DC RAIDx 'doet'. In een RAID systeem staan de disks continu te reutelen en is er vrijwel continu activiteit, en ik neem aan ook schrijfactiviteit. Dat is funest voor SSD's. Daar wil je alleen maar schrijven als er ook daadwerkelijk ook iets te schrijven valt.

Je neemt hier al iets aan? Bijna iedere hardware kan je hierin meer informatie geven. Maar juist in hardware based raid controllers zitten er allemaal checks in, en de raid volumes kunnen met van alles bezig zijn.
Maar wat voor een SSD's gebruiken jullie precies? Want de bijna iedere grote hardware leveranciers heeft verschillende types SSD, afhankelijk van de eigenschappen wat er noodzakelijk is.
Hoe ver is de wearing ook momenteel van de SSD's?

Dus kwam de gedacht in mij op om voor database clusters machines RAID uit te zetten en alleen maar SSD's aan te bieden. Eventueel wel in RAID0 of RAID1. De redundantie komt dan niet uit de onderdelen maar moet het cluster maar voor zorgen. Als we RAID1 inzetten en een strak wisselschema uitwerken om op tijd de SSD's te verversen krijg je een stabiel en voorspelbaar geheel.

Je kunt ook gewoon in een RAID5 volume de SSDs vervangen.
Het is maar waar je voor wilt gaan. Het is zeker mogelijk om de databases op een enkele SSD disk te plaatst. Maar bij uitval loop je hierin een groter risico met meer impact. Is dat verantwoordelijk? Ik zou er persoonlijk nooit voor gaan.
Maar de laatste Exchange versies zijn hierop ook eigenlijk gebouwd. Redundantie hoeft niet meer op storage gedaan te worden, maar op/in de applicatie.
Alternatief zou kunnen zijn om logfiles op SSD's te zetten en databases op HDD's. Maar dit hangt er vanaf of dit weer voldoende IO's kan leveren.

Ik denk dat dan de SSD's veel langer mee zullen gaan dan in een RAID5 of hogere opstelling.

Op basis waarvan?
Slimme raid controllers kunnen lees transactief verdelen over een mirror. Dus het aantal lees actief kan je inderdaad verminderen.
Maar bij schrijven, zal er toch echt iets op iedere SSD geschreven moeten worden.

maak ik nu een grote denkfout (sta ik bekend om )

Je stelt hele goede vragen en denkt ergens over na.

[boner]

Rolfie schreef op donderdag 19 september 2019 @ 11:47:
[...]

Je neemt hier al iets aan? Bijna iedere hardware kan je hierin meer informatie geven. Maar juist in hardware based raid controllers zitten er allemaal checks in, en de raid volumes kunnen met van alles bezig zijn.
Maar wat voor een SSD's gebruiken jullie precies? Want de bijna iedere grote hardware leveranciers heeft verschillende types SSD, afhankelijk van de eigenschappen wat er noodzakelijk is.
Hoe ver is de wearing ook momenteel van de SSD's?


[...]

Je kunt ook gewoon in een RAID5 volume de SSDs vervangen.
Het is maar waar je voor wilt gaan. Het is zeker mogelijk om de databases op een enkele SSD disk te plaatst. Maar bij uitval loop je hierin een groter risico met meer impact. Is dat verantwoordelijk? Ik zou er persoonlijk nooit voor gaan.
Maar de laatste Exchange versies zijn hierop ook eigenlijk gebouwd. Redundantie hoeft niet meer op storage gedaan te worden, maar op/in de applicatie.
Alternatief zou kunnen zijn om logfiles op SSD's te zetten en databases op HDD's. Maar dit hangt er vanaf of dit weer voldoende IO's kan leveren.


[...]

Op basis waarvan?
Slimme raid controllers kunnen lees transactief verdelen over een mirror. Dus het aantal lees actief kan je inderdaad verminderen.
Maar bij schrijven, zal er toch echt iets op iedere SSD geschreven moeten worden.


[...]

Je stelt hele goede vragen en denkt ergens over na.

Ik ben architect bij een organisatie die alles europees moet aanbesteden. Dat betekent dat ik nooit, in welk bestek ook, merken of technieken mag sturen. Dus ik mag bijvoorbeeld nooit zeggen dat we een bepaald merk SSD of een bepaald type RAID controller willen inzetten. Alles moet en zal functioneel blijven.

Dus ook over welk merk Database is de aanbieder veel meer aan het stuur dan ik, en met mij de rest van de club. Heel frustrerend, maar zo zijn de regels.....

Dus kan ik alleen maar opschrijven dat we in algemene termen op deze en deze manier de storage van de Database servers willen insteken. Zo mag ik wel aangeven dat we wel/niet SAN of NAS willen. Dat we wel of niet SAN/NAS voor de database in willen zetten maar 'terug willen vallen' op serverbased storage.

Ook mag ik wel zeggen dat we hyperconverged willen werken, maar niet dat we bijvoorbeeld Nutanix wensen. Dus moet ik ook de beschrijving en opbouw zo opstellen dat er geen specifieke zaken in staan.

Dus daarom de vrij lompe aanpak wel of geen raid hoger dat 1 in een database server....

[CAPSLOCK2000]

Je mag wel vragen om een RAID controller die geschikt is voor SSDs.

Databases op SSD draaien is over het algemeen een uitstekend idee, de hoge IOPS zijn precies wat je nodig hebt.

De meeste abstracte manier om dit probleem op te lossen is dan ook om niet naar specifieke hardware te vragen, maar op te geven hoeveel IOPS je storage systeem moet leveren.
Als de databasesoftware zelf ook aanbesteed moet worden zou om een aantal SQL-transacties/seconde kunnen vragen.
Praktisch gezien is het alleen erg lastig om daar iets zinnigs over te zeggen als je er geen ervaring mee hebt, of een ander vergelijkbaar systeem om aan te meten.

Ik sta ook wel achter je keuze om redundantie op cluster niveau te regelen. Je zou je kunnen afvragen of je dan nog een RAID-kaart nodig hebt. De extra snelheid van een RAID0 is bij SSDs eigenlijk nooit de moeite waard.

[The Eagle]

Over RAID en DB's is heel veel geschreven. De meesten zijn het er wel over eens dat een RAID 10 (1+0) prima functioneert voor DB's.
SSD is qua IOPS altijd een goed idee. Om een indicatie te geven: Oracle Database Appliance heeft 15k SAS disks met een SSD cache en doet sustained ca 1500 - 1700 IOPS. Gooi je er Enterprise FLash SSD onder, haal je met gemak 150K IOPS sustained. IO is dan ineens geen bottleneck meer.

Maar in principe wil je gewoon een storage array dat je storage beheerder neerzet wat voor DB's geschikt is. En die je aan je DB servers op je vm's kunt koppelen, op wat voor manier dan ook, of dat nou LUN, RAW of SCSI is. Daarbij zijn er voor de verschillende smaken DBMS'en natuurlijk wel zaken om rekening mee te houden irt HA en DR en wat er odnersteund wordt en wat niet.

[ Voor 10% gewijzigd door The Eagle op 25-09-2019 15:53 ]

[borft]

CAPSLOCK2000 schreef op woensdag 25 september 2019 @ 14:49:
Je mag wel vragen om een RAID controller die geschikt is voor SSDs.

Databases op SSD draaien is over het algemeen een uitstekend idee, de hoge IOPS zijn precies wat je nodig hebt.

De meeste abstracte manier om dit probleem op te lossen is dan ook om niet naar specifieke hardware te vragen, maar op te geven hoeveel IOPS je storage systeem moet leveren.
Als de databasesoftware zelf ook aanbesteed moet worden zou om een aantal SQL-transacties/seconde kunnen vragen.
Praktisch gezien is het alleen erg lastig om daar iets zinnigs over te zeggen als je er geen ervaring mee hebt, of een ander vergelijkbaar systeem om aan te meten.

Ik sta ook wel achter je keuze om redundantie op cluster niveau te regelen. Je zou je kunnen afvragen of je dan nog een RAID-kaart nodig hebt. De extra snelheid van een RAID0 is bij SSDs eigenlijk nooit de moeite waard.

Ik heb wel toepassingen gezien, waarbij het schrijven van temporary tabellen (die niet in memory pasten) heel veel baat had van een hogere throughput dan 1 ssd kon bieden. Hier was raid0 een heel economische oplossing.

Verder ben ik het met je eens, dat je eigenlijk schrijf/lees capaciteit in i/o's moet uitdrukken, dan kan een leverancier zelf zorgen dat ie dat haalt, op wat voor manier dan ook.

Raid5 zou ik ver van weg blijven bij databases, zeker als je write-load hoog is, aangezien je hier een write penalty krijgt (parity moet ook geschreven worden).

Ik gebruik al jaren ssd's in database servers, en ik zou eigenlijk geen reden weten om het niet te doen. Op papier is er een limiet, hoeveel ssd's kunnen schrijven, maar als je dat in de realiteit bekijkt, duurt het vaak jaren voordat je die limiet bereikt, oa door wear-levelling meachanismes op de drives zelf.

[The Eagle]

@boner over welk DBMS gaat het in jouw geval exact? Voor Oracle, MS SQL en MySql kan ik wel wat roepen. Heb ca een jaar lang platformbeheer en -bouw gedaan voor die drie smaken. Hyperconverged, inclusief HA en DR, denk totaal een 5 a 600 servers.
Verder snap ik je punt dat je slechts een programma van eisen op mag stellen. Dat wil echter niet zeggen dat je het niet zo kunt schrijven dat er slechts 1 of 2 opties mogelijk zijn

[ Voor 3% gewijzigd door The Eagle op 25-09-2019 20:42 ]

[boner]

We kennen hier officieel 3 database bouwstenen: Oracle, MS-SQL en Postgress. Er zijn echter ook veel legacy applicaties met MySQL. Ik denk dat we in de toekomst Mongo en Cassandra gaan inzetten.

Voor Oracle gebruiken we al een dedicated oplossing om te voorkomen dat we het hele DC moeten licenceren.

Voor SQL Server zijn veel kleinere instances actief en voor Postgress geldt hetzelfde. Die worden oer oplossing ingezet waar Oracle een generieke Database is waar verschillende applicaties op werken

[Question Mark]

boner schreef op donderdag 19 september 2019 @ 16:04:
[...]
Dus kan ik alleen maar opschrijven dat we in algemene termen op deze en deze manier de storage van de Database servers willen insteken. Zo mag ik wel aangeven dat we wel/niet SAN of NAS willen. Dat we wel of niet SAN/NAS voor de database in willen zetten maar 'terug willen vallen' op serverbased storage.

Waarom zou je dat willen doen? Ik zou mij in dit geval alleen maar focussen op de aansluitvoorwaarden (integratie) met je bestaande infrastructuur. Voor de rest geef zou ik alleen maar de harde requirements op gaan geven (beschikbaarheid, RPO, RTO, etc).

Of de leverancier het dan met een SAN, NAS of DAS invult is aan hem...

[The Eagle]

Als je de storage helemaal los ziet van de andere bouwblokken geldt je opmerking over de aansluitvoorwaarden wel ja. Maar DB storage is een gevalletje apart ivm de continue openstaande files en het gebruik van archivelogs e.d. Backups of snapshots van DB's doe je ook meestal niet op storage niveau maar op DB niveau. Sure, voor een MS SQL bak zou het met MSFT data protector of hoe dat ding ook heet ook kunnen. Maar een backup restoren van een DB wil je toch echt wel graag je DBA laten doen en niet de lokale storage man
En geloof het of niet, maar het gebruik van recoverytools is een vrij groot deel van het werk van een DBA. Refresh van een ACC DB anyone? Ter info: bij Oracle wordt meestal een verhouding van 1:3 aangehouden voor DB : archivelog en backupstorage. DB van 1 TB heeft dus minimaal 4T aan diskspace nodig.

En beschikbaarheid, RTO en RPO moeten idd leidend zijn in dit, maar zeggen maar voor een deel iets. Ik ben destijds ook eeen situatie van een restore tegen gekomen waarbij de RTO niet gehaald werd terwijl de storage het makkelijk aan kon. Daar bleek een 40GBit uplink van de hyperconverged stack naar de fysieke stack de bottleneck

[BachW]

Dit is een interessant topic ja... Ik herken een hoop argumenten. Maar als het om specificeren van performance gaat is het definiëren van IOPS wel key. Dit is helaas in de praktijk makkelijker gezegd dan gedaan omdat de meeste applicatie suppliers het niet echt weten.
Dan kom je al snel op iets wat makkelijker te schalen is zoals hyperconverged infra. Dat werkt prima maar kan ook voor bottlenecks zorgen (zoals netwerk eerdere reply). Met HCI zorgt het onderliggende systeem voor de storage tiering, dus dan heb je de hele RAID discussie niet. Geef een HCI systeem een mix van disken en het systeem doet de rest. Ik heb nu zelfs al NVMe+SSD systemen gezien, dan is disk IO het laatste waar je je druk om maakt...
Persoonlijk heb ik het meeste ervaring met Microsoft S2D (Storage Spaces Direct) en dat werkt ook prima voor MSSQL DB's heb ik me laten vertellen.

TL;DR als het lastig is IOPS te definieren vraag dan om iets wat schaalbaar is. ;-)

[The Eagle]

Naja, eigenlijk is het heel simpel. Een DB werkt met data, en dat spul staat in files op disk. Disk access times was tot de komst van SSD altijd de bottleneck. En dus bestaan er zaken als indexen, hints en what have you om explain plans te optimaliseren en daarmee het ophalen en wegschrijven van overbodige data en daarmee disk IO te kunnen beperken. En toen kwam de SDD. Zo snel dat de IO bottleneck er niet meer was, en CPU de bottleneck werd. Niet memory overigens; dat is werkgeheugen voor een DB en als een DB die niet genoeg heeft gaat ie veel disk IO doen. Prima, die was toch snel zat met een SSD, merk je niet.