Tweakers tijdelijk read-only bij live gaan nieuwe databaseserver - update

Op maandagochtend 21 januari heeft Tweakers een nieuwe databaseserver in gebruik genomen. De site is hierdoor enkele minuten read-only beschikbaar geweest. Inmiddels is het onderhoud succesvol afgerond.

Omdat de huidige databaseserver, Artemis 6, zijn derde verjaardag al enige tijd geleden heeft mogen vieren, is het hoog tijd om hem te vervangen. Het uitzoeken van een waardige opvolger voor deze databaseserver was geen sinecure, de specificaties van Artemis 6 zijn zelfs na 3 jaar nog behoorlijk indrukwekkend. Desondanks zijn we er weer in geslaagd om de specificaties te verbeteren.

De nieuwe databaseserver, Artemis 7, is een 1u IBM x3550 M4, met daarin twee Intel Xeon E5-2643-quadcore-processoren die op 3,3GHz lopen. Omdat geheugen meestal sneller is dan een harde schijf, hebben wij deze server afgeladen met 16 reepjes ddr3-geheugen van 1600MHz en 16GB, zodat de totale hoeveelheid geheugen op 256GB uitkomt. Dat is genoeg om onze hele database in het geheugen te laden en meer dan alle voorgaande Artemis- en Apollo-iteraties bij elkaar. Het nadeel hiervan is wel dat je makkelijk een kopje koffie kunt gaan drinken terwijl de server tijdens de boot het geheugen controleert.

Het is wel leuk om je hele database in het geheugen te laden, maar zodra je de server reboot, wil je je data ook nog ergens veilig hebben staan. Om dit te regelen hebben we de server ook uitgerust met 6 ssd's van 256GB, die in raid 10 hun werk doen. Ten slotte zitten er nog twee sata-harde schijven van 250GB in, waarop het besturingssysteem staat.

Deze nieuwe server hebben wij op maandagochtend rond 9 uur in gebruik genomen. Hierdoor zal de site korte tijd slechts read-only beschikbaar zijn.

Hieronder volgt een overzicht van oude hardware die jullie met je postgedrag versleten hebben:

	Artemis 1 (06-12-2000)	Apollo 1 (15-06-2001)
Processors	2x Pentium III 733MHz - 1,0GHz	2x Pentium III 1,0GHz
Geheugen	1,5GB - 4GB PC133 SDR	2GB - 4GB PC133 SDR
Raid-controller	AMI MegaRAID Elite 1500	Adaptec ASR-3200S
Opslag	1x 20GB ata 3x Seagate Cheetah X15 18GB	2x Quantum Atlas 10K II 18GB
	Artemis 2 (14-12-2001)	Apollo 2 (31-08-2002)
Processors	2x Athlon MP 1600+ 1,4GHz	2x Athlon MP 1900+ 1,6GHz
Geheugen	2GB DDR-266	3,5GB DDR-266
Raid-controller	Adaptec ASR-3200S	Adaptec ASR-3200S
Opslag	1x 20GB ata 5x Seagate Cheetah X15 18GB	1x 20GB ata 5x Seagate Cheetah 36XL 36GB
	Artemis 3 (01-11-2003)	Apollo 3 (20-12-2003)
Processors	2x Opteron 246 2,0GHz	2x Opteron 242 1,6GHz
Geheugen	4GB DDR-266	6GB DDR-266
Raid-controller	LSI MegaRAID Elite 1600	LSI MegaRAID Elite 1600
Opslag	2x Seagate Cheetah 18XL 9GB 4x Seagate Cheetah 10K.6 36GB	6x Seagate Cheetah 10K.6 36GB
	Artemis 4 (17-11-2006)	Apollo 4 (17-05-2004)
Processors	2x Opteron 254 2,8GHz	2x Opteron 244 (1,8GHz)
Geheugen	8GB DDR-333	8GB DDR-333
Raid-controller	LSI MegaRAID SCSI 320-2X	LSI MegaRAID SCSI 320-2X
Opslag	2x Seagate Cheetah 10K.6 36GB 6x Seagate Cheetah 15K.3 36GB	2x Seagate Cheetah 10K.6 36GB 6x Seagate Cheetah 15K.3 36GB
	Artemis 5 (28-07-2007)	Apollo 5 (01-09-2006)
Processors	2x Xeon X5355 2,66GHz	2x Xeon 5160 3,0GHz
Geheugen	16GB DDR2-667	16GB DDR2-667
Raid-controller	Dell Perc 5/i Dell Perc 5/e	Dell Perc 5/i Dell Perc 5/e
Opslag	2x Seagate Savvio 10K.2 73GB 15x Seagate Cheetah 15K.5 73GB	2x 73GB 10K SAS 15x Fujitsu MAX3036RC 36GB 15K SAS
	Artemis 6 (24-10-2009)	Apollo 6 (01-06-2010)
Processors	2x Xeon X5570 2,93GHz	2x Xeon X5660 2,80GHz
Geheugen	72GB DDR3-800	48GB DDR3-1066
Raid-controller	Dell Perc 6/i	Dell Perc H700
Opslag	2x Seagate Savvio 10K.3 300GB 6x Dell / Samsung MCCOE50G5MPQ 50GB	2x Seagate Savvio 10K.3 300GB 6x Dell / Samsung MCB4E50GAD3Q 50GB
	Artemis 7 (21-1-2013)
Processors	2x Xeon E5-2643 3,3GHz
Geheugen	256GB DDR3-1600
Raid-controller	IBM ServeRaid M5110
Opslag	2x 250GB SATA 6x 256GB SSD

De oude hardware krijgt, zoals gebruikelijk, werk als test- en developmentserver.

Update 21-1 9:42: Het vervangen van de oude server is gelukt. In totaal was er een downtime van iets minder dan 3 minuten voor nodig.

Reacties (183)

[Verwijderd]

Ik zit even met jullie configuratie van de harde schijven: met name het datagedeelte, dat jullie op 6 SSD-schijven hebben gezet. Nu weet ik dat een RAID-10 zo'n beetje de snelste dataoverdracht biedt van de bekendere RAID-configuraties. Echter: door voor een RAID-10 te kiezen, halveer je de helft van de effectieve schijfruimte. (Voor diegenen die RAID-configuraties niet kennen, Wikipedia heeft een mooie uitleg, en RAID 10 kun je dan het beste omschrijven als een gespiegelde stripe-set).

Indien er één schijf in jullie configuratie uitvalt, zal die in principe makkelijk vervangen worden, zonder dat er enig probleem optreedt. Echter: het is een bekend probleem dat in dit soort configuraties vaak al de schijven uit dezelfde productieserie komen, en dus vaak ook dezelfde problemen (life expectency) hebben: valt er één uit, dan valt vaak binnen no-time ook een tweede uit. Valt die tweede uit, en blijkt die dan net aan de andere kant van de mirror te liggen, gaat de gehele server onderuit, en zijn de gegevens zeker niet zomaar te herstellen, tenzij van een back-up.

Aan de hand van bovenstaande is mijn vraag: waarom is er niet gekozen voor een RAID6 oplossing? Die biedt meer bescherming. In het artikel stellen jullie dat de gehele database in het geheugen wordt geladen, en dat dat sneller zal werken dan de SSD's, dus is de snelheid waarmee de informatie in een RAID benaderd kan worden, geen doorslaggevende factor. Daarop voortbordurend zou je met een RAID6 zelfs meer effectieve schijfruimte tot je beschikking krijgen.

Even voor de duidelijkheid: Ik heb dan wel een verleden in systeembeheer, maar ben daar al een hele tijd uit. deze post is met name gebaseerd op mijn kennis van data recovery (wat mijn werk is).

[ACM]

Het grootste nadeel van RAID 5 en 6 is dat bij iedere block-write elke disk mee moet doen en een klein stukje van de data moet wegschrijven. Dat is normaal gesproken het grootste voordeel, maar dat wordt wat minder als je met storage-devices zitten die letterlijk per schrijfhandeling verslijten.

Dan wil je zo min mogelijk per disk schrijven. De RAID-10 configuratie past daar beter bij dan RAID6. Uiteraard zullen moderne controllers - zeker als ze speciale SSD-modi hebben - wel proberen het aantal schrijf-handelingen te beperken...

Naast betrouwbaarheid is performance voor databases inderdaad behoorlijk belangrijk, vooral de schrijfprestaties van ie I/O-omgeving (omdat het gros van de data inderdaad wel in RAM blijft). Met RAID6 degradeer je de maximale schrijfprestaties tot wat de raid-controller ervan kan cachen en daarna tot de snelheid van je langzaamste schijf. Ook hier geldt dat moderne controllers het redelijk weten te maskeren, maar ook hier geldt dat RAID10 er net wat beter bij past

Al met al is het een lastige keuze omdat zowel RAID6 en RAID10 voordelen hebben en die voordelen zijn nogal met elkaar in strijd.

Overigens is je punt van gelijktijdige uitval ook bij RAID6 juist een groot probleem, vooral met traditionele harde schijven. De rebuild van het RAID-array belast je disks zoveel, dat er een grote kans is dat een andere disk juist stuk gaat tijdens de rebuild
Aangezien SSD's niet echt slijten van leeswerk is dat voor SSD's waarschijnlijk niet zo'n probleem.

Naast ssd's kan er natuurlijk wel meer stuk gaan waar de hele server van onbruikbaar wordt. Denk aan een cpufan die het begeeft en daarmee de boel in paniek-modus schopt of een nic of moederbord die de geest geeft. Ook zijn voedingen en de power-circuits daar direct achter plekken waar de boel het kan begeven.

Dit soort problemen is dan ook de reden dat we een met replicatie werken. Als de master-server om wat voor reden dan ook helemaal onbruikbaar wordt kunnen we met weinig tot geen dataverlies overschakelen naar de slave-server.

[itlee]

@esollie, legitime vraag daar ligt het niet aan, maar of tweakers heeft een goed ondershoudcontract op die spullen of ze hebben een paar spares op de plank liggen.

aangezien het datacentrum bijna om de hoek is ben je ook snel met wisselen.

Tweakers kennende gaan ze voor maximale snelheid, performance en zijn ze min of meer ook verplicht naar de tweakers die elke dag de site bezoeken.

eigenlijk is het al 3 dubbel op, SSD zijn al rete snel (80.000iops ofzo?) dan nog is een keer in een raid wat het dus nog sneller maakt, en dan ook nog is een keer gestriped...

Als ze willen kunnen ze ook gewoon een Raid 1 aangezien de hele database 200 gb is,...zelfs dan ga jij en ik het niet merken als we een videootje of artikeltje klikken.

@tweakers.net puike configuratie, gaaf hoor! +1 zeg ik.

[Freeaqingme]

Mooi speelgoed!

Is er een keuze niet voor blades + SAN te gaan?

[Kees]

Voornamelijk omdat wij tweakers graag snel willen houden.

Shared storage vertraagt de boel nogal tov lokale storage, en blades zijn gewoon te duur in het algemeen. En als je gaat virtualiseren dan is het al helemaal een ramp qua performance.

Een ander nadeel van blades is dat je je enclosure ook zo snel mogelijk wil vullen, en ook daar gaat het mis want wij vervangen servers 1 voor 1 zodat we ze niet al te lang nutteloos in het rack laten hangen.

Enkele servers zouden wel naar blades kunnen, maar op deze manier kunnen wij telkens van verschillende leveranciers offertes opvragen zonder dat wij gelimiteerd worden door een blade-chassis.

[Verwijderd]

Shared storage vertraagt de boel nogal tov lokale storage
Ik denk dat menig (lees: alle) storage leveranciers het hier niet mee eens zijn. Als SSD even buiten beschouwing wordt gelaten zit je bottleneck qua IOPS to echt in de hoeveelheid schijven (Meer schijven = meer IOPS). Op een gegeven ogenblik zul je dus wel over moeten naar een SAN gezien je maar een beperkt aantal schijven in een server kunt plaatsen.

en blades zijn gewoon te duur in het algemeen.
Blades zijn inderdaad duurder dan losse servers maar als normaal bedrijf moet je rackruimte, koeling en stroom mee rekenen. Daardoor kom je vaak bij vervanging van een groot aantal servers (lees:meer dan 8 ) goedkoper uit met blades. Daarnaast vereenvoudigt blades je beheer waardoor meer beheerd kan worden met minder mensen en tijd (=geld).

En als je gaat virtualiseren dan is het al helemaal een ramp qua performance.
Virtualiseren bied enorm veel voordelen ten opzichte van fysieke machines. Ongeacht dat is het inderdaad niet altijd de verstandigste keuze om een bepaalde server te virtualiseren. De opmerking dat virtualiseren een ramp is qua performance is echter totale onzin. Ieder bedrijf virtualiseerd tegenwoordig een groot deel van zijn servers met prima performance. Ook grote, zware machines kunnen prima gevirtualiseerd worden waar tegenwoordig zelfs betere performance wordt gehaald dan met fysieke machines. Virtualisatie projecten falen vaker door gebrek aan kennis dan door gebrek aan performance.

Een ander nadeel van blades is dat je je enclosure ook zo snel mogelijk wil vullen, en ook daar gaat het mis want wij vervangen servers 1 voor 1 zodat we ze niet al te lang nutteloos in het rack laten hangen.
Het vervangen zou een valide reden kunnen zijn. Echter hoef je echt niet je rack volledig te vullen vanaf dag 1. Bij groei of vervanging kun je bijzetten. Het is een kosten kwestie waarbij de vraag is hoeveel je in 1x wilt vervangen. Als je 1 server wilt vervangen dan is de situatie totaal anders dan als je 10 servers wilt vervangen.

Enkele servers zouden wel naar blades kunnen, maar op deze manier kunnen wij telkens van verschillende leveranciers offertes opvragen zonder dat wij gelimiteerd worden door een blade-chassis.
Dat is één van de nadelen van blades maar ook één van de voordelen. Je hebt natuurlijk wel nog maar 1 contact nodig voor je service en garantie. Ook het beheer is veel eenvoudiger. Probeer maar eens de hardware centraal te monitoren van 6 verschillende leveranciers. Niet onmogelijk maar zeker niet handig. Tevens kun je goede deals maken met 1 leverancier als je alles daarvan aanschaft waardoor je onder de streep soms goedkoper uit bent.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 18:27]

[Kees]

Shared storage vertraagt de boel nogal tov lokale storage
Ik denk dat menig (lees: alle) storage leveranciers het hier niet mee eens zijn. Als SSD even buiten beschouwing wordt gelaten zit je bottleneck qua IOPS to echt in de hoeveelheid schijven (Meer schijven = meer IOPS). Op een gegeven ogenblik zul je dus wel over moeten naar een SAN gezien je maar een beperkt aantal schijven in een server kunt plaatsen.

Klopt, daarom hebben wij ook servers met enclosures gehad zodat we op 15 disks konden draaien, maar met de komst van ssd's is dat overbodig geworden. En verder is een SAN een dure bezigheid, want een gbit verbinding (iscsi bv) gaat te langzaam en trek je te snel vol (met deze ssd's haalde ik op een gegeven moment bijna 2gbyte/s). Om dat te bereiken met een SAN zul je al snel op duurdere technologien uitkomen, en om dat redundant uitgevoerd te hebben zul je diep in de buidel moeten tasten. Dan zijn 6 SSD's ineens bijzonder goed te betalen. Verder hebben wij niet genoeg servers die heel erg veel baat zouden hebben bij een san/nas want lokale storage is vaak goed genoeg en goedkoper dan (snelle!) san's. Als je naar onze budgetten kijkt, dan is dit volgens ons de beste oplossing met de beste performance.

en blades zijn gewoon te duur in het algemeen.
Blades zijn inderdaad duurder dan losse servers maar als normaal bedrijf moet je rackruimte, koeling en stroom mee rekenen. Daardoor kom je vaak bij vervanging van een groot aantal servers (lees:meer dan 8 ) goedkoper uit met blades. Daarnaast vereenvoudigt blades je beheer waardoor meer beheerd kan worden met minder mensen en tijd (=geld).

Klopt, maar wij hebben nog niet dermate veel servers dat overstappen naar blades ervoor zorgt dat we minder mensen nodig hebben
En wij zijn niet een heel normaal bedrijf, we hebben maar 3 half-volle racks op het moment, en de investeringen in blades zou zich niet uitbetalen in de stroom/koeling/mensen kosten. Bovendien hebben wij voor de eerste twee een sponsor

En als je gaat virtualiseren dan is het al helemaal een ramp qua performance.
Virtualiseren bied enorm veel voordelen ten opzichte van fysieke machines. Ongeacht dat is het inderdaad niet altijd de verstandigste keuze om een bepaalde server te virtualiseren. De opmerking dat virtualiseren een ramp is qua performance is echter totale onzin. Ieder bedrijf virtualiseerd tegenwoordig een groot deel van zijn servers met prima performance. Ook grote, zware machines kunnen prima gevirtualiseerd worden waar tegenwoordig zelfs betere performance wordt gehaald dan met fysieke machines. Virtualisatie projecten falen vaker door gebrek aan kennis dan door gebrek aan performance.

Virtualisatie heeft zeker voordelen, maar zodra 1 virtuele machine de hele bare-metal server voltrekt, dan is het imo verstandiger om die server ook op bare-metal te draaien. Pas als je makkelijk veel vm's op een enkele server kan draaien dan is het verstandig om te virtualiseren. Iets wat wij ook doen met bijv onze dev-omgeving.

En betere performance dan bare-metal machines lijkt mij bijzonder lastig, want je zal altijd een vertaalslag hebben van de VM naar de bare-metal server, en als die er niet is, dan zal de machine nog sneller zijn.

Ik weet dat VM's ook goed kunnen presteren, maar ik heb tot nu toe vrijwel altijd gezien dat er performanceverlies optreed, bijvoorbeeld bij connecties die 0,15ms ipv 0,1ms duren. Dat lijkt niet veel, maar met genoeg connecties kan dat aardig hard oplopen.

Een ander nadeel van blades is dat je je enclosure ook zo snel mogelijk wil vullen, en ook daar gaat het mis want wij vervangen servers 1 voor 1 zodat we ze niet al te lang nutteloos in het rack laten hangen.
Het vervangen zou een valide reden kunnen zijn. Echter hoef je echt niet je rack volledig te vullen vanaf dag 1. Bij groei of vervanging kun je bijzetten. Het is een kosten kwestie waarbij de vraag is hoeveel je in 1x wilt vervangen. Als je 1 server wilt vervangen dan is de situatie totaal anders dan als je 10 servers wilt vervangen.

Enkele servers zouden wel naar blades kunnen, maar op deze manier kunnen wij telkens van verschillende leveranciers offertes opvragen zonder dat wij gelimiteerd worden door een blade-chassis.
Dat is één van de nadelen van blades maar ook één van de voordelen. Je hebt natuurlijk wel nog maar 1 contact nodig voor je service en garantie. Ook het beheer is veel eenvoudiger. Probeer maar eens de hardware centraal te monitoren van 6 verschillende leveranciers. Niet onmogelijk maar zeker niet handig. Tevens kun je goede deals maken met 1 leverancier als je alles daarvan aanschaft waardoor je onder de streep soms goedkoper uit bent.

Klopt als een bus, maar daar hebben wij nog niet genoeg servers voor. En twee telefoonnummers op je wiki in plaats van 1 voor je service en support word je werklast ook niet heel veel zwaarder van
Verder kunnen we nu ook al goede deals maken, juist door leveranciers tegen elkaar uit te spelen omdat ze weten dat wij niet aan ze vast zitten omdat wij hun enclosures gebruiken.

[Verwijderd]

Bedankt voor je reactie! In de situatie van Tweakers zal ik waarschijnlijk ook voor deze oplossing hebben gekozen. Men argumenten waren ook alleen bedoeld om wat tegenwicht te bieden zodat duidelijk is deze punten niet voor iedere omgeving gelden

Ik kom voor men werk vaak in deze discussie en zie dat men punten afschrijft omdat men niet objectief heeft gekeken. Het is altijd interessant om te lezen hoe men tot een bepaalde configuratie komt. Iedere omgeving is altijd uniek en een uitdaging.

[To_Tall]

je moet ook niet vergeten dat een zwaardere web omgeving met meerdere onderdelen is. Dat ten opzichte van een kantoor omgeving. Exchange wil je graag virtualiseren Simpel omdat het kosten efficient is. Zeker in een vorm van een cluster. Het zelfde geld voor file servers. Die doen niets anders dan bestanden voorschotelen. San + File server op een VM is totaal geen probleem en ook perf is meer dan goed. Als je het goed size natuurlijk

Een AD wil je niet virualiseren. het kan wel. Maar niet handig. Een simpele niet al te zware bak kan dat voor je doen. Liefst 2 in 2 verschillende racks

[MaDMaRTiGaN648]

Microsoft predikt echter dat Exchange (2013) virtualiseren financieel gezien geen voordelen biedt (het kan en mag wel) en dat je voor de opslag gebruik moet maken van 'consumer grade' SATA disks.

[PcDealer]

Gb is echt achterhaald in een virtuele omgeving en/of blades. Veel te veel touwtjes i.c.m. redundantie:
• 2x management
• 2x vMotion,
• 2x iscsi
• 2x vm verkeer
Met 10GbE kun je af met 2 adapters (1 voor redundantie). IK heb in het verleden meerdere calculaties gedaan voor VMware servererparken en 10 GbE is slechts 20% duurder dan op 1GbE. Daarbij is het verkeer gemaximaliseerd (simpel) op 8x 1Gb t.o.v. 2x10Gb. Het duurste zijn de switches. Het verschil tussen Cisco en concurrenten kan echter gigantisch zijn in prijs.

[Reactie gewijzigd door PcDealer op 23 juli 2024 18:27]

[Verwijderd]

Bij mij op het werk alleen maar problemen met virtualisatie... slechte performance, en slechte betrouwbaarheid.

Alle fabrikanten hebben prachtige verkooppraatjes, maar de praktijk is vaak anders. En ondanks alle support, is het probleem nog steeds niet opgelost!

[Verwijderd]

Fabrikanten prijzen hun producten altijd de hemel in. Daar moet je niet teveel naar luisteren. Het beste is om zelf te kijken en te beslissen wat voor jou omgeving de beste oplossing is.

Virtualisatie is echt een lastig onderdeel. Het is een hele nieuwe techniek die de ICT wereld volledig op zijn kop zet. Ik kom bij klanten die altijd op losse hardware hebben gedraaid waar ze nu over zijn gegaan op een virtualisatie platform. Nu draaien ze 35 servers op 1 stuk hardware en zijn ontevreden over de performance.... Tja, als je niet goed je omgeving sized dan gaat er natuurlijk iets fout. Dit wil echter niet zeggen dat dit aan de techniek ligt maar vaak is het gewoon verkeerd ingezet.

Dit is echter snel en goed aan te passen (jaja, dankzij virtualisatie). Mijn advies zou zijn om eens een externe specialist in te schakelen als je problemen hebt met performance. Slechte betrouwbaarheid duidt echter meer op onkunde dan op de techniek want virtualisatie verhoogt juist de betrouwbaarheid.

[Arfman]

Dan biedt ik mezelf bij deze aan om eens naar jullie problemen te kijken (VMware dan wel ).

10 tegen 1 dat de problemen niet door virtualisatie komen, maar door slechte keuzes uit het verleden qua hardware en/of software. Of misschien niet genoeg kennis inhouse van hypervisors of de impact daarvan.

[BlaDeKke]

Enkele servers zouden wel naar blades kunnen, maar op deze manier kunnen wij telkens van verschillende leveranciers offertes opvragen zonder dat wij gelimiteerd worden door een blade-chassis.
Dat is één van de nadelen van blades maar ook één van de voordelen. Je hebt natuurlijk wel nog maar 1 contact nodig voor je service en garantie. Ook het beheer is veel eenvoudiger. Probeer maar eens de hardware centraal te monitoren van 6 verschillende leveranciers. Niet onmogelijk maar zeker niet handig. Tevens kun je goede deals maken met 1 leverancier als je alles daarvan aanschaft waardoor je onder de streep soms goedkoper uit bent.

Maar dan maak je je wel afhankelijk van 1 partij. Dit is ook niet altijd de beste oplossing. Wel gemakkelijk, maar daarom niet beter.

[Verwijderd]

Zeker waar. Iedere leverancier heeft zijn eigen sterke punten en meestal ben je beter af door voor ieder probleem de beste oplossing te kiezen. Echter moet het wel ondersteund worden en daarvoor moet de communicatie tussen alle partijen wel goed zijn. Ik kom echter daar in de praktijk de meeste problemen tegen....

[smooc]

Ik denk dat menig (lees: alle) storage leveranciers het hier niet mee eens zijn. Als SSD even buiten beschouwing wordt gelaten zit je bottleneck qua IOPS to echt in de hoeveelheid schijven (Meer schijven = meer IOPS). Op een gegeven ogenblik zul je dus wel over moeten naar een SAN gezien je maar een beperkt aantal schijven in een server kunt plaatsen.

Natuurlijk zullen die storage leveranciers dat zeggen. Ze hebben er immers een belang bij zoveel mogelijk van dat soort spul te verkopen. Maar als je naar cloud discussies gaat kijken zie je al veel langer de trend om shared storage af te raden voor de compute nodes wegens performance issues: het schaalt gewoon domweg niet, noch financieel noch technisch.

Deze ervaring hebben wij ook met onze setups die soms meer dan 900 nodes tellen.

Blades hebben een zelfde soort probleem. Indien de enclosure kapot gaat zijn al je blades weg. Of ook leuk: je enclosure wordt EOL, dan zijn je blades dat ook direct. Gefeliciteerd: je hebt een extra single point of failure geintroduceerd en een vendor lock-in.

Blades en shared storage komen eigenlijk uit een oude philosophy: alles zo bouwen dat het nooit gaat omvallen. Helaas dat is een utopie. Je kan beter richten op een "build for failure" constructie en dat verandert nogal iets aan de verwachtingen aan je hw en software.

[SpamLame]

Kees heeft eea al aangegeven waarom lokaal sneller zou kunnen zijn dan shared.
Een van de dingen die ik echter niet in zijn reaktie zie staan, maar zeker niet onbelangrijk is de introcductie van latency zodra je met SAN's aan de slag gaat.

Daarnaast is ook EMC zich bewust van de verandere markt. Het is niet voor niets dat zo flashbebaseerde oplossingen op de markt brengen. VFcache is daar een van met als doel de storage weer ditchter bij de host te brengen terwijl tegelijkertijd de TB's die nodig zijn te kunnen blijven aanbieden met 1000+spindels in een array.

[Sando]

Nieuwschierig, waarom het OS op HDD en de rest op SDD?
Dacht men na 256GB geheugen en 1536GB SSD dat er op de systeemschijf wel bezuinigd kon worden, of is er ook een andere reden?

[ACM]

We reboten dit soort servers hooguit 2x per jaar... er is dus weinig reden voor een snelle disk voor het OS

Voor de OS-disks nemen we dus doorgaans domweg de goedkoopste die volgens ons voldoende schijfruimte hebben. Bij dit soort aankopen heb je het dan nog altijd over verschillen van meerdere tientjes of zelfs een paar honderd euro. Dat steken we liever in de ssd's en het RAM-geheugen, dan in een paar OS-disks

[MMaI]

De reden voor snellere lokale disks zit onder andere in de logfiles.
Bij diverse servers in ons serverpark bepaald de lokale disk 25-30% van de performance vanwege de log en tmp folders.

Ik hoop dat jullie daar ook aan gedacht hebben, en de logfiles en tmp netjes op de SSD schijven hebben staan, anders is er nog wat winst te behalen

Wat mij een leuk idee lijkt is om jullie keuze voor configuratie etc. een keer toe te lichten in een .plan of .review, en dan niet alleen hardware, maar ook software keuzes en configuratie (config parameters etc.)

[Reactie gewijzigd door MMaI op 23 juli 2024 18:27]

[hostname]

Als performance echt zo'n probleem is, dan zet je /tmp toch op een ramdisk in het geheugen en je logging wat lager, zodat je applicatie echt werk doet ipv alleen maar zit te loggen?

[Kees]

De systeemschijf word nauwlijks gebruikt, het zou verspilling van geld zijn om daar een SSD in te stoppen (alhoewel ik laatst weer een server uitzocht bij IBM en de kleinste/goedkoopste SSD van 128G was goedkoper dan de 250-300G SATA schijven, dus in een volgende server zal waarschijnlijk wel een ssd als OS schijf zitten )

[freaq]

hebben SSD's ook neit een lager idle verbruik, in dat geval had het in principe nog zo kunnen zijn dat je uiteindelijk alsnog goedkoper uit zou zijn emt een SSD, al gaat het natuurlijk over een extreem klein verschil in opgenomen vermogen.

[kaas-schaaf]

Ik vermoed veel kleine read/write operaties welke een ssd iets minder goed tegen kan.

[real[B]art]

Ik vermoed dat het in de eerste plaats is om OS en data gescheiden te houden. De server kan (re)booten en blijven draaien ongeacht de status van de SSD array. Daarnaast zou het zonde zijn van de performance om een SSD array aan te leggen voor je data en die bandbreedte dan weer deels voor je OS te gaan gebruiken (al zal die impact minimaal zijn). Verder voorkom je onnodige fragmentatie en slijtage van je SSDs.
Tot slot komt er misschien ook nog het budget om de hoek kijken. Dit is zeker geen goedkope verzameling hardware, desalniettemin zal er een limiet zijn aan hoeveel er uitgegeven kan worden. Ik kan me voorstellen dat er dan gekozen wordt voor de beste performance wanneer de server draait, dan duurt het booten van het OS maar wat langer. Bovendien vraag ik me af hoeveel 'last' je nog hebt van het feit dat het OS op HDD staat, als de server eenmaal draait hoeft er afgezien van logs nog maar weinig te gebeuren op de HDD.

edit: ACM was me voor

[Reactie gewijzigd door real[B]art op 23 juli 2024 18:27]

[robin5210]

Indrukwekkende server. Maar wat verbruikt zo een server nu?

[Kees]

Het precieze verbruik per server weet ik niet, maar het rack waar hij instaat trekt 1700W momenteel, en alle servers samen doen 5840W.

[Verwijderd]

wat voor noodstroom hangt daar aan? eatons of APC? of is dat trade secret?

[Kees]

Qua noodstroom vertrouwen wij op onze hoster / datacentrumleverancier. Er staat wel wat leuk speelgoed in EUNetworks maar ik weet niet wat precies.

We hebben ook twee aparte feeds, en bijna alle servers en switches hebben redundantie voedingaansluitingen zodat we live blijven als er 1 feed uitvalt.

In ons eigen rack doen hebben we geen interesante noodstroomvoorzieningen, alleen een switched (& metered) PDU om de stroom te verdelen.

[xheroxkefx]

Kanonne, das 'n hoop. wat kost dat in de maand betreft de €€€?

[Tricq]

5840W is in een maand van 31 dagen 4345 kWh
plus minus 0,22 eurocent per kWh

4345 * 0,22 = 995 euro per maand. Maar dat is uiteraard bij full load, kan begrijpen dat ze 's nachts misschien maar de helft of een kwart verstoken.

[Bolletje]

Je vergeet hierbij enkele essentiële aspecten:

Kennelijk heeft Tweakers sponsors voor de koeling en stroom (zie Kees z'n verhaal]

[...] stroom/koeling/mensen kosten. Bovendien hebben wij voor de eerste twee een sponsor

Uit Kees z'n antwoord kan ik nog niet herleiden wat die vermogens precies inhouden. Als ik zo herleid zijn dat momentopnames, zonder er bij te vertellen wat de belasting precies is. Berekeningen er op los laten is dan ook gevaarlijk.

Je moet niet rekenen met consumentenprijzen van elektrische energie. Die 22 cent per kWh is een gebruikelijke waarde hier op Tweakers, omdat er dan wordt uitgegaan van een gemiddeld huishouden (met 3600 kWh op jaarbasis). Leuk voor de thuisservers dus. Een groot deel van die 22 cent bestaat uit belasting. Dat werkt met schalen (Rijksoverheid) waardoor de prijs per kWh fors minder wordt als je veel meer energie afneemt. Datacenters kopen energie op veel grotere schaal in, waardoor de prijs van één kWh eerder naar de 10-12 cent gaat.
Gebruikers/afnemers van datacenterruimte hebben hier niet mee te maken, omdat dat het pakkie-an is van het datacenter. Bij een datacenter huur je een rack en betaal je kosten van energie aan het datacenter, niet aan de energieleverancier van het datacenter. De prijs van een kWh (of ampères) bij een datacenter hangt dan ook af hoeveel je huurt enzo. Ik heb zo geen inzage in precieze getallen, maar er zullen vast tweakers zijn die dat wel weten.


Er gaat nog veel energie verloren in overhead. Daarvoor betaal je dus ook aan het datacenter.
Een gebruikelijke indicator van de energie-efficiënte van een datacenter is de PUE-waarde (Power Usage Efficiency). Deze waarde houdt de gebruikte energie door de componenten gedeeld door de gebruikte energie inclusief de overhead energie. Onder het onderdeel overhead valt ook de energieconsumptie van koeling van het datacenter. Deze indicator kan dus variëren door de gebruikte energie van de onderdelen te veranderen of de overhead. Energiezuinigere onderdelen zullen zorgen voor een verlaging, maar ook efficiëntere koeling kan grote gevolgen hebben.

Marktleiders op het gebied van het inrichten van datacenters, waaronder Google, Facebook en Microsoft, hebben op het moment PUE-waardes variërend van 1,06 tot 1,2 (gigacom.com, 2012). Zij hebben al vele innovatieve ontwikkelingen toegepast om deze waarde nog verder te verlagen, zoals het gebruik van zeewater en passieve radiatoren als koeling ('free cooling' etc).

[Reactie gewijzigd door Bolletje op 23 juli 2024 18:27]

[CyBeR]

Als t.net's stroomgrafieken er ongeveer uitzien als de mijne is dat gewoon redelijk constant. (Gemiddeld per 5 minuten-- als je dichterbij gaat kijken zul je wellicht meer fluctuaties zien.)

[Reactie gewijzigd door CyBeR op 23 juli 2024 18:27]

[KoploperMau]

's nachts verbruik je juist weer wat meer omdat je dan je backups draait en andere belangrijke dingen doet die je overdag niet wilt vanwege de impact op je systeem. Ik denk juist dat de rustigste tijd voor een server zo'n rond de 23:00 - 01:00 en 05:00 - 07:00 is. Dan zijn de minste gebruikers online en hoeft de server geen backupwerk te doen!

EDIT: Ik reageer op het verkeerde bericht. Deze reactie was bedoeld op het bericht van Tricq hierboven.

[Reactie gewijzigd door KoploperMau op 23 juli 2024 18:27]

[Proxy]

Bedoel je niet 22 eurocent per kWh, 0.22 lijkt me wat weinig....

[ACM]

Artemis 6 neemt gemiddeld 203W op. Het maximum lag afgelopen week op 313W (gedurende een zware data-import) en het minimum op 185W (diep in de nacht).

Maar e.e.a. kan aardig fluctueren, want zelfs in het "last minute" lijstje noemt ie een gemiddelde van 210W, piek van 280W en minimum van 193W.

Van Artemis 7 hebben we uiteraard nog geen verbruikscijfers onder normale belasting

[Jorn1986]

Het is wel leuk om je hele database in het geheugen te laden, maar zodra je de server reboot, wil je je data ook nog ergens veilig hebben staan. Om dit te regelen hebben we de server ook uitgerust met 6 ssd's van 256GB, die in raid 10 hun werk doen. Ten slotte zitten er nog twee sata-harde schijven van 256GB in, waarop het besturingssysteem staat.

Wat voor SSD's en SATA HDD"s zijn dat eigenlijk, in zo'n professionele omgeving?

[ACM]

Er is maar een beperkt aantal leveranciers voor zulk soort dingen. Harde schijven zijn vaak gerelabelde Savvio's van Seagate of vergelijkbare modellen van Hitachi (maken die nog zelf schijven?) of Western Digital.

Voor SSD's is het wat onduidelijker. De huidige Artemis 6 heeft Samsung SLC SSD's met een Dell-stikkertje erop. De IBM heeft "value enterprise MLC", oftewel gewoon normale MLC-ssd's met hooguit wat betere garantievoorwaarden en wat beter getestte firmwares e.a. Het zou dus prima een standaard Corsair of Crucial model kunnen zijn

[Jorn1986]

Wowie... $ 709 per stuk!...

Nee, privé moet ik toch maar een ''normale'' nemen ben ik bang.

[Kees]

IBM 250GB 7.2K 6Gbps NL SATA 2.5" SFF HS HDD
IBM 256GB SATA 2.5" MLC HS Enterprise Value SSD

Die Welk merk IBM precies levert kan per server zo'n beetje verschillen, maar de SSD's zijn van het merk STEC voor zover ik weet.

[Sjah]

Wat draait hier nou op? Vermoeden doe ik een linux....Unix kost geld...

[ACM]

We draaien standaard met Linux inderdaad. Al jaren

Deze draait Ununtu 12.10 en de database is uiteraard MySQL (5.5 op de nieuwe).

[Blokker_1999]

Ubuntu 12.10 lijkt me een vreemde keuze. Ubuntu omdat het nu niet direct een populaire distro is bij server beheerders (prefereer zelf nog altijd Debian) en 12.10 omdat het geen LTS release is (als ik me niet vergis).

[Inspector]

Er draait 12.04 LTS op Dit voornamelijk vanwege de goede ondersteuning van Canonical, de community en puur het feit dat de packages op Debian (stable) te outdated zijn voor ons om als server te kunnen fungeren.

[Verwijderd]

Ik heb persoonlijk niet echt problemen met Ubuntu als server, maar ik zou ook voor 12.04 LTS gaan.

[joostlaan]

Ook al eens naar Percona Server gekeken als drop-in replacement van MySQL? Daar zitten bepaalde SSD optimalisaties ingebakken waardoor de performance een stuk beter is dan standaard MySQL.

[MMaI]

Waarom draaien jullie geen cluster omgeving? Daarmee zou geen read only moment nodig zijn, en is de database schaalbaar. Denk daarbij aan clusters zoals mysql cluster, maar ook galera (wsrep).

[C00KW4US]

Lekkere specs, waarom geen Xeon E5-2640 genomen? 6 cores ipv 4, zuiniger en tegen een gelijkwaardige prijs. Wel iets lagere clockspeed.

Welke SSD's worden gebruikt?

[Reactie gewijzigd door C00KW4US op 23 juli 2024 18:27]

[Kees]

De SSD's zijn volgens mij van STEC, maar worden verkocht als 'IBM 256GB SATA 2.5" MLC HS Enterprise Value SSD'

De CPU hebben we juist de quadcore voor genomen omdat:
- uit onze metingen blijkt dat er zelden meer dan 8 threads gelijktijdig op de databaseserver aan het werk zijn
- De kloksnelheid ligt hoger, dus elke thread zal nu eerder klaar zijn in plaats van dat we dus meer threads gelijktijdig trager kunnen verwerken zijn we gegaan voor het snel verwerken van een kleiner aantal threads.

[ScoeS]

Het valt me op dat geen van deze schijven in de buurt komt van bijvoorbeeld een Samsung 840 pro qua iops en seq read/write. Ook een gevalletje 'niet nodig'?

[Rolfie]

De 840 is een consumenten SSD, en geen server SSD.
Dat is een groot verschil voor betrouwbaarheid, wat je zeker wilt voor je DB server.

[freaq]

alsnog zijn alle SSD's eigenlijk waarschijnlijk zo snel en de verschillen in realword benchmarks zo klein dat het er simpelweg amper toe doet welke ssd (performance wise iig)

en zoals al gezegd enterprise SSD's hebben meestal meer provisionering van extra flash voor betere spreiding van de slijtage.

maar een nog sneller tweakers.net dus, klinkt goed

[hifigamefreak]

Als ik zoek op die SSD's krijg ik dit te zien: http://www.redbooks.ibm.c...okAbstracts/tips0879.html

Volgens deze site zijn dat betaalbare MLC SSD's voor enterprises: http://www.micron.com/pro...p400e-enterprise-sata-ssd

[Lisadr]

Ik snap te weinig van dit soort dingen, maar 256GB DDR3-1600 klinkt goed!

Zou leuk zijn als tweakers een keer aandacht besteed aan caching, hoe je dingen doet met een server enz.

[Kees]

reviews: Tweakers 7: waarom een eigen Java-back-end?
reviews: Praktisch geheugenbeheer in Java bij Tweakers.net
reviews: Tweakers.net-serverbeheer: Phoenix

Alsjeblieft

[larsg]

Ivm jullie Phoenix project.

Dat was toch om ervoor te zorgen dat als er plots een meteoor te pletter stort op locatie a (waar jullie servers stallen), dat de servers op locatie b het overnemen. Zou dat er dan niet voor moeten zorgen dat er geen read only tijd is?

Dit is geen flame, maar gewoon iets dat ik mij afvraag.


Mooi speelgoed overigens!
Jullie zouden is een review moeten doen val jullie server racks, zou zeker geapprecieert worden door veel tweakers

[GlowMouse]

Geinig dat jullie qua cpu en geheugen tot eenzelfde configuratie zijn gekomen als wat FOK! binnenkort in gebruik neemt. Wij zien alleen geen noodzaak voor SSD's omdat we met innodb_buffer_pool_restore_at_startup de data sequentieel in kunnen lezen, en die drie keer dat het voor zal komen de vijf minuten extra downtime voor lief nemen. Ik vraag me af hoe jullie tegenover De Persgroep een extra investering van duizenden euro's kunnen verantwoorden om toekomstige downtime met vijf minuten te verkorten.

[ACM]

"duizenden euro's" is wel wat overtrokken. Zelfs als je teruggaat naar 2x600GB SAS is het prijsverschil minder dan 2500 euro ($3136). Strikt beschouwd is dat inderdaad "duizenden", maar jouw opmerking suggereert dat het aanzienlijk meer is dan dat

Afgezien daarvan spreken we gewoon budgetten af voor serverhardware en verantwoorden we de details van aankopen alleen intern en naar het directe management. De Persgroep ziet dus alleen de budgetten langskomen en op een gegeven moment een factuur verschijnen
Zolang we binnen de gestelde budgetten blijven - en die budgetten reeel lijken - gaat men echt niet een uitgebreide verantwoording van ieder detail vragen en/of ons dwingen om wat op de aanschafkosten te besparen als we niet helemaal met uitgebreid cijferwerk kunnen verantwoorden waarom we kiezen voor SSD's tov SAS-disks.
Overigens was het bij de laatste servers zonder SSD's eerder een half uur tot een uur problematisch. Maar toen bestond (of kenden we) de innodb_buffer_pool_restore_at_startup-parameter nog niet, dus we hebben eigenlijk nooit uitgebreid getest hoe het daarmee zou gaan.

[Reactie gewijzigd door ACM op 23 juli 2024 18:27]

[Verwijderd]

Krijgen we dan nu eindelijk weer eens een uitgebreide foto- reportage van de plaatsing en van de huidige setup in de racks, net zoals vroegah?

[ACM]

Hij hangt er al een tijdje

Maar ik wil inderdaad binnenkort weer eens een uitgebreid overzicht geven van wat voor hardware we hebben, fotoverslagen van het plaatsen zit er voorlopig niet in: We hebben nu weer even niks liggen om te plaatsen en bovendien maken we er niet zoveel foto's meer van. We zijn maar wat blij om weer uit die herrie van de datacentra weg te zijn en met de nieuwe servers is het plaatsen vaak in minder dan een uur gedaan (inclusief inchecken bij de beveiliging enzo)

[_David_]

Uitgebreid overzicht met wat foto's zou leuk zijn