Bekijk Volledige Versie : Aanschaf nieuwe DB server
Ralphmeister
20/02/13, 10:41
Ik wil graag een nieuwe database server welke draait op een RAID1 of RAID5 array. Hier ben ik nog niet helemaal uit en is voor mij ook niet heel erg van belang.
Wat ik wel belangrijk vindt is dat op het moment dat een van de schijven kapot gaat ik de array kan rebuilden terwijl het systeem doordraait. Dat hij automatisch rebuild naar een hotspare zou nog mooier zijn.
Maar in eerste instantie gaat het erom dat het niet de bedoeling is dat wanneer het rebuilden 4 uur duurt de server ook 4 uur downtime heeft.
Is dit mogelijk en met welke hardware (RAID controller) zou dit het beste gaan? Meeste kopen we bij Dell dus in eerste instantie gaat de voorkeur die kant uit.
Enkel probleem is dat ik iemand van Dell heb gesproken en hij mij vertelde dat Dell hier geen oplossing voor heeft. Volgens hem kan je OS niet blijven draaien als het OS een de array staat die je aan het rebuilden bent.
Heel bijzonder verhaal van dell, want dat is toch echt wat ik vrijwel altijd doe, rebuilden terwijl het OS weer aanstaat (of meestal, terwijl het OS niet uit geweest is)
Waar ik wel altijd naar vraag is of er ook cli tooltjes voor linux/unix zijn.
asusk7m550
20/02/13, 11:31
Wat een bijzondere reactie van Dell.
Op het moment dat je een hardwarematige RAID controller hebt (de PERC H series, de PERC S series is softwarematig), moet dit gewoon mogelijk zijn, zolang je maar de juiste drivers hebt onder het OS. Je moet (als het OS draait), het rebuilden natuurlijk wel kunnen aansturen.
Qua snelheid zou ik voor RAID5 gaan, op dit moment heb je een goede balans tussen het schrijven en lezen vanuit een RAID array. Om het zeker te weten, zou je wat tests kunnen uitvoeren, om te kijken wat het beste voor je is.
Ik zou standaard al een extra schijf toevoegen, zodat je snel kan rebuilden mocht het nodig zijn.
Verbaas me ook over de reactie van Dell. De H700 e.d. kan dit prima.
systemdeveloper
20/02/13, 11:43
Misschien heb je een m$ medewerker gesproken die al bij dell aan de telefoon zit?
De meeste hardware raid controllers hebben mogelijkheden voor hotswaps en live rebuilden vanaf een hotspare, aangenomen dat je chassis uiteraard ook hotswap is :D
De meeste hardware raid controllers hebben mogelijkheden voor hotswaps en live rebuilden vanaf een hotspare, aangenomen dat je chassis uiteraard ook hotswap is :D
Hotswap chassis nodig om hotspare te gebruiken?
Gaat weer lekker vandaag
systemdeveloper
20/02/13, 13:02
Hotswap chassis nodig om hotspare te gebruiken?
Gaat weer lekker vandaag
Uiteraard, anders kun je de kast openschroeven om alsnog de kapotte disk te vervangen. Ik weet niet of jij dat met de power erop doet, maar ik niet iig ;)
Nee, maar het geeft je wel de tijd om een onderhoudsvenster in te plannen. ;)
Ralphmeister
21/02/13, 17:36
Dit klinkt allemaal wat beter dan wat ik eerder gehoord heb.
Dit is overigens letterlijk gekopieerd uit de correspondentie met Dell:
Ik krijg onderstaande reactie van mijn technische collega.
Eventueel is een server met een gescheidden array en betere optie, dan spreekt men van een raid 1 voor OS en een raid 1 of 5 voor de data.
Het blijft echter zo dat bij het rebuilden van een raid array de gegevens niet beschikbaar zijn.
Om het allemaal nog iets duidelijker te maken, al deze gesprekken zijn naar aanleiding van een offerte voor o.a.:
1x Chassis with up to 4, 3.5" or 2.5" Hot Plug Hard Drives
4x 1TB, Near-Line SAS 6Gbps, 3.5-in, 7.2K RPM Hard Drive (Hot-plug)
1x PERC H310 Integrated RAID Controller
Als laatste nog even de vraag of ik hiermee dan een RAID5 array kan maken van 3x1TB met 1x1TB als hotspare. En als belangrijkste punt nog steeds, als deze hotspare aan de array wordt toegevoegd (tijden de rebuild dus) bij een kapotte schijf, blijft mijn server dan gewoon in de lucht en kan ik na een tijdje de kapotte schijf dan weer vervangen voor een nieuwe hotspare?
Ik zou zeker overwegen om de H710 controller te nemen, over de h310 lees je veel verhalen mbt slechte performance.
En ipv raid5 met 3 schijven en hotspare zou ik dan kiezen voor raid6. (zodat er ten alle tijden 2 disken kunnen failen voordat de data kwijt is)
Alleen kost raid6 (of raid5 met hs) de helft van je disken als je maar 4 disken in totaal hebt. (en zou je ook raid10 kunnen doen)
Ik vind het vreemd dat iedereen hier aanbevelingen loopt te doen terwijl het helemaal niet duidelijk is wat de noden zijn van de topic starter.
Kan topic starter misschien eens even aangeven:
- Welk Operating System en RDBMS er gebruikt wordt?
- Wat is de grootte van de huidige database(s)
- Hoe ziet het huidige systeem eruit?
- Waarom wordt het huidige systeem vervangen? Is de performantie niet meer voldoende? Indien ja, ligt dit bij zekerheid aan de hardware?
- Welke specificaties zijn er nodig? En dan vooral geheugen en IOP's. Voor mij gaan DB server en 7200RPM disks + RAID5/6 écht niet samen bv.
PS: Trek je niet teveel aan van die opmerking van de Dell medewerker. Dat lijkt mij zéér onwaarschijnlijk bij een server-grade systeem met een RAID controller.
Ralphmeister
22/02/13, 12:08
Ik vind het vreemd dat iedereen hier aanbevelingen loopt te doen terwijl het helemaal niet duidelijk is wat de noden zijn van de topic starter.
Kan topic starter misschien eens even aangeven:
- Welk Operating System en RDBMS er gebruikt wordt?
- Wat is de grootte van de huidige database(s)
- Hoe ziet het huidige systeem eruit?
- Waarom wordt het huidige systeem vervangen? Is de performantie niet meer voldoende? Indien ja, ligt dit bij zekerheid aan de hardware?
- Welke specificaties zijn er nodig? En dan vooral geheugen en IOP's. Voor mij gaan DB server en 7200RPM disks + RAID5/6 écht niet samen bv.
PS: Trek je niet teveel aan van die opmerking van de Dell medewerker. Dat lijkt mij zéér onwaarschijnlijk bij een server-grade systeem met een RAID controller.
- CentOS met MySQL
- 220GB maar groeit redelijk snel
- Dell R2, Pentium(R) Dual-Core CPU E5400 @ 2.70GHz, 4GB, 250GB RAID1, CentOS 5.9, MySQL
- Performance is OK, kan beter. Wordt vervangen omdat hardeschijfruimte opraakt. Dit ligt dus met zekerheid bij de hardware. Omdat alles overzetten veel werk is willen we het meteen goed doen.
- Prijs / kwaliteit.. Moet wel 2TB aan opslag zijn en wat ik zeg, wat er nu staat is stuk minder en OK. Budget 2000/3000 en voor dat geld de opslag van 2TB en verder zo snel mogelijk.
Yourwebhoster
22/02/13, 19:48
Vraagje: is 220GB echt database of van de server? Kan het zo zijn dat logs of andere bestanden dan de database zoveel ruimte in neemt? Ik kan mij niet voorstellen dat een database van 220GB met een budget dual core CPU en 4GB RAM goed kan performen. Ik weet natuurlijk niet wat voor databases allemaal op die server zit maar echt performen zal deze setup nooit doen.
Uiteraard, anders kun je de kast openschroeven om alsnog de kapotte disk te vervangen. Ik weet niet of jij dat met de power erop doet, maar ik niet iig ;)
Een hotspare is een extra disk die al in de kast zit en automatisch gebruikt wordt zodra er een disk uitvalt. Hoewel het wel handig is om hotswap te hebben om de defecte disk te vervangen, is het absoluut niet noodzakelijk voor het gebruik van de hotswap disk.
En als belangrijkste punt nog steeds, als deze hotspare aan de array wordt toegevoegd (tijden de rebuild dus) bij een kapotte schijf, blijft mijn server dan gewoon in de lucht en kan ik na een tijdje de kapotte schijf dan weer vervangen voor een nieuwe hotspare?
Ja (duidelijker kan ik het niet maken)
Yourwebhoster
23/02/13, 10:20
Een hotspare is handig maar ivm continuïteit ga ik mee met John (Systemdeveloper). Als je dan toch al een luxe oplossing hebt waarom dan hotswap achterwege laten?
@TS: als je niet zeker weet wat de db omvang is of wat meer info zou willen zoals de situatie nu is stuur dan even een PB. Ik kijk dan even met je mee.
systemdeveloper
23/02/13, 12:58
Een hotspare is een extra disk die al in de kast zit en automatisch gebruikt wordt zodra er een disk uitvalt. Hoewel het wel handig is om hotswap te hebben om de defecte disk te vervangen, is het absoluut niet noodzakelijk voor het gebruik van de hotswap disk.
Na 20 jaar weet ik echt wel het verschil tussen hostspare en hotswap, hoor ;)
Je pakt toch een hotspare om sneller zonder downtijd weer een werkende raid te krijgen? Uiteraard is een hotswap niet nodig als je zin hebt om je klant alsnog down te gooien, ook al is het binnen een nachtelijk onderhoudswindow, en de bak open te schroeven.
Echter met een hotswap kun je dat gemakkelijk live en overdag doen of via een telefoontje naar het dc.
Ralphmeister
23/02/13, 19:34
@TS: als je niet zeker weet wat de db omvang is of wat meer info zou willen zoals de situatie nu is stuur dan even een PB. Ik kijk dan even met je mee.
In de eerste plaats gaat het om mobiele devices die via een simkaart hun verzamelde data naar ons backoffice stuurt waar deze data in de database wordt gezet. Omdat het om aardig wat devices gaat die elke 5 / 10 / 60 seconde hun logwaardes sturen is de database echt groot. Mede ook door de index om het allemaal een beetje te laten performen. Het kan misschien veel sneller met betere hardware maar het was acceptabel en het budget was toen kleiner dan nu. Er zijn meer klanten, dus meer data waardoor de database nog sneller groeit en daardoor gelukkig nu ook een groter budget. Voordeel is wel dat we dus heel veel data opslaan maar dit niet continu wordt uitgelezen, de grote queries vallen dus best mee. De database is dus groot omdat we veel opslaan maar deze data wordt niet continu gebruikt zeg maar.
Dan nu de getallen, er zijn wat overige databases maar het overgrote deel wordt bepaald door een database (uitgelezen met MySQL Administrator) van 75GB en een index van 105GB.
CREATE TABLE `database`.`log_data_uint16` (
`deviceid` mediumint(8) unsigned NOT NULL default '0',
`logid` smallint(5) unsigned NOT NULL default '0',
`timestamp` timestamp NOT NULL default '0000-00-00 00:00:00',
`value` smallint(11) unsigned NOT NULL default '0',
PRIMARY KEY (`deviceid`,`logid`,`timestamp`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
Deze tabel is er ook voor uint8, uint32, uint64 en de signed types. Aan de key kan je zien dat de data dus per device, per logid wordt binnengehaald. Dit gaat dan over het algemeen om een uur een dag en maximaal eigenlijk een maand. In de query wordt deze data dan gegroepeerd tot maximaal 500 waardes waaruit een grafiek wordt gecreëerd.
Nu ben ik wel benieuwd of het allemaal toch wel mee valt en logisch is dat het soepel draait op de huidige machine of dat je denkt dat het stukken sneller kan met betere hardware?
Misschien dwalen we nu alleen een beetje af van mijn initiële vraag al sta ik open voor andere suggesties, wat zou voor die 2000/3000 euro een betere setup zijn om de core business zoals hierboven omschreven op te laten draaien?
systemdeveloper
23/02/13, 20:20
Ik zou een cumalatieve tabel toevoegen met de reeds gegroepeerde waardes. Mysqld performt pas goed als ie zijn indexen in het geheugen kan laden en dat lijkt me met 105GB aan indexen een beetje lastig.
(Een truukje kan zijn om je value veld ook nog in de index te gooien. Dat maakt de index iets groter maar het voordeel is dat mysql niet meer hoeft te lezen uit de datafile omdat alle velden reeds in de index zitten).
Verder kun je de tabel nog partitioneren (op maand/week/whatever) zeker omdat je maximaal 500 waardes gebruikt.
Eigenlijk lijkt het meer op een logtabel en dan zou ik eens kijken of je de index niet helemaal kunt dumpen en eventueel vervangen door een inserttrigger/cronjob die een cumulatieve tabel bijwerkt. Spaart je direct 105 gb aan indexen waardoor alleen de cumulatieve indexen nog ram gebruiken. Dat is sowieso een stuk minder en zal retrievel een stuk sneller maken.
Een iets andere opzet kan je dus al veel performance schelen en problemen in de toekomst als je data 3 keer zoveel is of een storing (Een index nieuw moeten aanmaken van 105GB duurt wel even namelijk).
Ralphmeister
25/02/13, 11:50
De truuk van de value ook in de index is inderdaad wel een idee, verder is het eigenlijk een logtabel. Hoe ouder hoe verder bovenaan de data staat, de nieuwe data komt er onder.
Al zou ik me in dat logtabel stuk verder moeten verdiepen.
Je laatste punt heb ik momenteel opgelost. Elk device heeft nu een eigen database in plaats van alle devices in één enkele tabel. Je haalt toch altijd data op van maar 1 device per keer. Dit maakt backuppen ook makkelijker en de data is meer geïsoleerd.
Maar deze dingen zouden misschien nog iets kunnen optimaliseren maar voor de rest denk ik dat het wel soepel draait als je kijkt naar de hardware die we hebben staan.
Mijn vraag was dan ook eigenlijk of je nog suggesties hebt wat betreft de aan te schaffen hardware voor dit soort werkzaamheden in de 2000/3000 euro range?
systemdeveloper
25/02/13, 12:01
Zolang je niet megaveel geheugen nodig hebt omdat je geen gekke joins maakt zou je eens kunnen kijken naar 2x480gb ssd's en 2xsata backupdisks (voor mysqldumps of zo), beide in raid 1 en een snelle quadcore.
Als je dan nog budget over hebt -> aanvullen met ram.
Met partitioneren bedoelde ik eigenlijk http://dev.mysql.com/doc/refman/5.1/en/partitioning-types.html maar jouw manier kan net zo goed werken.
Ramon Fincken
25/02/13, 12:47
Klopt het dat die logtabel MyISAM is? Mogelijk haal je meer snelheid als je werkt met innoDB.
Wellicht een idee om ook een MySQL DBA naar je hele setup te laten kijken, een goede MySQL configuratie kan ook veel schelen. InnoDB e.d. kan mogelijk interessant zijn afhankelijk van de hoeveelheid geheugen/je MySQL configuratie en applicatie. Verder zou ik zeker een hotspare nemen en een disk/cold spare op locatie laten leggen zodat je direct een defecte disk kan vervangen indien deze failed.