Datawarehouse Server

[liledevil]

Beste,

Mij is gevraagd om onze huidige datawarehouse server te gaan vervangen door een, met name sneller, model. Dit omdat de huidige DWH server niet meer toereikend is.
Normaliter levert dit niet zo snel een probleem op, maar gezien de combinatie van een server van (pas) 2 jaar oud die niet meer toereikend is en de limiet die op dit moment gesteld is van ca 10.000 euri's loop ik wel tegen een probleem op.
Op dit moment hebben we een DL380G3, dual 3066Mhz, 5GB RAM. De schijven die erin zitten zijn 10K en werken in een raid 10.
Natuurlijk is er bij een DWH, zoals bij iedere DB, altijd wel winst te halen uit optimalisatie. Echter heeft de business aangegeven dat dit genoeg geprobeerd is, dit heeft ook wel wat winst opgeleverd, maar dat een nieuwe server als noodzakelijk moet worden beschouwd.
Nu wil ik niet een server configuratie gaan neerzetten(gewoon opvolger DL380) met iets meer CPU(3,6GHz) en pakweg 8GB RAM, maar echt een daadwerkelijk krachtigere machine met betere schaalbaarheid.
Hierdoor wilde ik graag een DL580 of DL585, waarbij ik de D-Core Opteron wel een mooie mogelijkheid vond, echter bij het opvragen van de prijs vielen hier een aantal mensen van de stoel.
Nu weet ik dat je niet voor een dubbeltje op de eerste rang kunt zitten, maar dit prijsverschil was ook wel aardig hoog(3x zo duur voor de basis tov DL380).
Nu vroeg ik me af of ik een model over het hoofd heb gezien bij hp/compaq of dat er misschien goede ervaringen zijn met andere merken(alhoewel ik dit zeer goed zal moeten gaan onderbouwen bij het management).
Kortweg, ik moet een krachtige opvolger hebben van een DL380(2x3Ghz, 5GB) welke bij voorkeur nog onder de 10K blijft.

[djluc]

Meerdere servers misschien een optie?

[Skaah]

Wellicht valt er het een en ander te scoren op het gebied van storage? Is het mogelijk om de server te upgraden met een RAID5 array van 10.000 euro's? Heb je gegevens (statistieken) over storage-, memory- en processorload?

[Jazzy]

liledevil schreef op maandag 24 oktober 2005 @ 15:25:
Natuurlijk is er bij een DWH, zoals bij iedere DB, altijd wel winst te halen uit optimalisatie. Echter heeft de business aangegeven dat dit genoeg geprobeerd is, dit heeft ook wel wat winst opgeleverd, maar dat een nieuwe server als noodzakelijk moet worden beschouwd.

Je zult dan wel heel goed moeten weten welke factor de belemmerende is. Ik heb het idee dat je dat niet weet. Of je weet het wel maar vertelt het niet.

Heb je pure processorkracht nodig? Als je nu een dual Xeon 3066 GHz hebt dan moet je inderdaad naar 4, 6 of 8 processoren. Maar dat kun je dus prima meten en aan de hand van die gegevens is het geen enkel probleem om te bepalen wat je nodig hebt om de vereiste performance te leveren.

Welke eisen worden er gesteld aan de opslag? Hoeveel IO's meet je nu en hoeveel doorvoer? Zit daar een bottleneck? Idem qua werkgeheugen e.d.

Zomaar even een 'snellere' server aanschaffen gaat niet werken, tenzij je heel rigoreus te werk gaat.

Het budget van 10k stelt je hopelijk in staat om de bottleneck op te sporen en op te kunnen lossen. Een nieuwe server met aanzienlijk betere prestaties op welk gebied dan ook gaat veel meer kosten.

[Abom]

Heel toevallig zijn wij ook naar een nieuwe server voor onze BI-tool aan het kijken.

Op dit moment is de server erg simpel, dl360g3, xeon 2.8ghz, 2gb memory.

Bij ons is de bottleneck hoofdzakelijk de storage, ik denk dat dit bij jullie ook het geval is. Om er zeker van te zijn, zul je toch iets moeten monitoren. Het is een beetje zonde wanneer je nu een hele nieuwe server gaat aanschaffen wanneer een extern storage cabinet ook al je probleem oplost.

Wij gaan waarschijnlijk naar een dl385 (dual-core, dual-cpu) met een extern storage cabinet (MSA30), wij hebben een bedrag van 17.500 euro hiervoor begroot.

[FastBunny]

Skaah schreef op maandag 24 oktober 2005 @ 15:35:
Wellicht valt er het een en ander te scoren op het gebied van storage? Is het mogelijk om de server te upgraden met een RAID5 array van 10.000 euro's? Heb je gegevens (statistieken) over storage-, memory- en processorload?

In een database server is een RAID10 array sneller. Alleen is het grote nadeel dat je 50% van je harddiskcapaciteit verliest. Echter is de schrijf snelheid een stuk hoger dan bij RAID5, en bij het verlies van een schijf blijft de snelheid hetzelfde.

Maar als er in de server nu nog 10k schijven zitten loont het zeker de moeite hier 15k schijven in te zetten.

[Stewie!]

Ga er wél vanuit dat als je voor één server gaat, je een single point of failure hebt, maar wél maar één dikke server hoeft te onderhouden ipv meerdere. Die dual-core is nieuw en leuk, maar ik zou even afwachten totdat ze in prijs dalen (zodra de eerste goede dualcore xeon's ruimer beschikbaar komen). Wat je ook kan doen is kijken naar een scherpgeprijsde Sun server met 4 opteron's uit de 8xx serie erin, die heb je ook al onder de 10k

edit:
linkje: http://catalog.sun.com/pr...item=FC_SC_CAT&group=2010

[ Voor 14% gewijzigd door Stewie! op 24-10-2005 16:09 ]

[liledevil]

Allemaal alvast bedankt voor de reacties.

Om nog even op een aantal zaken terug te komen, er wordt even van 1 server uitgegaan die productie gaat draaien, de "oude" server zal gaan dienen als ontwikkel en acceptatie server.

Ik heb zo geen directe logs bij de hand, wel meteen aangezet, maar ik meende mij de herinneren dat de schijven inderdaad het zwaar te verduren hebben. het raid bestaat nu uit een gedeelde 10/15K schijven. Wellicht dat het wat winst oplevert. Echter heb ik de log voor 24 aangezet en zal deze zeker posten.
Ik moet hier wel meteen bij zeggen dat dit niet van een moment van intensief gebruik is, ik heb daarom direct met de ontwikkelaar afgesproken dat op het eerstvolgende moment(schatting 1 nov) even een log wordt gedraaid tijdens intensief gebruik.

Raid 5 is nooit gebruikt op advies van verschillende DBA, dit hangt samen met de post die daarop volgde dat raid 10 sneller is in schrijfbewerkingen dan raid5. De investering in schijven is hierdoor altijd voor lief genomen.

De schijven zitten nu, bij voorkeur ook in een volgende opstelling, in een extern schijven kabinet(MSA30) die aan een 6400 series controller hangt met BBWC.

Nu ik er door alles heen lees begin ik ook weer te denken waarom ik geen single-core cpu's had opgevraagd, heeft iemand een idee hoe deze zich in prijs verhouden tot de dual-core, anders vraag ik even een nieuwe offerte op.

nogmaals alvast bedankt voor jullie input

[Stewie!]

Hoewel serverfabrikanten vaak extreme marges op CPU's hanteren, is de pricewatch wel handig om een indruk te krijgen:

Tweakers.net Pricewatch
AMD Opteron 248 (S940, 2,2GHz, 1MB, Boxed) € 343,95
AMD Opteron 275 Dual Core (S940, 2,2GHz, 2x1MB, Boxed) € 1080,-
AMD Opteron 848 (S940, 2,2GHz, 1MB, Boxed) € 909,-

Duidelijk te zien dat een dual-core dual opteron vrijwel altijd goedkoper zal zijn dan een 4 weg Opteron server. De dualcore 4 weg opteron server zal echter wél weer meer "bang for your buck" geven

[ Voor 38% gewijzigd door Stewie! op 24-10-2005 16:42 ]

[Abom]

DaMorpheus schreef op maandag 24 oktober 2005 @ 16:40:
[...]
Duidelijk te zien dat een dual-core dual opteron vrijwel altijd goedkoper zal zijn dan een 4 weg Opteron server. De dualcore 4 weg opteron server zal echter wél weer meer "bang for your buck" geven

Waarschijnlijk wel. Ik weet even niet welke database er op deze machine draait, ik ga even van MSSQL uit. Microsoft handteerd een per socket license model, bij een 4-way server ben je al 10.000 euro kwijt voor je SQL license (5k voor een dual-core, dual-CPU). Oracle heeft ook een iets voordeliger model voor dual-cores dan single, maar niet per socket zoals MS...

Is ook wel de moeite waard om rekening mee te houden.

[ Voor 5% gewijzigd door Abom op 24-10-2005 16:55 ]

[Jazzy]

Ik heb zo geen directe logs bij de hand, wel meteen aangezet, maar ik meende mij de herinneren dat de schijven inderdaad het zwaar te verduren hebben. het raid bestaat nu uit een gedeelde 10/15K schijven. Wellicht dat het wat winst oplevert. Echter heb ik de log voor 24 aangezet en zal deze zeker posten.
Ik moet hier wel meteen bij zeggen dat dit niet van een moment van intensief gebruik is, ik heb daarom direct met de ontwikkelaar afgesproken dat op het eerstvolgende moment(schatting 1 nov) even een log wordt gedraaid tijdens intensief gebruik.

Begin daar nu maar eens mee. De leverancier van de database zal je het één en ander aan documentatie kunnen geven om specifiek te kunnen monitoren. Sizing is de volgende stap.

Stel dat de bottleneck in je storage zit dan koop je voor 30k een nieuwe server met 15k schijven en ontdek je dat dit maar een heel klein beetje scheelt in performance. Terwijl je dezelfde winst ook had kunnen berijken door een paar schijven te vervangen.

Raid 5 is nooit gebruikt op advies van verschillende DBA,

Logisch.

[Verwijderd]

DaMorpheus schreef op maandag 24 oktober 2005 @ 16:40:
Duidelijk te zien dat een dual-core dual opteron vrijwel altijd goedkoper zal zijn dan een 4 weg Opteron server. De dualcore 4 weg opteron server zal echter wél weer meer "bang for your buck" geven

Plus dat de performance, mits het geen geheugenbandbreedte-intensieve app is behoorlijk gelijk oploopt als ik de benchmarks mag geloven. Erg netjes dus

[paulhekje]

Voordeel van de DL385 (Opteron) t.o.v. DL380 (Xeon) is dat er meer geheugen in de server kan.
VMware ESX draait hier daarom op dual Opterons, naast het feit dat ze meer rekenkracht bezitten.

meten=weten, dus eerst een goede performance meting doen.

[Rolfie]

Er zit een groot verschil tussen de dl38x en de dl58x. Het grootste verschil zit hem in de redudantie mogelijkheden van deze server. De 58x heeft ook een veel sneller geheugen bus en de kans dat je een kritiek hardware probleem op deze machine krijgt is kleiner. Daar is echter de prijs ook naar.

Als je onder de 10K wilt blijven, dan zou ik gaan naar een dl385, 10Gb geheugen, smart array 6400 (192Mb) dual processor, redudantie fans redudantie voeding. RAID 1 voor het OS, daarnaast nog een RAID 1 voor overige applicaties. Kies ook de dual backplane optie, met deze optie split je de interne SCSI bay in 2 verschillende bays (= 2 SCSI bussen). Daarbija een losse 6400 Array Controller voor je MSA30. Dit moet te doen zijn voor rond de 10K

[Jazzy]

Rolfie schreef op dinsdag 25 oktober 2005 @ 08:07:
Er zit een groot verschil tussen de dl38x en de dl58x. Het grootste verschil zit hem in de redudantie mogelijkheden van deze server. De 58x heeft ook een veel sneller geheugen bus en de kans dat je een kritiek hardware probleem op deze machine krijgt is kleiner. Daar is echter de prijs ook naar.

Als je onder de 10K wilt blijven, dan zou ik gaan naar een dl385, 10Gb geheugen, smart array 6400 (192Mb) dual processor, redudantie fans redudantie voeding. RAID 1 voor het OS, daarnaast nog een RAID 1 voor overige applicaties. Kies ook de dual backplane optie, met deze optie split je de interne SCSI bay in 2 verschillende bays (= 2 SCSI bussen). Daarbija een losse 6400 Array Controller voor je MSA30. Dit moet te doen zijn voor rond de 10K

Maar nu weet de TS nog niets met zekerheid over de performancewinst die hij mag verwachten. Het enige wat zeker is is dat zijn baas 10k lichter is geworden en dat de TS een goed verhaal moet klaar hebben als blijkt dat de performance niet significant verbeterd is.

Laat de TS nou eerst maar eens meten waar zijn probleem zit en pas dan een gericht hardwarer-advies geven. Een leuk servertje in elkaar schroeven voor 10k kunnen we allemaal wel.

[liledevil]

Daar is mijn log dan, ff voor de snelheid,
geel is geheugen,
blauw(achtig) is processor en
paars(achtig) is disken.
Het blijkt toch meer dan, ik had , verwacht te zitten in de disken, dit zal zeker denk ik een hele andere draai gaan geven hoe we verder gaan.
Toch denk ik dat de vraag voor een nieuwe datawarehouse blijft openstaan om een goede seperate ontwikkel-omgeving te hebben ipv enkel een losse db-instance.
Dus tips waar allemaal rekening mee te houden blijven welkom.

[ Voor 3% gewijzigd door liledevil op 25-10-2005 10:24 ]

[StevenK]

liledevil schreef op dinsdag 25 oktober 2005 @ 10:21:
[afbeelding]
Daar is mijn log dan, ff voor de snelheid,
geel is geheugen,
blauw(achtig) is processor en
paars(achtig) is disken.
Het blijkt toch meer dan, ik had , verwacht te zitten in de disken, dit zal zeker denk ik een hele andere draai gaan geven hoe we verder gaan.
Toch denk ik dat de vraag voor een nieuwe datawarehouse blijft openstaan om een goede seperate ontwikkel-omgeving te hebben ipv enkel een losse db-instance.
Dus tips waar allemaal rekening mee te houden blijven welkom.

Die disk queue length kan ook veroorzaakt worden door de manier waarop de disken benaderd worden. Wat voor platform is het ?

Het kan bijvoorbeeld zijn dat het file system de bottleneck is en dan kun je met bijvoorbeeld MS SQL er ook voor kiezen RAW partitions te gebruiken...

[ Voor 9% gewijzigd door StevenK op 25-10-2005 10:34 ]

[Verwijderd]

De oplossing voor je probleem zit waarschijnlijk in het gebruik van je disken. Bij databases worden steeds veel en kleine bestanden van en naar de disken gestuurd. De oplossing zal dus meer liggen in het bijplaatsen van een diskcabinet met voldoende schrijfarmen om het I/O gebruik op te vangen. Een zeer goedkoop trucje kan echter ook zijn om caching modules op de raidcontrolers te plaatsen. Je hebt een (kleine) kans dat dit al je probleem oplost.

[The Eagle]

Verwijderd schreef op dinsdag 25 oktober 2005 @ 14:51:
De oplossing voor je probleem zit waarschijnlijk in het gebruik van je disken. Bij databases worden steeds veel en kleine bestanden van en naar de disken gestuurd. De oplossing zal dus meer liggen in het bijplaatsen van een diskcabinet met voldoende schrijfarmen om het I/O gebruik op te vangen. Een zeer goedkoop trucje kan echter ook zijn om caching modules op de raidcontrolers te plaatsen. Je hebt een (kleine) kans dat dit al je probleem oplost.

Helemaal mee eens. En zoals al gezegd: meten is weten
Hoe zit het met je clustergrootte e.d.? kan best zijn dat die verkeerd is ingesteld, waardoor je performance-verlies krijt. En wat voor DWH hebben we het over? Welke DB, welke DWH-software? DWH software mag misschien geoptimaliseerd zijn, maar als de DB zelf dat niet is heb je er nog geen kloot aan
Wat ik je verder ook nog aan wil raden is eens naar O&O Defrag te kijken. Die kan op verschillende manieren defraggen, waarbij expliciet gekeken wordt naar de soort server. kan een bult in performance schelen

[_Arthur]

http://www.oreillynet.com.../2002/01/18/diskperf.html

Goed stuk over diskperformance en hoe je de 'output' van de performance itsm moet uitleggen.