Tweakers' serverpark

De situatie in 2015

Inleiding

Afgelopen september hebben we weer flink wat oude servers in de verkoop gedaan. In de daarbij horende discussie werd er enthousiast op gereageerd, maar ook gezegd dat het tijd werd voor een update over de hardware die we nog wél hebben. Dat waren we met jullie eens; dit artikel is een vervolg op ons verhaal uit 2013. Hoewel er allerlei servers zijn vervangen, is de architectuur grotendeels gelijk gebleven. Daarom richten we ons vooral op de verschillen in software en hardware, en leggen we niet van alle software opnieuw uit waarom we die nog steeds gebruiken.

In totaal zitten we nu op 27 fysieke servers, twaalf pdu's, negen switches, drie loadbalancers en drie firewalls. Dat alles is nog steeds verspreid over twee locaties. De hoofdlocatie wordt gesponsord door True en is daardoor uiteraard voor ons het goedkoopst. Omdat de bandbreedte, de ruimte en het stroomverbruik voor ons gratis zijn, sturen we normaliter vijfennegentig procent van ons verkeer hierheen. De andere locatie krijgt vijf procent, om op die manier de caches 'warm' te houden en ons ervan te verzekeren dat alle hard- en software nog goed werken.

Toch zie je dit onderscheid in hoeveelheid verkeer bij bepaalde keuzes terugkomen. Als een van de twee locaties ergens 'meer' van heeft, dan is dat telkens de hoofdlocatie. Op die locatie hebben we bijvoorbeeld een redundante 10Gbit-verbinding, met bijpassende switches en firewalls. De uitwijklocatie moet het met 'slechts' 1Gbit doen. Meer over die netwerkhardware kun je lezen in onze recente .plan.

Met de bovenstaande lijst servers hebben we nog steeds vrijwel dezelfde structuur als in 2013. Het is nog steeds een 'uitgebreide' LAMP-stack, hoewel we op dit moment twee verschillend ingerichte webservers hebben en geen OpenSolaris meer gebruiken voor de opslag.

Webservers

Onze drie loadbalancers verdelen het verkeer over de diverse webservers, althans er zijn er op ieder moment steeds maar twee actief, omdat we in onze hoofdlocatie twee loadbalancers in active-passive-modus hebben staan. De loadbalancers zorgen er bovendien voor dat het verkeer via gslb over de twee locaties wordt verdeeld. De standaardverdeling daarbij is 95/5 procent, maar dat wordt automatisch op honderd procent ingesteld als een van de locaties niet meer werkt.

Een groot verschil ten op zichte van de webservers van 2013 is dat we nu twee typen webservers gebruiken. Het eerste type is verantwoordelijk voor de 'statische content', zoals onze javascript, css en (dynamisch gegenereerde) afbeeldingen. Het tweede type is verantwoordelijk voor de 'application'. Daarmee doet dit het leeuwendeel van de php-verwerking en genereert dit type dus de uiteindelijke html.

Hoewel deze opsplitsing verschillende voordelen biedt, vormde één specifiek soort downtime de aanleiding hiertoe. Af en toe was onze nfs-server even niet bereikbaar, waarna in rap tempo alle 'workers' van Apache bezet raakten omdat ze wachtten op een reactie van de nfs-server. Zelfs als de daadwerkelijke onbereikbaarheid van de nfs-server maar enkele seconden duurde, kon dit grote gevolgen hebben voor Apache. Vaak moesten we Apache herstarten en de disk remounten om het probleem op te lossen. Soms moesten we zelfs de server opnieuw starten.

Dit probleem verdwijnt natuurlijk niet door webservers in twee typen op te splitsen, maar daarmee bereiken we wel dat alléén de plaatjes en andere statische content op een dergelijk moment onbereikbaar zijn. Overigens is intussen ook de nfs-configuratie aangepast, waardoor het in de praktijk niet meer voorkomt.

Statische-contentserver

De splitsing gaf ook ruimte om zaken specifiek voor hun doel te optimalizeren. Zo hebben de statische-contentservers een grotere in-memory Varnish-cache (15 versus 5GB) en zijn de 'application'-servers juist voorzien van onze Java Engine, die we ook gelijk wat meer geheugen hebben gegeven. Verder gaan we nog bekijken of het eerste type server een andere http-daemon moet krijgen. Apache werkt erg goed en biedt krachtige functionaliteit, maar voor statische content zijn er efficiëntere webservers beschikbaar, zoals nginx en lighttpd.

2x 'application'-server

Voor meer informatie over al die software kun je onze vorige versie doorlezen. Aan de inrichting is verder weinig veranderd.

Onderdeel	2013	2015 Application	2015 Statische content
Hoofdlocatie	3x IBM x3550 M3	3x IBM x3550 M5	2x IBM x3250 M5
Uitwijklocatie	3x IBM x3550 M3	1x IBM x3550 M5	IBM x3250 M5 + x3250 M4
Cpu	2x Xeon X5675 (3,06GHz 6C)	2x Xeon E5-2640 v3 (2,6GHz 8C)	M5: Xeon E3-1271 v3 (3,6GHz 4C) M4: Core i3-3220 (3,3GHz 4C)
Geheugen	6 x 4GB (24GB)	8 x 8GB (64GB)	4 x 8GB (32GB)
Disk	146GB 10K SAS	500GB SATA	M5: 250GB SATA M4: 64GB SSD
Apache	*.tweakers.net *.tweakimg.net	*.tweakers.net (behalve static.tweakers.net)	static.tweakers.net *.tweakimg.net
Varnish	5GB	5GB	15GB
Tomcat	8GB	10GB	n.v.t.
ActiveMQ	2GB	2GB	2GB

Ten opzichte van 2013 hebben de nieuwe application-webservers veel meer ram gekregen. De 24GB was wat aan de krappe kant voor de combinatie van Varnish, Apache, Tomcat en ActiveMQ. Met die 64GB hebben ze voorlopig nog behoorlijk wat geheugen vrij. De statische-contentservers hebben met 32GB ook meer geheugen gekregen dan de oude servers, maar doordat de Varnish daarvan meer geheugen toegekend heeft gekregen, is die extra ruimte onmiddellijk alweer in gebruik genomen.

Hoewel er per application-webserver nu vier cpu-cores extra zijn, lijken ze aan de hand van de specificaties per cpu-core iets langzamer. In werkelijkheid valt dat reuze mee, omdat de E5-2640 v3 drie generaties nieuwer is dan de X5675 en daardoor meer werk per clock tick kan doen. Zodra turboboost actief is, loopt het verschil in kloksnelheid ook nog eens terug, de E5-2640 haalt maximaal 3,4GHz op een of twee cores en de X5675 3,46GHz.

De statische-contentservers zijn overigens nog wel een stuk sneller met singlecore-prestaties. De Xeon E3-1271 v3's hebben tenslotte min of meer dezelfde cpu-architectuur, maar hebben een minimale kloksnelheid van 3,4GHz en kunnen dat met turboboost verhogen tot maximaal 4GHz.

De redundantie van de servers is met de genoemde splitsing ook anders ingericht en dat was meteen onze eerste serieuze afwijking van het originele plan om de locaties te spiegelen. Op de hoofdlocatie hebben we volledige redundantie voor de application-webservers, omdat zij vijfennegentig procent van het verkeer moeten verwerken. Als we ook voor de andere vijf procent drie van die dikke servers hadden moeten plaatsen, hadden we flink moeten inleveren op de capaciteit per server om binnen ons budget te blijven. Servers plaatsen die vervolgens weinig werk krijgen, vonden we een te groot offer.

Volgens onze schattingen kan één dergelijke application-webserver op een normale dag al het verkeer aan, daarom hebben we er in de uitwijklocatie ook maar een geplaatst. Uiteraard zal die ene overgebleven server het bij uitval van de hoofdlocatie wel gelijk behoorlijk druk krijgen. Om dat effect te minimaliseren zijn de loadbalancers geconfigureerd om bij hoge load ook de statische-contentservers in te zetten voor het tweakers.net-domein. Uiteindelijk zijn daardoor in de hoofdlocatie nu maximaal vijf webservers beschikbaar en in de uitwijklocatie, net als voorheen, maximaal drie.

Video en virtualisatie

Ons videoplatform draait ook al enkele jaren lokaal op software van StreamOne. Sterker nog, dat was een van de redenen voor de upgrade naar 10Gbit. We draaien ondertussen met drie streamingservers, waarvan er een in de uitwijklocatie is geplaatst.

In 2013 hadden we nog dedicated servers voor het transcoden van video's, maar door de aanschaf van nieuwe vm-hosts was de rekenkracht daarvan voldoende toegenomen. Kortom, die extra servers waren overbodig geworden.

Onderdeel	Streaming 2013	Streaming 2015
Server	2x Dell R210	3x IBM x3250 m4
CPU	Core i3 530 (2,93GHz 2C)	Core i3 3220 (3,3GHz 2C)
Geheugen	2x 4GB (8GB)	4x 8GB (32GB)
Disks	1x 160GB SATA	64GB MLC SSD + 900GB 10k SAS

De nieuwe streamingservers hebben veel meer geheugen, waardoor de diskcache van Linux een groter aantal video's kan vasthouden. In eerste instantie gingen we ervan uit dat de 64GB-ssd's genoeg capaciteit zouden hebben voor het 'lokaal' cachen van videobestanden. Helaas zijn die bestanden zo groot en worden er zoveel verschillende bekeken, dat het cache-algoritme niet genoeg had aan die 64GB-ssd's. Onze pas uit gebruik genomen NoSQL- en searchservers waren voorzien van 900GB-sasdisks en die hebben we daaruit verhuisd naar de nieuwe streamingservers.

Vm-server (boven) en videoserver (onder)

Virtuele-machinehosts

We hebben ook een aantal servers nodig als host voor de virtuele machines die we hebben. Voor de meeste taken gebruiken we bare metal, maar er is een aantal services die te klein zijn om een eigen server te krijgen. Onder andere de eerder genoemde transcoding-back-end van het videoplatform, de irc-servers en mailfilters zijn gevirtualiseerd.

In vergelijking met 2013 zijn we van twee naar drie servers gegaan. Twee daarvan hangen in de hoofdlocatie en de derde in de back-uplocatie. De hardware is niet significant veranderd. De nieuwe cpu's hebben iets meer kernen en zijn uiteraard twee generaties nieuwer. Verder hebben we de diskruimte uitgebreid om, waar nuttig, vm-images lokaal te kunnen hosten, in plaats van gedwongen te zijn alles van onze nas te laden. De hypervisor is nog steeds KVM boven op Ubuntu LTS.

Onderdeel	Virtual machine hosts 2013	Virtual machine hosts 2015
Server	2x Dell R410	3x IBM x3550 M4
Cpu	2x Xeon E5630 (2,53GHz, 4C)	2x Xeon E5-2630 v2 (2,6GHz, 6C)
Geheugen	64GB DDR3-1066	64GB DDR3-1866
Disks	1x 250GB	2x 1TB 7,2k

Database en filestorage

Voor de opslag van bestanden en gegevens hebben we allerlei servers in gebruik. Sinds het vorige verhaal zijn de desbetreffende servers allemaal vervangen. We gebruiken nog wel dezelfde typen databases.

MySQL

In de onderstaande tabel lijkt het alsof we een server hebben doorgeschoven van master 2013 naar slave 2015. In werkelijkheid hebben we een paar maanden na het vorige artikel een tweede x3550 M4 aangeschaft en vervangen we rond de publicatiedatum van dit artikel de 'master 2013' (eigenlijk al 2012) door een 'master 2015'

Een andere wijziging is dat we zijn overgestapt van MySQL naar Percona Server. Dat is een MySQL-distributie die zich wat meer richt op prestaties en wat eerder nieuwe servertechnieken bevat. Enkele voorbeelden zijn betere I/O- en cpu-schaling, en zaken als NUMA-ondersteuning.

Onderdeel	Master 2013	Slave 2013	Master 2015*	Slave 2015
Server	IBM x3550 M4	Dell R710	HP DL360	IBM x3550 M4
CPU	2x E5-2643 (3,3GHz 4C)	2x X5660 (2,8GHz 6C)	2x E5-2643 v3 (3,4GHz 6C)	2x E5-2643 (3,3GHz 4C)
Geheugen	16x 16GB (256GB)	12x 4GB (48GB)	16x 16GB (256GB)	16x 16GB (256GB)
OS-disks	2x 250GB SATA	2x 300GB 10k SAS	2x 80GB MLC SSD	2x 500GB SATA
Datadisks	6x 256GB MLC SSD	6x 50GB SLC SSD	6x 240GB MLC SSD	6x 240GB MLC SSD

* Deze nieuwe databaseserver is in bestelling op het moment van schrijven

Zoals je hierboven kunt zien, zijn de configuratie en opslageisen sinds 2013 nauwelijks gestegen. De servers hebben nog steeds ruim 600GB netto-opslagruimte via hun raid 10-configuraties. Op het moment van schrijven gebruikt de masterdatabase daar zo'n 300GB van. Ook het ram is met 256GB nog steeds ruim voldoende om onze belasting aan te kunnen. Uiteraard is dit nieuwe geheugen wel sneller. De nieuwe reepjes zijn ddr4-2133MHz, waar de oude nog ddr3-1600 waren.

Oude Master-database (2013). De Slave ziet er net zo uit.

De cpu's zijn volgens hetzelfde principe uitgezocht als voorheen; gegarandeerd goede singlecore-prestaties vinden we hier belangrijker dan veel cores. Voor ongeveer hetzelfde geld koop je namelijk de E5-2670 v3 met 12x 2,3GHz. Vergeleken met de vorige servers krijgt de nieuwe overigens alsnog vier extra cores. Wat de variatie in OS-disks betreft, hebben we bij de nieuwste drie servers domweg gevraagd om 'de goedkoopste disks, liefst ssd', die de specifieke leverancier op dat moment aanbood. Snelle(re) disks zijn niet nodig; ze hebben nauwelijks invloed op de starttijd, omdat die wordt gedomineerd door de tijd die het bios nodig heeft voor allerlei tests. Voor de andere schrijf- en leesacties van het besturingssysteem volstaat vrijwel elke harde schijf.

De nieuwe master is ook gelijk van een andere hardwareleverancier. Ons moederbedrijf koopt al jaren alle servers bij HP, dus we hebben gekeken of we konden meeprofiteren van de schaalgrootte daarvan. Dat bleek het geval, dus de keus voor een andere leverancier was snel gemaakt

NoSQL en Search

De NoSQL- en search-servers hebben we halverwege 2015 vervangen door vier nieuwe servers. We hebben de onderlinge verschillen opgeheven, omdat die weinig meerwaarde boden. De verschillen met de oude modellen zijn vrij groot.

Er is veel minder opslagcapaciteit, maar alles staat nu wel op ssd's. De reden hiervoor is dat we niet zoveel ruimte nodig hadden. Door over te stappen op Lucene ging de benodigde schijfruimte voor onze zoekdatabase voor het forum van tientallen gigabytes naar 'slechts' 14GB. Voor MongoDB gold iets soortgelijks, ook daar was de benodigde capaciteit veel kleiner dan de 900GB. Omdat er relatief weinig zoekopdrachten tegelijk worden uitgevoerd, hebben we dit keer cpu's gekozen met wat minder cores, die per core wel sneller zijn. Het verschil in kloksnelheid wordt uiteraard ook hier versterkt door de drie generaties die ertussen zitten.

Onderdeel	NoSQL 2013	Search 2013	NoSQL 2015	Search 2015
Server	2x IBM x3550 M3	2x IBM x3550 M3	2x IBM x3550 M5	2x IBM x3550 M5
CPU	2x E5645 (2,4GHz 6C)	2x E5645 (2,4GHz 6C)	2x E5-2623 v3 (3GHz 4C)	2x E5-2623 v3 (3GHz 4C)
Geheugen	12x 4GB (48GB)	12x 4GB (48GB)	4x 16GB (64GB)	4x 16GB (64GB)
OS-disks		2x 146GB 10k SAS
Datadisks	2x 900GB 10k SAS	2x 900GB 10k SAS	2x 120GB MLC SSD	2x 120GB MLC SSD
SSD-accelerator	1x 50GB SLC	2x 50GB SLC

Search-server, NoSQL-server ziet er hetzelfde uit

Opslag

De opslagoplossing heeft de grootste verandering doorgemaakt. We hebben de server met OpenSolaris vervangen door twee Oracle ZFS-appliances. Deze zijn een stuk eenvoudiger te beheren en boden zelfs een wat ruimere featureset dan onze oude oplossing. Hoewel de hardware wellicht nauwelijks een vooruitgang lijkt, zijn ze ruim snel genoeg voor onze toepassingen. We hebben hiermee overigens niet alleen onze nfs-opslag vervangen, maar ook onze Dell MD3200i iscsi-opslag. De vm-images stonden voorheen op de iscsi-opslag en nu, afhankelijk van de vraag of ze gedeeld moeten kunnen worden, op de lokale disks van de vm-hosts of op de nieuwe nas.

Back-upserver (boven) en storage-appliance (onder)

Onderdeel	NAS 2013	SAN 2013	Backup 2013	NAS 2015	Backup 2015
Server	Sun x4270 met OpenSolaris	Dell MD3200i	Dell R510 met Nexenta Core	2x Oracle ZFS 7120	IBM x3630 M4
CPU	2x E5520 (2,26GHz 4C)	2x iSCSI controller	2x E5620 (2,4GHz 4C)	1x E5620 (2,4GHz 4C)	2x E5-2407 (2,2GHz 4C)
Geheugen	6x 4GB (24GB)	2GB/controller	6x 4GB (24GB)	64GB	4x 16GB (64GB)
OS-disks	2x 146GB 10k SAS		2x 146GB 10k SAS		2x 64GB SSD
Datadisks	10x 500GB SATA	12x 1TB SAS	12x 2TB SATA	11x 3TB SATA	12x 4TB SATA
SSD-accelerator	2x 80GB (read) 2x 32GB (write)			73GB (write)

De back-upserver is vervangen door een met meer opslagcapaciteit, maar minder krachtige cpu's. Snelle cpu's waren niet meer nodig, omdat onder andere de 'replicatie' vanaf ZFS niet meer op deze machine hoefde te gebeuren. Binnen ons budget gaven we daarom liever wat meer uit aan extra opslagcapaciteit dan aan extra rekenkracht. De huidige cpu's zijn nog altijd ruim voldoende voor het verzamelen (en maken) van back-ups van onze databases en de nas. Verder verzamelt en bewaart deze server de logs van diverse servers, waaronder de 'access logs' van onze webservers.

Overige servers

Naast alle servers uit de pagina's hiervoor hebben we nog allerlei hardware voor taken waar je als bezoeker niet direct mee te maken hebt. Toch zijn ze vaak van cruciaal belang, waardoor we ook hiervoor meestal bare metal servers gebruiken.

Taak	Mail		Management		Development
Jaar	2013	2015	2013	2015	2013	2015
Server	Dell R610	IBM x3550 M4	2x Dell R310	2x IBM x3550 M4	IBM x3550 M3	IBM x3550 M5
CPU	2x X5570 (2,93GHz 4C)	2x E5-2620 v2 (2,1GHz 6C)	Xeon X3440 (2,53GHz 4C)	1x E5-2420 v2 (2,2GHz 6C)	2x E5654 (2,4GHz 6C)	2x E5-2630 v3 (2,4GHz 8C)
Geheugen	6x4GB (24GB)	2x16GB (32GB)	2x2GB (4GB)	4x 8GB (32GB)	18x8GB (144GB)	8x 16GB (128GB)
OS-disks	2x 300GB 10k SAS	2x 64GB MLC SSD	2x 160GB SATA	1x 1TB SATA
Data-disks	4x 50GB SLC SSD	2x 240GB MLC SSD			6x 900GB 10k SAS 2x 50GB SLC SSD	4x 1TB MLC SSD

Mailserver

De mailserver verstuurt bij ons de uitgaande mail, zoals registratiemailtjes, mails voor notificaties en de dagelijkse nieuwsbrief. Daarnaast verzorgt hij de imapboxen voor @tweakers.net-accounts.

De vorige mailserver was eigenlijk een noodoplossing. We hadden aangenomen dat dit werk ook prima door een virtual machine gedaan moest kunnen worden. In werkelijkheid werd de toegang tot de mailboxen, door alle I/O, uiteindelijk behoorlijk traag, zeker op het moment waarop de dagelijkse nieuwsbrieven werden verzonden. Daarom hebben we destijds onze voormalige searchserver ingezet als mailserver, om toch weer bare metal te hebben en (vooral) toegang te krijgen tot snelle (ssd-)storage. In de vervangronde erna hebben we weer gekozen voor bare metal. De nieuwe server hoefde uiteraard niet van hetzelfde databasekaliber te zijn als de oude; we hebben daarom eenvoudigere cpu's en 'normale' ssd's uitgezocht. De nieuwe ssd's hebben uiteraard wel veel meer capaciteit

Managementservers

Onze twee managementservers verzorgen alle interne coördinatie, zoals dhcp, dns, puppet, ntp, monitoring en nog veel meer. De oude servers hadden daarvoor te weinig geheugen en de opslagruimte bleek ook aan de krappe kant te zijn. Met de nieuwe modellen hebben we dat gecorrigeerd.

Managementserver

Developmentserver

Om te controleren of aanpassingen in de code van Tweakers goed werken, hebben we zogeheten test- en acceptatieomgevingen nodig. Het liefst doe je dat met een kopie van je productieomgeving, maar om daarvoor nou vijftien of meer extra servers en bijpassende infrastructuur aan te schaffen, vonden we wat te veel van het goede…

We hebben het veel goedkoper opgelost door één dedicated server te plaatsen en die met virtual machines en docker-instances uiteindelijk dezelfde scheiding van verantwoordelijkheden te laten simuleren. Dat leidt uiteraard tot wat verschil in de prestatiekarakteristieken. De productieomgeving is echter op vrijwel alle vlakken (veel) sneller, waardoor eventuele verschillen na een 'release' hooguit voordelig uitvallen. Om een voorbeeld te geven, migratiescripts om gegevens in de database aan te passen zijn op de productiedatabase vaak dertig tot vijftig procent sneller dan op deze server.

Ontwikkelserver

Naast deze acceptatieomgeving hebben we in ons kantoor nog enkele servers hangen waarmee we diverse ontwikkel- en testomgevingen in leven houden. Dit zijn veelal afgeschreven servers, die hiermee een tweede leven krijgen. Zo zal de MySQL Master 2013 van de vorige pagina zijn leven waarschijnlijk nog enkele jaren voortzetten als database voor onze ontwikkelomgeving.

Toekomstplannen

Normaal gesproken komt er op dit soort artikelen veel feedback. Jullie overladen ons met vragen, tips en eigen ervaringen. Die feedback is voor zowel ons als de medetweakers interessant en we steken er ook nog wat van op. De feedback dwingt ons om na te denken over onze huidige oplossingen, geeft inzichten in hoe we die beter kunnen inzetten en opent onze ogen voor alternatieven.

Helaas kunnen we er in de praktijk niet altijd wat mee. De besproken hardware en software zijn over het algemeen al daadwerkelijk in gebruik. 'Even' iets anders kopen of installeren is op zijn minst onpraktisch en soms te kostbaar. Dat is natuurlijk extra jammer als blijkt dat jullie alternatieve oplossingen noemen die beter en/of goedkoper zijn. Dat soort tips krijgen we liever vóórdat we een keuze maken

We gaan binnenkort ook hardware en software vervangen. Voor die zaken komt de feedback dan natuurlijk juist nu op het goede moment. Daarom geven we jullie een vooruitblik op wat we in 2016 van plan zijn.

Loadbalancers

Het eerste project wordt het plaatsen van nieuwe loadbalancers. Op dit moment gebruiken we daarvoor drie adc's in een active-passive paar op de primaire locatie en een enkele op de uitwijklocatie.

Van boven naar beneden: 10Gbit-switch, firewall en loadbalancer

Er komt veel kijken bij de selectie van loadbalancers, omdat er allerlei functies bestaan die interessant kunnen zijn. We beschrijven hieronder de zaken waar we naar kijken, om zo ook een kijkje in de keuken te geven. Het is overigens een lastig proces door de vele variabelen

Mogelijke varianten

De eerste keuze zit in het type platform. Er kan ruwweg gekozen worden tussen een hardware-appliance, een virtuele appliance en losse, zelf gekozen software.

• Hardware-adc's
• Virtuele adc's
• Losse software

Hardware-adc's hebben als voordeel dat de apparatuur en software van dezelfde leverancier komen en daardoor goed op elkaar zijn ingespeeld. De software integreert bovendien alle functies in een centrale beheer- en gebruikservaring, en er wordt ondersteuning op het geheel van hard- en software geboden.

Als nadeel is er onder andere de prijs. In verhouding tot wat je uitgeeft, zijn de hardwarecomponenten meestal niet erg snel en zelfs redundante voedingen zijn niet standaard. Een ander nadeel is dat ondersteuning op een gegeven moment zal worden stilgelegd. Als je dan toch nieuwe functionaliteit of ondersteuning wil, zal er een nieuwe investering moeten volgen. Ook als de soft- of hardware in principe nog voldoet.

Er zijn ook allerlei 'virtuele' adc's verkrijgbaar. Deze variant heeft natuurlijk ook voordelen. De hardware kunnen we zelf inkopen en op maat maken. Ook kunnen we dan de hardware en software onafhankelijk van elkaar vervangen of upgraden. Door toch een totaalpakket te nemen, blijven de voordelen van de software bestaan (geïntegreerd, gui, e.a.)

De nadelen omvatten onder andere de prijs. De prijs van virtuele adc's is meestal gerelateerd aan de benodigde bandbreedte en komt soms dicht in de buurt van die van de hardwareversies. Verder introduceer je met virtuele machines extra (kans op) latency in een toepassing waarin je dat niet wil.

Naast totaalpakketten kunnen we een eigen Linux-installatie voorzien van software die soortgelijke functionaliteit biedt. De voordelen hiervan zijn onder andere dat dit de goedkoopste oplossing zal zijn. De software is vaak zelfs gratis. Ook kun je zelf kiezen aan welke functionaliteit je speciale aandacht besteedt en of je bijvoorbeeld een bepaalde functie, zoals caching, naar een dedicated server verhuist.

Nadelen zijn er ook; We moeten zelf alles met elkaar combineren en verbinden. Het is lastiger te achterhalen waar het fout gaat. Ook zullen de eventuele gui's minder compleet en/of informatief zijn.

We hebben nog geen keuze gemaakt uit de drie opties en horen graag jullie mening hierover. We hebben uiteraard nog wel wat eisen en wensen daarbij, waar we ook rekening mee moeten houden.

• Eisen en wensen
• Must have
• Should have
• Nice to have

Er is een aantal functies die we nodig vinden in een loadbalancer. Verder zijn er functies die niet strikt noodzakelijk zijn, danwel leuk zijn om erbij te krijgen. We werken daarom zelf met drie losse lijstjes, voor de selectie van nieuwe loadbalancers.

Als je die lijstjes interessant vindt, kun je ze in de tabjes hiernaast bekijken.

Robuuste en transparante werking (always on)

Als een webserver uitvalt of weer terugkomt, moet dat automatisch herkend worden en op de achtergrond gebeuren. Ook voor andere (eenvoudige) configuratiewijzigingen mag er geen noemenswaardige downtime zijn.

Multipool/last resort

Zoals je kunt lezen bij de webservers hebben we op dit moment twee pools van servers. Als geen enkele server van de eerste pool nog reageert, wordt de tweede ingezet. En als ook dat niet meer lukt, word je door onze loadbalancers geredirect naar error.tweakers.net. Dan krijg je in ieder geval een bevestiging dat het aan ons ligt in plaats van aan jouw verbinding

Automatische fail-over/fail-back

In onze hoofdlocatie willen we (minimaal) twee adc's plaatsen. Deze hoeven niet per se in active-active-modus te draaien, maar moeten wel automatisch elkaars werk kunnen ovenemen.

10Gbit-aansluitingen

We hebben een redundante 10Gbit-verbinding en 10Gbit-switches, dus het is wel zo handig als we de adc's daar direct op aan kunnen sluiten. In de praktijk komt het gros van het verkeer via de videostreaming, waardoor de adc's niet per se ook die 10Gbit hoeven te kunnen verwerken.

Global server load balancing

Hiermee zorgen we ervoor dat jullie automatisch naar de uitwijklocatie worden gestuurd. Het werkt door dns-responses voor 'tweakers.net', afhankelijk van de belasting, te beantwoorden met een van twee ip's.

Ssl-offload

Op dit moment gebruiken we Varnish voor caching van data. Varnish werkt goed, maar kan niet overweg met ssl. We kunnen uiteraard Varnish vervangen of een extra proxy voor Varnish zetten, maar ssl-termination op de adc zou dit ook oplossen.

Http/2

De browserondersteuning voor http/2 is al behoorlijk ver. Daarom is het ook handig als de adc dat al ondersteunt of in ieder geval bij de makers in beeld is.

Ipv4 naar ipv6/ipv6 naar ipv4

Op dit moment is onze ipv6-implementatie nog niet compleet. Het kan daarom nuttig zijn als een adc het inkomende ipv6-verkeer kan omzetten in ipv4.

Scripting/api

Soms wil je meer dan de standaardfunctionaliteit en dan is een ingebouwde scriptingtaal en/of api erg nuttig.

Support/documentatie

Zonder documentatie kom je nergens en als het dan nog niet lukt, is iemand anders kunnen vragen hoe iets moet ook wel handig.

'Layer 7'-loadbalancing

Soms is het handig om aan de hand van de inhoud van requests keuzes te maken. Het inspecteren van requests wordt meestal L7-loadbalancing genoemd.

Direct server return

Voor video-streaming is het handig als de loadbalancer een server uitkiest en als daarna de streaming-server zélf reageert op de request, in plaats van het naar de loadbalancer terug te sturen. Daarvoor is dsr bedoeld.

Caching

We gebruiken Varnish voor 'reverse proxy'-caching. Als de adc dat beter kan of meer functionaliteit erbij biedt, kan dat interessant zijn om in te zetten.

Web application firewall

Voor de beveiliging kunnen waf-functies nuttig zijn. We zijn er overigens op dit moment nog niet van overtuigd dat dat gaat werken op Tweakers, al is het alleen maar omdat je voorbeeldscripts wil kunnen plaatsen in een programmeertopic

Het kan natuurlijk zijn dat we in de bovenstaande lijsten nog dingen vergeten zijn of aannemen dat het standaard op adc-platforms zit; denk aan tcp-multiplexing en syn-flood-bescherming. Dan horen we dat graag van jullie in de reacties onder dit artikel. Uiteraard horen we in elk geval graag jullie ervaringen, tips en feedback, ook als je denkt dat we genoeg zouden moeten hebben aan een oplossing die niet aan alle bovenstaande wensen en eisen voldoet

Centrale opslag

Na onze loadbalancers is de centrale opslag aan de beurt. Zoals beschreven gebruiken we nu twee ZFS-storage-appliances. Ze werken goed, maar hebben bij ons geen automatische fail-over. Verder is er een complete analyse van de data nodig, nadat er handmatig wordt overgeschakeld. Dat is niet vaak nodig, maar betekent wel dat het urenlang in de gaten moet worden gehouden.

Naast ZFS-oplossingen zijn er allerlei object storage- en private cloud-toepassingen, zoals Ceph en GlusterFS. Dan gaat het ons vooral om de redundantie en automatische fail-over, niet om de 'oneindige' capaciteit. We verwachten dat de gebruikte capaciteit voorlopig onder de 30TB blijft. Onze huidige 2U back-upserver biedt dat al.

Ook hiervoor kijken we naar allerlei aspecten.

• Eisen en wensen
• Must have
• Should have
• Nice to have

Net als bij de loadbalancers zijn er allerlei functies die we per se willen of waarvan we verwachten dat ze nuttig zijn. Ook die hebben we in losse tabjes gestopt, voor als je ze interessant vindt

Betrouwbaar

Een opslagplatform moet natuurlijk betrouwbaar zijn, bestanden moeten daadwerkelijk op permante opslag staan als het filesystem dat beweert. Overigens mogen thumbnails wel 'wegrotten', zolang ze dan maar als geheel worden verwijderd.

Ondersteuning voor veel (kleine) files

We hebben veel kleine bestanden, vooral (thumbnails van) afbeeldingen. Met veel bedoelen we een paar miljoen; we zijn geen Google of Facebook Als we een directory met dergelijke bestanden verwijderen, moet het platform dat natuurlijk ook aankunnen.

Ondersteuning voor grote files en vm-images

We bewaren ook grote files zoals video's en vm-images. Video's worden alleen geschreven en niet meer aangepast, maar bij vm-images worden juist kleine stukjes van de bestanden veranderd.

Replicatie/redundantie

Er moet een vorm van replicatie en redundantie beschikbaar zijn, idealiter met automatische fail-over waar we niets van merken.

Back-ups

Het moet mogelijk zijn om back-ups van delen van het filesystem te maken. Liefst is het ook mogelijk om incrementele back-ups te maken, bijvoorbeeld door het verschil tussen twee snapshots op te vragen.

Posix/nfs

Een migratie van Posix (via nfs) naar 'iets anders', bijvoorbeeld object storage, zal tijd kosten en voor sommige bestanden, zoals cli-scripts, niet zomaar kunnen. Daarom is ondersteuning voor Posix handig. Dat mag eventueel ook met een losse nfs-server, maar we hebben dat het liefst net zo betrouwbaar en redundant als de rest.

Snapshots

Met de hoeveelheid bestanden die we hebben, is het lastig om (vaak) back-ups te maken, snapshots kunnen helpen om fouten te herstellen. We willen er het liefst een paar per dag, week en maand hebben. Idealiter kan het aanmaken en verwijderen van snapshots automatisch worden gedaan.

Always on/uitbreidbaar

Hardware gaat zo nu en dan stuk en software krijgt updates. Beide willen we liefst zonder merkbare gevolgen kunnen vervangen. Ook is het handig als de capaciteit gaandeweg uitgebreid kan worden, mocht onze schatting toch niet kloppen.

Geolocatie

We slaan bestanden op twee locaties op. Idealiter houdt het platform daar rekening mee, liefst zo dat servers op locatie A ook vooral met de nodes van locatie A communiceren.

Prestaties

Door caching op webservers wordt het bestandssystem relatief weinig gebruikt, maar voor alle cache misses willen we wel een snelle reactie. Ook moet het uploaden of wijzigen van bestanden niet te lang duren.

Deduplication

Bij afbeeldingen en andere bestanden komen duplicaten voor. Deduplicatie kan daarom helpen om ruimte te besparen.

Compressie

Hoewel we vooral afbeeldingen en video's plaatsen, kan het ons toch wat ruimte besparen als we, voor delen van het systeem, kunnen aangeven dat de bestanden gecomprimeerd mogen worden.

Multi-level storage/ssd-caching

We hebben bestanden die vaak worden opgevraagd en bestanden die nauwelijks worden opgevraagd. Hoewel die eerste al in Varnish zullen worden gecached, kan het toch nuttig zijn om (automatisch) de meestgebruikte typen bestanden op ssd's te plaatsen.

Support

We vinden het niet erg om zelf een server in te richten, maar bij dit soort complexe toepassingen zijn goede documentatie en de mogelijkheid tot ondersteuning wel prettige bijkomstigheden.

Bovenstaande eisen en wensen zijn afgeleid van wat we nu met ZFS doen en sterk beïnvloed door wat Ceph zoal kan. Dat lijkt goed te voldoen aan de meeste van de eisen en wensen, en doet zelfs nog een gooi naar de nice to haves. Als de eisen en wensen onrealistisch zijn, horen we het graag. Verder lezen we natuurlijk ook hierover graag jullie ervaringen, tips en feedback onder dit artikel.

Webservers en reverse proxy

We zijn behoorlijk tevreden over onze caching reverse proxy Varnish en onze webserver Apache, maar er zijn diverse alternatieven te vinden. We weten uiteraard van het bestaan van veel ervan, maar we kunnen ze niet zo makkelijk 'even' in productie uitproberen. We maken dankbaar gebruik van allerlei krachtige functionaliteit in Varnish en Apache; dat zouden we dan moeten omzetten of soms zelfs moeten verplaatsen naar onze php-code.

Het is niet allemaal perfect. Zo kan Varnish niet overweg met https en dat biedt ook weinig hoop voor http/2.0-ondersteuning. Daarnaast krijgen we bij Apache de stabielste werking via de proces-based workers, maar dat schaalt niet goed.

Om dat soort redenen zijn we erg benieuwd naar praktijkervaringen met die mogelijke vervangers. De bekendste is waarschijnlijk Nginx. In benchmarks die we een tijd geleden deden, bleek die niet sneller te zijn. Apache+mod_php was sneller dan Nginx+php-fpm en doordat Varnish de statische content toch al voor zijn rekening neemt, is de winst van Nginx daarbij beperkt.

We horen natuurlijk graag of dat intussen beter is geworden of dat er andere, (nog) betere alternatieven bestaan.

Conclusie

In dit artikel hebben we een nieuw overzicht gegeven van de hardware die Tweakers gebruikt. De architectuur, waaronder de gebruikte software, is niet echt veranderd. Er zijn vast allerlei dingen nog niet duidelijk of niet in voldoende detail benoemd. We verwachten uiteraard dat jullie dat in de reacties kenbaar maken, zodat wij nog meer kunnen uitleggen

Op deze laatste pagina hebben we beschreven waar we het komende jaar mee aan de slag gaan. Mocht je hierover wat willen weten of juist kunnen delen, dan horen we dat heel graag. We proberen de beste keuze te maken, maar de mogelijkheden zijn legio en het is lastig om overal een goed beeld van te krijgen. Jullie ideeën, tips en praktijkervaringen zullen ons, én de medetweakers, erg van nut zijn.

Reacties (183)

[CyberThug]

Leuk artikel. Dank daarvoor. Maar het kost ook nogal wat aan investering in hardware, datacenter en daarnaast in het beheren van de servers. Is het niet efficiënter om te overwegen naar een cloud platform (Amazon of Azure) te gaan?

Die machines zijn misschien iets minder krachtig maar dan schaal je (voor de zekerheid) toch horizontaal uit?

[Reactie gewijzigd door CyberThug op 23 juli 2024 18:16]

[Kees]

Datacenter/hosting kosten ons niet zoveel (paar duizend per maand, rest is gesponsoord). Hardware krijgen wij vrij goede prijzen voor, servers moet je ook beheren als ze in de cloud draaien.

Het vervelende van de cloud zijn de prijzen. Laten we onze databaseserver nemen, die moet altijd bereikbaar zijn, moet goede performance hebben (dus genoeg geheugen om een groot gedeelte van de database in geheugen te houden) en ssd's hebben als backend om een goede write performance te hebben.

Bij AWS zouden we dan op een r3.8xlarge instance uitkomen. Als we lekker flexibel willen zijn en gewoon poer uur betalen en dichtbij willen zijn dan nemen we een instance in ierland voor $4.215 per uur. Dan komen we voor 3 jaar uit op: $110.770 dollar en 20 cent. Voor dat bedrag zouden wij elke 3 maand een hardwarematig equivalent (maar dan met veel modernere hardware zoals v3 cpus, ddr4 en recente ssd's) kunnen kopen en dan nog een paar duizend euro besparen.

Deze moet nonstop draaien dus we betalen vooruit om het goedkoop te houden. 3 jaar up front kost dan $45239 waarbij je dus net zo flexibel bent als wanneer je een hardware investering doet voor 3j. Voor dat bedrag zouden wij elke 6 maand een nieuwe hardware variant kunnen kopen (again, met up to date specs, en niet de oude zooi uit de amazon cloud).

Dus ja, leuk die cloud. Geef mij maar bare metal.

[chaoscontrol]

Jammer dat jullie dat niet goed uitgezocht hebben. De helft van je punten raakt kant noch wal en zijn typische opmerkingen van een sysadmin die niet naar de cloud wil "want daarom".

Ik weet sowieso van 1 NLse aanbieder waar jullie wensen niks vreemds zouden zijn en de prijzen niet veel duurder zouden zijn dan in eigen beheer. Om nog maar even niet over Cost of Ownership te hebben. (Onder de streep ben je nu duurder uit denk ik)

Ook zit je daar nooit met oude hardware en of specs en kun je per maand flexibel zijn.

Dus leuk ja die cloud! Alleen Azure en AWS misschien niet, maar gelukkig is de cloud wereld een stuk groter dan dat.

[Kees]

Ja, ik ben ook een typische sysadmin die niet koste wat het kost naar de cloud wil, want het is duurder, je hebt minder controle en de performance is lager. En de cloud is gewoon iemand anders z'n server. Bovendien wil je niet naar 1 cloud aanbieder, maar naar 2 vanwege de redundantie.

Verder mis je dan ook de afgeschreven hardware. Bij een cloudprovider kun je vast wel elke 3 jaar een upgrade van je platform verwachten, maar de oude hardware blijft van de cloud provider. Een van de voordelen die wij hebben is dat we die weer kunnen verkopen of zelf kunnen gebruiken als test machines, of ervoor te kiezen om ze in productie te laten draaien als ze nog voldoen met genoeg redundantie om uitval op te vangen.

Verder kopen wij servers die precies aan onze specificaties voldoen. Bijvoorbeeld een databaseserver met hele snelle (maar niet zoveel) cores en veel geheugen. Of webservers met een beetje geheugen maar vooral snelle cpu's en veel cores. Bij de meeste cloudproviders is het en-en, dus veel cores en veel geheugen waardoor je niet de optimale performance uit de servers haalt omdat cpu's met veel cores vaak relatief langzamer zijn singlethreaded.

En ik betwijfel heel erg of wij onder de streep goedkoper uit gaan zijn als wij geen concessies willen doen op het gebied van performance, flexibiliteit en redundantie.

[Reactie gewijzigd door Kees op 23 juli 2024 18:16]

[chaoscontrol]

- Redundatie kan prima bij 1 cloud aanbieder. Deze hebben over het algemeen meerder locaties.
- Performance is zeker niet lager, misschien heb je een verkeerd cloud pakket bekeken.
- De hardware die je niet kan verkopen bespaar je in aanschaf en onderhoud.
- Je kan IaaS resources prima precies volgens specificaties afnemen.
- Je hoeft zeker geen concessies te doen om goedkoper uit te zijn, dat is afhankelijk van andere keuzes.

Erg jammer dat uit je antwoord blijkt dat je geen kaas gegeten hebt van een echte cloud oplossing, maar het vooral moet hebben van jou idee van een cloud oplossing.

Ik ben echt geen cloud evangelist en heb ook geen cloud aandelen. Ben echter zelf van verstokte onsite sysadmin steeds meer open gaan staan voor cloud oplossingen. Dit is lang niet altijd de beste oplossing, maar voor een webdienst (bijna altijd) zeker wel.

Ik wil nog even toevoegen dat er genoeg redenen zijn om niet naar de cloud te gaan, maar dat zijn niet de redenen die jij nu noemt! Althans, dat hoeft tegenwoordig echt niet meer!

[Reactie gewijzigd door chaoscontrol op 23 juli 2024 18:16]

[Kees]

- Onder redundantie versta ik ook dat je blijft doordraaien als je cloudaanbieder failliet gaat, of onder een zware ddos over meerdere locaties ligt, of als iemand perongeluk hun interne netwerk plat legt door een router verkeerd te configgen. Daar zul je gewoon 2 aanbieders voor moeten hebben. Dat hebben wij nu ook, en tussen onze rack bij die twee aanbieders ligt een 20gbit dark fiber die 'van ons' is.

- Performance van cloud tov bare metal is altijd lager omdat de cloud gewoon bare metal + virtualisatielaag is. Dat performance verschil kan minimaal zijn als die virtualisatielaag goed is. Verder kun je last hebben van crosstalk, en naar wat ik hoor is de storage vaak ook een punt. Als die al lokaal is, dan weet je ook dat de server die staat te repliceren naar een andere host/opslag en dat je daardoor ook weer resources gebruikt.

- Performance in de zin van locatie; dit is dan puur amazon, maar die hebben geen datacenter in a'dam maar in ierland. Elke request zal door de snelheid van het licht al trager zijn dan een request die in amsterdam afgehandeld word. Voor 900km is die overhead 3 miliseconden. Een request op onze servers duurt gemiddeld 30ms, dat is dus 10% extra overhead. En voor een statische request is die overhead bijna 100%.

- De besparing op aanschaf en onderhoud wordt volledig tenniet gedaan door de prijs die je per maand overmaakt naar de cloudprovider (en als dat niet het geval is dan is punt 1 wel erg relevant ). Vergeet niet dat wij vrij strakke prijzen krijgen van leveranciers.

Ik ben ook zeker niet tegen een cloud oplossing, maar ik ben wel tegen een cloudoplossing 'omdat het moet' of 'omdat het hip is'. Het kan in heel veel situaties een prima alternatief zijn, of zelfs veel beter uitpakken dan bare metal, Ik gebruik al vrij veel virtualisatie voor dingen waar de genoemde eisen niet voor gelden, maar aan de echte productieservers voor tweakers.net stel ik wel zware eisen

Het grote voordeel van de cloud is flexibiliteit, de mogelijkheid om op te schalen wanneer dat nodig is, en naar beneden te schalen als het weer rustig is. De beschikbaarheid van een enkele node, of juist opzetten het opzetten als 'build to fail', verder de lage kosten vooraf (geen grote investering) en dat je alleen betaald voor wat je gebruikt.

Als ik tweakers nu zou moeten opzetten, dan zou het waarschijnlijk ook in de cloud zijn. Ik denk alleen dat, na de initiele groeiperiode van een paar jaar we het dan weer uit de cloud zouden trekken en het op bare metal zetten en daardoor grote kostenbesparingen krijgen.

[Rob Coops]

Bij het lezen van je reacties heb ik heel erg het gevoel dat je te lang voor een klein bedrijfje hebt gewerkt en echt eens zou moeten kijken naar een baan bij een bedrijf waar een extra 90 servers aanschaffen een gewoonte is in plaats van een planning van maanden. Het ik wil het allemaal zelf in de hand houden en het is eng als een ander etc... verhaal is echt niet meer van deze tijd. Hardware is een service geworden in de wereld buiten Tweakers.net. De service en up time garanties zijn zo goed dat is iets dat je zelf zeker als kleine speler simpel weg nooit zult kunnen evenaren. En dus is het vaak zeker als je een duidelijke curve hebt voor de belasting van die hardware veel al beter om simpel weg in de cloud te hosten omdat de dan betaald voor wat je gebruikt in plaats van voor de piek die je misschien wel zo af en toe zult zien.
Maar goed als je hosting gratis is is dat natuurlijk een ander verhaal.

Zo als hier onder ook gezegd simpel weg je servers 1 op 1 vergelijken met wat je in de cloud wilt hebben is precies waar het fout gaat. Het hele concept vand e cloud is anders. Hardware is een service je hebt er geen omkijken nar net zo als je geen vliegtuig koopt om op vakantie te gaan naar Spanje maar een stoeltje huurt en er op vertrouwd dat de vliegtuigmaatschappij de rest doet. Gaat dat vliegtuig stuk dan regelen zij een ander toestel en stap jij zonder dat je het door hebt gewoon in en kom je op tijd op je bestemming aan.
Bij de cloud is het net zo je koopt niet een hele database server je huurt een database, die kan dan simpel weg opgeschaald worden tot het formaat dat je nodig hebt en je betaald volgens een sleutel voor de opslag, het geheugen en de processor tijd die die database nodig heeft. Als het laat in de avond is en het verkeer inzakt zakken de kosten ook.

Het idee dat je zelf je eigen hardware moet beheren om kwaliteit te garanderen of uptime te verzekeren is onzin. Sterker nog kijkend naar de uptime van bijvoorbeeld AWS en Azure of Google Cloud dan waag ik toch ten zeerste te betwijfelen of tweakers.net een zelfde uptime voor kan laten zien jaar in jaar uit.

Maar goed met gratis hosting is het natuurlijk erg moeilijk om een goede reden te vinden met de rest van de wereld mee te gaan in de volgende stap in de computer geschiedenis en te accepteren dat de cloud simpel weg een veel betere oplossing is dan dure specialist(en) in dienst hebben om dure fragiele veel al nog voor het in gebruik is genomen verouderde hardware te onderhouden en software te installeren als je dat allemaal voor een habbekrats kan uit besteden en alleen hoeft te betalen voor het geen je gebruikt als je het gebruikt.

Wat dat betreft zou True tweakers een veel grotere service bewijzen als ze zouden aanbieden de cloud hosting voor een deel te betalen in plaats van gratis een verouderde en enigszins achterhaalde dienst gratis aan te bieden.

[Kees]

Ik ageer ook niet tegen de cloud, ik ben niet tegen de cloud, ik probeer alleen duidelijk te maken dat het voor ons niet heel veel voordelen bied en dat het zeker geen voordelen bied als je applicatie er niet voor gemaakt is en je dus grotendeels overnieuw moet beginnen.

En ja, als ik voor een groot bedrijf zou werken met een idem dito serverpark dan zou ik natuurlijk ook zoeken naar manieren om mijn kosten te verlagen en mijn leven gemakkelijker te maken. Maar dan heb je ook de mogelijkheid om eeen groot team er een jaar lang aan te laten werken terwijl wij met een relatief klein (tov de codebase) team dat er nooit doorkrijgen.

Ik krijg de indruk dat jij weer voor een groot bedrijf werkt waar 90 servers aanschaffen de gewoonste zaak van de wereld is en waar een groot team van duur betaalde specialisten rondliep. Dan zou ik ook naar alternatieven kijken. Maar ik werk bij een klein bedrijf, met een idem ditto website die maar 2 miljard requests per maand afhandeld met niet al teveel hardware. Dan kun je wel heel hard roepen dat onze manier verouderd is maar dat maakt het nog niet waar. Wel voor het grote bedrijf, maar voor ons is de cloud geen verbetering

Verder nog een punt, de load op tweakers is vrij constant, dus afschalen kan eigenlijk maar voor 25% van de tijd en de rest zal je 'gemiddeld' draaien of meer moeten inzitten bij pieken.

En qua uptime. Met een korte zoekopdracht vond ik dit nieuwsbericht:
http://www.networkworld.c...est-uptime-last-year.html

Daar worden wat getallen in genoemd voor 2014:
Azure: 39.77 uur downtime
Rackspace: 7.52 uur downtime
Google CP: 4.46 uur downtime
Joyent: 2.6 uur downtime
AWS: 2.41 uur downtime

Mischien hebben wij geluk gehad tot nu toe, maar voor dit jaar:
Tweakers: 1.46 uur downtime. (gemeten door een externe partij vanaf 3 locaties)

[Reactie gewijzigd door Kees op 23 juli 2024 18:16]

[tunnelforce1]

Wat is het probleem als een site als Tweakers 40 uur downtime zou hebben in een jaar ??

Het is toch geen levensreddende site ofzo ?
Laten we het belang van Tweakers nou niet overdrijven.

Ik ben fan van tweakers maar ik zou het erger vinden als bijvoorbeeld Foxsports-app het niet doet als het zondagmiddag is.

[trogdor]

Site down = geen inkomsten.

En trouwens, ik weet niet of ik de dag wel zou doorkomen zonder tweakers...

[Reactie gewijzigd door trogdor op 23 juli 2024 18:16]

[007Nightfire]

Ben ik met je eens.
Echter als een andere aanpak niet goedkoper is en je er zelfs meer downtime voor terug krijgt, dan is de downtime wel een argument om geen gebruik te maken van de genoemde alternatieve services.
Over de prijzen zijn ze volgens mij nog niet helemaal uit, maar daar houd ik me verre van

[chaoscontrol]

Ik snap je punten! Ik wil alleen aangeven dat sommige van die punten dus geen probleem zijn en een gedegen onderzoek dat misschien had laten blijken. Ik weet ook niet of het verstandig is voor Tweakers om naar de cloud te gaan, dat weet jij beter denk ik. Het volgende wil ik er nog even over kwijt;

- Redundantie, een voorbeeld welke ik in mijn hoofd heb heeft om dataverlies bij faillissement te voorkomen een aparte BV opgezet welke eigenaar is van de data. Hoe het precies zit weet ik niet maar onze legal afdeling ging er mee akkoord, dus dat zal wel een solide constructie zijn. Dat is maar een enkel voorbeeld, kan mij niet voorstellen dat andere partijen hier niet aan denken. (Al is die angst bij een club als MS of Amazon natuurlijk een stuk kleiner/niet bestaand.)

- Performance, virtualisatie. Als je hier bepaalde eisen in hebt kan daar vast aan voldaan worden. Je kan bijvoorbeeld rekening houden met de performance hit van virtualisatie en hier een overhead voor nemen. Ook IO is geen probleem. We hebben het niet over een VPS o.i.d. maar een dedicated datastore met afgesproken/overeengekomen IOPS. Ook hier kun je het zo gek maken als je zelf wilt!

- Performance, locatie. Ik heb naar beide datacenters (waar mijn systemen hangen) een ping van 6ms. Ook is onze data enkel in NL beschikbaar en valt dus alleen onder de Nederlandse wet. (Ook een goede reden waarom mensen niet naar AWS of Azure willen.)

Nogmaals ik kan niet in jullie systemen, toekomst plannen en financiele administratie kijken, maar bij sommige zaken zie je beren op de weg.

[Aikon]

Het punt van redundantie los je niet op met een BV. Van wie de data technisch is doet er niet toe als deze onbereikbaar zijn. Kees bedoeld dat als je bij één cloudhoster zit je afhankelijk bent van deze ene cloudhoster. Als deze failliet gaat of down is houdt het gewoon op. En dus heb je een tweede cloudhoster nodig, want natuurlijk nooit een kostenefficiënt iets is.
Óf een tweede cloudhoster nodig is, is afhankelijk van de situatie. Ik kan me voorstellen dat je ook een goed noodplan kan maken zodat je snel kan overstappen naar een andere cloudhoster, maar dan heb je alsnog een goede backup nodig lokaal...

Persoonlijk heb ik ook een voorkeur om niet in de cloud te gaan, als je de kennis in huis hebt om alles zelf in beheer te hebben. Overigens is deze kennis ook niet gratis, en dat moet je ook meenemen in je kostenplaatje.

[thegve]

Wij, een kleine MKB hoster, zijn op mijn advies wel alles naar de cloud aan het outsourcen.
Onze eigen infra is gedateerd, en zou gemoderniseerd moeten worden. Als je dan wilt voldoen aan plaatjes zoals je tegenwoordig moet kunnen leveren, en jullie hierboven schetsen, ben je zo maar 75-100K verder voor wat onze klanten allemaal vragen, en dan heb je alleen nog maar een hoop ijzer. Dan heb je nog erg veel kennis nodig van erg veel verschillende elementen. Veel tijd om alles te installeren en onderhouden.
De cloud hosting partij waar wij nu mee werken is een Nederlands bedrijf, ik heb hun architectuur opgevraagd en dat zat dusdanig goed + A-merk in elkaar dat wij daar alleen maar van kunnen dromen om dat zelf te hebben, en dat tegen prijzen die voor ons niet uit kunnen.
Ik denk dat outsourcen/cloud vooral voordelen bied als virtualisatie op zichzelf ook al voordelen bied, en dat zie ik met name als je niet dusdanig veel power nodig hebt dat je een fysieke server echt aan het werk kan zetten, en dat is met moderne server-hardware een redelijke uitdaging als je geen Tweakers bent. De server die Kees hierboven noemt heeft 244GB ram, lijkt me logisch dat je daar geen cloud-voordelen bij krijgt.
Ik heb trouwens Amazon ook bekeken toen wij aan het zoeken waren, maar die is vrij goed in het opzetten van een prijsmodel dat erg goedkoop lijkt, maar in ieder geval toen ik mijn eisen daar in zetten, toch vrij duur er uit kwam.
En ik heb een slecht voorgevoel qua service. Als ik een 'uitdaging' heb op hosting gebied kan ik nu mijn hoster even bellen en even babbelen met een engineer van hun, zo'n informeel en snel advies kan je denk ik bij Amazon wel vergeten.

[Leknaas]

De cloud vind ik vooral ideaal voor statische bestanden. Google Cloud Storage heeft mijn voorkeur boven Amazon. En de kosten zijn laag. De keuze om met de servers niet de cloud in te gaan snap ik zeker. Vooral als een groot deel gesponsord wordt.

[BugBoy]

Bovendien wil je niet naar 1 cloud aanbieder, maar naar 2 vanwege de redundantie.

En toen haakte ik af. Dan heb je de cloud inderdaad niet begrepen... AWS heeft meerdere availability zones per regio, dus dat is geen probleem. Bij Azure is dat ook het geval. En dacht je dat AWS/Azure failliet gaan? Dan heeft de wereld een bijzonder groot probleem. Die twee zullen op zo'n moment gewoon door de overheid in de lucht worden gehouden. Je wilt niet weten wat er op deze twee diensten draait.

Ik wil zeker niet zeggen dat de cloud (Azure, AWS, ...) voor iedereen de juiste keuze is. Voor sommige oplossingen is het geweldig en soms is het onhandig of te duur. Je geeft aan dat je nu flexibeler bent, maar dat geloof ik niet. Hardware die je nu koopt moet je 3 jaar mee doen, dus hoezo flexibeler? Het enige waar je flexibeler in bent is in de keuze van de hardware. Maar of je daarmee het verschil gaat maken? Ik vraag het me af...

Als bandbreedte al vrijwel gratis is en ook de rest krijg je deels vergoed, dan wil ik wel geloven dat jullie nu goedkoper uit zijn en dat de AWS/Azure voor jullie duurder uitpakken.

Azure zit ook in Nederland (Amsterdam) en AWS heeft al een tijd een regio in Frankfurt. Ook heeft AWS een edge region voor CloudFront (CDN) in Amsterdam, dus voor statische content heb je al geen vertragingen.

Je gaat hier alleen wel heel erg op de kosten van alleen ijzer zitten. Als je AWS/Azure ziet als vervanging van ijzer, dan zal het vrijwel altijd duurder zijn. Vergeet alleen ook niet service contracten, energiekosten (voor jullie dan niet), serverruimte, airco, ... mee te rekenen als je gaat vergelijken met eigen servers

Cloud oplossingen kunnen je TCO verlagen, omdat SaaS oplossingen veel werk en kosten uit handen kunnen nemen. AWS S3 garandeert 99.999999999% durability. Dat ga je zelf niet redden met een eigen oplossing of tegen extreem hoge kosten.

Daarbij kun je ook je load schalen naar bezoek. Tweakers zal 's nachts veel minder load hebben, dus dan kun je servers afschakelen en/of je database throughput verlagen. Dat kan flink in de kosten schelen.

Ook het uitrollen van een nieuwe release is veel praktischer. Wij jagen een volledige nieuwe stack in de lucht met daarop de nieuwe release. De DNS wijst naar die nieuwe stack. Als het niet werkt, dan klapt die weer net zo snel om naar de oude servers. Als het goed blijkt te werken, dan gaan de oude servers uit. Dat is met eigen ijzer niet te doen, omdat je tijdelijk twee keer zoveel nodig hebt.

Een virtualisatielaag is inderdaad extra overhead. Die wordt wel steeds minder, vanwege hardware support voor virtualisatie. Maar zolang jullie nog vasthouden aan PHP denk ik dat je op andere vlakken wel wat winst kunt halen m.b.t. performance

Nogmaals... Het is niet voor iedereen de juiste keuze, maar het biedt vaak wel lage initiële kosten waarbij hardware kosten niet je groei beperken. Maar ook grote partijen (Dropbox, Netflix, Spotify, ...) draaien allemaal in AWS. Die zijn toch wel een paar tandjes groter dan Tweakers en daar kan het schijnbaar toch uit. Die clubs moeten ook wereldwijd beschikbaar zijn, dus dat zal ook wel uitmaken.

[Bor]

En dacht je dat AWS/Azure failliet gaan? Dan heeft de wereld een bijzonder groot probleem. Die twee zullen op zo'n moment gewoon door de overheid in de lucht worden gehouden.

Dat kun je echt niet zo duidelijk stellen hoor. Cloud aanbieders zijn commerciele bedrijven die doorgaans ook failliet kunnen gaan zonder dat een overheid deze in de lucht zal houden. Er is geen enkele aanwijzing of reden dat een overheid een commerciele instelling zal ondersteunen. Dat is economisch gezien ook geen goed idee. Als een cloud provider failliet gaat zitten de gebruikers met de gebakken peren. Dat is een scenario waar je altijd rekening mee moet houden.

[BugBoy]

Volgens mij was ABN AMRO ook een commerciële partij en daar hebben we allemaal stevig aan meebetaalt. Als AWS omvalt, dan vallen een hele boel zaken om. De wereld draait wel door zonder Netflix en Spotify, maar het wordt al heel wat vervelender dat ook Dropbox plat gaat en niemand meer bij zijn bestanden kan. Dat is voornamelijk consumentenleed en nog te overzien.

Vervelender wordt het dat er megaveel data in S3/Glacier staat die bedrijven wettelijk moeten kunnen overleggen. Salarisadministraties die veel in AWS draaien (vanwege de maandelijkse piekbelasting) zouden plat gaan. Veel overheden (met name VS) hebben veel in AWS draaien, maar ook erg veel multinationals.

Geloof maar dat de financiële schade van een failliet AWS vele malen groter zal zijn dan het in de lucht te houden. Daarbij klopt het business model van die clubs echt wel. Als het mis gaat, dan zou dat door mismanagement komen, maar niet omdat de business zelf niet winstgevend kan zijn (op die schaal). Hetzelfde geldt ook voor Azure.

Een LeaseWeb, SoHosted, ... zouden failliet kunnen gaan, zonder ingrijpen van de overheid. Bij AWS/Azure zijn de belangen gewoon te groot. Daar zou linksom of rechtsom wat moeten gebeuren...

[Olaf van der Spek]

Maar zolang jullie nog vasthouden aan PHP denk ik dat je op andere vlakken wel wat winst kunt halen m.b.t. performance

Wat is tegenwoordig *de* taal?

[Gijs007]

Hebben jullie overwogen om Cloudflare te gebruiken als vervanging voor de statische cache?

Tweakers.net heeft dan gelijk ook een groot stuk bandbreedte besparing en DDoS bescherming.

Daarnaast maken jullie dan ook meteen gebruik van de laatste technieken zoals Ipv6 en HTTP/2.

[egeuens]

Een heleboel mensen schijnen te vergeten dat Cloud ook veel gevaren heeft (ik spreek uit ervaring).
Vb van een Cloud probleem waar niemand aan denkt (ik ook niet toen). Mijn klant wou absoluut zijn servers onderbrengen in 'the cloud'. Ik teken verzet aan maar toch ging hij in zee met een bekend Frans bedrijf. De 2 navision servers werden overgezet en verder gehost in Lille/Rijsel. Hij wou geen nieuwe server kopen om zijn 8 jaar oude te vervangen wegens te duur.

Op een zeker moment geen connectie meer, servers niet beschikbaar.
Na 2 dagen bellen en zoeken, vloeken en schreeuwen toch iemand aan de lijn gehad. Het bedrijf was failliet.
Op de vraag om onze data terug te halen werd niet gereageerd. Ik met de baas naar ginder gereden, op de deur hing een brief van de curator.
Naar de curator gegaan met de vraag om onze data terug te halen.
Antwoord van de man: data bestaat niet juridisch. De servers waren geleased en IBM had ze al teruggehaald. Data is nog steeds juridisch niet vastgelegd in de Europse wetgeving. Het is allemaal nogal vaag. Ze zijn er al een tijdje mee bezig maar soit. De curator had enkel hardware en licenties als officieel argument.

Resultaat?
ik had een extra backup gemaakt in het weekend en deze terug gezet bij de klant. Bijna 1 week werk kwijt voor 80 man, dat is pas een prijskaartje...

Ook dit is Cloud waar geen enkele marketeer over spreekt. Het is allemaal nog veel te onduidelijk, te vaag en je weet nooit waar je precies aan toe bent.

Ik geloof niet dat Amazon of Microsoft faiilliet gaan maar er is al genoeg miserie met de NSA en andere juridische zaken.
Een mogelijk doemscenario: de USA en Europa gaan massaal in conflict (is de laatste tijd ook al wat geweest rond privacy). De datacenters worden tijdelijk lam gelegd door een lawsuit... waar ben je dan?

Ander mogelijk scenario: je betaling komt niet goed aan en er is serieuse discussie over. Wie houdt de cloud provider tegen om de login tijdelijk te blokkeren?
Staat nergens in de SLA trouwens.

Je zou eens moeten vragen aan bedrijven die wel problemen hebben gehad wat ze denken over cloud. Passieve data, backups, non-kritische zaken kan je gerust plaatsen (maar hou steeds een copy bij de hand)!

Een paar jaar geleden ging idereen outsourcen naar derdewereld landen, ook daar stappen ze van af, wegens ...te duur en te complex.

Er is steeds een andere kant van de medaille. Techniek gaat supersnel vooruit maar de jurdische kant van de zaak volgt niet (wetten, ...)

Succes verder
Erwin

[Reactie gewijzigd door egeuens op 23 juli 2024 18:16]

[tijgetje57]

Performance is lager, Tuurlijk beste. Blijf dromen.

Als jij een HP rack neemt met een bladeserver met daarin een flex fabric naar een 3par SSD cabinet. Dan is je performance super hoor.

Ohw ik lees dat je IBM gebruikt. Die heeft XIV

[Reactie gewijzigd door tijgetje57 op 23 juli 2024 18:16]

[Anoniem: 5897]

Helemaal mee eens. Ik denk dat een site als Tweakers prima in AWS zou kunnen draaien (op een kosten effectieve manier). De servers 1 op 1 over willen zetten zal duur zijn, daarom worden applicaties ook opnieuw ontworpen voor de cloud als is het alleen maar om je applicatie klaar te maken voor het built-to-fail concept. Want een HD crash in AWS betekent servertje weg. Daar moet je wel op designen.
Je kan het zelfs vrij eenvoudig over 2 clouds heen plaatsen, Azure en AWS, voor redundancy.

[ACM]

En dus wordt de investering van een overstap nog groter

[Anoniem: 5897]

Met 2 clouds bedoel je? Hoeft niet per se hoor. Je kan "gewoon" active/active draaien.

Uiteindelijk kan het natuurlijk zo zijn dat het nog steeds duurder is, maar dat rekenvoorbeeldje dat Kees schetst is niet hoe het zit.
Er draaien zat grote en kleine websites in AWS, denk je dat die allemaal die bedragen neerleggen? Of dat ze naar de cloud gaan als ze er niets mee opschieten? Die voordelen zitten niet alleen in het 1 op 1 omrekenen van kosten, je moet je hele organisatie erop aanpassen en dan komen de voordelen pas echt.
Wat levert het op als je de tijd die je nu besteed aan beheer omzet in tijd voor innovatie? Dat je je processen opnieuw gaat uitvinden en zo efficienter wordt. Veel bedrijven doen dat niet, maar zo moet je wel denken wil je echt voordeel halen.

[Kees]

Het probleem nu is dat wij een enorme berg code hebben die daar niet mee om kan gaan. Nu zul je niet alles te hoeven herschrijven, maar vrij veel wel.

Let er ook op dat wij een site zijn met vrij veel onderdelen die aan elkaar hangen. De meeste grote sites zijn vaak sites met maar 1 of 2 onderdelen, dan is het vaak wat eenvoudiger. Maar wij hebben nieuws, reviews, de pricewatch, het forum, downloads, de benchdb, vraan & aanbod, video's, tweakblogs etc.

Verder hebben wij nu een vrij robuste setup die we dan ook in de cloud zouden willen repliceren (want je wil nog steeds niet alleen op bv amazon vertrouwen, want dat is dan je spof).

Wat de cloud aan beheerstijd gaat besparen is mij nog niet helemaal duidelijk. Het hardware uitzoeken en plaatsen neemt hooguit een paar dagen per jaar in beslag. De rest: installatie, configuratie, netwerkconfig, backups regelen etc zul je ook met een cloud nog steeds hebben.

[BugBoy]

Dit vind ik een zeer valide reden om niet over te stappen. Om goed gebruik te maken van de mogelijkheden van AWS/Azure, dan moet dat in je architectuur verweven zitten. Om echt de voordelen te hebben moet je daar op ontwerpen. Achteraf aanpassen is vrijwel niet te doen.

Ik verwacht dat je vooral bij de database een issue zal hebben. Waarschijnlijk zijn er heel wat tabellen die behoorlijk wat onderlinge relaties hebben. Dat is vrijwel niet te migreren naar een no-SQL oplossing, dus dan kom je uit op Aurora (uitgaande dat het nu MySQL is).

Maar ook je sysadmins moeten bijgeschoold worden. En je hebt ook een transitie periode en dat geeft ook de nodige kopzorgen. Ik zou er achteraf ook niet gauw voor kiezen.

[ACM]

Ik reageerde op deze zin: "daarom worden applicaties ook opnieuw ontworpen voor de cloud".

Dat kost misschien niet direct geld, maar onze developmentcapaciteit daarvoor inzetten zal alsnog als investering worden gezien

[Anoniem: 5897]

Eens. Dat moet je dan wel zien als een investering. Dat kan natuurlijk alsnog betekenen dat de business case negatief uitvalt...

@Kees;
Je spof vang je op door Azure en AWS tegelijk te gebruiken en eroverheen te loadbalancen (50/50 of 80/20 net hoe de prijzen zijn). Serverbeheer heb je nauwelijks, het gaat meer over code beheer. Je code wordt je grootste (is het nu ook) asset. Het deployen van je omgeving is geautomatiseerd, upscaling is geautomatiseerd, peakloads kan je makkelijk opvangen, etc.

Maar goed, het punt is natuurlijk wat je hebt omvormen naar een nieuw concept en dat is een enorme stap. Daarom zie je nieuwe bedrijven veel makkelijker starten in de cloud (Netflix, Spotify)

Ik zou alleen het niet zomaar afschrijven zonder dat je exact weet wat het je wel of niet gaat brengen. Je servers afmeten tegen de cloud prijzen is niet de manier om daar achter te komen. Dat is mijn punt eigenlijk.

[BugBoy]

Als je op AWS EC2 gaat deployen dan moet je er vanuit gaat dat die machine af en toe gerecycled wordt. Als je daar niet op rekent, dan heb je EC2 niet begrepen. Overigens heb je wel persistent storage, zodat je zo'n recycle slag wel kunt "overleven". AWS en Azure zijn niet bedoelt als VPS aanbieder. Dan zijn er altijd goedkopere leveranciers te vinden (SoHosted, LeaseWeb, ...).

Twee cloud providers is gewoonweg geen optie. Een oplossing die goed gebruik maakt van AWS of van Azure gebruikt ook de IaaS delen er van. Die zijn volstrekt niet uitwisselbaar. Ook de SaaS oplossingen zijn vaak volledig anders en deployment verschilt. Als je daar allemaal geen gebruik van maakt, dan lekker op eigen ijzer houden of naar een goedkopere VPS aanbieder gaan.

[Anoniem: 5897]

Twee providers is zeker wel een optie, laats nog gebouwd in een training namelijk. Gaat prima zolang de applicatie de HA regelt. Maar goed, het ligt er maar net aan wat je eisen zijn natuurlijk.

[BugBoy]

Ik geloof best dat je een VM uit AWS kunt laten babbelen met een VM uit Azure. Maar ik ben heel benieuwd hoe jij een VPC opzet binnen AWS en Azure, zonder twee keer over het werk te hebben. Daarbij zal een oplossing op basis van DynamoDB, Aurora of een andere provider-specifieke SaaS oplossing niet uit te rollen zijn op Azure.

[Blokker_1999]

Ik weet sowieso van 1 NLse aanbieder waar jullie wensen niks vreemds zouden zijn en de prijzen niet veel duurder zouden zijn dan in eigen beheer. Om nog maar even niet over Cost of Ownership te hebben. (Onder de streep ben je nu duurder uit denk ik)

Ook zit je daar nooit met oude hardware en of specs en kun je per maand flexibel zijn.

Dus leuk ja die cloud! Alleen Azure en AWS misschien niet, maar gelukkig is de cloud wereld een stuk groter dan dat.

Zonder een specifieke case study te doen is het onmogelijk om daar zomaar uitspraken over te doen. Het kan zijn dat het op het eerste zicht wel een voordeel kan opleveren maar als je meer in detail gaat kijken je toch weer meerkosten zult vinden die een overstap minder interessant maken.

Ik kan me niet voorstellen dat men bij Tweakers de evolutie niet opvolgt in deze markt en regelmatig een herberekening doet van wat de meer of minderkost zou zijn.

Je vergeet ook dat ze een deel van hun hosting vandaag in de vorm van sponsoring krijgen. Wil je dat meenemen dan moet je een goede lokale aanbieder vinden van clouddiensten die zich daar ook voor wil openstellen..

Cloud lijkt mij vooral interessant als je veel elasticiteit nodig hebt en lijkt mij minder interessant wanneer je dag in dag uit een gelijkwaardige belasting hebt want dan leg je een continue beslag op resources en de servers waar die op draaien moeten betaald worden door iemand. Of dat nu door jezelf in eigen beheer is of de cloud aanbieder in zijn beheer maakt weinig verschil.

[Reactie gewijzigd door Blokker_1999 op 23 juli 2024 18:16]

[chaoscontrol]

Je hebt die korting niet nodig als je onder de streep al goedkoper of even duur uit bent. Als Tweakers nu al duizenden euros per maand betaald (zie artikel) is die korting niet veel soeps, of ze zitten bij een extreem dure leverancier.

Het is ook koffiedik kijken maar als ik zo snelle vergelijking maak, is het verschil niet zo groot. Dan moeten er wel heel exotische zaken draaien om het echt niet interessant te maken.

Tweakers wil natuurlijk ook gewoon alles zelf in beheer hebben omdat het Tweakers zijn, daar kan geen prijs tegenop. Maar dan moet je niet beweren dat het zoveel duurder is.

[Blokker_1999]

As I said: wij hebben veel te weinig informatie om ook maar een inschatting te kunnen maken van wat het Tweakers zou kosten om in de cloud te gaan.

Tweakers is onderdeel van De Persgroep en moet binnen dat bedrijf ook een winstgevende entiteit zijn en blijven. Zij zullen zeker wel uitkijken naar manieren om hun kosten te drukken en hun winstgevendheid te verhogen. Of ze de hardware nu zelf in beheer hebben danwel of ze virtuele instances in de cloud beheren zal echt ondergeschikt zijn aan een mogelijks grote besparing.

[CAPSLOCK2000]

Jammer dat jullie dat niet goed uitgezocht hebben. De helft van je punten raakt kant noch wal en zijn typische opmerkingen van een sysadmin die niet naar de cloud wil "want daarom".

Ik ben ook zo'n admin die niet naar de cloud wil tenzij daar een duidelijk voordeel tegenover staat. Welke voordelen zie jij voor een site als Tweakers? Realistisch gezien, dus niet puur theoretisch als je alles vanaf de grond opnieuw mag doen maar inclusief migratie van de huidige setup.

Als je een paar developers moet inhuren om je software te herschrijven dan kan het volgens mij nooit kosteneffectief zijn, die kosten meer aan salaris dan al die hardware samen.

Misschien heb ik last van oogkleppen, dat zou niet de eerste keer zijn, maar daarom de vraag: welke voordelen zie jij?

[chaoscontrol]

Ik heb het niet over het omschrijven van bestaande applicaties en ik snap dat een migratie ook een hoop centen kost, maar uiteindelijk bespaar je op FTE. Je hebt immers minder mensen nodig om het te onderhouden, je hele hardware team valt al bijna weg. Maar ook het op en afschalen van resources tijdens drukke of rustige periode, met bijbehorend prijsplaatje.

Zoals ik in een andere post ook al zei is het koffiedik kijken, ik weet ook niet wat er allemaal bij Tweakers draait, maar afgaande op dit artikel komt het niet super bijzonder over en zou het een mooie case zijn voor de cloud.

Het hoéft niet naar de cloud, maar het kan naar de cloud en Tweakers zal zelf moeten uitzoeken of dat voordelig is. Het komt alleen over of dat onderzoek er nooit is geweest.

[thegve]

Hardware team? Zoals Kees hierboven beschrijft kost dat hooguit een paar dagen per jaar. Ik ben redelijk pro-cloud, maar de case van Tweakers leent zich hier echt niet zo best voor. Cloud betekent practisch gezien het outsourcen van je ijzer, dus een commerciele partij die je daarvoor inschakelt.
Als je dusdanig relatief statisch en groot bent als Tweakers dan geloof ik best dat dat nooit uit kan. Zoals in deze post is te lezen is de structuur grotendeels hetzelfde gebleven de laatste 3 jaar. Ze hebben dus voornamelijk even een nieuwe versie van hun bestaande server opgehaald en met Puppet ingericht. Puppet kost hier in mijn ervaring vrij veel tijd om te onderhouden, maar dat heb je in de cloud ook gewoon.

[LopendeVogel]

Ja precies, dan krijg je dus zoiets als een auto monteur die alleen wilt leasen.
Slaat toch kant noch wal vind ik persoonlijk?

Het gaat hier niet om nu.nl of de telegraaf, het gaat om tweakers.net. Dat vind ik al genoeg redenen waardoor dit niet uit handen gegeven zou moeten worden, al was het goedkoper.

Zelfde als mijn voorbeeld: een beroeps auto monteur die niet aan zijn eigen auto wilt zitten maar het wilt leasen en door andere wilt laten regelen, wat staat die beroeps monteur dan even flink voor paal ej.

Ej waarom onderhoud jij je eigen auto niet zelf? Ja is makkelijker en goedkoper door het te laten doen. Voor jou en mij: ja, voor een beroeps monteur is dat een schande.

[klakkie.57th]

Cloud Cloud Cloud.

Niet iedereen heeft "elasticity" nodig, velen ondert ons hebben een erg stabiele omgeving, die vaak net zo goed of al dan niet beter is dan welke cloudprovider dan ook.
Dingen als redundante datacenters , Dark fiber, Metroclusters doen we gewoon zelf VEEL gooedkoper.

Ieder moet de berekening gewoon zelf maken.
Ik ben het gewoon eens met Kees.

[Reactie gewijzigd door klakkie.57th op 23 juli 2024 18:16]

[BoringDay]

Waarom zou je naar de cloud moeten?
Zelf in beheer lijkt me altijd de beste keuze in plaats van alles uit te gaan besteden.

[R3m3d7]

Cloud proposities zijn voor dit soort doeleinden zelden qua prijs interessant als je het mij vraagt.
Ik heb ook meerdere keren gerekend voor klanten maar het komt niet uit als je toch de servers nog moet beheren (het OS en de applicatie vragen niet minder tijd).
Daarnaast is netwerk ontsluiting soms nog best een dingetje, heb je iets op b.v. het POWER platform nodig dan kan je helemaal nergens terecht.

Mijns inziens gaan de cloud cases meer om burst events, zoals b.v. een NPO die voor een WK hun webcapaciteit voor een aantal weken met 500% wil uitbreiden.
Ook heb ik klanten die de cloud gebruiken voor uitwijk doeleinde, dan maken de kosten ineens niet zo heel veel meer uit, niet iedereen heeft een active/active setup nodig of kan active/passive setup betalen. Dan komt de cloud om de hoek kijken waar je met je credit card in de hand binnen no time hardware uit de muur trekt.

Wij gebruiken daar dan ook geen Amazon of Microsoft voor maar Softlayer.

[Aragnut]

Er zijn wel bedrijven die POWER met AIX leveren op aanvraag, echter is tweakers.net denk ik een wat kleine partij hiervoor. Dergelijke oplossingen zijn meer voor bedrijven van wie IT niet de core business is en ze deze in zijn geheel willen uitbesteden. Bij oudere omgevingen is de hardware nog bezit van de klant, maar wordt alles door een dienstverlener beheerd. Het is dan een stuk intressanter om ook de hardware aanschaf uit te besteden en voor het hele plaatje een per maan prijs te betalen. Dan hoef je geen rekening meer te houden met afschrijvingen en ontwerp. Dit is ook een stuk intressanter in de boeken (je houdt immers geen kapitaal meer vast in de servers). Dit zijn dan IaaS (infrastucture as a service) en SaaS (software as a service) oplossingen.

Voor tweakers.net absoluut niet intressant lijkt me, ook gezien hun geschiedenis.

[Omaha2002]

Het is jammer dat IBM weinig aan marketing doet met betrekking tot Softlayer, het is het beste cloudplatform dat je in Nederland kan gebruiken.

Baremetal mixen met VM's over twee datacenters waartussen het verkeer gratis is, per uur afrekenen en dmv API's op en afschalen naar behoefte.

[lordawesome]

Wow, wat een prijzen!

Ik betaal 65 euro per maand in Nederland voor de huur van een dedicated E3-1230 3.2ghz (aka i7-2600k), 8gb ram, 2x1tb raid en 25tb traffic. Met centos en een plesk licentie voor automatische updates.

Dat was een aanbieding, maar hier zijn hun reguliere prijzen, ook laag: http://www.i3d.net/dedicated/single-socket.php

[448191]

Ik ben het met je eens, maar om andere redenen: hardware virtualisatie is inefficiënt. VMs waren toch niet meer dan een manier om hardware in geïsoleerde eenheden te delen: daar zijn nu containers momentum hebben gekregen (Docker et al) betere oplossingen voor. Zwaai zwaai hardware emulatie.

[svennd]

Het enige wat je afgeeft is controle, prijs gewijs is het zeker niet goedkoper, zeker niet als je wat meer data wil gaan opslaan.

[Niemand_Anders]

In de regel niet. De cloud is vooral handig voor startups omdat ze niet direct tienduizenden euros hoeven neer te leggen voor een serverpark en eenvoudig de capaciteit kunnen verhogen. Maar de grote cloud omgevingen zoals Azure en AWS staan niet bekend om hun performance of goedkope prijs. Voor je het weet betaal al je snel 200 tot 400 euro per server per maand.

Voor politieke partijen licht het anders. Zij kunnen in de basis een lichte server afnemen in rond verkiezingen de setup zwaarder maken om de piek van 4 of 5 maanden op te vangen. Bij Tweakers zal de 'idle' uren korter zijn dan de piek uren.

Verder kun je een cloud omgeving niet tweaken en dat zal voor tweakers.net toch echt een vereiste zijn. Daarbij heeft Tweakers al 15 servers staan en met hun huidige setup is het vrij eenvoudig om een extra server in het rack te hangen mocht dat nodig zijn..

[Rafe]

Relevante blog post van de jongens achter forumsoftware Discourse.

[johnkeates]

Amazon of Azure zijn eigenlijk nooit rendabel. Het klinkt altijd heel leuk, maar in de praktijk betekent het gewoon dat je veel betaalt voor je resources, nog steeds mensen met kennis van zaken moet hebben (en die dus niet weg kan doen) en eigenlijk een stukje minder flexibiliteit hebt.

[SA007]

Mag ik vragen wat jullie doen met 12 pdu's?

Meestal gooi je 2 PDU's per rack.

27 servers + 15 andere gear komt op 42 apparaten, verdeeld over 2 locaties.
Klinkt niet als meerdere racks voor nodig.

Of mis ik wat hier.

[Kees]

Wij hebben 3 racks, elk rack heeft 2 feeds, en er hangt teveel apparatuur in de racks om aan 12 poorten genoeg te hebben. Dus hebben we per rack 4 PDU's (2 bovenin, 2 halverwege of onderin), met 3 racks krijg je dan 12 pdu's . Bovendien is vrijwel alles redundant aangesloten, dus kom je op zo'n 80 poorten die in gebruik zijn (van de 144).

De reden dat we 2 racks op 1 locatie hebben is dat we in het verleden teveel stroom trokken voor 1 rack, dus mochten we een tweede rack vullen, met als gevolg dat beide racks halfvol zijn.

[Haribo112]

Dus er wordt daar niet genoeg stroom geleverd om een heel rack aan te kunnen sluiten?? Da's wel gek.

[Kees]

Dat kan wel, maar het stroomverbruik hangt mede af van de airco.

Voor elke ampere die een rack ingaat word een gedeelte omgezet in warmte, die warmte moet je kunnen afvoeren dus dat moet de airco aankunnen. Daarom leggen ze een limiet op aan de racks. Wij mogen maximaal 14 ampere in die racks verstoken. Dan kunnen we wel het hele rack volhangen, maar dat moet dan met low-power apparatuur. Als we een stevige server met veel disks erin in het rack hangen dan verbruikt die meer stroom en kunnen we maar een half rack vullen. Het probleem is niet de stroom (alles kan 16 of 32 amp aan) maar de warmte.

Onderhand zitten we wel weer zo laag dat we net in 1 rack zouden passen, maar dan is dat rack wel heel erg vol, en dat werkt niet heel erg lekker als je vaak dingen vervangt.

[Tribits]

Voor elke ampere die een rack ingaat word een gedeelte omgezet in warmte, die warmte moet je kunnen afvoeren dus dat moet de airco aankunnen.

Eigenlijk kan je er gemakshalve wel van uit gaan dat iedere watt die je in een rack pompt omgezet wordt in warmte. Een gedeelte wordt omgezet in kinetische energie (luchtstroming, geluid) en een gedeelte in elektromagnetische energie (licht en andere straling). Dat aandeel is echter vrij klein en wordt uiteindelijk ook weer omgezet in warmte. Zie verder http://superuser.com/a/148121

[SA007]

Ah, met kleinere pdu's heb je er snel veel nodig inderdaad.
Met 12 poorten per PDU snap ik het prima.

[CAPSLOCK2000]

Op mijn werk hebben we drie elektrische groepen en dus ook drie PDU's per rack. Die drie groepen worden aan beide kanten van het rack aangeboden. Dan zit je al op zes pdu's per rack. Dat maal twee locaties en dan kom je op 12.

Ik weet niet of ze dat doen uit efficientie of voor extra availability.

[SA007]

Dat is best fors inderdaad.
Racks die ik tot nu toe gezien heb zijn voorbereid op een full-height pdu aan beide kanten.
Meeste gear is toch single of dual feed, meer pdu's zou de availablility niet echt verbeteren lijkt me.
(Tenzij je je backup systeem op gescheiden feeds in hetzelfde rack doet, maar dat lijkt me dom, dan heb je alles redundant maar als 1 systeem uitfikt kan je alsnog je primary en backup afschrijven)
Efficientie in een datacenter op een per-rack basis lijkt me ook vreemd.

[CAPSLOCK2000]

Meeste gear is toch single of dual feed, meer pdu's zou de availablility niet echt verbeteren lijkt me.

Bij onderhoud aan het ene circuit verplaats je alle aangesloten apparatuur naar een van de twee andere circuits. Dan blijf je redundantie behouden zodat je niet alles kwijt bent als er tijdens het onderhoud iets stuk gaat.

Aan beide kanten van het rack aanbieden is vooral handig voor je kabelmanagement, nodig is het niet.

Wat betreft efficient doelde ik er op dat onze stroom als drie-phase krachtstroom binnenkomt (ik hoop dat ik het goed zeg). Misschien dat het efficienter is om dat als drie groepen aan te bieden dan als twee. Ik weet niet genoeg van electro om daar iets zinnigs over te zeggen.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 18:16]

[SA007]

Voor onderhoud een voor een server naar een andere feed schuiven lijkt me niet erg efficient, zou zelf de invoer van de pdu op een andere feed gooien, maar dat kan in een andere omgeving wellicht minder makkelijk.

Qua efficientie boeit het niet in een datacentre omgeving.
Als je een paar racks hebt is het belangrijk om te balanceren over je fases.
Als je er heel veel hebt is rack1 fase 1/2, rack 2, 2/3, rack3, 3/1, enz.
Dan boeit het weinig meer hoeveel fases je beschikbaar hebt per rack.

[klakkie.57th]

Misschien heb ik je opmerking verkeerd begrepen, maar je wilt natuurlijk wel meer dan 1 fase per rack Ieder aparaat maakt gebruik van 2 verschillende fasen liefst zelf op 2 aparte invoeren van 2 aparte leveranciers, die ieder een ander toeganspad naar je datacenter hebben.

Daarenboven Is 1 fase per rack ook helemaal niet optimaal om je fasen gelijkmatig te belasten , aangezien je in de ene rack gewoon wat actief materiaal hebt en in de de andere rack 2 blade enclosures die ieder tot 9000W kunnen verbruiken.

Multiple Power Feeds zijn een vereiste indien je praat over een Tier3 of Tier4 datacenter

[Reactie gewijzigd door klakkie.57th op 23 juli 2024 18:16]

[Kees]

Wij hadden ook een full height pdu's in het rack.. met als gevolg dat we bijna niet meer in het rack konden werken omdat die dingen gruwelijk in de weg zaten Zie ook plan: Netwerkupgrade: nieuwe Fortinet-firewalls en switches van Arista

[klakkie.57th]

Kees wij hadden/hebben dit probleem ook.
Gewoon grotere racks kopen.
Standaard rack is nu 1200mm Diep en 800MM breed. Nooit meer problemen met PDU's , en racks zijn nog altijd een heel stuk goedkopoer dan pdu's

Veel nieuwe aparatuur is sowieso al erg diep en een rack van 1000mm is dan niet meer voldoende.

[Kees]

Zoveel controle hadden wij niet over de racks, die zijn gewoon van het datacentrum en wij kunnen niet zomaar onze eigen racks plaatsen

[bento smit]

Misschien ook leuk om eens een stuk over de kantooromgeving bij Tweakers te doen. Kan ik misschien een alternatief voor thin cclients op winserver 2003r2 aan mijn baas aanbieden.

[Kees]

De kantooromgeving bij ons is niet zo spectaculair als je zou denken. We hebben een eigen vlan en een eigen dedicated lijn naar buiten voor het grootste gedeelte van het tweakers netwerk, puur omdat men ons niet op het kantoornetwerk van de persgroep wil hebben Wat wil je dan ook, iedereen is admin op zijn pc, iedereen installeert allerlei software, zoals gekke mensen met win10 nog voordat win10 officieel uit was, allerlei linux distros, macs, telefoons in alle soorten en maten etc.

Nee, ons kantoornetwerk wil je alleen hebben als iedereen op kantoor tweaker is

[jordees]

Persoonlijk vind ik dat dichtgetimmer door admins verschrikkelijk kinderachtig en erg DDR 2.0. Geef mensen de vrijheid om een eigen systeem te 'beheren', waardoor ze niet alleen vrijer, maar ook meer leren over de werking van hun gereedschap. Prima keuze van Tweakers. Wij werken op exact dezelfde wijze en hebben eigenlijk nooit problemen of hoge beheerskosten.

[walteij]

Ik ben het een heel eind met je eens. Iedereen zou verantwoordelijk moeten kunnen zijn om hun eigen systeem te kunnen 'beheren'.
Helaas is de praktijk een stuk weerbarstiger. Deze week weer een voorbeeld van iemand die een cryptolocker virus wist binnen te hengelen op zijn systeem. De persoon was niet eens admin op zijn systeem.
Makkelijkste oplossing dus maar weer, systeem imagen en backup van zijn home directory terugzetten.

Als dit soort dingen kunnen gebeuren zonder dat een 'gewone' medewerker admin (of power user) is op zijn systeem, wil je toch gewoon niet dat mensen meer rechten krijgen, met alle risico's van dien?

Vrijheid voor medewerkers op hun systeem ben ik helemaal voor, maar op het moment dat ze het verkloten (en dat gebeurd dan vaker dan je denkt), moet IT dit weer oplossen en kan de medewerker weer niet op zijn systeem werken.
Kortom: Dit kost teveel geld (zowel uren van de IT medewerker om de boel te repareren als de medewerker die niet productief is omdat hij niet op zijn systeem kan).

Ja, vanuit vrijheid en eigen verantwoordelijkheid heb je helemaal gelijk, maar vanuit een zakelijk oogpunt bekeken, beperk die vrijheid, zodat de medewerker weinig kan verprutsen op het systeem, zodat deze zo productief mogelijk kan zijn.

Maar toch, zo'n kantoornetwerk als tweakers heeft, klinkt wel lekker, maar dat kan ook echt alleen maar omdat het allemaal tweakers zijn. Die weten wat de risico's zijn als ze wat verprutsen.

[Kees]

Ik denk ook dat onze servicedesk helemaal gek zou worden als ze ons netwerk gingen dichttimmeren. Dat, of wij kunnen ons werk niet meer doen.

Een groot gedeelte van onze medewerkers heeft nu eenmaal 'prutsen met computers' in hun functieomschrijving staan, en dat werkt het beste in een (redelijk) vrij netwerk.

[Noeandee]

Ik zie niet in, wat het binnenhengelen van crypto software te maken heeft met local admin rechten.. Tegenwoordig zie je steeds meer RDS / VDI achtige omgevingen waar je totaal geen local admin rechten wil uitdelen. Al je apps worden virtueel aangeboden en normale medewerkers hebben het daarmee gewoon te doen.

En daarnaast denk ik niet dat mensen die zichzelf kwalificeren als tweaker local admin rechten zouden moeten hebben. Dat zijn meestal juist de mensen, die je dat niet wil moeten geven, die gaan doodleuk hobbyen in hun bedrijfsomgeving

Als niet-it medewerker binnen een bedrijf, heb je gewoon je eigen kantoorsoftware tot je beschikking en hoor je geen systeem te 'beheren'.

[Marientjuh]

Totdat je in een situatie komt waar de gebruikers alleen een trucje kunnen en niet lezen op een computer. Dan ben je heel erg blij dat je de boel dicht kan timmeren. Gelukkig werk ik ook in een omgeving met een hoog 'tweakers gehalte'. Maar als ik moet troubleshooten dan is dat altijd bij de dames van de administratie...

[Amito]

Ik heb jarenlang iedereen (local)adminrechten gegeven bij ons op het netwerk, maar ben blij dat ik ervan afgestapt. Je wilt niet weten wat voor troep ze allemaal installeren van belastingaangiftes tot torrent programma's (die dan niet werken doordat de poorten dichtgetimmerd zijn). Te vaak ook van die troep tegengekomen die perongeluk meegeinstalleerd wordt. Als je mensen aanspreekt dan was het altijd heb ik niet gedaan. Nu ze die rechten niet meer hebben (op een enkeling na die het wel netjes wisten te houden), heb ik er geen omkijken meer naar. Dus ja ergens heb je gelijk, maar niet iedereen kan met die vrijheid omgaan en dan moet je hen in bescherming nemen.

[Lednov]

Ja, want elke beheerder die de boel dicht timmert is een halve dictator. Fact of the matter is dat men binnen de kortste keren de boel de nek omdraait. Al dan niet bewust.
Zo heb ik ooit op een school gewerkt (niet als beheerder, als docent) waar helemaal niets dicht getimmerd was.
Je kan je de lol voorstellen die de wat 'handigere' leerlingen hadden met het netwerk. Het minst onschuldige was wel het spelen van Unreal over het netwerk... (waar ik overigens vrolijk aan meedeed; DeMeester draws first blood )

[Blokker_1999]

Hoewel ik zelf ook eingebruiker ben in zo een omgeving zie ik voldoende mensen rondom mij voor wie het een zegen is. Geef hen admin rechten en die hun PC zou meermaals per jaar geformateerd mogen worden. Om nog maar te zwijgen van de illegale software die men er op zou installeren.

In een kleine onderneming zou het nog mogelijk zijn zolang er voldoende controle is op respect voor de licenties. Maar in grote bedrijven waar tienduizenden computers staan kan je niet anders dan het beleid afdwingen.

[Matthijs Hoekstra]

Bij ons (100.000 pc's/laptops etc) is iedereen admin op zijn pc.

[SunnieNL]

Dat soort systemen richt ik ook in... De keuze is aan de klant.. een volledig beheerde omgeving zit dicht.. open systemen zijn minder beheerd...
Dus als er dan iets mis gaat met je pc, krijg je een nieuw image. Owh, die software die je er zelf op had gezet.. ja die had je zelf ook maar moeten backuppen.

Dat kun je echter niet overal. Het cryptolocker virus is bij veel van de overheidsklanten van mijn bedrijf gestopt voor het iets kon doen omdat juist de omgeving dicht zat. Een virusscanner was niet degene die de boel stopte (die kende in de beginfase het hele virus niet), dat was het read-only filter en de application guard die op de systemen aanwezig waren.

[psy]

Hier zijn de images ook standaard dichtgezet, maar je kan wel een open laptop aanvragen waardoor je local admin bent. Je manager moet dit wel goedkeuren, en je moet akkoord geven op een formuliertje waarop staat dat je niet geholpen wordt bij problemen als ze meer dan een tiental minuten moeten zoeken. Daarna wordt gewoon het standaard image teruggezet en heb je pech gehad.

Wat mij betreft een fijne oplossing zeker voor veel mensen binnen de ICT afdeling een uitkomst.

[Anoniem: 300229]

zo lang je er niet te veel tussen hebt die bij een nieuwe pc vragen waarom office niet is geinstalleerd omdat ze geen idee hebben waar die startknop voor is zou ik het zeker doen, maar voor de doorsnee bedrijfsomgeving is het geven van admin rechten een gevaar voor de hele bende. ze zijn net in staat om hun werk te doen als alles op de desktop staat

[bento smit]

Nee, ons kantoornetwerk wil je alleen hebben als iedereen op kantoor tweaker is

Was het maar zo'n feest. maar als ik als local admin zou kunnen draaien zou dat al een enorme vooruitgang zijn. Daar hoef je nou ook weer geen tweaker voor te zijn.

[Bacchus]

.. schrijft een bezoeker die een behoorlijk technisch artikel en toch minstens een handvol commentaren eronder gelezen heeft èn daar nog op reageert..

Tegenwoordig kwalificeer je toch al enigszins als Tweaker als je een neiging hebt niet tevreden te zijn met het standaard-image dat op je bedrijfslaptop geïnstalleerd wordt.

[MC Taz Man]

Of zijn bedrijf heeft als beleid dat niemand standaard als local admin inlogt...

[Bacchus]

Oh, dat is duidelijk. Wat ik vooral probeer over te brengen is dat als bento zo'n technisch artikel èn de commentaren leest en erop reageert, hij gewoon Tweaker is, in mijn ogen. En van een Tweaker verwacht ik, precies zoals van iemand die voor local admin kwalificeert, de nodige zelfredzaamheid met een computer.

[Markvankesteren]

Vorig jaar heeft Ordina een leuk event georganiseerd in het kantoor van Tweakers, misschien dat ze dit (binnenkort) weer eens gaan doen.

Erg leuk artikel om te lezen en ook al zegt het gros van de termen en hardware me helemaal niets is het ontzettend gaaf om als Tweakers.net zo transparant te kunnen zijn.

[freshy98]

Zou je dan niet eerst de baas gaan vervangen? ;-)

[Dasprive]

Heben jullie ooit de vergelijking gemaakt tussen een setup in AWS en wat jullie nu doen, namelijk eigen beheer? Zou dat gelet op jullie uitgebreide infra nog een echte oplossing zijn, aangezien AWS de laatste jaren toch aanzienlijke stappen zet?

Zou heel benieuwd zijn wat daar uitkwam, en ik kan me voorstellen dat dat een vraag die intern bij jullie ook al eens gesteld is.

[Reactie gewijzigd door Dasprive op 23 juli 2024 18:16]

[Kees]

Jazeker, dat vraag komt met elk artikel over onze servers weer terug

Kort gezegt kwam het er op neer dat wij, voor het bedrag dat wij aan AWS kwijt zouden zijn voor alleen al de databaseserver, wij elke 3 maand een nieuwe bare metal databaseserver zouden kunnen kopen en dan nog steeds goedkoper uitzijn dan bij AWS.

AWS is leuk als je veel kan schalen, maar dat kunnen wij niet, ons platform draait vrijwel nonstop met een vrij hoge belasting. En verder staat aws natuurlijk niet bekend om hun snelheid, performance en betrouwbaarheid (van performance) (alles in vergelijking tot onze snelheid, performance en betrouwbaarheid).

[BCC]

AWS is leuk als je heel klein bent of heel groot. Voor de meeste bedrijven is het inderdaad vaak te duur of wil je niet dat je core business afhangt van een externe partij. Maar voor sommige onderdelen kan het juist wel slim/goedkoper zijn, zoals bijvoorbeeld filestorage en het serveren van statics (CDN). Waarom pakken jullie hier bijvoorbeeld geen Cloudinary voor?

[Reactie gewijzigd door BCC op 23 juli 2024 18:16]

[Kees]

Dat zou inderdaad een optie kunnen zijn specifiek voor de plaatjes. Alleen is dat nog steeds vrij prijzig. Als ik het zo bekijk dan zouden wij qua hardware zo'n 40.000 per 5 jaar kunnen besparen. Beheerkosten blijven gelijk, bandbreedte en stroom betalen wij niet voor (lang leve onze sponsor True ).

Als ik dan naar de accounts kijk dan zouden wij meteen naar een enterprise account moeten. Hun grootste 'normale' account heeft een bandbreedte limiet van 400 gb per maand. Wij doen regelmatig 4tb per dag. Dus dat word een enterprise account, en ik schat dat dat minimaal $1000 per maand gaat kosten met ons verkeer. Dat is dan zo'n $70.000 in 5 jaar tijd. Dan kunnen we beter die hardware kopen en de boel zelf hosten.

[ejabberd]

Is Cloudinary wel goedkoop? Ik gok dat Amazon CloudFront wel eens een stuk goedkoper kan zijn. Op hun website hebben ze ergens een calculator om de kosten te berekenen. En je moet ook niet per se alle bestanden in een CDN willen stoppen. Je zou je kunnen concentreren op de homepage zodat die pagina sneller laadt voor mensen die op vakantie zijn.

[MadEgg]

Zodat die pagina sneller laadt? Sneller dan Tweakers.net? CDN is niet synoniem aan sneller hoor; vaak zelfs langzamer in mijn ervaring. Als ik dit artikel zo lees heeft Tweakers het erg goed voor elkaar, en het is dan ook een van de snelste sites die ik ken. Daar is weinig aan te verbeteren. En als het dan ook nog eens goedkoper is dan offloaden naar AWS, CloudFront, Cloudinary of weet ik wat, dan zie ik geen reden om dat te overwegen.

[BCC]

Had ik toch gelijk dat het vaak te duur is Maar misschien willen ze wel sponseren

[LoCuTuS2000]

Het billing model van AWS kan wel eens heel nadelig uitpakken als je een flinke baseload hebt. Dat wil zeggen dat als je in het merendeel van de maand veel resources nodig hebt het al snel voordeliger uitpakt om deze per maand in te huren of zelfs te kopen en colocaten zoals Tweakers doet. Het grote voordeel van AWS zit in de flexibiliteit en schaalbaarheid, maar dan wel tegen een flink prijskaartje.

In het geval van tweakers is hun colocatie gesponsord dus zal dit al snel voordeliger uitpakken dan een betaald model natuurlijk.

[ikke00]

De beste loadbalancer (die je dan ook als reverse proxy kan gebruiken) is zonder twijfel een oplossing van F5, is ook het product dat ik bij soortgelijke opstellingen bij klanten adviseer.
Het grootste nadeel is wel de kost.

Alternatieven die je zou kunnen bekijken:
Gezien jullie al FortiGates hebben staan is een FortiWeb met FortiADC geen slechte combo voor jullie basic requirements.
Momenteel is het product nog wel niet super uitgebreid getest dus ik zou vragen voor een POC.

Als jullie die piste willen bewandelen mag een PM altijd voor de contactgegevens van iemand binnen ons bedrijf. (om omgewilde reclame hier te vermijden)

[Reactie gewijzigd door ikke00 op 23 juli 2024 18:16]

[CAPSLOCK2000]

De beste loadbalancer (die je dan ook als reverse proxy kan gebruiken) is zonder twijfel een oplossing van F5, is ook het product dat ik bij soortgelijke opstellingen bij klanten adviseer.
Het grootste nadeel is wel de kost.

Ik heb laatst zo'n appliance bekeken en vond het nogal tegenvallen.
90% van wat zo'n ding doet is niet meer dan Linux + Apache, zeker wat betreft het load balancen.

Daarnaast zijn er uitbreidingsmodules met bv beveiligingsfeatures, maar als het je daar om gaat kun je beter een apparaat nemen dat zich daar in specialiseert. Ik ben geen fan van het mengen van functionaliteit. Het lijkt heel handig om alles in één doos te hebben zitten maar als er iets mis gaat dan moet je die hele kluwen weer ontwarren. Systemen die één ding doen zijn eenvoudiger te debuggen en als er iets mis gaat kun je ze gericht uitschakelen zonder ook andere functionaliteit te raken.

Bovenstaande geldt helemaal voor een loadbalancer. Een LB is bijna automatisch een SPOF en een bottleneck. Daar wil je dus geen polonaise maar het meest simpele systeem dat voldoet. Hoe minder complex hoe kleiner de kans op storingen. Een LB is in essentie een enorm simpel apparaat. Je neemt een verzoekje aan en schakelt het zo snel mogelijk door. Dat kan heel snel en is overzichtelijk en bijna stateless. Hoe meer toeters en bellen je er aan hangt hoe moeilijker het wordt om problemen snel te herstellen.

[Jebus4life]

De grootste kracht van F5 zit dan ook in z'n Irules; als je gewoon wilt load balancen en de appliance bovendien als een reverse proxy wilt gebruiken moet je inderdaad geen F5 kopen (tenzij je het gewoon koopt voor de naam ). Maar vanaf dat je in een "complexere" omgeving zit (complexer in de zin van meer/speciale requirements) kan je nauwelijks rond F5 heen (tenzij iemand mij nu een wonderproduct gaat voorstellen voor de helft van de prijs zodat ik m'n baas blij kan maken )

*Voor de setup die tweakers lijkt te willen hanteren lijkt F5 me daarom ook gewoon overkill en raad ik het op het eerste zicht niet aan, daar volg ik je dus wel in voor de duidelijkheid.

[Reactie gewijzigd door Jebus4life op 23 juli 2024 18:16]

[ikke00]

Je hebt absoluut gelijk ik zou het ook niet beter kunnen stellen, F5 zou bij deze ook overkill zijn als ik de requirements check vandaar ook het verdere advies.

[Anoniem: 181855]

Ik heb begin dit jaar zelf een F5 big ip vervangen door een linux server met nginx. Deze had een betere performance dat de hardware oplossing. Omdat een F5 de naam heeft wil niet zeggen dat ze beter zijn. Overigens vind ik persoonlijk een A10 beter.

[CH4OS]

Bij de toekomstplannen staat dit:

Om dat soort redenen zijn we erg benieuwd naar praktijkervaringen met die mogelijke vervangers. De bekendste is waarschijnlijk Nginx. In benchmarks die we een tijd geleden deden, bleek die niet sneller te zijn. Apache+mod_php was sneller dan Nginx+php-fpm en doordat Varnish de statische content toch al voor zijn rekening neemt, is de winst van Nginx daarbij beperkt.

Is er ook getest met Apache icm PHP-FPM? Of eventueel met LigHTTPD? Daarnaast is deze week PHP 7 ook uitgekomen, die een flink stuk sneller is geworden dan PHP5.6. Wellicht is het een en ander te combineren? Een site als Tweakers zal toch wel state of the art hard- en software gebruiken, lijkt me.

[Reactie gewijzigd door CH4OS op 23 juli 2024 18:16]

[Toettoetdaan]

Toevallig heb ik de meeste opties getest voor Magento webshops, dat is een relatief zware PHP applicatie die een stuk verder gaat dan alleen pagina's opbouwen.

Van alle opties was (voor de aankondiging van PHP 7) Apache + HHVM de beste optie.
Met lighttpd mis je een stukje flexibiliteit en met nginx heb je wat meer statische content nodig om winst te maken.

Het nadeel van de Apache + HHVM oplossing was dat het een `creatieve combinatie` was, je wil ook een stukje stabiliteit en support, dus toen een tijdje terug duidelijk werd dat PHP 7 echt dit jaar uit zou komen hebben we dat laten varen.

Dus uiteindelijk bleef bij ons Apache staan

[Kees]

Je hebt helemaal gelijk dat HHVM de snelste oplossing is. Echter toen ik die ging testen produceerde hij regelmatig een segmentation fault waardoor het hele proces ermee kapte. Dat is prima voor mijn test, maar niet iets wat ik in productie ga inzetten.

Dus nu zit ik met smart te wachten op een php7 repository met de modules die wij gebruiken

[Blokker_1999]

Lighttpd heb ik een tijd gebruikt maar heb destijds de overstap gemaakt naar nginx. Simpelweg omdat de developer van Lighttpd iets te weinig aan zijn gebruikers denkt. Feature requests worden niet vervuld en zelfs als je er zelf een patch voor zou aandragen word deze niet opgenomen in de main repo. Ook HTTP/2 zal niet in een 1.x versie komen en van een versie 2 is voor zover ik weet nog geen sprake.

Zelf maak ik gebruik van een lichtgewicht webserver omdat een full blown Apache gewoon overkill is (al wat ik nodig heb is static content+PHP) en de config ervan enorm eenvoudig is.

[hensema]

Het is handig om vóór varnish nog een nginx reverse proxy te zetten. Deze laat je http gewoon doorsturen naar varnish, en ssl offloaden voor https. In de https reverse proxy zet je een eigen http header (X-Tweak-SSL-Offloaded: yes). Leuke is ook dat je een backup backend kunt zetten. Mocht nu alles stuk zijn en nginx nog werken, dan kan die de requests nog doorsturen naar je backup die een pagina laat zijn met excuses voor de overlast.

Ook configureer je alvast in nginx een directe reverse proxy naar je applicatieservers. Die kun je inschakelen in geval van onderhoud aan je varnish.

Op je applicatieserver zeg je (bijvoorbeeld in .htaccess of je vhost config) iets als:

SetEnvIf X-Tweak-SSL-Offloaded yes HTTPS=on

Dat moet in feite al voldoende zijn om richting je applicatie duidelijk te maken dat een verbinding in origine vanuit https gekomen is.

[Rafe]

'X-Forwarded-Proto' is daarvoor toch de de facto standaard? En op pad om officieel gestandaardiseerd te worden

[Kees]

Inderdaad, zo'n soort oplossing hebben wij ook bedacht; we inserten een extra header en in de php code zetten we dan 'yep we hebben https'.

Het enige nadeel is dat er een bug in apache zit waardoor dat niet helemaal lekker werkt (heb ik al een bugreport voor gemaakt uiteraard) maar tot die opgelost is moeten we er omheen werken, maar daar zijn we nog niet aan toe gekomen.

(die bug met apache is trouwens als je in de apache config een redirect wil doen als de gebruiker https moet gebruiken maar je dat niet weet in de vhost omdat er een ssl proxy voor zit).

[CAPSLOCK2000]

Mooi artikel en erg leuk dat jullie ons om advies vragen.

Ik steun de bevinding dat Apache + Varnish in de meeste gevallen niet onder doet voor nginx en lighttpd. Persoonlijk vind ik het extra werk niet de moeite waard.

In de eisenlijsten mis ik IPv6. Dat mag nu toch wel bij de eisen, of is dat al zo vanzelfsprekend als dat er ventilatoren in de kast moeten?

Wat betreft de loadbalancer zou ik voor zelfbouw gaan. Ik wordt altijd teleurgesteld door appliances. Op het moment dat er problemen zijn kun je niks anders dan de leverancier bellen en hopen dat ze het snel komen oplossen. Wat ze in praktijk doen is meestal vrij eenvoudig, verzoekjes aannemen en doorgeven.

Voor Storage zou ik deduplicatie en compressie niet eens opnemen in de lijst. Deduplicatie kost zoveel performance dat het meestal niet de moeite waard is. Compressie gaat beter maar als de bulk van je data uit vidoe bestaat heeft het geen zin.
Als je maar 30TB hebt dan zou ik SSD-only storage overwegen. Dat hoeft niet zo duur te zijn als je zou denken. Met SSDs heb je geen dure RAID-controllers nodig en heb je ook niet de complexiteit van multi-tiered storage.
Met automatische multi-tier storage moet je ook oppassen. Zo'n ding moet je echt configureren anders werken die tiers alleen maar tegen je. Geloof niet te veel van zelflerende algoritmes, ook die moet je helpen.
Staar je niet blind op de dure enterprise-SSDs, die zijn mooi voor extreme omstandigheden maar als je IO toch voor 99% uit reads bestaat zijn die hun geld wellicht niet de moeite waard, zelfs een consumenten SSD is betrouwbaarder dan de meeste enterprise-draaischijven.

[Raven]

" In de eisenlijsten mis ik IPv6. Dat mag nu toch wel bij de eisen, of is dat al zo vanzelfsprekend als dat er ventilatoren in de kast moeten?"

Daar zat ik ook al naar te zoeken...

[ACM]

IPv6 is inderdaad iets dat gewoon op een loadbalancer hoort te zitten, met als aanvulling dat complexe proxying van of naar ipv4 dan onder de 'should have'-sectie valt

Voor de andere elementen zien we dat ook als basisonderdeel van de netwerkfunctionaliteit. Maar daar is het meer een aspect bij het OS hoort dan bij de applicatie.

Bedankt verder voor je suggesties. Die gaan we zeker (nog een keer) goed lezen.

[magnifor]

Wat zijn eigenlijk de gebruikte Linux-distributies? Ubuntu wordt even genoemd voor de KVM maar de rest? Ben er wel benieuwd naar.

[Kees]

Alle servers draaien Ubuntu 14.04 LTS met de meest recente updates

[Olaf van der Spek]

Geen Debian?
Echt voor LTS gekozen of was er een andere reden?

[Kees]

Bewust voor TLS gekozen, zodat je (naast de normale updates) maar eens per twee jaar een grote update hoeft te doen. Ik draai vaak wel de niet-LTS versies op een testomgeving (naast de normale dev omgevingen die ik wel op LTS hou, totdat ik moet overstappen). Bovendien wordt LTS langer bij gehouden dan de niet-LTS versies, waardoor ik kan voorkomen dat ik een server moet updaten omdat er geen ondersteuning voor is. Bovendien kan ik alles het grootste gedeelte van de tijd gelijk houden. Overigens is LTS draaien eigenlijk alleen maar mogelijk door verschillende PPA's in te zetten waardoor bijvoorbeeld php wel op 5.6 zit.

En Ubuntu ipv Debian omdat ik op een gegeven moment een keuze moest maken, de release schedule van Ubuntu beviel mij wat beter dan die van Debian, en Debian testing had ik slechte ervaringen mee, er gingen net even iets te vaak dingen stuk. Met Ubuntu weet je gewoon dat er elke twee jaar een LTS uitkomt en dat vind ik fijner werken. Verder verschillen ze natuurlijk niet heel erg veel van elkaar (op server gebied).

[magnifor]

Cool! Thanks voor het melden.

[MistaD]

Leuk en informatief artikel. Ben wel benieuwd hoe het zit met het energieverbruik. Is de nieuwe oplossing ook zuiniger?

Bij Randstad zijn veel van de hardware loadbalancers en Apache reverse proxies vervangen door HAProxy. Bevalt erg goed en zorgt er voor dat je niet meer afhankelijk bent van specifieke (dure) hardware en maakt het beheer een stuk eenvoudiger. Misschien het overwegen waard?

[ACM]

Omdat we er niet op worden afgerekend, houden we het verbruik niet heel goed in de gaten (het wordt wel gemonitored, maar ik check het nooit). Maar de nieuwe servers zijn doorgaans zuiniger dan de oude; dus het gaat bij de meeste vervangingen omlaag.

Anderhalf jaar geleden zaten we blijkbaar rond de 10 ampere per rack bij True. En nu op zo'n 6,5A per rack. Maar dat komt voor een groot deel doordat er diverse oude hardware op een gegeven moment uit kon (en ging), niet omdat we toen ineens zoveel zuinigere apparatuur hadden opgehangen

[Kees]

De grootste besparing zit erin dat wij voor de databaseservers ssd's zijn gaan gebruiken om de performance op te schroeven. De 4-6 ssd's in de databaseservers zijn iets zuiniger dan een vijftiental 15k RPM disks in een aparte enclosure.