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.209 •

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
Dus heel tweakers.net staat op minder dan 2 terabyte? Op mijn pc staat al meer dan 2 terabyte! Het is in ieder geval wel mooi dat er nu SSD's in gaan aangezien deze een stukje sneller zijn dan HDD's.
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.
Overigens lijkt mij dit dus ongeveer de nieuwe server te zijn: http://www.redbooks.ibm.com/abstracts/tips0851.html

@kees, welke SSD's zitten erin? Ik wil wel eens weten of tweakers.net uitkomsten van hun eigen reviews gebruikt.

[Reactie gewijzigd door Frozen op 18 januari 2013 15:29]

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]

Wat is het verschil als ik vragen mag? :)
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 :)
Je moet denken aan images, video's etc. Alles wat je niet in de database opslaat staat op de storage.

200G is een mooie database voor zo'n uitgebreide site. Knap werk.

edit: Te laat :Y)

[Reactie gewijzigd door Remz op 18 januari 2013 15:30]

Je kan een image toch als binary opslaan? (zal er wel niet sneller op worden..)
Het vervelende is dat je DB server dan meer werk moet gaan doen. Nu worden alle bestanden van een aparte file server geserveerd. Dat is een stuk beter te schalen.
Afaik draait die fileserver ook hele simpele webserver software, geen Apache, zodat alles in noodtempo geserveerd kan worden :)

Dat was enkele jaren geleden wat ik las iig, weet niet of ze dat anno 2013 nog doen.

Edit:

Hmm niet meer dus :)
HTTP/1.1 200 OK
Server: Apache
X-Tweakers-Server: pontus

[Reactie gewijzigd door Engineer op 18 januari 2013 17:24]

Is Apache zo'n trage webserver dan?
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).
Ik kan de link niet meer vinden, maar zag onlangs een benchmark langskomen waarin nginx amper sneller was dan Apache2. Er was één voorwaarde: in Apache2 moest het parsen van .htaccess files uitgeschakeld zijn.
ik gok dat de database alle text-based zooi is; reacties, forum topics, pricewatch e.d.
storage zullen alle plaatjes, filmpjes en backups zijn
Kees, hoe lang verwacht je dat de SSDs meegaan? Hoe vaak vervang je ze?
Elke 3 jaar. De huidige SSD's zijn ongeveer op 2/3'de van hun gespecificeerde aantal writes.
En Servers SSD's zijn DUUR bij Dell... :|
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.
Het is in elk geval bij HP vrij eenvoudig te achterhalen welke OEM ze gebruiken. Dat is dus Intel.
Tweakers is ook geen pornosite, hè?
@oeroeg
Voor een aantal tweakers zijn die specs anders wel degelijk porno...
Ja ik krijg al een kick als ik naar de afbeeldingen kijk en dan lees wat het is, Oh my.
Mwah .. vroeger, toen t.net nog zelf hun servers bouwde, toen was het porno. Nu is het gewoon een off the shelf kast met indrukwekkende specs, that's all. Eerlijk gezegd niet heel veel spannender dan een gemiddelde ESXi blade bij ons.

Hoort allemaal bij de professionalisering, ik zou t.net ook minder serieus nemen als ze nu nog zelf servers in elkaar gingen schroeven. Zo is de markt nu, hardware wordt steeds meer commodity. Tegenwoordig kun je met een nieuwe Acer of ASUS kant-en-klaar PC ook alle games op High draaien met Full HD resolutie. De tijd dat je nog uren in je zolderkamertje onderdelen uit zat te zoeken d.m.v. Pricewatch v1 en fora ligt lang achter ons.
Mwa, overdrijven is ook een kunst hoor, ik ken persoonlijk niemand die op een kant en klaar PC'tje van een groot merk gamet. Als ik ook bv bij Acer kijk, dan vind ik deze:
http://us.acer.com/ac/en/US/content/series/predatorg
Extreme gaming power!!! Met een GT630... Riiiiiight, ik denk dat je blij mag zijn als je nieuwe games op de laagste settings nog enigszins soepel aan het draaien krijgt daarop.
Asus dan?
http://www.asus.nl/Deskto...io_CG8250/#specifications
Beter, maar een GTX460 als beste keus is nog altijd bedroevend en daar ga je echt geen nieuwe games op high op spelen.
Neuh, in de PC game wereld stelt nog altijd bijna iedereen zijn eigen PC samen of laat een computer op maat maken door een winkel (wat op hetzelfde neerkomt alleen schroeft iemand anders voor je).
Wat heeft een (game-) PC met een productieserver te maken? Echt helemaal niks.
Je kan vaak nog naar supermicro gaan als je wat meer tweakers gevoel wilt.
Lees dan eerst de reactie van Afman voordat je dit neer plempt!
Tweakers.net is toch juist porno voor een echte nerd? :P 8)7
[vrijdag]
Lol, kan je een backupje op je pc draaien 8)7
[/vrijdag]
Mooi speelgoed! ;)

Is er een keuze niet voor blades + SAN te gaan?
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]

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.
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.... ;(
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!
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.
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.
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.
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.
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 ;)
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.
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 21 januari 2013 23:27]

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.
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.
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 SaturN op 18 januari 2013 15:19]

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.
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'?
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.
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 :)
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
Zo zo!! Klinkt goed allemaal!! Maar is 256GB Geheugen niet een beetje over kill?
Niet als je je complete database in het geheugen wil laden en ook nog voorbereid wil zijn op de toekomst.
Maar dan vraag ik me af wanneer gaat het geheugen te klein worden voor de volledige database (als die nu al 200G groot is) en wat gebeurd er dan? Swap? Of kan men bepaalde delen van de db aanmerken als zijnde prioritair?
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.
Dit is ook geen enkel probleem. De inhoud van oude nieuwsberichten en hele oude forumtopics zal vrijwel nooit opgevraagd worden, dus dat mag best wat langer duren. Het belangrijkste is dat je indexen wel in het geheugen blijven staan. Na een tijdje draaien regelt een goede database engine dat zelf wel.

Wel kan het zinvol zijn om zelf toe te wijzen op welk device een bepaald databaseonderdeel (tabel, index, ...) opgeslagen moet worden. BLOBs die je weinig gebruikt kun je op een wat trager device zetten (HDD) en de indexen of belangrijke tabellen op een SSD.

Een andere oplossing is natuurlijk een batterij brute SSDs en flink wat geheugen, zodat alles snel is. Blijkbaar heeft Tweakers daarvoor gekozen :)
...maar omdat we nu meer geheugen in de databaseserver konden stoppen dan dat de database groot is...
Kun je aangeven hoeveel MB/GB aan data er ieder jaar bij komt? Hebben jullie daar statistieken van?
Ik spreek nu uit ervaring met MSSQL(zover ik weet draait Tweakers op iets anders). Maar in MSSQL zal het geheugen zich vullen zodra de database wordt gebruikt. Het duurt een tijdje voordat dus een deel/gehele database in het geheugen is ingeladen.

De eerste keer duurt het dus wat langer om gegevens uit de database te halen dan de 2e keer, de 2e keer leest hij het namelijk uit het geheugen.
Momenteel staat er zo'n 33% in het geheugen bij Tweakers, of misschien iets minder. Voor velen is dit "best practice".

Een hele database in het geheugen inladen is het ideale scenario, maar wanneer de database groter wordt zal de rest wat niet in het geheugen staat uit de hdd's worden gelezen. In dit geval de 256GB SSD's. Flink snel dus :P

PS: Correct me if I'm wrong, maar dit zal niet veel anders zijn op de DB van Tweakers.
Eerst zeg je dat het anders zal zijn, en daarna stel je dat het niet veel anders zal zijn bij de DB van Tweakers ;) Welke is het nou?

In elk geval draaien ze geen MSSQL. Er is ook niet echt een reden toe, want het is niet goedkoper dan MySQL, en gaat ook niet sneller dan MySQL.
Nee, want zoals in het stuk staat, kan nu de gehele database direct in de RAM
Wat is het voordeel als je de database in het RAM zet? Ik snap hem namelijk niet echt... :+
Volgens mij is het grootste voordeel dat het simpelweg bloedsnel is! :9
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]

Laat dat vaak maar weg. Geheugen is bloedsnel als je het vergelijkt met traditionele hardeschijven en zelfs SSDs maken geen schijn van kans tegen RAM geheugen.
En RAM geheugen is dan weer retesloom in vergelijking met cache.
En waar denk je dat de gegevens die in cache staan in zit??
In geheugen, het geheugen van de server en/of geheugen van de HD.....
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
Zolang het maar geen SandForce SSD's zijn ;).
"Tweakers tijdelijk read-only bij live gaan nieuwe databaseserver"

Geen enkel probleem :)
Ik ben geen mass poster, maar een 'got triggered to post' mentaliteit, persoontje.
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?
Ik vermoed veel kleine read/write operaties welke een ssd iets minder goed tegen kan.
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]

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?
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 18 januari 2013 15:34]

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 ;))
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.
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?
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
Wowie... $ 709 per stuk!...

Nee, privé moet ik toch maar een ''normale'' nemen ben ik bang.
Wat draait hier nou op? Vermoeden doe ik een linux....Unix kost geld...
We draaien standaard met Linux inderdaad. Al jaren :)

Deze draait Ununtu 12.10 en de database is uiteraard MySQL (5.5 op de nieuwe).
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).
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.
Ik heb persoonlijk niet echt problemen met Ubuntu als server, maar ik zou ook voor 12.04 LTS gaan.
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.
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).
Gokje: er is, eens geboot, niet zo veel I/O meer vereist van het OS, en dus de systeemschijf.

Dit kan een domme vraag zijn, maar hoe zorgen jullie ervoor dat de DB altijd 1:1 in sync is met de raid-array van SSD's?
Het cache management van de database wordt automatisch door het DBMS gedaan (in dit geval: MySQL), gebaseerd op de instellingen die je maakt in je DBMS-configuratie.
goede controller met genoeg ram erop geprikt:)
Je bedoelt denk ik dat het geheugen veel sneller is dan de ssd's en de ssd's dus druk zouden zijn om continu de wijzigingen in de database in het geheugen bij te houden?

Ik ben geen expert, maar dat hoeft toch niet 1:1 in sync te lopen? Die raid-controller is vast uitgerust met een BBU waardoor eventuele asynchronisaties bij een power failure weggeschreven kunnen worden naar de ssd's. Hoeveel wijzigingen kunnen er nou helemaal zijn in een paar seconden?

Op dit item kan niet meer gereageerd worden.



Populair: Samsung Intel Smartphones Processors Sony Microsoft Games Apple Politiek en recht Smartwatches

© 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