Tweakers.net-serverbeheer: Phoenix

Een korte inhaalslag

Zoals je in de development updates hebt kunnen lezen, zijn we al sinds deze zomer bezig met een disaster-recoverylocatie onder de naam 'Project Phoenix'. Dit project begint nu vorm te krijgen. Onze backuplocatie is ondertussen opgeleverd, een deel van de hardware is al geïnstalleerd, en de eerste tests zijn al begonnen.

Onze laatste update is al van anderhalf jaar terug, dus het is hoog tijd voor een nieuw kijkje in de serverkeuken van Tweakers.net. En er is genoeg te vertellen, want we hebben bepaald niet stilgezeten, dus we gaan even in sneltreinvaart door de grootste wijzigingen heen.

Na de laatste update in augustus 2010 moest onze backupserver Athena worden aangepakt. De server begon oud te worden; de Opterons die erin zaten voldeden niet meer, de opslagcapaciteit was te beperkt en het geheugen was niet toereikend.

Als vervanging is bij Dell een R510 gehaald met twee Quadcore E5620-cpu's op 2.4GHz, 24GB geheugen en 12 sata-schijven van 2TB per stuk. Deze server werd voorzien van Nexenta Core zodat hij met behulp van zfs send/receive kan synchroniseren met onze storage server. De 24TB aan schijfruimte werd opgedeeld in twee raid z2-arrays: effectief is er 16TB ruimte om backups op te maken.

Tegelijk met Athena hebben we ook onze laatste twee APC-pdu's vervangen door zero-u-pdu's van ServerTech. Deze zijn identiek aan degene die we in 2009 in het andere rack in gebruik hebben genomen.

Terwijl we met deze klussen bezig waren, gaf onze kvm-switch de geest. Ter vervanging werd een Aten KL1516-kvm-switch met lcd-lade aangeschaft. Daar hebben we ook nog een kvm-over-ip-module bijgekocht; met deze CN8000 kunnen we vanuit onze luie bureaustoelen de servers bedienen als de remote-managementkaarten in de servers stuk gaan.

Om onze virtuele machines van opslag te voorzien gebruikten we een Dell Powervault MD3000i SAN-appliance. Deze vertoonde enige kuren en omdat hij al was afgeschreven, hebben we zijn opvolger besteld: de Dell Powervault MD3200i. Ons exemplaar is voorzien van twaalf 1TB-schijven.

De twee Towers of Power van Tweakers.net, in het euNetworks-datacenter bij True

Project Phoenix

Voordat wij met Project Phoenix van start gingen, hadden we diverse spof's in ons netwerk. Om te beginnen is elke locatie kwetsbaar voor stroomuitval, brand, overstromingen en dergelijke. Daarnaast hebben we apparatuur zoals de storage-, search- en MySQL-servers: deze kunnen wel snel vervangen worden, maar als ze onderuit gaan, zal de bezoeker dat merken.

De doelstelling van Project Phoenix is dat de bezoeker het helemaal níet merkt als er een server uitvalt, en dat zelfs als een datacentrum compleet van de aardbodem verdwijnt, hooguit een klein deel van de bezoekers daar eventjes hinder van ondervindt.

Wij zijn begonnen met het herinrichten van onze dns. Onze domeinen waren bij verschillende registrars ondergebracht, zodat wijzigingen in geval van nood maar lastig door te voeren waren. Verder stonden onze dns-servers allemaal in hetzelfde netwerk, zodat bij uitval van dat netwerk geen enkel dns-request meer zou worden beantwoord. Ondertussen zijn onze dns-servers over een aantal netwerken verspreid en beheren we alle domeinen via één registrar.

De locatie

Op dit moment staan al onze servers in één datacentrum: euNetworks, in het zuidoosten van Amsterdam. Daardoor lopen we verschillende risico's die ervoor zouden kunnen zorgen dat we dagenlang onbereikbaar zijn: naast de bovenvermelde rampen kan je ook denken aan netwerkstoringen, menselijke fouten en faillissementen van leveranciers.

Om die risico's te beperken wilden we een tweede locatie die ver genoeg van de huidige locatie afligt, zodat we bij de meeste calamiteiten nog gewoon een werkend rack hebben. Dat is uiteindelijk wel een locatie in Amsterdam geworden, vanwege de hoge kosten van een redundante dataverbinding met lage latency's en hoge snelheden.

Onze keuze is gevallen op Telecity3. Dit datacentrum in het noordwesten van Amsterdam kenden we al goed; Tweakers.net werd er van 2004 tot 2007 gehost door True voordat wij naar euNetworks verhuisden.

In dit datacentrum huren wij, onafhankelijk van een hoster, een rack. Zo kunnen we zelf bepalen waar we onze bandbreedte inkopen. Beide locaties zijn aangesloten op de glasvezelring van Amsterdam, zodat we eenvoudig een redundante 10Gbit/s-glasvezelverbinding tussen onze racks konden leggen.

Het nieuwe netwerk

Op het gebied van hardware hebben we voor dit project alle registers opengetrokken; in samenwerking met Quanza Engineering hebben we gekozen voor een vrijwel geheel vernieuwde netwerkinfrastructuur.

De kern van het nieuwe netwerk bestaat uit drie Cisco 2960S-48TD-L-switches: twee in de beide racks bij euNetworks en nog een derde in het rack bij Telecity. Als backup is er in elk rack ook nog een Cisco 2960S-24TD-L-switch geplaatst. In elk datacentrum zijn de switches onderling verbonden met een redundant netwerk van 10Gbit/s-FlexStack-kabels, en zoals gezegd ligt er tussen de beide locaties een redundante 10Gbit/s-glasvezelverbinding.

Ook is er op beide locaties een Cisco 1801 - een zogeheten 'out of band'-router - neergezet en zijn er dsl-lijnen naar de racks gelegd. Op die manier kunnen we ook bij uitval van netwerken en glasvezelverbindingen nog steeds bij de onze servers en switches. Verder komen onze uplinks binnen op aparte 48-poorts HP Procurve 2910al- en HP Procurve 2520-switches.

De nieuwe netwerkstructuur en de uitwerking ervan in het Telecity3-rack

Nieuwe loadbalancers

Ook de loadbalancers worden vervangen door nieuwe hardware. Tot nu toe hebben we altijd zelf onze loadbalancers gemaakt met GNU/Linux en LVS. We hebben er echter voor gekozen om de loadbalancers voortaan kant-en-klaar te kopen, met name omdat er domweg geen tijd was om de loadbalancers zelf te bouwen, ze te voorzien van features als high availability, gslb en ipv6, en ze uitgebreid te testen. Bovendien hadden de loadbalancers die wij op het oog hadden ook nog andere handige features die veel tijd zouden kosten om zelf te ontwikkelen en te testen.

Onze keuze is uiteindelijk gevallen op de AX2500 van A10 Networks. Deze loadbalancer heeft genoeg poorten en genoeg bandbreedte, en biedt bovendien uitgebreide configuratiemogelijkheden voor onze overige eisen en wensen. Ook van deze loadbalancer hebben we drie stuks gekocht: twee voor de euNetworks-racks en eentje voor Telecity3.

Met behulp van gslb zal het verkeer over beide locaties worden verdeeld. De verwachting is dat we onder normale omstandigheden ongeveer vijf procent van ons verkeer naar Telecity3 sturen en de rest naar euNetworks. Op die locatie wordt de traffic tenslotte nog steeds door onze vrienden van True betaald Met deze aanpak hebben we de zekerheid dat al onze Telecity3-servers werken en up-to-date zijn, en bovendien dat de diverse caches goed gevuld blijven. Als we geen verkeer naar Telecity3 zouden sturen, zouden we zomaar voor allerlei extra verrassingen kunnen komen te staan als de EUNetworks-locatie onverhoopt zou uitvallen.

De A10 Networks AX2500-loadbalancer

Nieuwe webservers

De volgende stap in het project was het aanschaffen van nieuwe webservers voor de tweede locatie. Aangezien ook onze huidige webservers bijna afgeschreven waren, hebben we besloten om die ook maar meteen te vervangen.

De nieuwe webservers zijn zo krachtig, dat ze in theorie elk de hele site in hun eentje kunnen draaien. Desondanks hebben we er in totaal zes - voor iedere locatie drie - gekocht, zodat we voldoende redundantie hebben om ook bij uitval van een locatie onderhoud te kunnen plegen en pieken in het verkeer aan te kunnen.

Na een offertetraject met meerdere aanbieders bleek IBM uiteindelijk de beste prijs voor de gewenste specificaties te vragen. De bestelde zes IBM x3550 M3 1U-servers zijn ondertussen geleverd en geïnstalleerd.

De specificaties van de nieuwe webservers zijn uiteraard weer beter dan die van de huidige. Zo hebben ze wederom meer cores en meer geheugen, en per core zijn ze ook nog een paar procent sneller.

Jaargang	2006	2009	2012
Merk	2x Dell 1950 2x Supermicro	2x Dell R410 2x Sun Fire X2270	6x IBM x3550 M3
CPU	2x 5150 @2.66GHz 2x Opteron 275 @2.2GHz	2x X5570 @2.93GHz	2x X5675 @3.06GHz
Cores	4	8 (16 HT)	12 (24 HT)
Geheugen	4x1GB 667MHz	6x2GB 1333MHz	6x4GB 1333MHz
Disk	80GB 7.2K SATA	500GB 7.2K SATA	146GB 10K SAS

Met een eenvoudige benchmark - het compileren van de linux 3.1.1-kernelsource in het werkgeheugen, met een default config - is te zien hoeveel sneller de nieuwe webservers zijn. Met slechts een enkele thread is het verschil tussen de oude en de nieuwe servers nog niet heel erg groot.

Singlethreaded kernel compileren
Jaargang	Tijd in seconden, lager is beter
2012	******** 466s
2009	******** 489s
2006	********** 612s

De kracht van de nieuwe webservers ligt echter niet zozeer in het feit dat hij één bezoeker snel kan helpen, maar dat hij véél bezoekers snel kan helpen. Als we de '-j ($cores * 2) + 1'-optie bij het compileren van de kernel meegeven, is pas echt de performanceverbetering van de nieuwe webservers te zien.

Multithreaded kernel compileren
Jaargang - # threads	Tijd in seconden, lager is beter
2012 - 25 threads	** 37s
2009 - 17 threads	*** 56s
2006 - 5 threads	********** 178s

Deze servers zijn in de afgelopen weken bij euNetworks en Telecity3 opgehangen, en zullen binnenkort, na een uitgebreide testfase, de website gaan serveren.

Naast de webservers zullen we nog diverse andere servers bijplaatsen of vervangen. We hebben onder andere al twee zoekservers, twee memcached/nosql-servers en een nieuwe developmentserver besteld. Meer hierover komt in een vervolgartikel, maar we kunnen in ieder geval verklappen dat ze samen 336GB ram, 18 harde schijven en 8 caching-ssd's hebben.

Nieuwe software

We hebben niet alleen de hardware aangepakt. We gebruiken al jaren Debian Testing als standaard OS, met als grote voordeel dat we de nieuwste updates van onze software snel binnenkrijgen. Het nadeel is echter dat er elke week heel veel updates zijn, waarvan sommige eerst goed getest moeten worden.

Uiteraard is er ook nog Debian Stable, maar dat wordt juist weer heel langzaam van updates voorzien. Als we nieuwe functionaliteit zoeken, lopen we daarmee dus achter de feiten aan, tenzij we allerlei kunstgrepen toepassen. Het had altijd veel voeten in de aarde om Debian Stable - of Ubuntu LTS - op de nieuwste servers te installeren: in deze besturingssystemen ontbreken bijvoorbeeld vaak drivers voor nieuwe netwerkinterfaces of raid-controllers.

Met de nieuwe webservers als eerste slachtoffer zijn we dus overgestapt op Ubuntu Server 11.10. Met de halfjaarlijkse releasecycle van Ubuntu hoeven we maar eens per half jaar een nieuwe release te testen, en zullen we toch niet snel opgezadeld zitten met een verouderd OS dat onze nieuwe hardware niet meer kent of functionaliteit mist.

Nog meer veranderingen

In de afgelopen jaren hebben we Lighttpd ingezet voor statische content, Varnish als reverse proxy voor semi-statische content en Apache als webserver voor de dynamische php-content. Dat gaat veranderen. Welk domein je straks ook gebruikt: alle requests worden in eerste instantie door Varnish afgehandeld. De bezoeker wordt alleen naar Apache verwezen als blijkt dat er naar dynamische content wordt gevraagd of als een pagina nog niet in de cache blijkt te zitten.

De afgelopen jaren is ons serverpark stevig gegroeid, maar installatie en beheer van de servers ging nog steeds met de hand via ssh-terminals. Omdat dit ondertussen wel erg veel tijd in beslag nam, zijn we op zoek gegaan naar provisioning-software om eenvoudig servers te installeren en de configuratie up-to-date te houden. Van de onderzochte software sloot Puppet het beste op onze wensen aan. Hiermee kunnen we voortaan binnen enkele minuten een kale Ubuntu-installatie omtoveren in bijvoorbeeld een webserver.

Het vervolg

Al met al staan we nog maar aan het begin van Project Phoenix. De komende tijd worden de nieuwe switches, de glasvezelverbindingen en de nieuwe loadbalancers verder getest. Daarna worden de loadbalancers en de nieuwe webservers in gebruik genomen.

Verder gaan we onderzoeken hoe onze MongoDB-, ActiveMQ-, zoek-, en memcached-servers in een zogeheten multi-masterconfiguratie kunnen worden opgezet. Dat moet ervoor zorgen dat een bezoeker er niets van merkt als er een server uitvalt, uitgezet wordt en later weer aangezet wordt.

Voor de storage ligt een grotere uitdaging te wachten. Ook hier willen we graag een multi-masteroplossing, zodat de clients - zoals webservers - zonder ingewikkelde kunstgrepen altijd een werkend filesystem tot hun beschikking hebben. Ons huidige nfs-systeem is daar niet voor geschikt, omdat alle servers bij uitval de mount van de uitgevallen server op een of andere manier moeten vervangen door een mount op een werkende server. Daarom gaan we kijken naar de diverse distributed filesystems, zoals GlusterFS, XtreemFS en Ceph.

Later dit jaar moeten ook onze MySQL-servers in een multi-masteropstelling worden geconfigureerd; nu gebruiken we nog een master-slave-opzet. Ook hier is het de bedoeling dat onze webservers verbinding met een willekeurige MySQL-server kunnen leggen en dan zowel kunnen lezen als schrijven, zonder dat de programmeurs (waar we overigens nog versterking voor zoeken) zich zorgen hoeven te maken over hoe die data op de andere servers terechtkomt. Voor de serverbeheerders is er dus nog wel genoeg te puzzelen - maar we heten niet voor niets Tweakers.net.

Reacties (171)

[merlijn85]

Ik moet zeggen dat jullie m.i. toch wel een paar aparte keuzes maken met betrekking tot de hardware.

Het aanschaffen van een KVM over IP doos ter backup van de remote control interface is absoluut zinloos. Zorg dat je monitoring software het IPMI IP in de gaten houdt, en wanneer die wegvalt kan je in 99% van de gevallen het weer up krijgen door over ssh via de KCS interface een `ipmitool mc reset cold` te doen. Als dat niet helpt dan is je IPMI interface stuk en wordt het tijd voor een RMA bij de leverancier.

Verder geven jullie aan de DNS opzet aan te hebben gepast. Netjes met IPv6 in de glue, en in aparte datacentra. Echter zitten de nameservers nog allemaal op het domein tweakdns.net - dat is niet al te slim en kan problemen opleveren wanneer bijvoorbeeld je zone eruit valt vanwege een DNSSEC fuckup, of in het geval het hele .net TLD wegvalt. Het is dan ook aan te bevelen om verschillende registries te gebruiken voor je nameservers om dat goed op orde te krijgen.

Wat betreft software zou ik voor jullie aanraden om ook eens te kijken naar ZeroMQ ipv ActiveMQ, en mogelijk MariaDB ipv MySQL - zeker met multi-master setups maakt dat het leven een stuk minder ingewikkeld.

Wat betreft het opslagprobleem zou ik ook eens goed kijken naar Openstack Swift. Het is misschien wat minder stoer dan alles op FS niveau oplossen - maar als je het goed inzet kan het je ook een hele hoop geld schelen. Daarbij is Openstack veel meer flexibel qua uitbreiding dan de oplossingen die jullie aandragen.

[Kees]

De KVM-over-IP is ook meer een 'legacy' aanschaf geweest. We hebben momenteel nog enkele oudere servers die geen remote management kaart hebben en die zijn ook wel handig om te bedienen. Verder hebben we momenteel een test-server in het rack hangen die buiten de garantie valt en een dode remote management kaart heeft, die zijn wij aan het vervangen, maar zolang die vervanging er nog niet is kunnen we hem afentoe via die KVM wel benaderen

Verder ben ik het met je eens dat hij tegenwoordig niet meer nodig is, en in het rack bij Telecity3 hebben we die dan ook niet opgehangen.

Mbt DNS, daar heb je gelijk in, en dat zouden de laatste puntjes op de i zijn.

Qua "MySQL" software hebben wij nog niet heel uitgebreid rond gekeken, maar wanneer wij dat doen zullen we zeker ook naar percona, mariadb etc gaan kijken. Daar zijn interesantere ontwikkelingen gaande die wij ook goed zouden kunnen gebruiken. Dat we het niet meteen opnoemen is puur omdat we er nog niet heel uitgebreid naar gekeken hebben. Maar wij kijken echt wel verder dan Oracle/mysql

En openstack swift klinkt wel heel erg leuk, maar aan de andere kant limiteer je je er ook mee, en zul je delen van je applicatie moeten herschrijven. Wij zoeken liever een oplossing waar wij onze applicatie grotendeels intact kunnen laten.
Ik ken swift niet al te goed, maar volgens mij is het lastig om dat te gebruiken als nfs-replacement, waarbij je aan de ene kant miljoenen plaatjes kan opslaan, maar ook bijvoorbeeld video's, en liefst ook nog zo dat alle applicaties (sommige waar wij weinig invloed op hebben) erbij kunnen komen en ze kunnen bewerken/aanpassen/converteren etc.

Nogmaals, ik ken swift niet heel erg goed, maar het lijkt mij meer een cloud product waarbij je met een http-rest api je data beheerd en minder een soort van shared storage.

(en uiteraard schrijven wij ook dit soort artikelen om input van onze bezoekers te krijgen die er vaak veel meer van afweten dan wij )

[Reactie gewijzigd door Kees op 24 juli 2024 00:34]

[merlijn85]

MySQL is idd een lastig verhaal, maar het is tegenwoordig niet meer goed genoeg om met de standaard MySQL te werken als je wat meer dan gemiddeld wilt. Percona doet ook hele leuke dingen, en is ook beter geschikt voor sommige situaties. MariaDB heeft de veranderingen van MySQL 5.5 (en deels 5.6) nog niet in een productie release zitten, dus als jullie al met die functionaliteit werken is het zeker niet stom om te kijken wat Percona kan betekenen.

Openstack swift gaat inderdaad betekenen dat je delen van je applicatie moet gaan herschrijven, maar met een nette codebase is dat redelijk goed te doen. Het probleem met een shared filesystem zoals jullie dat voorstellen is dat het vaak lastig te bouwen is, en flinke eisen stelt aan het platform en de infra die je nodig hebt om dat lekker te laten werken. Nu ben ik niet ontzettend bekend met alle opties die jullie aangeven, maar o.a. bij DRBD wordt absoluut afgeraden om de pakketten te routeren, en bij voorkeur niet eens een switch erin te zetten. Vaak wordt er ook met locking gewerkt wat write operaties traag kunnen maken, en als laatste is het op filesystem niveau zo dat alle data op iedere mirror moet staan.

Openstack swift maakt dat weer makkelijker door te fungeren als een "object store" - bestanden worden op een bepaald aantal servers opgeslagen waarmee ze als redundant kunnen worden beschouwd, en de proxy servers regelen dat het bestand van de juiste server wordt geplukt. Mooie hieraan is dat je het prima kan bouwen met goedkope hardware, en het super linear schaalt. Zoals gezegd betekend het echter wel dat je code aan moet passen - maar het kan je zomaar duizenden euro's schelen met de hoeveelheid opslag en performance die jullie nodig hebben.

[ACM]

ZeroMQ ziet er op zich wel leuk uit, maar wij willen berichten liever niet kwijtraken als de message queue er onverhoopt uitklapt of tijdelijk niet zijn data kwijt kan. ZeroMQ biedt daar geen garanties voor.
Daarnaast hebben wij situaties waarbij consumers tijdelijk niet beschikbaar zijn, ik heb niet de indruk dat ZeroMQ daar uberhaupt voor bedoeld is.

Kortom, een STOMP/JMS(-achtige) omgeving lijkt vooralsnog beter aan te sluiten op onze huidige situatie dan ZeroMQ. Overigens is de performance van ActiveMQ ruim voldoende voor ons.

@itlee: Wij weten uiteraard ook niet alles, dus het is absoluut welkom als mensen vragen stellen, nieuwe ideeen of andere producten aandragen dan wij hier noemen

[Reactie gewijzigd door ACM op 24 juli 2024 00:34]

[Jrz]

Maar 0mq is een library en geen server.
Swift is idd een service, waar je niet je php en afbeeldingen vanaf kan serveren.
Ceph heeft een S3 interface, en biedt daarmee een mooie transitie oplossing.

Het 'omprogrammeren' kost ook makkelijk duizenden euros. Daarnaast is een filesystem toch net wat makkelijker te managen mbt backups enz.

[itlee]

ik zeg een tweaker die tweakers.net gaat leren hoe ze het moeten doen,...ik vind m leuk +1

[Supermario16]

Voor storage replicatie zouden jullie ook kunnen kijken naar DRBD in combinatie met Hearbeat en Pacemaker. Dit is een vorm van replicatie op blockniveau, waardoor je er naar eigen wens een filesystem of service aan kunt hangen. Linux ziet het gewoon als een logische drive. Ik heb het als test al meerdere keren gebruikt in combinatie met Vmware (VMFS5) en een iscsi target, maar je zou ook via NFS het een en ander kunnen opzetten. Er wordt eigenlijk gebruik gemaakt van 1 failover ip adres en een of meerdere multicast signalen (je kunt dit over meerdere fysieke of logische netwerk adapters spreiden) zodat de systemen van elkaar weten of ze up of down zijn. Bij een probleem zal automatisch het secondary systeem primary worden, maar je kunt ook handmatig een failover doen in geval van onderhoud. Ten tijde van de test hebben we ongeveer 20 virtuele machines op dergelijke setup draaien en bij een failover hebben die helemaal nergens last van

[analog_]

clustered filesystems en zeker in combinatie met next-gen filesystems zoals ZFS zijn tegenwoordig toch wel meer the-way-to-go dan zelf je DRBD scripting. Ik dacht dat Ceph hand in hand ging met BTRFS en GlusterFS bezig is met ZFS. Wat ook mogelijk is, is overstappen van Nexenta Core naar NexentaStor en daar licenties van afnemen voor replicatie/tralala, echter kan dat kostelijk uitvallen.

[Beatboxx]

Ik vind dit allemaal hartstikke gaaf, maar waar halen jullie 't geld vandaan? Tja, ik snap dat als je €0,01 voor een ad per pageview vraagt, T.net €40 000 per dag verdient, maar ik reken dan nogal ruim denk ik.

Ik vind t hartstikke goed dat jullie zoveel aandacht aan performance en redunancy uitgeven, maar 't maakt een bezoeker van jullie site écht niet uit of het 0,2 of 0,3 seconden kost om zijn pagina te genereren. Waarom hechten jullie zoveel waarde aan überpeformance, en kan 't niet wat goedkoper maar met minder ads?

[ACM]

40.000 is wel wat veel ja, dat redden we geloof ik niet Overigens is die 0.01 euro vziw zelfs vrij laag voor advertenties, maar we verkopen niet genoeg advertenties om op elke pagina er eentje neer te kunnen zetten. Wat ook gelijk een indicatie is dat we op zich vrij weinig advertenties plaatsen, zeker de vaste bezoekers zullen zien dat ze op een groot deel van de pageviews geen of weinig advertenties voorgeschoteld krijgen.

Maar er is ondertussen vrij veel onderzoek gedaan naar de impact van performance: het maakt wel uit. Zelfs 0.2 vs 0.3 seconde maakt (een beetje) uit, uiteraard lang niet zoveel als 0.2 vs 2 seconde. Hier vind je allerlei linkjes naar artikelen erover (hoewel ze gedeeltelijk naar dezelfde onderzoeken wijzen). Een snelle site levert dus trouwere bezoekers, (mede daardoor) meer bezoekers en uiteindelijk ook betere "conversie" op (in het geval van tweakers.net gaat dat dan vooral om winkelaars bij winkels in de pricewatch). Bovendien laat o.a. Google de snelheid van een site meewegen in de resultaten en dat levert dan uiteraard weer meer bezoekers op.

Het is dus niet zo dat we kunnen zeggen "ach, het boeit de bezoekers toch niet", dat is pertinent niet waar. Onbewust maken zelfs kleine verschillen nog wat uit. Domweg een tragere site betekent volgens diezelfde onderzoeken dus ook minder bezoekers en minder pageviews per bezoeker. Dus als we de performance terugschroeven, leveren we niet enkel maar een stukje imago in, we raken dan ook een deel van (de aandacht van) onze bezoekers kwijt. Hoeveel minder is uiteraard erg lastig te voorspellen... Dat hangt ook af van hoeveel concurrentie er is en hoe goed zij het doen. En of het dus de meerprijs waard is, is ook lastig te zeggen

Overigens is er geen 1:1-verhouding tussen de kosten en de performance, hoe dichter je tegen je capaciteit aan gaat zitten, hoe moeilijker het wordt om nog piekmomenten aan te kunnen. En juist die piekmomenten wil je natuurlijk wel goed op kunnen vangen, want dat zijn de momenten dat je relatief veel nieuwe bezoekers krijgt die voor het eerst jouw site bekijken.

Het is overigens wel zo dat een groot deel van de totale laadtijd niet echt beinvloed wordt door hoe snel je servers zijn. Wel is het zo dat het laden van een pagina pas kan beginnen zodra die servers klaar zijn met het uitvoeren van de php-code. En we willen vooral ook dat relatief complexe pagina ook nog snel laden; de meest rekenintensieve pagina's zitten in de pricewatch, net een van de delen waar we direct geld verdienen aan bezoekersgedrag, pageviews per bezoeker en de "conversie"

Met allerlei nieuwe features en gebruikerswensen worden de diverse pagina's trouwens ook steeds complexer, dus we moeten onder andere om die reden wat overcapaciteit inplannen, zodat onze site ook na 3 jaar verder ontwikkelen nog steeds snel is op de dan oude servers. Daarbovenop zit dan nog de verwachting dat onze bezoekersaantallen (volgens de huidige trend) blijven groeien.

[Reactie gewijzigd door ACM op 24 juli 2024 00:34]

[Beatboxx]

Ohja, en pagina's zoals de frontpage en de pricewatch gewoon cachen naar static HTML? Als je de pw elk uur update bijvoorbeeld, is dat ruim genoeg lijkt me...

[harley]

Oftewel grote veranderingen in het complete serverpark.

Ergens wel jammer om te lezen dat voor vrijwel alles kant en klare oplossingen aangeschaft worden. Er is volgens mij niets meer zelfgebouwd (hardwarematig dan)
aan de andere kant geldt dan ook wel weer dat het allemaal proffesionele, geteste en doordachte apparatuur is wat wel weer past bij de proffesionaliteit van Tweakers. Het is geen hobbyproject meer en daar hoort ook de juiste hardware bij.

Wel goed om te zien dat er nergens op bespaard wordt. Maar bij sommige dingen vraag ik me af hoeveel overkill er wel niet is.
aan de andere kant op lange termijn is niks overkill natuurlijk.

[Reactie gewijzigd door harley op 24 juli 2024 00:34]

[ACM]

't Is uiteraard de bedoeling dat dit soort hardware over drie of meer jaar nog steeds overcapaciteit levert om pieken op te vangen. Bovendien zijn sommige pieken erg hoog, we hebben wel pieken gezien van bijna 100.000 pageviews in een blok van 10 minuten door fout geconfigureerde crawlers. Normaal hebben we op de drukste momenten van een dag minder dan 50.000 pageviews in zo'n blok van 10 minuten.

En dan is het natuurlijk leuk dat de gewone bezoeker gedurende die periode nog steeds een snel reagerende site voor zijn neus krijgt. Bovendien willen we ook dat soort pieken kunnen opvangen als er een of enkele servers om wat voor reden dan ook hun werk niet kunnen doen

[dasiro]

moet er dan niet aan gedacht worden om een fout geconfigureerde crawler te detecteren en van de site te kicken, vooraleer die de load gaat verdubbelen ipv te investeren om dit op te vangen

[ACM]

Uiteraard, en dat doen we dan ook. Maar het duurt even voor zo'n crawler gedetecteerd wordt. Als je het direct per pageview zou willen controleren zou elke pageview weer zwaarder worden. Kortom, linksom of rechtsom moet je wel dat soort pieken op kunnen vangen. Ongeacht hoe lang het duurt voor ie gedetecteerd en geblokkeerd wordt.

En zoals eymey zegt; het was vooral ook een makkelijk en duidelijk voorbeeld

Een ander voorbeeld is dat bij de vorige lancering van deze layout er ineens heel veel extra bezoekers kwamen met plaatjes en andere bestanden die ze nog niet in hun browser-cache hadden. Dat leverde ook een behoorlijke piek in het werk van de diverse webservers op.
Uiteraard kunnen we een deel van zo'n piek dan weer voorkomen door bezoekers op de achtergrond al de nieuwe plaatjes te laten cachen, maar dat werkt ook maar gedeeltelijk.

[eymey]

Dat is natuurlijk maar 1 van de factoren die pieken kunnen veroorzaken he .

ACM bedoelt denk ik gewoon dat het om allerlei redenen nodig kan zijn om overcapaciteit te hebben. Verkeerd geconfigureerde crawlers zijn maar 1 reden, niet de hoofdreden.

Bovendien kan ik het me in het voorbeeld van de crawlers voorstellen dat zo'n piek ook niet lang zal duren en dat je dus ook weer oplossingen moet implementeren om zeer snel de aard van zo'n hoge piek te achterhalen.

[Kees]

Van de zelfbouw oplossingen zijn wij al even afgestapt, puur omdat het eigenlijk geen voordeel opleverde, en wel een heleboel nadelen had. Zo zit er op deze servers gewoon support zodat, mocht er iets stuk gaan, er een mannetje met een vervangend onderdeel in notime op de stoep staat.

Verder wordt er nog genoeg bespaard, we hadden ook oplossingen kunnen kiezen waar wij bijvoorbeeld BGP routers nodig hebben, dan heb je nog minder downtime (als je onverwachts moet switchen) maar dan is de prijs nog een stukje hoger.

En tja, er is gewoon een kosten-baten verhaal op los gelaten: downtime kost ons zoveel per dag, het kost ons zoveel om dat nog beter aan te pakken, is dat het waard? Ja, dat is het.

[ShadowBumble]

Verder wordt er nog genoeg bespaard, we hadden ook oplossingen kunnen kiezen waar wij bijvoorbeeld BGP routers nodig hebben, dan heb je nog minder downtime (als je onverwachts moet switchen) maar dan is de prijs nog een stukje hoger.

BGP Routers ? Ik neem aan dat je bedoelde de functionaliteit BGP ? Aangezien ( Voorbeeldje ) je out-of-band router Cisco 1801 deze functionaliteit al bezit, echter om je DC's BGP redudant te maken kun je 2 wegen kiezen.

Onderlinge koppeling via 10Gbit/ Cityrings ( zoals je nu doet ) of een geografisch gescheiden BGP "cluster" waarbij je beide dc's inzit als actief maar op basis van metric's je actieve entry point defineerd, en deze via de L2 cityring naar de andere cluster gooit.

Hoe dan ook als je 2DC's volledig via BGP wil inregelen kost je dat aanzienlijk meer dan de manier waarop het nu gedaan is, echter in de toekomst zal ik er toch serieus naar kijken, ja de kosten zijn hoog maar die kosten verdien je terug door beide DC's in te zetten als actieve omgeving.

[ACM]

Met GSLB hebben we ook beide datacentra in gebruik hoor... Wat we daarbovenop met BGP vooral nog hadden kunnen bereiken was dan dat een datacentrum vrijwel naadloos overgenomen kon worden. Maar dat soort dingen vereiste dan wel de aanvraag van een of twee private IP-space blokjes en de aanschaf van nogal prijzige routers die dan die de routes naar die blokjes kunnen adverteren en faciliteren.

Maar je terugverdienverhaal snap ik dus niet zo goed. We hebben met BGP dan meer kosten en die vooral een iets kortere overschakeltijd met zich mee brengt. Maar vziw kunen we met GSLB onze hardware juist completer inzetten (ook een extra loadbalancer en de tweede verbinding met een provider).

[ShadowBumble]

Dat terug verdien verhaal was dan ook ervan uitgaande dat er een actief/passief opzet was maar met beide DC's in een GSLB opzet vervalt dat natuurlijk alleen maar en zal BGP alleen kwa overschakel tijd schelen.

Had nergens in het stukje gelezen namelijk over een actief/passief of actief/actief systeem. ( of met me neus gelezen )

[Fermion]

Er komt een moment dat een business case dit verantwoord en dat de stakeholders inzien dat dit geld oplevert, hoe gek het soms ook klinkt.

edit: Ze gaven zelf al aan dat het ontwikkelen van Loadballancers veel tijd in beslag neemt, kant en klaar kan dan voordeliger zijn. Ook ligt de kennis vaak bij één persoon, wat als die vertrekt? De ontwikkelingen ligt dan stil en een vervanger vindt je niet zo snel. En zo zijn er nog wel een tal van argumenten te vinden om voor kant en klare (vaak dure) oplossingen te gaan.

[Reactie gewijzigd door Fermion op 24 juli 2024 00:34]

[Superstoned]

Inderdaad. Feitelijk vind ik het nog wat vreemd dat ze geen enterprise linux gebruiken (zoals SUSE of Red Hat) maar met een klus distro als Ubuntu aan de slag gaan... Dat testen moet toch aardig wat tijd kosten en zo duur is een enterprise distro ook weer niet.

[sfranken]

Ubuntu kan zich anders gewoon meten met SUSE en Red Hat hoor.

[Z-Dragon]

Tweakers.net is een populaire website met een hoop bezoekers en sponsoren die beide graag zien dat de site altijd beschikbaar is. En natuurlijk heb je een reputatie hoog te houden. Maar begint dit niet wat overdreven te worden? Uiteindelijk wordt de investering wel erg hoog om die laatste minuten downtime te bestrijden. Tweakers.net zou die (vanuit de klant gezien) inmiddels sterker kunnen reduceren door providers te adviseren hoe hun netwerk stabiel te houden, dan door verder te klussen aan de eigen servers.

[Reactie gewijzigd door Z-Dragon op 24 juli 2024 00:34]

[Daniel]

Of het nodig is, kun je natuurlijk discussie over voeren Ik vind dat een site met de omvang en reputatie van Tweakers.net zich niet kan veroorloven om langdurige downtime te hebben: zowel bezoekers als klanten verwachten dat wij online zijn.

Er zijn bijvoorbeeld nogal wat webwinkels die veel omzet genereren uit het verkeer vanuit de Pricewatch. Als Tweakers.net door een calamiteit 24 uur of langer uit de lucht is voelen zij ook direct de gevolgen. Ook andere klanten verwachten dat als ze een advertentiecampagne bij ons inkopen er ook een site is om het op uit te leveren. Het is dus ook niet meer dan logisch dat we de kans op substantiële downtime zo ver mogelijk proberen te minimaliseren.

Project Phoenix is ook niet primair bedoeld om die laatste paar minuten downtime te bestrijden (we zijn geen bank), maar om voorbereid te zijn op echte calamiteiten zoals brand waarbij ons primaire datacenter 24 uur of langer - of permanent - niet meer beschikbaar is. In de oude situatie zou bij een dergelijke calamiteit de downtime waarschijnlijk minimaal 48 uur en waarschijnlijk veel langer zijn omdat we simpelweg dan ineens alles zouden moeten gaan regelen: servers, rackspace, configuratie etc.

Hoewel de kans klein is, zijn de gevolgen potentieel enorm groot en nu de mogelijkheid hebben dat op te vangen doen we dat ook.

[Help!!!!]

Wat je in je eerste alinea schrijft kan ik volledig onderschrijven. (Rest ook trouwens)

Voor de grootste technologiesite van Nederland waar heel veel kundige IT hobbyisten en proffesionals komen zou het toch wat knullig overkomen als door zo'n calamiteit je evt. dagen of langer uit de lucht bent.

[Jasper Janssen]

Een voordeel is dat bij brand/aardbeving/etc je iig een goed verhaal hebt *waarom* de hele boel niet werkt. Als er een calamiteit is die net wat minder goed 'bekt', zoals een blikseminslag of stroomstoring of waterschade, dan heb je kwa reputatie meteen een groter gat.

[ACM]

Deze investering is niet echt bedoeld om "de laatste minuten downtime" op te vangen. Maar juist om "uren, dagen of zelfs weken van downtime" te voorkomen. Dit moet je dan ook meer zien als een (dure) verzekering tegen echt ernstige problemen.

Als we dat soort problemen afwachten en pas dan wat gaan doen, heb je grote kans dat Tweakers.net zo vreselijk veel bezoekers verloren heeft, dat het dan weer maanden of jaren duurt voor e.e.a. weer op de niveau's van net daarvoor is.
Een paar minuten downtime boeit op de inkomsten waarschijnlijk vrijwel niets. Een paar uur downtime zal ons die specifieke dag wat minder geld opleveren, maar waarschijnlijk nauwelijks bezoekers kosten... Maar een dag of meer downtime? Ik vermoed dat we dan behoorlijk wat inkomsten mislopen en bovendien ook de minder reguliere bezoekers voor langere tijd kwijt zijn. Mensen gaan op het Internet vrij snel op zoek naar een alternatief en zodra ze die gevonden hebben is de kans groot dat ze die blijven gebruiken.

[Termy]

Helemaal geen enkele SSD? Zelfs niet in de webserver waar nu een 146GB 10k SAS in zit? Hoe is dat ding beter dan een willekeurige SSD? Beetje verbazend.

Op AnandTech is recent een verhaaltje neergezet over SSD's in enterprise en hoe ze die zelf gebruiken. Had wel gedacht dat op Tweakers.net SSD's op z'n minst genoemd zouden worden als optie (met reden waarom ze het niet geworden zijn, uiteraard).

[ACM]

O.a. onze huidige MySQL-databases hebben array's van SSD's.

Daarnaast onze NFS-server en onze oudste server met SSD's is zelfs in juli 2009 al in het rack geplaatst.

Maar deze webservers doen vrijwel niks met hun disks, dus het is onzin om geld uit te geven aan SSD's. Voor onze nieuwe databases, storage-machines en andere machines die dingen met hun disks moeten doen kijken we er uiteraard wel heel sterk naar.

[fdh]

denk dat de latency van iscsi (of nfs) domweg te hoog is om dan aan storage kant gebruik te maken van SSD.
Bij fiber channel is de round-trip latency al 10-20 µs, terwijl de read latency van een SSD iets van een 25 µs zal zijn. Bij iscsi of nfs is de round-trip latency hoger (maar heb ik niet echt cijfers van).
Het heeft dus geen nut om veel te investeren in ssd aan je storage kant als je tussenliggend netwerk zulke vertragingen heeft.
Wat je wel kan doen is ssd gebruiken als buffer (voor read en writes), maar dan moet je san / nas dit ook ondersteunen.

Een andere optie is om over te stappen of infiniband, wat een round trip latency heeft van 1 µs :-))

[Femme]

De toegangstijd van een ssd is vaak wel wat hoger, zo tussen de 65 en 160 microseconden bij moderne exemplaren. Dan nog loopt jouw redenering mank. Het alternatief voor een ssd is een conventionele harde schijf waarvan de beste exemplaren met short stroking een toegangstijd hebben van rond de drie milliseconden. Dat is meer dan een factor 100 hoger dan de door jouw genoemde roundtrip latency van fibre channel. Een ssd is dus ook in een san of nas met een hogere latency dan direct aangesloten opslag veel sneller dan een harde schijf.

[Reactie gewijzigd door Femme op 24 juli 2024 00:34]

[fdh]

Dat hangt af van je type van SSD (RAM SSD vs Flash SSD), voor een flash SSD zit je inderdaad aan hogere tijden.

Mijn punt is dat als je gebruik maakt van ssd, je best deze ofwel rechtstreeks in de server plaatst of voorziet in een low latency connectie.

[Navi]

Er staat wel dat ze in het vervolg het gaat hebben over servers met caching SSD's.

[Kees]

In de webservers is geen ssd nodig, die doen bijna alles uit het geheugen, in andere servers wordt wel veel gebruik gemaakt van ssds :-)

[Sfynx]

Uiteraard stamp je eerst alles tot de nok toe vol met RAM, maar als dat nog niet toereikend is voor het cachen van je random read workload op een ZFS storage pool, dan zijn een of meer snelle SSD's als L2ARC absoluut een zeer nuttige aankoop.

[Reactie gewijzigd door Sfynx op 24 juli 2024 00:34]

[eymey]

Het valt me, net als anderen, op dat jullie nog steeds aardig wat gesponsord krijgen (terecht natuurlijk), terwijl jullie tegenwoordig ook onderdeel zijn van het grote VNU.

Is er nooit een moment geweest dat jullie bang waren om binnen de infrastructuur van VNU (die ze ongetwijfeld ook zullen hebben) opgenomen te worden? Of ziet VNU jullie gewoon als dusdanig specialistisch dat ze het hosting werk graag bij jullie zelf houden?

Of wellicht hoopt VNU ooit nog van jullie expertise te kunnen profiteren?

[Wilbert de Vries]

Zoveel krijgen we niet gesponsord hoor. We hebben al een jarenlange samenwerking met True voor dataverkeer, dat is geen geheim. Alle hardware wordt gewoon aangeschaft, waarbij we uiteraard net als andere klanten kijken of we nog wat korting kunnen krijgen.

VNU heeft uiteraard ook sites die gehost moeten worden, maar er wordt gewoon gekeken naar wat een titel/merk/functie nodig heeft en wie dat kan bepalen. Uiteraard wordt er vanuit Tweakers.net op technisch gebied overlegd met de betrokken collega's van VNU (denk aan iemand als de cto), maar net zoals ik redacteuren soms gewoon moet vertrouwen op hun expertise werkt dat met de hosting en serverinrichting ook. We hebben goede mensen, dus laten we die mensen het 'regelen'.

[Peleus2K]

Het Tweakers Technologie team staat volledig los van de rest van VNU Media en dat zal ook zo blijven.

[tikkietrugjaap]

God wat een mooi spul is dat toch. Ben bang dat het feit dat ik hebberig word als ik jullie verhaal lees toch wel betekent dat een beetje een nerdie ben, haha. Ach, ik embrace hem gewoon.

Anyway, wat ik me afvroeg. Jullie hebben nu twee locaties maar die staan allebei in Amsterdam. Staan ze dan allebei op een ander stroomnet? Je hoort wel eens dat er ergens een trafo doorbrandt en dat een deel van de stad zwart gaat. Ik neem aan dat een serverpark zijn eigen noodstroomvoorziening heeft maar hoe lang kan zoiets het volhouden gezien het grove geschut dat ze moeten onderhouden? Nemen jullie dit mee bij het kiezen van een serverpark?

Ook vroeg ik me af op welke hoogte de serverparken staan. Niet dat het een prio is van T.net om nog bereikbaar te zijn als de dijken doorbreken maar ik vroeg me af of jullie zoiets meenemen in jullie beslissing.

[ACM]

Ze staan een behoorlijk eind uit elkaar. We gaan er dus inderdaad van uit dat bij stroomuitval in de meeste gevallen slechts een van de twee locaties plat gaat. En inderdaad hebben beide locaties generatoren om het een tijdje zonder stroom van buitenaf uit te zingen.

De hoogte is zo te zien respectievelijk 0.5m boven NAP en 1.2m boven NAP volgens de AHN.

[Verwijderd]

Hij heeft een goed punt over locatie!
24/7 uptime willen en dan je servers in de zelfde regio plaatsen zelfs in de zelfde stad is gewoon niet goed doordacht Het lijkt meer op een locatie lekker dicht.
Wat is juist het doel van de een backup systeem dat 24/7 uptime moet garanderen?
juist ja dus creëer je dat nooit in de zelfde regio laat staan in de zelfde stad.

Ik moest enorm lachten NAP aanhalen want bij overstroming is de kans dat je stroom hebt 0,0. en als je overstroming hebt hoe krijg je dan diesel?

Niet dat je voor overstoming bang moet wezen
Het Punt is stroom storing is je grootste vijand en probleem.
want hoe krijg je diesel bij jou data center? Amsterdam is een verkeers- chaos zonder stroom storing laat staan met en met 2 data centers in de zelfde regio....... zie ik niet hoe je 24/7 waar kunt maken in een risico analyse. en stel jouw data center heeft alles onder controle hoe zit dat met de rest van de infra????

Een veel betere Locatie voor deze 100% redundant 24/7 uptime Zou je veel verder weg moeten neer zetten liefst bij een totaal ander knooppunt eunetworks heeft in de buurt Dusseldorp Hamburg Frankfurt ook gewoon een locatie.

Aan gezien ik dagelijks werk met slecht doordachte systeem die in theorie allemaal heel goed klinken dacht ik even mijn mening geven.

[dvz89]

Een 10Gbit fiber link naar Dusseldorp maken.. De hele aanpak is wellicht al overkill, maar om CERN na te bouwen..

[Powermage]

even een aanname van mijn kant, maar de meeste DC's hebben een voorraad voor 12 tot 24 uur Diesel.
Desondanks dat ze relatief dicht bij mekaar liggen zal een stroom impact niet zo een impact hebben dat 'alles' plat gaat, dit gaat vaker toch gesegmenteerd.

Daarnaast lijkt me sterk dat een stroomstoring in deze tijd zo lang duurt (24 uur), het moet ook ruim binnen die tijd mogelijk zijn om diesel daar te krijgen, 24 uur is een lange tijd, Amsterdam mag dan redelijke chaoas zijn, maar de taferelen die je beschrijft zijn nog nooit in NL voorgekomen.

[Diz-X]

Wat ik me nu afvraag is waarom de keuze is gevallen op de A10 AX2500 load balancer, waarom geen Barracuda?

Na een beetje googlen kom ik er achter dat de load balancer die jullie hebben aangeschaft al snel 25.000 dollar kost. Wat heeft deze wat goedkopere alternatieve niet hebben?

[ACM]

We wilden sowieso een doorvoersnelheid van minstens 2Gbit en eventueel zelfs 4Gbit per loadbalancer aankunnen. De Barracuda's kunnen volgens hun eigen specificaties maar 950Mbps aan (oftewel 1 Gbit-aansluiting vullen met verkeer en meer niet). De AX2500 kan gewoon al zijn (12) netwerkpoorten samen vullen met verkeer. En volgens mij hebben die barracuda's niet eens een redundante voeding, wat ook wel nogal nuttig is voor je entry-point van verkeer.

Al met al zal het qua features niet eens zoveel verschillen, maar we kregen bij de A10 networks toch een beter gevoel dan bij de Barracuda's.

Bovendien ben je voor de Barracuda 640 met veel Gbit-poortjes (inclusief support en updates) zo'n 20.000 euro kwijt. Dus qua geld scheelt het niet eens zoveel.

[Diz-X]

950 Mbps is alleen voor inkomend verkeer. Barracuda werkt volgens het "Direct Server Return" principe, wat LVS (Linux Virtual Server) ook eigenlijk doet.

Zelfs moet ik eerlijk toegeven dat ik werk met LVS ism Keepalived, zit nog rustig te kijken naar een vervanging.

[ACM]

Ik weet niet meer precies wat de nadelen van direct server return waren, maar wel dat het zowel op de Barracuda als LVS niet de standaardmethode is. En vziw kunnen we dan in ieder geval minder eenvoudig SSL-termination op de loadbalancers doen (wat we overwegen) en vereist het wat trucage met Ethernet en ARP waar vast weer eigen haken en ogen aan zitten.

Met deze loadbalancers hoeven we dat niet te doen (ze ondersteunen 't uiteraard wel) om toch meer dan 1Gbps te gebruiken.

[Verwijderd]

Wat weerhoud jullie er van om alles bij rackspace/amazon/etc neer te zetten? Bespaar je nogal een bak met geld mee, en veel betere uptime als hun krijg je zelf moeilijk voor elkaar. Ook kan je bij extreme load dit binnen minuten opvangen. - Hoewel laten we eerlijk zijn, een systeembeheerder zou dit niet snel adviseren/toegeven omdat hij zijn eigen baan er mee uitbesteed.

Ik snap de angst voor de Amerikaanse wet enzo wel (terwijl er ook Nederlandse alternatieven zijn), alleen dat lijkt me voor een community als Tweakers nou niet echt interessant.

[Kees]

Wat ons weerhoud is dat we dan onze hele applicatie moeten herschrijven, tonnen aan performance inleveren, nog net zo goed plat kunnen gaan (zie amazon) en bezoekers een hogere latency geven (rackspace zit in londen, amazon in ierland), en het minimaal evenveel werk is om te beheren.

En in the end is het niet eens goedkoper; voor onze database zouden wij bij amazon ijvoorbeeld de High Memory instance willen hebben, die is $2.10 per uur, oftewel $55.188 per jaar, en daar hebben wij er twee van nodig. Voor dat geld kunnen wij prima 2x highend (met veel meer geheugen, performance en io/bandbreedte) halen, en die 3 jaar ergens hosten. En dan hebben we het nog niet eens over de rest van de ~20 servers die wij erin zouden willen hebben.

[eborn]

Bedenk wel dat je daarvoor ook nog iemand moet hebben die hem kan onderhouden. Stel je nou voor dat Kees onder een bus komt... ? ;-)
Maar zonder gekheid, met dit soort grote setups loont Amazon eigenlijk nooit. Als je een servertje nodig hebt, of zelf helemaal niemand in dienst hebt met hardware kennis, dan is het misschien nog interessant.

[Jrz]

Waarom denk je dat dat zoveel geld bespaard?
En hoe kom je er bij dat amazon kwa performance sneller is dan zelf alles regelen?