Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 183, views: 39.216 •

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.Artemis 7 - geheugen

Artemis 7 - geheugen 2

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)

Reactiefilter:-11830181+1155+241+34
De database is inderdaad maar ongeveer 200G groot. De storage is wel iets groter hoor - Die neemt momenteel zo'n 7TB in totaal.

En nee, wij gebruiken de uitkomsten van onze eigen reviews niet voor serverhardware, puur omdat de meeste fabrikanten (dell, ibm, hp) je geen keuze geven anders dan '256GB SSD', eventueel nog een keuze tussen mlc/enterprice mlc/slc maar veel verder gaat het niet helaas.

[Reactie gewijzigd door Kees op 18 januari 2013 16:00]

De database bevat voornamelijk tekst (al het nieuws, review, .plans, meuk, product informatie, etc). De storage bevat alle bestanden die we serveren, zoals plaatjes en video's. Dat maakt het verschil :)
Niet heel traag, maar Apache is een beetje een doorsnee webserver. Je kan er zo'n beetje alles mee, en dat levert wat baggage. Je hebt webservers die gespecialiseerder zijn in bepaalde taken, die bijvoorbeeld heel snel statische files kunnen laten zien. Of gewoon heel simpel en licht zijn.

http://en.wikipedia.org/w...on_of_web_server_software
Apache is vooral veelzijdig. En vooral goed in bepaalde taken, PHP runnen bijvoorbeeld. Echter, apache is ook groot, en daarmee heeft het veel overhead. Voor de ingewikkeldere taken (draaien van PHP bijvoorbeeld) is dat ideaal. Echter, voor het simpelweg terugsturen van statische files, kun je net zo goed een lichter gewicht server gebruiken (zoals NginX, of lighttpd).
Elke 3 jaar. De huidige SSD's zijn ongeveer op 2/3'de van hun gespecificeerde aantal writes.
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.
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 dycell op 18 januari 2013 16:24]

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.
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.
Momenteel is het geheugen ook al te klein om de hele database in te laden, dus dat is geen enkel probleem.

De database staat normaliter op de hardeschijven en word vanaf de harde schijf gelezen door de mysql server. Omdat de harde schijven langzaam zijn zal hij, wat hij aanspreekt, in het geheugen laden om zodoende 'gecached' te houden. Op het moment dat hij iets moet hebben wat niet in die cache staat dan zal hij dat van de harde schijf lezen en vervolgens in de cache zetten.

Dat is de normale situatie voor de meeste databases, maar omdat we nu meer geheugen in de databaseserver konden stoppen dan dat de database groot is, zou het nu mogelijk zijn om de volledige database in het geheugen te laden, waarbij hij eigenlijk alleen nog maar naar de schijven hoeft om data weg te schrijven.
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.
De leessnelheid van werkgeheugen is vaak sneller dan de leessnelheid van een harde schijf. Als jij dus content opvraagt (query) zal hij het resultaat uit het werkgeheugen halen. Hierdoor kan opgevraagde content sneller verstuurd en dus door jouw browser geladen worden.

[Reactie gewijzigd door Goldin op 18 januari 2013 15:38]

Hier kan je een voorbeeld vinden:

http://blog.laptopmag.com...ra-memory-into-a-ram-disk

Een conventionele HDD haalt zo'n 100 MB/s write, een SSD komt tot 250 MB/s, en een RAM schijf gaat makkelijk door tot 7000 MB/s
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 :P
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 18 januari 2013 19:22]

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 ;))
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.
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 :P
We draaien standaard met Linux inderdaad. Al jaren :)

Deze draait Ununtu 12.10 en de database is uiteraard MySQL (5.5 op de nieuwe).
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.

Op dit item kan niet meer gereageerd worden.



Populair: Desktops Samsung Smartphones Privacy Sony Microsoft Apple Games Consoles Politiek en recht

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013