Databaseserver met redundante NVMe storage

[Maxonic]

Ik probeer op de Dell site een snelle databaseserver bij elkaar te klikken. Heb zo'n 8K budget te besteden. Nu moet deze server een PostgreSQL database van zo'n 1TB gaan draaien en de hele database in RAM gaat hem niet worden voor dat bedrag. Ik wil daarom graag wat extra aandacht aan de snelheid van de storage besteden.

Continuïteit bij het defect raken van een schijf is belangrijk en dus is het in RAID plaatsen van de schijven een must. De nieuwe lijn van Dell bied ondersteuning voor U.2 NVMe schijven maar het is mij onduidelijk hoe in zo'n setup met RAID omgegaan wordt.

Nu hoor ik her en der dat om de Raid controller niet de bottleneck in de setup te laten zijn, het aan te bevelen is software RAID te gebruiken. Ik denk dan gelijk aan Linux MD raid maar er is blijkbaar ook zoiets als Intel VROC. Ik kom er alleen niet achter wat nu echt het verschil tussen Linux Software Raid en VROC is, wat voor verschil in performance ik tussen beide kan verwachten en of VROC überhaupt een volwassen techniek is die men in productie zou moeten willen gebruiken.

Heeft iemand ervaring met het in RAID plaatsen van NVMe drives die mij kan vertellen of ik hier problemen mee kan verwachten?

[FireDrunk]

Kan prima met Linux MD, maar je hoeft ook niet de 'hele' database in RAM te laden, als het maar de meestgebruikte data is.
Heb je daar wel inzicht in?

Heb je performance gegevens van de huidige machine? IO karakteristieken? Latency grafieken, query tijden, noem het maar op.

Met alleen Linux MD ben je er nog niet. Je kan op nog veel meer plekken optimaliseren.
Zo kan je de blocksize / stripesize veranderen, spelen met prefetch, spelen met IO Schedulers, iets doen met filesystem tuning. IO Prioriteiten van je applicatie.

Er komt veel meer bij kijken dan alleen een 'mirrored' storage setup.

Daarnaast zou ik me drukker maken om goede backups dan om een RAID engine.
Uiteraard wil je niet dat bij het falen van 1 disk de hele server weg is, maar ook een RAID systeem kan kapot, een filesystem kan corrupt raken, en developers kunnen een 'DROP ALL TABLES' of een 'TRUNCATE TABLE' per ongeluk doen

[ Voor 20% gewijzigd door FireDrunk op 04-11-2019 13:14 ]

[Maxonic]

Dank voor je reactie!

Uiteraard is bovenstaande niet het hele verhaal. We doen streaming replication, maken periodieke dumps die offsite geplaatst worden. We testen configuraties met pgBench en draaien pgBadger om inzicht te krijgen in trage queries, missende/niet gebruikte indexes of andere bottlenecks.

Ik moet nu alleen vrijwel hals-over-kop een keuze voor de aanschaf van nieuwe hardware maken en focus me daarom voor nu even op hardware opties. OS-tuning en andere optimalisaties kunnen ook op andere momenten nog verder worden overwogen.

We hebben niet echt "meest gebruikte" data. De hele database wordt gebruikt en data die niet meer actueel is wordt gedenormaliseerd in een JSON document gemikt en ergens anders gearchiveerd. De database heeft zo'n 50-50 SELECT en INSERT statements en vrijwel geen updates. De database heeft een kleine honderd tabellen maar bijna de helft van de omvang is aan één enkele tabel toe te rekenen.

Op dit moment schrijft de database regelmatig temp-files weg maar ik verwacht niet dat dat in de nieuwe situatie nog zal gebeuren. RAM gaat namelijk van 92GB naar 320GB. Ik ben in mijn zoektocht naar de juiste hardware voornamelijk nog zoekende of NVMe vanuit een performance oogpunt meerwaarde kan bieden ten opzichte van een SSD SATA Raid-array, en probeer te achterhalen of ik hierbij tegen onverwachte problemen kan aanlopen.

[FireDrunk]

Draait de huidige server nog op spindles? Want dan is een SATA SSD RAID array al een orde van grootte sneller. Bedenk je goed dat met meer disk performance er ook behoorlijk meer CPU cycles nodig zijn.

NVMe in RAID is leuk, maar SATA SSD RAID is doorgaans snel 'genoeg'. Nou is dat een extreem subjectief antwoord, omdat ik echt niet weet over wat voor load je het hebt.

Het antwoord ligt in de benodigde snelheid van alle andere componenten voordat je NVMe SSD Array de bottleneck gaat zijn. Als je 2 (of meer) SSD's in zo'n pool zet, zit je al snel aan > 300.000 IOPS en > 5GB/s transfer speed.

Dat zijn insane hoge getallen voor een enkele database. Je CPU gaat veel drukker zijn met alle queries en het verwerken van al die IO's. De storage zal zeer waarschijnlijk niet je bottleneck zijn.

Bedenk dus goed wat je wil bereiken met je budget. Snelste mogelijk voor dat geld, of genoeg voor de database en extra features waar leuk.

[vso]

@Maxonic als 1 disk 3000 R/W is dan gaat 2de disk in RAID natuurlijk niet bijdragen aan de snelheid eerder een dip.. nog altijd sneller dan een HDD RAID set.
Maar goed als /boot en /home/postgres oid heb je een goeie start.

houd er wel rekening mee dat er geen SMART is dus de kans is groter dat de disks "poef" doen en alles weg is. ik zou zelf de transactie log oid naar een HDD raid mirror setje oid en/of een dump per x tijd ..
niet alleen zit je veiliger .. maar maakt het ook makkelijker..

en natuurlijk backup zoals je nu hebt ?

[ Voor 3% gewijzigd door vso op 04-11-2019 15:23 ]

[Maxonic]

@FireDrunk Nee, helaas nu draaien er 4 SATA SSD's in Raid5 (Als ik het opnieuw mocht doen zou ik er Raid10 van maken). Hoewel de schijven dedicated zijn draait de server nu wel gevirtualiseerd, we willen dus weer naar bare metal.

De database moet nu zo'n max 60 connecties tegelijkertijd afhandelen wat niet veel is, maar er wordt wel veel BI gedaan en dus veel zware queries. En er zijn nu regelmatig ook peaks met zo'n 3000 queries per seconde (al vermoed ik dat dat met het beter opleiden van de programmeurs nog wel wat te reduceren valt. )

Ik vind het moeilijk om te voorspellen waar in de nieuwe situatie de bottleneck gaat zitten. Gezien het lage aantal connecties neig ik qua processor naar krachtigere cores boven aantal cores. Een Xeon Gold 5222 of zo. Mijn vermoeden was echter dat de lagere latency van NVMe drives ook wel een positieve impact zouden kunnen hebben.

Maar op basis van de reacties tot nu toe concludeer ik dat SATA SSD Raid wellicht snel zat is. In dat geval stop ik de bespaarde centjes gewoon in meer RAM.

Edit: Toch nog twee vragen...

@vso Is het niet zo dat die NVMe drives gewoon SMART ondersteunen?

@FireDrunk

Dat zijn insane hoge getallen voor een enkele database. Je CPU gaat veel drukker zijn met alle queries en het verwerken van al die IO's. De storage zal zeer waarschijnlijk niet je bottleneck zijn.

Is NVMe dan niet juist aan te bevelen gezien verwerking van IO bij NVMe ten opzichte van SATA een veel lagere CPU belasting geeft? ¹⁾

1) https://global-uploads.we...ME-Protocol_WP_080915.pdf

[ Voor 23% gewijzigd door Maxonic op 04-11-2019 16:04 . Reden: Nog twee vragen toegevoegd. ]

[vso]

Maxonic schreef op maandag 4 november 2019 @ 15:30:
@FireDrunk Nee, helaas nu draaien er 4 SATA SSD's in Raid5 (Als ik het opnieuw mocht doen zou ik er Raid10 van maken). Hoewel de schijven dedicated zijn draait de server nu wel gevirtualiseerd, we willen dus weer naar bare metal.

De database moet nu zo'n max 60 connecties tegelijkertijd afhandelen wat niet veel is, maar er wordt wel veel BI gedaan en dus veel zware queries. En er zijn nu regelmatig ook peaks met zo'n 3000 queries per seconde (al vermoed ik dat dat met het beter opleiden van de programmeurs nog wel wat te reduceren valt. )

Ik vind het moeilijk om te voorspellen waar in de nieuwe situatie de bottleneck gaat zitten. Gezien het lage aantal connecties neig ik qua processor naar krachtigere cores boven aantal cores. Een Xeon Gold 5222 of zo. Mijn vermoeden was echter dat de lagere latency van NVMe drives ook wel een positieve impact zouden kunnen hebben.

Maar op basis van de reacties tot nu toe concludeer ik dat SATA SSD Raid wellicht snel zat is. In dat geval stop ik de bespaarde centjes gewoon in meer RAM.

Edit: Toch nog twee vragen...

@vso Is het niet zo dat die NVMe drives gewoon SMART ondersteunen?

@FireDrunk


[...]


Is NVMe dan niet juist aan te bevelen gezien verwerking van IO bij NVMe ten opzichte van SATA een veel lagere CPU belasting geeft? ¹⁾

1) https://global-uploads.we...ME-Protocol_WP_080915.pdf

tja backup backup & backup of het nu wel/geen smart ondersteunt .. en tja het lijkt mij gewoon slim om niet op 1 paard te wedden.


Als het nu op een Hypervisor VM draait heb je veel meer "issues" steek wat tijd in de fabrikant van de BI software te vragen wat hun advies / guideline(s) zijn .. ook voor het OS dat je in gedachte hebt.

128/256GB ram is nooit weg .. maar je database tweak & tune (optimaliseren/reindex en dat soort geneuzel..) kan ook veel impact hebben. en natuurlijk de software configuren voor de HW die je hebt.

de VM issues zijn over commitment, CPU-time sharing en ander ongein die je nu kwijt raakt maar je verliest andere zaken zoals High Availablity / fail-over en ander geneuzel. het blijft een trade-off...C.q CATCH 22

edit:

ik zou nooit een "haast klus" als dit doen .. lees zorg dat je niet als een blok beton opstelt .. maar wees riet .. buig wat mee zonder teveel aan de wortels te komen.. zodat je niet afbreuk doet aan de rest van je omgeving

[ Voor 5% gewijzigd door vso op 04-11-2019 16:17 ]

[Tijntje]

Op dit moment heeft Dell geen NVMe hardware RAID controller. De enige oplossing is de Dell S140 onboard controller te gebruiken aangezien die raid over NVMe kan bieden. Andere oplossing is de redundancy in de software op te lossen.
https://www.dell.com/supp...3-e9db3f1ef70d&lang=en-us

Dell ondersteund ook geen VROC (is een Intel CPU feature), de S140 is de Dell tegenhanger daarvan.

[ Voor 11% gewijzigd door Tijntje op 04-11-2019 16:28 ]

[FireDrunk]

@vso NVMe heeft voor zover ik weet ook gewoon SMART, en veel raid controllers hebben in de drivers ook SMART mogelijkheden.

Maar hij was software RAID aan het overwegen, dan hou je sowieso SMART. (Mits je een HBA gebruikt)

[Thralas]

Maxonic schreef op maandag 4 november 2019 @ 13:05:
Ik denk dan gelijk aan Linux MD raid maar er is blijkbaar ook zoiets als Intel VROC. Ik kom er alleen niet achter wat nu echt het verschil tussen Linux Software Raid en VROC is, wat voor verschil in performance ik tussen beide kan verwachten en of VROC überhaupt een volwassen techniek is die men in productie zou moeten willen gebruiken.

Het is gewoon een sausje bovenop tried & tested techniques (Linux MD).

quote: https://www.intel.com/con...0/memory-and-storage.html

What is the difference between Intel® VROC and Linux MD* RAID?
Intel® VROC for Linux is built on MD RAID, and Intel® VROC team has an MD RAID maintainer on the team. However, Intel® VROC has the following extra features:

• Provides UEFI HII and UEFI Shell command line RAID management
• Provides webpage based, remote RAID management and RESTful APIs
• Fully validated and supported with Purley platform and industry-select SSDs
• Provides hotfix/patch to specific customer issue on supported OS
• Provides a bootable NVMe RAID solution

Qua performance maakt het niet uit of je vanuit je UEFI (VROC) of OS (vanilla MD) je array configureert, alleen RAID metadata heeft een ander formaat. Als je de handleiding goed bekijkt zie je zelfs dat ze 'IMSM' als format gebruiken, dat is wat Intel al sinds jaar en dag slijt als Intel RST.

Dat laatste punt lijkt wel nuttig - booten van klassiek software RAID is niet geheel triviaal. En er vindt ook nog wat trucage op PCIe-niveau plaats (Intel VMD), maar dat lijkt transparant voor Linux.

[FireDrunk]

Booten van een md array is al jaren prima te doen? GRUB kan tegenwoordig md arrays mounten?

[Maxonic]

@Thralas Nuttige info, dank! Ik hoef niet van die schijven te booten dus of dat kan of niet maakt me niet zo veel uit.

[Tricq]

PostgreSQL doet uberhaupt niks in-memory toch?

[Keiichi]

Tricq schreef op dinsdag 5 november 2019 @ 13:35:
PostgreSQL doet uberhaupt niks in-memory toch?

Stel dat PostgreSQL niets in memory zou doen, dan heeft het OS vaak ook gewoon vrij recent aangeraakte blokken op een blockdevice gecached staan.

[Thralas]

Maxonic schreef op dinsdag 5 november 2019 @ 13:23:
@Thralas Nuttige info, dank! Ik hoef niet van die schijven te booten dus of dat kan of niet maakt me niet zo veel uit.

Dan denk ik dat je er weinig mee opschiet.

FireDrunk schreef op dinsdag 5 november 2019 @ 12:08:
Booten van een md array is al jaren prima te doen? GRUB kan tegenwoordig md arrays mounten?

Natuurlijk, maar één stapje terug nog: je UEFI. Die verwacht één EFI partitie, maar snapt geen RAID.

Je kunt het alsnog in RAID zetten, maar dan is het hopen dat je bootvolgorde correct ingesteld is en het niet alsnog spaak loopt bij een halfbrakke drive. En dat alles gaat ook enkel als je het non-default md (1.0) metadata format gebruikt - anders ziet je EFI helemaal geen bootpartitie. En dan maar hopen dat er geen scenario is waar het UEFI toch besluit naar je system partition te gaan schrijven.

RAID aware EFI is een stuk minder fragiel wat dat betreft, dus in die zin zie ik het selling point wel.

Keiichi schreef op dinsdag 5 november 2019 @ 13:40:
Stel dat PostgreSQL niets in memory zou doen, dan heeft het OS vaak ook gewoon vrij recent aangeraakte blokken op een blockdevice gecached staan.

Met andere woorden: PostgreSQL is afhankelijk van het OS voor caching - een designkeuze.

Handig om genoeg page cache te hebben om de hele database te cachen.

[ Voor 3% gewijzigd door Thralas op 05-11-2019 13:54 ]

[Keiichi]

Thralas schreef op dinsdag 5 november 2019 @ 13:53:

[...]


Met andere woorden: PostgreSQL is afhankelijk van het OS voor caching - een designkeuze.

Handig om genoeg page cache te hebben om de hele database te cachen.

PostgreSQL doe overigens genoeg zelf met het geheugen, zoals hier te lezen: https://severalnines.com/...mory-postgresql-databases

Denk dat vooral de 'shared buffer pool' als een soort van in-memory cache van tabellen en indexes gezien kan worden.

Dat het OS ook iets doet is een soort van bijeenkomstigheid als je niet veel aan tuning gedaan hebt. Hoe meer postgresql aan memory zal gebruiken, hoe minder er dan ook overblijft voor het OS natuurlijk.

[FireDrunk]

Thralas schreef op dinsdag 5 november 2019 @ 13:53:

Natuurlijk, maar één stapje terug nog: je UEFI. Die verwacht één EFI partitie, maar snapt geen RAID.

Je kunt het alsnog in RAID zetten, maar dan is het hopen dat je bootvolgorde correct ingesteld is en het niet alsnog spaak loopt bij een halfbrakke drive. En dat alles gaat ook enkel als je het non-default md (1.0) metadata format gebruikt - anders ziet je EFI helemaal geen bootpartitie. En dan maar hopen dat er geen scenario is waar het UEFI toch besluit naar je system partition te gaan schrijven.

RAID aware EFI is een stuk minder fragiel wat dat betreft, dus in die zin zie ik het selling point wel.

Goed punt, ik ben persoonlijk niet zo bang voor even de grub installatie 'opnieuw' doen in het geval van calamiteiten, maar je punt is zeker valide, het is weer een zorg minder.

[rippiedoos]

Hoezo is 2x SAS/SATA RI-SSD's in RAID1 voor booten van je OS geen optie dan? Is toch veel gebruikelijker dat je 2x RAID1 van 240G SSD's hebt en daarnaast die S140 of MD RAID voor 2x 1T NVMe in RAID1? Er wordt niet door de TS gesteld dat er alleen maar 2 NVMe-disken inkomen.

Wij hanteren die optie heel vaak en drukken er dan nog 2x 2T 7k2 SAS RAID1 in voor lokale backup.
2x 240G SSD's voor booten + OS
2x ??G SSD's voor database
2x ?T SAS-7k2 disken voor (lokale) backups of dumps

[johnkeates]

Heb je al gemeten wat er daadwerkelijk gebeurt? Kijk bijv. heel simpel wat de iowait is op het moment.
En waarom draai je zelf nog hardware? Stel dat het belangrijke data is, dan heb je ongetwijfeld redundancy, snapshots, replication, off-box backups, redundant power enz.

Schets anders eens een wat completer plaatje (met metrics), het kan zomaar zijn dat nu nog fysiek iets neerzetten geen toegevoegde waarde heeft. Aan de andere kant: stel dat je een softwarepakket hebt dat met een database moet praten en dat pakket geen webinterface heeft maar een klassieke fat client applicatie, dan moet je pakket natuurlijk in de buurt van de DB staan om dat de RTT anders supersnel in de weg gaat zitten als de applicatie een beetje onhandig geschreven is.

De enige reden dat ik nog fysiek spul ga neerzetten is als er een fat client is die niet mee kan, of als er geen snelle internetverbinding ligt. Alle andere combinaties zijn gewoon risico nemen waar dat helemaal niet nodig is.

[Kees]

Voor het OS en booten zou ik inderdaad gewoon de BOSS controller met 2x 240G ssd selecteren bij Dell. En dan de database op een rits ssd's. nvme gaat denk ik niet voor bijzonder grote verbeteringen zorgen tov bijvoorbeeld 8x 480G in een raid-10

[_-= Erikje =-_]

Postgres is sowieso geen ster in het gebruiken van multi threading.