Door Luke van Drie en Wout Funnekotter

Feedback • 02-01-2025 06:00 194

Dit is hoe we Tweakers hosten - 1320 cores, 5 TB ram en 364TB opslag

02-01-2025 • 06:00

Hoewel steeds meer bedrijven overgaan op cloudhosting, draait Tweakers sinds jaar en dag al op eigen hardware. Om Tweakers bij jou op je scherm te krijgen, hebben we anno 2024 een serverpark met in totaal 1320 cores, 5 TB aan ram en 364TB aan opslag. In deze video neemt Wout je mee achter de schermen bij ons serverpark en maak je kennis met de man die het helemaal uitgedacht heeft.

00:00 - Dit is hoe we Tweakers hosten! 1320 cores, 5 TB ram en 364TB opslag
00:25 - Datacentrum van euNetworks
00:52 - Koeling datacentrum
01:27 - De serverkasten van Tweakers
03:16 - De indeling van de servers
06:16 - Waarom niet in de cloud?
07:06 - De binnenkant van een server
07:35 - Opslag
08:46 - Koeling
10:26- CPU en RAM-geheugen
12:25 - Voeding
12:50 - Zelfbouw vs kant-en-klaar

Vorige video Volgende video

Lees meer

Deze nieuwe monitors zijn grensverleggend!

Deze nieuwe monitors zijn grensverleggend! Video van 13 januari 2025

Dit waren de tofste smarthomegadgets van CES

Dit waren de tofste smarthomegadgets van CES Video van 12 januari 2025

Dit zijn de nieuwe oleds van Samsung! S85F, S90F, S95F en QN900F 8K qled- tv's

Dit zijn de nieuwe oleds van Samsung! S85F, S90F, S95F en QN900F 8K qled- tv's Video van 8 januari 2025

Eindelijk alles over de Nvidia GeForce RTX 5090, RTX 5080 & RTX 5070 Ti

Eindelijk alles over de Nvidia GeForce RTX 5090, RTX 5080 & RTX 5070 Ti Video van 7 januari 2025

Ik wist niet dat er nog zulke slechte Game PC’s werden verkocht…

Ik wist niet dat er nog zulke slechte Game PC’s werden verkocht… Video van 22 december 2024

Vooruitgang in lokale spraakherkenning - Home Assistant Voice review

Vooruitgang in lokale spraakherkenning - Home Assistant Voice review Video van 19 december 2024

Koning der avonturiers claimt zijn troon - Indiana Jones and the Great Circle

Koning der avonturiers claimt zijn troon - Indiana Jones and the Great Circle Video van 14 december 2024

Kleine stap voor gamers, grote stap voor Intel - Intel Arc B580 Review

Kleine stap voor gamers, grote stap voor Intel - Intel Arc B580 Review Video van 12 december 2024

Deze drone vliegt helemaal zelf - HoverAir X1 Pro Max Review

Deze drone vliegt helemaal zelf - HoverAir X1 Pro Max Review Video van 6 december 2024

Meer producten en artikelen

Netwerk en systeembeheer Netwerkapparatuur Netwerkbeheer Netwerkkabel Netwerktechnologie Netwerkverkeer

IT-banen

Meer vacatures

Reacties (194)

pim 2 januari 2025 08:54

Interessante video, bedankt!

Ik heb net zelf een cloud hosting infrastructuur opgezet voor een multiplayer game, die oneindig opschaalt.. Als er hypothetisch miljoenen spelers zijn kunnen er letterlijk miljoenen server aangemaakt worden, en ook weer gekilled, als de spelersaantallen droppen. Doe dit via de api van digital ocean.
Dat automatisch op en afschalen is waar de kostenbesparing zit, ik betaal alleen voor wat ik gebruik.

Vraag me af als je nu tweakers.net vanaf de grond af aan op zou bouwen in de cloud, of het dan prijs technisch zou concurreren met een eigen dedicated oplossing.

Anyways, interessante video!

Kees BOFH

Netwerk en systeembeheer

@pim • 2 januari 2025 09:16

Het nadeel van Tweakers is dat we niet echt grote pieken hebben. Een game zal in de middag en avond waarschijnlijk veel verkeer hebben en direct na de launch heel veel verkeer dat vervolgens langzaam wegloopt over enkele jaren en dan nog maar een fractie is van wat je in het begin nodig had.

Bij Tweakers hebben we 'gewoon' 365 dagen lang bezoekers en is het verkeer behoorlijk goed verspreid over de hele dag, van 's ochtends 8 uur tot 's avonds 11 uur. Daarnaast hebben we nog een aantal behoorlijk zware taken die elk kwartier draaien van 6:00 tot 24:00, namelijk de prijslijsten van de winkels importeren voor de pricewatch. Dat is een vrij constante load.

De cloud is inderdaad goed als je makkelijk kan op- en afschalen en je dat ook doet. Als je een vrij constante load hebt, dan zijn de voordelen van de cloud ineens niet zo voordelig meer. Ik zie het ook bij collega's die alles in de cloud doen; veel van hun tijd zit onderhand in Finops; oftewel proberen de rekening zo laag mogelijk te krijgen waardoor ze vaak weer minder felxibel zijn.

Maar als je die kennis niet hebt (wat steeds zeldzamer word) en je moet iets nieuws opzetten wat vanaf het eerste moment goed moet werken en je niet de tijd hebt om het rustig op te bouwen dan is de cloud inderdaad een goede plek om te starten of opnieuw te beginnen.

knokki @Kees • 2 januari 2025 13:18

"Maar als je die kennis niet hebt (wat steeds zeldzamer word)"
Just to make sure: wat wordt volgens jou steeds zeldzamer? Het wel-hebben van kennis of het niet-hebben van kennis. Ik lees het als dat het niet-hebben van kennis steeds zeldzamer wordt (dus er komt steeds meer kennis), maar ik neem aan dat je het tegenovergestelde bedoelt.

[Reactie gewijzigd door knokki op 2 januari 2025 13:29]

roawser @knokki • 2 januari 2025 14:30

'Wat' slaat op het hebben van kennis, en dat maakt deze zin lastig te begrijpen. Er zou moeten staan: "als je die kennis niet hebt (die/welke steeds zeldzamer wordt)...".

Kees BOFH

Netwerk en systeembeheer

@roawser • 2 januari 2025 15:13

Taal is zeg maar niet echt mijn ding, ik hou het liever bij servers

Maar inderdaad, de kennis die je nodig hebt om zelf zaken te co-hosten word naar mijn idee steeds zeldzamer, ook omdat het steeds ingewikkelder word en de diverse cloud providers veel eenvoudigere tools beschikbaar stellen waardoor je het ook niet meer zelf leert.

Waarom zou je willen leren hoe je een database op kan zetten en tunen als je gewoon een managed database in de cloud kan huren? Hoe kun je een netwerk leren opzetten als je dat nooit hoeft te doen omdat de cloud provider dat al voor je heeft gedaan? Waarom zou je een server in willen duiken om een probleem te vinden en op te lossen als je gewoon een nieuwe server kan opstarten?

HKLM_ @Kees • 2 januari 2025 16:39

Hoe kun je een netwerk leren opzetten als je dat nooit hoeft te doen omdat de cloud provider dat al voor je heeft gedaan?

|

Hier sla je wel echt de spijker op zijn kop want hier gaat het in de cloud toch helaas vaak mis, Ow de cloud boer doet dit voor mij. Terwijl je als je naar Azure kijkt, je best wat moet doen om een goed en veilig netwerk op te bouwen in je omgeving.

@HKLM_ • 2 januari 2025 17:07

Velen zetten de firewall rules op 'allow all' want dat is wel zo gemakkelijk. Of het ook veilig is is een geheel andere kwestie.

Kees BOFH

Netwerk en systeembeheer

@FrankHe • 2 januari 2025 17:15

In hetzelfde straatje: file- or directorypermissies op '777' zetten, want dat staat zo in de documentatie.

Voor degene die het niet weten: dan mag dus iedereen op de server dat bestand inzien, aanpassen en uitvoeren. Dat is meestal niet wat je wil.

@Kees • 2 januari 2025 17:44

Het is alleen wel dagelijkse kost wanneer je kijkt naar al die uitgelekte persoonsgegevens. Een database backup die als bestand in de web root staat en door de hele wereld gedownload kan worden. Je verzint het niet maar het gebeurt echt.

Frame164 @HKLM_ • 2 januari 2025 18:08

Dat zijn wel de zaken die je leert als je cloud architect wordt. Zelf een netwerk kunnen bouwen heeft geen waarde als je het vervolgens in een cloud gaat zetten waar andere principes worden gebruikt. Je kunt beter AWS, GCP of Azure cloud specialist worden dan weten hoe je het zelf moet maken. Als je organisatie de cloud computing wil gaan omarmen natuurlijk.

Guru Evi @Frame164 • 3 januari 2025 08:21

Ik vind het omgekeerde waar. Als je weet hoe het onderliggend werkt is het gemakkelijk om wat de GUI doet te begrijpen (en ook op te lossen voor je naar de telefoon grijpt).

Ik heb al mensen geïnterviewd die enkel maar cloud kennen - een log in Linux zie je niet in met CloudWatch en een kant-en-klare VM is niet altijd te importeren, dat is ook ongelukkig als dat het enige is dat je kent op een technisch interview.

Zie ik nu vooral met die VMWare mensen, ik heb er een stuk of 10 geïnterviewd net nadat Broadcom ze overnam en massaal ontslagen liepen bij hun “partners” sorry maar die mensen gaan na 20 jaar exclusief op VMware knopjes te duwen geen baan meer vinden, al die gouden partners zijn indien ze niet failliet willen gaan aan het overstappen naar een van de KVM aanbieders zoals Nutanix of Proxmox, en die herscholing wordt lastig als je de basis niet kent.

borft @Frame164 • 3 januari 2025 09:45

Totaal niet mee eens. Om goed met de cloudoplossingen te kunnen werken is het, imho, juist belangrijk om de onderliggende principes te begrijpen. De cloud providers hebben echt het netwerken niet opnieuw uitgevonden, de principes zijn hetzelfde. Hoogstens zijn er wat tools omheengebouwd om het leuk te laten integreren met de rest van het platform, en/of orchestratie makkelijker te maken.

ForReal @Frame164 • 3 januari 2025 12:59

Zelf een netwerk kunnen bouwen heeft geen waarde als je het vervolgens in een cloud gaat zetten waar andere principes worden gebruikt.

Zo anders zijn die principes niet. Een AWS VPC heeft 'gewoon' cidrs, subnets, route tabellen, NAT. De security groups (firewalls) draaien om poorten, de loadbalancers zijn L4/L7.

Blijft misschien enigzins verstopt als je alleen met Lambda/SQS/DynamoDB te maken hebt. Maar vroeg of laat moet je ergens mee integreren waar het een rol speelt.

Het is net als Frontend frameworks en vanilla Javascript/HTML/CSS: Helpt om de basis te kennen.

Jay-v @Kees • 2 januari 2025 15:41

Een "alleskunner" is altijd zeldzaam geweest. Ik heb voor menig bedrijf gewerkt waar de netwerk persoon alleen maar networking doet, de VMware man alleen maar VMware en dan nog een clubje Windows admins, een clubje linux admins, wat DBA's etc. Dit wordt meestal pas zichtbaar op het moment dat er complexe problemen zijn en mensen het hele plaatje moeten begrijpen.

@Jay-v • 2 januari 2025 17:05

Een interdisciplinair team van mensen kan met een beetje geluk onderling ook heel ver komen. Heb je een performance probleem met de database? Zet de DB en VM mensen een uurtje naast elkaar, hoewel ze weinig van elkaars disciplines weten verwacht ik dat ze na een uur proberen samen al de nodige inzichten hebben verworven die ze verder helpt in de diagnose en oplossing van het voorliggende vraagstuk.

wica @FrankHe • 2 januari 2025 18:01

En dan was het zoals altijd een DNS probleem

De performance en grafieken van de DB zien er oke uit, die van de VM ook. We hebben ook een netwerk wat normaal lijkt te werken.
Ops, op de 2de nameserver had een probleem

Wat ik hiermee bedoel, is dat de meeste mensen die gespecialiseerd zijn in een bepaald domein, echt niet verder kunnen kijken.

[Reactie gewijzigd door wica op 2 januari 2025 21:45]

@wica • 2 januari 2025 18:07

Met een beetje pech zit je inderdaad opgescheept met lui die zeer eenkennig zijn en alleen hun eigen technology stack beheersen. Als je geluk hebt dan heb je een aantal mensen die iets verder kijken en wat betreft ervaring en competenties enige overlap laten zien. Dat zijn de beste teams.

poktor @wica • 2 januari 2025 18:11

Inderdaad. En dan komen ze bij de oude rotten uit, zoals ik.

Ik heb ondertussen alles wel onder handen gehad. En dan kun je het geheel overzien. Dit is regelmatig van onschatbare waarde.

Pathogen @poktor • 3 januari 2025 10:41

Helaas staan er zo weinig vacatures op "ouwe rot"... Ik ben er zelf ook één maar zie alleen maar oogklepfuncties gevraagd.

poktor @Pathogen • 3 januari 2025 14:17

Herkenbaar. Bedrijven willen nog steeds voor het bekende dubbeltje op de eerste rang. Dat verklaart die "oogkleppenfuncties".

StCreed @Pathogen • 4 januari 2025 12:06

Dat is precies waarom ik freelance. Heb je je reputatie opgebouwd, dan krijg je de klussen waarbij er gewoon iets moet gaan werken, en ze een expert zoeken.

-Colossalman- @wica • 2 januari 2025 19:36

Ik krijg altijd te horen dat het een netwerk probleem is..
Als het dan al aan de firewall ligt heeft een TABer geen idee hoe zijn applicatie werkt en de leverancier dus maar weer inschakelt

Sommigen weten niet eens wat een subnet is..

Guru Evi @wica • 3 januari 2025 08:27

Ik verwacht dat iedereen die een beetje helpdesk gedaan heeft wel degelijk weet hoe je basis IP, DNS en DHCP kan troubleshooten en tenminste de simpele protocollen kent (25, 80 en TLS/SSH tunnels opzetten en basis problemen testen). Dat je Cisco’s smaak van VLAN niet kent, of vandaag niet weet hoe je manueel POP3 of FTP moet doen, tot daar aan toe maar je moet wel weten wat het is, of je nu een DBA, programmeur of sysadmin bent, de algemene problemen met een TLS certificaat kunnen aanwijzen op alle niveaus is een vereiste met de staat van beveiliging.

[Reactie gewijzigd door Guru Evi op 3 januari 2025 08:29]

Frame164 @FrankHe • 2 januari 2025 18:05

Bij een beetje complex IT systeem heb je niet alleen domein experts nodig maar ook system architects die het geheel kunnen overzien en ook weten welke impact een storing op de business heeft.

@Frame164 • 2 januari 2025 18:11

Wanneer er een daadwerkelijke storing is dan zorgt de business er zelf voor dat je dat te horen krijgt.

Mensen die een goed algeheel overzicht hebben hoeven niet direct alle technische in-and-outs te weten als ze maar in staat zijn om te vertalen wat ze willen overbrengen.

wica @Kees • 2 januari 2025 15:25

Waarom zou je willen, als X het al voor je doet?
Omdat je wil weten en begrijpen hoe zaken werken i.p.v. een support/github ticket te maken. Voor mij is dat de meerdere die brengt als IT-er in het oerwoud van IT-ers kan brengen.

Frame164 @wica • 2 januari 2025 18:04

Maar als iets niet doet wat het moet doen, maak je een ticket aan bij je cloud provider. Je kunt er ook wel van uit gaan dat een cloud provider problemen sneller opgelost heeft dan als je zelf wat hebt gebouwd, al was het maar omdat ze heel veel verschillende workloads hebben en ze door de schaalgrootte veel meer specialisten in dienst kunnen hebben. En wat te denken van vulnerability management. Daar heb je een dagtaak aan.

wica @Frame164 • 2 januari 2025 18:59

Dat is heel erg afhankelijk van je support contract. Lees hoeveel je betaald.

Het help je support vraag heel erg. Als je kan zeggen wat je zelf al uitgezocht hebt. En waar jij denkt dat het probleem ligt.

Lucky0wn @Kees • 22 januari 2025 13:05

En daarom ben ik voor hybrid (multi) cloud! En zet mijn werkgever (hyperscaler) daarop ook vol in.

De constante workloads on prem; en daarnaast de pieken in de Cloud. Tevens kun je alle voordelen van cloud gebruiken en de nadelen mitigeren met eigen hardware.

D0phoofd @knokki • 2 januari 2025 13:42

De kennis over het opzetten van goede infrastructuur. Dat is namelijk steeds meer een abstract (mede door de opkomst van cloud). Mensen zijn over het algemeen steeds specialisticher geworden. Om een goede infra te bouwen moet je snappen wat de software vraag is en deze kunnen vertalen naar een architectuur. Je moet dus veel concepten begrijpen tot op zekere hoogte, op zowel hard als software.

wica @knokki • 2 januari 2025 13:50

Mijn ervaring, als voornamelijk een OpenSource System engineer met ruim 25 jaar ervaring.
Is de kennis en ervaring bij de nieuwe aanwas, van de afgelopen tijd. Verschoven van HW, source code begrijpen vooral verschoven naar het beheren via API's en vooral gespecialiseerd op bepaalde onderdelen. Waardoor het lastiger is, om een omgeving in zijn geheel te kunnen begrijpen. Laat staan te kunnen debuggen.

Toen ik begon, moest ik kennis hebben van Windows, Linux, netwerken en hardware en code. Eigenlijk je moest van alles wel verstand hebben. Waardoor het gemakkelijker is, om problemen op te sporen en vandaag de dag ook gemakkelijker maakt om te communiceren met andere Teams.

Begrijp mij niet verkeerd, ik heb niets tegen API's en de moderne manier van beheren. Maak er maar al te graag gebruik van. Maar zie wel bij jongere collega's dat ze moeite hebben met de complete omgeving te begrijpen.

Frame164 @wica • 2 januari 2025 18:10

In die tijd waren systemen een stuk eenvoudiger waardoor het ook mogelijk was om van alles wat te weten. Maar ook zijn veel systemen nu zover uitontwikkeld dat problemen van toen eigenlijk niet meer bestaat. Toen ik met PC begon, was je bezig om te zorgen dat je geen conflicterende interrups had en zo. Dat is nu helemaal geen issue meer. En dat geldt voor heel veel andere onderwerpen ook.

Jay-v @Kees • 2 januari 2025 13:58

Tweakers wordt natuurlijk enorm geholpen door True (althans dat was voorheen zo), maar gezien de tech-stack lijkt een cloud oplossing toch een behoorlijk stuk eenvoudiger te beheren.

Een gemiddelde hyperscaler biedt:
- Managed Kubernetes+ Managed AddOns (CNI/CSI, auto-scaler, logging, upgrades, node-lifecycle management, certmanager, managed cluster).
- Managed MySQL cluster
- Managed MongoDB
- Managed memcached
- s3 compatible storage (dat kan CEPH).
- Managed WAF + CDN

Imports e.d. kunnen als CronJob op Kubernetes of een serveless achtige oplossing landen.

De vraag is natuurlijk hoeveel meer zou het kosten? En hoe afhankelijk is Tweakers.net nu van Kees

, kan natuurlijk ook een risico zijn.

@Jay-v • 2 januari 2025 14:40

De prijs is denk ik een zeer sterke motivatie. Storage buckets zijn verre van gratis, voor hetzelfde geld zet je zelf vijf omgevingen op met dezelfde of een grotere opslagcapaciteit. Omdat Tweakers geen dynamische schaalbaarheid nodig heeft is er geen reden om naar de cloud te gaan. Bij een min of meer voorspelbare belasting is eigen metaal eigenlijk altijd goedkoper.

Een ander punt is denk ik performance. Voor veel toepassingen maakt het niet echt uit hoe snel de systemen zijn. De Tweakers community is op dat punt wellicht wellicht wat veeleisender dan andere omgevingen. Ik wil niet beweren dat cloudomgevingen langzaam zijn, het enige wat ik zeg is dat eigen metaal net een beetje sneller is.

@FrankHe • 2 januari 2025 15:25

Omdat Tweakers geen dynamische schaalbaarheid nodig heeft is er geen reden om naar de cloud te gaan.

Ik lees:

8 uur tot 's avonds 11

9 uur van de 24h zou je kunnen afschalen.

zware taken die elk kwartier draaien van 6:00 tot 24:00

6 uur van de 24h zou je kunnen afschalen.

En uiteraard hangt het er ook van af wat de architectuur van de applicatie is.
Door de cache aan de front end verwacht ik dat voor veel servers de load zowiezo vrij constant is en die er al passend op geschaald is.
De kwartier jobs van pricewatch zijn gewoon volle belasting en ik verwacht optimaal geconfigureerd kwa hardware en software.
Kees heeft jaren lange ervaring met deze website, weet dus echt wel hoe de boel efficiënt in te richten.

In de cloud ben je snel heel wat tonnen kwijt per maand als je dit wilt hosten.

[Reactie gewijzigd door djwice op 2 januari 2025 15:29]

@djwice • 2 januari 2025 15:45

Afschalen voor een paar uur in de nacht klink misschien leuk maar is totaal niet zinvol. Bij cloudaanbieders is een doorlopende server voor een hele maand aanzienlijk goedkoper dan een server die je dynamisch opschaalt en afschaalt. Stel een maand kost EUR 30, zet dat af tegen bijvoorbeeld EUR 0,15 per uur dan laat een eenvoudige berekening zien dat je de machine het beste gewoon aan kunt houden.

Bij een min of meer constante load is het hebben van eigen machines per definitie goedkoper dan welke cloudoplossing dan ook. De cloud heeft als voordeel dat je per maand betaalt en er geen initiële investering is. Die investeringen heeft de cloudaanbieder immers al gedaan en die willen de gemaakte kosten uiteraard met winst terugverdienen. Simpele economie, onder de streep is de cloud altijd duurder. Het punt waarop je eventueel quitte kunt spelen is de beheerskosten. Wanneer je deze kennis en kunde niet in huis hebt en extern moet inkopen dan kom je met een managed cloud wellicht iets goedkoper uit al is dat wel heel erg afhankelijk van de 'use case' en de architectonische beslissingen die men neemt.

@FrankHe • 2 januari 2025 15:50

Klopt en je kunt 60% korting krijgen als je ze 3 jaar afneemt en dan nog een 15% contract korting en dan nog het eerst jaar gratis omdat naar cloud migreert.

Dus effectief betaal je 25.5% van de list-prijs.

Maar heel simpel, als je echte piek load hebt of juist hele gespreide load. Kan cloud juist voordelig zijn. Er zijn scenario's waarin ik duizenden machines nodig heb, die heb ik dan een paar minuten nodig en daarna niet meer. En dat kan voor minder dan een euro per minuut per duizend incl. aansturing en start in een paar milliseconden op.

Zo'n pricewatch batch job ook. Je kunt die gewoon paralel draaien (doen ze nu vast ook al). Dus het is een kwestie van het juiste ontwerp, die kunnen vast ook serverless op AWS. Betaal je per milliseconde dat de node bezig is. Bandbreedte schaalt automatisch mee, hoef je niets voor te regelen.

Scheelt wellicht in je netwerk capaciteit behoefte als dat stukje in cloud draait. Maar goed dat kan bij de volgende afschrijving overwogen worden.

[Reactie gewijzigd door djwice op 2 januari 2025 16:01]

@djwice • 2 januari 2025 16:02

En bij die dynamische instances betaal je ieder uur de volle mep. Dat is prima wanneer je een nieuwe game lanceert en in de eerste 72 uur twintig keer de standaard servercapaciteit nodig hebt die je na afloop weer afschaalt. Voor de standaard capaciteit sluit je een langdurig contract af omdat je anders factoren duurder uit bent.

Jay-v @FrankHe • 2 januari 2025 15:35

"Omdat Tweakers geen dynamische schaalbaarheid nodig heeft is er geen reden om naar de cloud te gaan"

Juist bij data gaat dat niet op, die groeit alleen maar.

"Een ander punt is denk ik performance"
Het god ganse internet serveert plaatjes en videos vanaf een storage bucket met een CDN ervoor. Zo uniek is dat niet

@Jay-v • 2 januari 2025 15:49

Het punt van dynamische schaalbaarheid en performance slaat uiteraard niet op statische data maar op dynamische data. Een eigen dedicated databaseserver die direct naast de applicatieserver staat is gewoon sneller dan een omgeving waarin de instances middels virtualisatielagen verder van elkaar verwijderd zijn.

StCreed @FrankHe • 4 januari 2025 12:08

Dat ligt nogal aan je ontwikkelaars. Want ja, het is overhead per call, maar daar kun je vrij veel aan doen door calls te bundelen, cachen, et cetera.

@StCreed • 4 januari 2025 13:42

De caching lagen buiten beschouwing gelaten, die zijn er immers al. Het gaat zuiver om de latency tussen nodes. Machines die fysiek dicht bij elkaar staan behalen de laagste latency.

StCreed @FrankHe • 28 januari 2025 19:23

Qua latency klopt dat, maar bij de databases die ik bouw is dat zelden een punt. De queries kunnen minuten duren. Het gaat daar veel meer over bandbreedte en goede disk management. Twee glasvezellijnen naar een hardwarematig gespiegeld SAN met daarboven een HA cluster is dan handiger dan zelf die storage moeten gaan regelen.

Frame164 @FrankHe • 2 januari 2025 18:14

Ik denk niet dat DPG de eisen van de community meeneemt in hun business case eerlijk gezegd. Maar los daarvan: in de cloud kan je prima kritische applicaties qua performance laten draaien. Door de opzet van de grote cloudplatformen nog wel beter dan in een (klein) eigen DC. Maar het vereist wel andere competenties om dat te kunnen bouwen.

Maar zoals gezegd: bij een redelijke constante load is eigen hardware goedkoper, zeker als je door de jaren heen een goed softwareplatform hebt gebouwd. Als je nu van scratch zou beginnen is het een ander verhaal.

Whazor @Jay-v • 2 januari 2025 22:21

Als iemand die voor een cloud provider werkt en aan de andere kant zit: het grootste voordeel aan cloud is dat andere mensen voor je de systemen 24/7 draaiend houden. Met een ploegendienst heb je in mijn mening toch minstens vijf mensen nodig om fatsoenlijk af te kunnen wisselen. Dan hoef je als sys-admin eens in vijf weken de pager te houden.

Vooral bij managed diensten is dat zeer waardevol, want naast het niet onderhouden van fysieke servers hoef je ook niet te zorgen dat je database omvalt. Daarnaast hebben hyperscalers het voordeel dat ze in tientallen regio's dezelfde software langzaam kunnen uitrollen. Dus operationeel gezien is het voor ze gemakkelijker om meer uptime te halen dan eigen beheer.

Maar thuis draai ik ook alles zelf en is het een hobby. Ook kun je natuurlijk bij tweakers.net zeggen dat een nachtje downtime niet het einde van de website is. De meeste bezoekers horen dan toch in bed te liggen.

Speculum @Jay-v • 3 januari 2025 10:25

Ik dacht precies hetzelfde, ik heb het idee dat net zoals bij het bedrijf waar ik werk de beheerders dat minder leuk vinden en het een beetje tegenhouden. Een paar geleden was dit allemaal wel goedkoper maar tegenwoordig is dat echt niet meer zo. Als je alle kosten in ogenschouw neemt (hardwarekosten, energiekosten, rackhuur, loonkosten, support contracten etc) dan is dit een vrij kostbare aangelegenheid die een hyperscaler als AWS veel efficienter en goedkoper kan hosten (EKS + spot instances voor de webservers).

Als ze naar een hyperscaler gaan dan heeft deze meneer eigenlijk geen werk meer bij Tweakers want dan kan alles door de developers onderhouden worden via Infra as Code (IaC). Deze stack is natuurlijk deels custom door de evolutie van de website en het bedrijf en vereist wel een paar aanpassingen die ook niet gratis zijn maar ik denk dat het uiteindelijk goedkoper zal zijn als alles op een hyperscaler draait en dan wel multi-AZ op 3 locaties ipv 2.

[Reactie gewijzigd door Speculum op 3 januari 2025 10:28]

Jay-v @Speculum • 3 januari 2025 11:05

Karpenter maakt dat ook nog eens super eenvoudig om op spot te draaien. Anyway, denk niet dat Kees dan zonder werk zit, het werk zelf veranderd simpelweg een beetje.

3raser @Jay-v • 4 januari 2025 08:04

Tweakers heeft alles redundant uitgevoerd, behalve Kees. Kees is dus de single point of failure.

ro8in @Kees • 2 januari 2025 20:36

Wat als je salaris mee rekent van de mensen die het beheren. Is het dan nog steeds zo goedkoop?

Ik ben altijd jaren geweest van het zelf hosten lekker ijzer in de racks hangen met alles echt van jou, maar het bedrijf waar ik nu werk volledig op GCP staan en moet zeggen de flexibiliteit is toch wel echt waardoor ik niet zo gauw meer naar self hosted zou gaan. Je kan je resources echt afstellen op de cores en ram wat je precies op dat moment nodig hebt en met de seconde kan het omhoog en omlaag. Al die underused hardware is het probleem van de cloud leverancier. Als ik over 3 min een server park voor 100 miljoen bezoekers nodig heb schaal ik de boel instant op en is over een uur de hype over schaal ik net zo hard weer terug naar 1 servetje zonder een enkele investering. Ik zou eigenlijk niet anders willen meer.

Maar ergens hoort Tweakers natuurlijk wel gewoon thuis op hun eigen servers met hun eigen setup etc. Om ons af en toe te laten zien wat voor coole dingen ze draaien. Tweakers die naar AWS of GCP verhuisd is ergens dan niet echt Tweakers meer.

Moet wel zeggen dat voor mijn gevoel Tweakers vroeger nog wel echt wat meer Tweaker was ook met hun servers etc dan nu. Nu is het eigenlijk een beetje recht toe recht aan. Paar 1u servers, sannetje erin met 150tb (heb thuis al 30tb in me Synology zitten dus echt amazing is dat verder ook niet) loadbalancertje waarvan verder niets genoemd wordt over type etc en een switch. En dat dan x2 op een andere locatie nog.

Maarja eigenlijk hoeveel heb je nou nog nodig voor een nieuws site met een forumpje enzo vandaag de dag. 20 jaar geleden was dat nog best een uitdaging om dit aan 10 miljoen bezoekers te serveren, maar vandaag de dag doet een beetje 1u server dit met 2 vingers in zijn neus. Video doen ze al niet zelf gaat via youtube gewoon dus ja. De enige uitdaging ligt misschien in de legacy software van pricewatch eigenlijk, maar gewoon een zooi product feeds inladen is vandaag de dag eigenlijk ook niet echt heel speciaal meer.

Tweakers heeft gewoon beetje te maken met dat een site runnen als Tweakers gewoon eigenlijk helemaal niet meer zo moeilijk is meer als dat pak em beet 20 jaar geleden was, waardoor hun server racks eigenlijk ook steeds saaier worden. Beetje jammer maarja het is wat het is

[Reactie gewijzigd door ro8in op 2 januari 2025 20:52]

MsG @pim • 2 januari 2025 09:10

Maak je je dan niet heel erg afhankelijk van heel specifieke API's waardoor je maar moeilijk naar een andere cloud-provider kan overstappen?

CH4OS @MsG • 2 januari 2025 10:14

Met dingen als Infrastructure as Code en bijvoorbeeld Terraform is dat redelijk generiek te maken, zeker in de (Private) Cloud.

Jeoh @CH4OS • 2 januari 2025 13:24

Ik denk dat je overschat hoe generiek je je code kan maken met Terraform. Tuurlijk, het is allemaal Terraform, maar er zitten significante verschillen tussen verschillende providers. Om maar niet te spreken over bijvoorbeeld de functionele verschillen tussen AWS Lambdas, Azure Functions, en Google Cloud Functions...

CH4OS @Jeoh • 2 januari 2025 13:26

Klopt, maar het is gemakkelijker aan te passen dan wanneer je zelf bash scripts zou hebben bijvoorbeeld die specifiek geënt zijn op 1 specifieke provider/doel.

glaaj @CH4OS • 2 januari 2025 13:33

Mwah, dat lijkt me vooral het gevoel wat jij erbij hebt.

Als je diensten van Cloud A/B/C gaat gebruiken dan krijg je dat echt niet zo maar 1,2,3 om naar een andere cloudprovider ookal maak je gebruik van Terraform. Tuurlijk zijn dingen als een VM gemeengoed, maar iedere provider heeft toch zijn eigen twist gegeven aan dat soort diensten waardoor ze uniek zijn ten opzichte van elkaar. En dat kunnen hele simpele dingen zijn die een fundamenteel verschil maken, iets als de manier waarop azure adressen reserveert in een VNET is echt wel anders dan hoe AWS ermee omgaat in een VPC en vice versa.

Het is met Terraform dus echt niet zo dat je een simpele find/replace kunt doen om van `azurerm` naar `aws` en vrolijk init/plan/apply kunt draaien met dezelfde codebase en verwachten dat het werkt.

CH4OS @glaaj • 2 januari 2025 13:35

Maar dat beweer ik dan ook nergens. De Terraform scripts ombouwen zodat ze een andere provider gebruiken, lijkt mij gemakkelijker om te doen dan wanneer je de eigen gemaakte bash scripts van A tot Z kan weggooien, dat is wat ik zeg.

glaaj @CH4OS • 2 januari 2025 13:40

Ombouwen van scripts heb je per definitie niet bij terraform gezien het declaratief gebeurt i.t.t. bash.

Of het echt makkelijker is zal voor het bash gedeelte afhangen hoe complex je scripts in elkaar zitten en wat eraan moet wijzigen om het compatibel te maken.

Voor terraform zit 'm dat (wat mij betreft) eerder bij hoe "intensief" je leunt op de betreffende cloudprovider. (zie het verhaal hierboven).

MsG @CH4OS • 2 januari 2025 10:22

Klopt, maar dit klonk alsof hij rechtstreeks Digital Ocean-specifieke API's aansprak. Als je alle toeters en bellen van de specifieke cloud providers rechtstreeks gebruikt, kom je soms al gauw in een vendor lock terecht van technieken.

pim @MsG • 2 januari 2025 09:38

Niet echt, er zijn maar een paar generieke api calls, die andere cloud hosting providers ook ondersteunen. Zoals het aanmaken/killen van een virtual server. En er vervolgens een bestaande snapshot op installeren. Of het managenvan dns records met api calls.
De logica van balancing doe ik zelf op de servers, niet via digital ocean tools.

BartOtten @pim • 2 januari 2025 11:19

Been there, done that. Reken jezelf niet helemaal rijk met de compatibiliteit met andere providers, dat valt in de praktijk tegen.

Maar het werkt nu, dus vooral zo blijven doorgaan! No time to waste.

Fijne 2025 toegewenst

Frame164 @MsG • 2 januari 2025 18:17

Dat hangt er helemaal van af van hoe ver je gaat met het gebruiken van API's. Hoe meer je gebruik maakt van specifieke API's hoe lastiger het wordt om te migreren. AWS biedt bijvoorbeeld allerlei streamingfunctionaliteit waarmee je heel snel een streamingapplicatie kunt bouwen. Maar je zit dan wel vast aan AWS. Mocht je de weg naar anderen open willen houden dan zou je zoiets alleen voor de eerste opzet willen gebruiken (snelle TTM) en vervolgens een eigen implementatie gaan maken die onafhankelijk van het platform is. Maar dat zijn meer zakelijke keuzes dan technische keuzes.

Scriptkid @pim • 2 januari 2025 13:54

Het is idd raar om te horen dat alle cloud voordelen hier in het filmpje worden afgedaan als juist de nadelen.

Juist het beheer van de hardware, firmwares drivers + de echte hosting kosten en stroom kosten zijn vaak de voordelen van de prijs van de cloud.

Moet je natuurlijk geen lift en shift gaan doen maar ook cloud native gaan designen. (Je gebruikt een BD instace en host geen windows DB server in de cloud)

borft @Scriptkid • 3 januari 2025 09:51

mwah, dat is wel heel kort door de bocht. Bij veel van de cloudnative, hosted database oplossingen word je sterk gelimiteerd in mogelijkheden voor configuratie. Als je, vanwege je applicatie / workloads een afwijkende configuratie nodig hebt, word je al snel naar het zelf hosten (lees db app op een vm), of een te grote instance geduwd, met alle extra kosten die daarbij komen.

Juist als je je eigen applicatie en workload heel goed kent, en genoeg kennis hebt om zelf te beheren, is het zeker niet ondenkbaar dat er een goeie business case te maken is voor self-hosten op bare metal (al is het alleen maar vanwege de maximale flexibiliteit qua hardware en software setup).

2 januari 2025 11:08

Heel interesant om te zien!

In die video zijn nauwelijks vendor logo's te zien. Wellicht is dat opzettelijk, maar kunnen jullie iets zeggen over welk melk/leverancier Tweakers gebruikt? Is dat dezelfde leverancier als toen er nog bare-bones gekocht werden? En wellicht het meest interessante: vanwaar de keuze voor een specifiek merk/leverancier? Maakt het voor de keuze nog uit dat Tweakers onder de de DPG paraplu valt?

Ik heb het idee dat het aantal bare-bones de laatste 2 jaar behoorlijk afgenomen is in de Pricewatch. Heeft dat nog iets te maken met het overstappen naar complete systemen?

Kees BOFH

Netwerk en systeembeheer

@Sanjuro • 2 januari 2025 11:34

Servers: Dell (met een enkele HP van 8 jaar oud die we als test hadden gekocht).
Switches: Juniper (en een verdwaalde procurve en cisco nog ergens)
Firewalls: Fortigate

In het verleden kochten we vaak meer een mengelmoes aan merken, we hebben 6-jaar lang IBM gekocht bijvoorbeeld en er zit ook een verdwaalde HP server ergens in het rack. En dat heeft inderdaad met DPG te maken. We kregen de vraag waarom wij IBM kochten terwijl Dell de prefered supplier was binnen DPG met als tweede optie HP. We hebben toen voor een aantal servers offertes opgevraagt aan IBM, Dell en HP (via DPG). De offerte van IBM was bijna 20% lager dan de andere twee. Toen ik dat liet zien aan degene die er vragen over stelde was het een jaar stil. Na een goed jaar kreeg ik de vraag om die oefening nog een keer te doen, en nu was de Dell offerte via DPG 5% lager dan IBM en had ik geen reden meer om IBM te kopen. Sindsdien kopen wij Dell servers.

De barebones/zelfbouw die wij kochten waren nog meer een mengelmoes van alles. Van supermicro naar procase tot chenbro met nog ergens een Compaq een keer.

De pricewatch houd ik niet bij, dus waarom de barebones daar zijn afgenomen weet ik niet.

[Reactie gewijzigd door Kees op 2 januari 2025 11:36]

SwerveShot @Kees • 2 januari 2025 11:40

Is er eigenlijk ooit een opvolger gekomen van de stats pagina? Ik lees wel dat deze ooit uitgefaseerd is omdat er informatie van oude systemen stond: https://gathering.tweakers.net/forum/list_messages/2053220

Kees BOFH

Netwerk en systeembeheer

@SwerveShot • 2 januari 2025 11:50

Dat was vrij oude code uit 2002 en behoorlijk statisch; ik moest hem dus handmatig updaten en dat vergat ik regelmatig. Toen we begonnen was dat ook onze enige monitoring; tegenwoordig hebben we veel meer.

tweazer @Kees • 2 januari 2025 21:58

monitoring; tegenwoordig hebben we veel meer.

Is daar iets van te zien/lezen ?

PS ik zou wel esd maatregelen nemen, even 'hier en daaren' met een vonkje en het is gebeurd ..
PS2 met die ssd's, hoe houd je de wear leveling/levensduur in de gaten ?

Netwerk en systeembeheer

@Kees • 2 januari 2025 13:31

Sowieso niet vergeten van die oefening regelmatig te herhalen

Zeker als ineens prijzen bij Dell sterk omhoog gaan. Zo zijn wij voor laptops overgestapt van Dell naar HP. Het laatste duwtje dat we nodig hadden was dat Dell ineens met een prijs voor het nieuwe model kwam dat dubbel zo hoog was als het vorige. Toen we vroegen of het een grapje was, antwoorde men dat het dat niet was, ondanks dat de laptops commercieel, inclusief BTW, op hun eigen site goedkoper te kopen waren. Na wat heen en weer hadden ze de prijs uiteindelijk wel verlaagd, maar damage done op zo een moment.

Ongetwijfeld is men destijds met jullie offerte van IBM ook naar Dell getrokken om een grotere korting te kunnen bekomen.

Frame164 @Blokker_1999 • 2 januari 2025 18:27

Het zijn dagprijzen.... Als de targets gehaald zijn kan de prijs wat omhoog, en mocht een deal niet doorgaan is er geen man overboord. Of als er een opdracht is waar mee aan verdient kan worden gooien ze de prijs omhoog omdat ze eigenlijk geen zin hebben om te leveren.

Scriptkid @Blokker_1999 • 3 januari 2025 10:13

je hebt ook nog zoiets als software en drivers,

Moet zeggen dat ik HP echt een ramp vind met hun management en ILO interfaces en nog maar niet te spreken over hun sea of sensors,

Ik preffer zelf echt wel dell als het om servers gaat.

SwerveShot @Sanjuro • 2 januari 2025 11:18

Easy, lees deze post maar en je weet iets over de netwerk infra: https://tweakers.net/plan...-switches-van-arista.html. Al is dat ook wel weer een gedateerd artikel. De firewalls zijn nog overduidelijk fortigates, maar dan een nieuwer type. Qua switches kun je het wat lastig zien in de video. Qua servers herken ik wel vrij duidelijk dat het Dell PowerEdges zijn.

[Reactie gewijzigd door SwerveShot op 2 januari 2025 11:20]

DaanHetEendje 2 januari 2025 08:02

Leuk om te zien! Zie heel veel overlap met ons. Draaien jullie Kubernetes barebone of gevirtualiseerd? En zo ja, welke software gebruiken jullie daarvoor?

"Linux" voor het OS is ook zo'n breed begrip. Ben ook wel benieuwd of dit Debian of Redhat gebaseerd is

Kees BOFH

Netwerk en systeembeheer

@DaanHetEendje • 2 januari 2025 08:34

We doen beide

We draaien de productie-kubernetes op bare metal, waarbij we kubernetes nog een beetje misbruiken door niet perse kubernetes alles te laten doen. Zo zitten bijvoorbeeld de memcache servers 'gewoon' op het host netwerk en vast op drie nodes om de overhead van kubernetes networking/proxy te voorkomen. Andere services waar latency minder boeiend is (bijvoorbeeld de image generator/cache) draaien we wel als een service in kubernetes. En de loadbalancer zit ook buiten kubernetes, want die hadden we al. (Een van de meest behulpzame guides om Kubernetes te leren vond ik Kubernetes: the hard way. Vooral om te leren waarom iets zo werkt in kubernetes)

Daarnaast draaien we nog een development kubernetes voor onze test omgevingen waar we voor elke feature-branch een nieuwe omgeving opzetten in een nieuwe namespace. Maakt het opruimen of restarten ook erg makkelijk; namespace weg is omgeving weg. De virtualisatie word gedaan door Qemu/KVM/virtmanager

En ja, "linux" is een breed begrip, dat doe ik met een reden. We draaien voornamelijk debian-based, maar zijn bezig om van Ubuntu naar Debian over te stappen, dus dat is nu nog een mix. Maar er zitten ook een paar servers op een redhat-based distro waar we nog geen echt goede vervanging voor hebben. Dan moet je denken aan FreeIPA die nu nog op centos draait (maar naar een Rocky container met een debian docker-host gaat binnenkort) en een drietal vm's die AlmaLinux draaien voor een stuk software van een externe leverancier.

[Reactie gewijzigd door Kees op 2 januari 2025 08:38]

superbikkel @Kees • 2 januari 2025 13:25

Wat is de reden waarom jullie van Ubuntu naar Debian over stappen?

Kees BOFH

Netwerk en systeembeheer

@superbikkel • 2 januari 2025 13:42

Ik wilde Ubuntu voor de snellere releases, maar dat is geen reden meer met docker containers, dan zit ik liever dicht bij de source.

En snap en de reclame voor ubuntu pro en reclame in de motd hielpen ook niet mee. Debian is meer wat ik van een distro verwacht en heeft niet de onnodige poespas van Ubuntu.

Maar de druppel was het verdwijnen van de mini.iso en dat is hoe ik de servers via de remote access card installeer, dan heb ik liever een iso van 60mb die in een paar seconden opstart dan een iso van 4gb waar het 10 minuten duurt voordat hij is opgestart.

Netwerk en systeembeheer

@Kees • 2 januari 2025 13:26

Nu ben ik wel benieuwd naar wat de motivatie is om van Ubuntu naar Debian te gaan.

Q @Blokker_1999 • 2 januari 2025 17:54

Deze gezien? Kees in 'Dit is hoe we Tweakers hosten - 1320 cores, 5 TB ram en 364TB opslag'

Jay-v 2 januari 2025 13:23

Super tof om te lezen/zien dat Tweakers (deels) over is op Kubernetes. Draaien jullie baremetal op iets als Talos?

En voor "development Kubernetes", gebruiken jullie vcluster? Of bedoelt @Kees echt namespaces op hetzelfde cluster?

Hoe wordt er ge-deployed? GitOps ArgoCD/Flux? Helm of Kustomize?

En waarom hosten jullie zelf images/videos? Is een s3 achtige oplossing niet veel praktischer dan het zelf te doen in CEPH?

Verder ben ik heel benieuwd wat er nog meer uit het CNCF eco systeem gebruikt wordt :-).

Kees BOFH

Netwerk en systeembeheer

@Jay-v • 2 januari 2025 13:54

Op het metaal draait 'gewoon' debian, met name omdat we nog niet alles helemaal virtueel hebben draaien en het dan wel handig is om die servers ook gelijk te kunnen houden met wat er in de images draait (die debian-slim als base hebben).

En ja, in het development cluster maken we een namespace en daarin deployen we dezelfde omgeving die een developer ook lokaal kan draaien. Maakt het opschonen ook eenvoudig; namespace weg = environment weg.

Voor deployen gebruiken we gitlab pipeline die een helm chart uitvoert/deployed. Deployen naar productie gaat met ook met gitlab maar heeft iets meer stappen; ook omdat we daar nog een deel rsyncen (wat we al sinds ~2006 doen, dus daar is nog niet al te veel aan aangepast). De meeste services (zoals memcached/thumbor/mongo etc) hebben ook helm charts die RenovateBot up-to-date houd en we regelmatig deployen.

En waarom zouden we de images/video's niet zelf hosten? S3 kan behoorlijk duur worden en ceph is niet heel erg ingewikkeld (en heeft ook een S3 interface wat we ook gebruiken

). We gebruiken overigens voornamelijk cephfs, wat een soort van nfs is die we op alle servers beschikbar hebben.

Het grootste voordeel is dat we het allemaal lokaal hebben en dus met 25gbit/s kunnen uitlezen en ons geen zorgen hoeven te maken over hoeveel requests we doen, hoeveel we opslaan en wat de maandelijkse rekening is.

Jay-v @Kees • 2 januari 2025 14:05

Renovate.

In mijn ervaring kan s3 voordelig zijn. Zeker in combinatie met tiering naar goedkopere storage classes en een CDN welke aan de voorkant alles cached. Waarom? Gemak, betrouwbaar durable. Zelf doen via CEPH, waarschijnlijk goedkoper als ik alleen de infra hoef te betalen

.

Kees BOFH

Netwerk en systeembeheer

@Jay-v • 2 januari 2025 14:46

Ik ben ook wel naar S3 aan het kijken, en dan voornamelijk voor backups - ik ben nog niet helemaal tevreden hoe we die nu doen (eerst op locatie zelf, en dan nog een keer naar kantoor/offsite). En daar wil ik dan wel S3 glacier voor gaan gebruiken. Nu nog een goed programma daarvoor vinden, want weinig zin om alles zelf te scripten

@Kees • 2 januari 2025 15:19

Een dikke tape library in een bezemkast op kantoor is waarschijnlijk stukken goedkoper dan een glacier abonnement.

Jay-v @FrankHe • 2 januari 2025 15:44

Tot je er achterkomt dat je een externe firma moet betalen om elke dag een doosje tapes te komen wisselen (en naar een externe brandveilige kluis te brengen).

@Jay-v • 2 januari 2025 15:56

Het kantoor is al een off-site lokatie, het datacenter staat aan de andere kant van de stad. Als de bezemkast op kantoor onder water staat dan heb je nog steeds alle data in de twee datacenters.

ACM Software Architect @FrankHe • 2 januari 2025 22:53

Dat valt nog wel wat "tegen" die afstand. Sinds de verhuizing is het hemelsbreed nog maar zo'n 700 meter tov de hoofdlocatie

Naar de andere locatie is het dan gelukkig nog wel bijna 10km hemelsbreed vanaf het kantoor.

[Reactie gewijzigd door ACM op 2 januari 2025 22:53]

Scriptkid @ACM • 3 januari 2025 10:17

10 Km is wel ver binnen je rampen plan cirkel,

Dacht dat je toch minimaal 100 KM aan moet houden en serieuze datacenters zitten op 300 Km.

@ACM • 3 januari 2025 12:00

Ja natuurlijk, jullie zijn verhuisd naar Overamstel. In mijn hoofd zaten jullie nog steeds bij NDSM in Amsterdam Noord maar dat is al even niet meer. Die 700 m is inderdaad net wat te dichtbij wanneer je zuiver kijkt naar geografische spreiding.

Jay-v @Kees • 2 januari 2025 15:31

Ik doe dit momenteel (naar s3it, niet Glacier) met Kopia, gebruikt zstd compressie (dat is fijn want parallel compression = snel).

Zstd benchmarks: https://facebook.github.io/zstd/#benchmarks

[Reactie gewijzigd door Jay-v op 2 januari 2025 15:47]

@Jay-v • 3 januari 2025 12:02

Hoeveel compressie behaal je dan in de praktijk. Ik neem aan dat er op lossy afbeeldingen zoals jpeg geen winst valt te behalen?

Jay-v @FrankHe • 3 januari 2025 13:21

Dat ligt natuurlijk grotendeels aan het soort data, er zijn genoeg benchmarks te vinden voor zstd. Nu is compressie voor mij niet het belangrijkste, maar het samenvoegen van kleine files in grotere chunks (beter voor de kosten)

C0okiejar @Kees • 2 januari 2025 17:27

Afhankelijk van hoe je je backups nu draait kan RCLONE interessant zijn, super simpele copy / move functie met eventuele logs, checks etc.

jep @Kees • 2 januari 2025 20:18

Dan zou ik ook eens naar Minio kijken. Prachtige software die we al lang en met plezier gebruiken. Je kunt er natuurlijk mee repliceren naar andere locaties, maar ook naar AWS e.a.

@Kees • 2 januari 2025 14:23

Storage buckets kunnen inderdaad flink in de papieren lopen. Dan is een eigen opslagcluster best een verstandige keuze.

Sjaakys 2 januari 2025 10:52

Wat is me mij afvraag, zijn de switches ook als stack uitgevoerd? Maw als er 1tje uitvalt neemt de andere het over. En wat is de motivatie dat jullie niet voor SFP+ switches hebben gekozen met optie tot glasvezel naar de servers / andere apparatuur? Is het een kostenoverweging of iets anders? Ik ben erg benieuwd.

Kees BOFH

Netwerk en systeembeheer

@Sjaakys • 2 januari 2025 11:27

We hebben beide, maar de switches zitten bewust niet in een stack. In mijn ervaring gaat zo'n hele stack vaker stuk dan een paar kabels tussen switches en 'gewoon' stp en bonding/trunk/port-channels.

De switches aan de achterkant van het rack zijn bewust cat-5, dat zijn de (1gbit) backupswitches waar ook alle management poorten aangesloten zijn (en dat is altijd cat5, en nooit sfp). De switches aan de voorkant zijn 48x 25gbit sfp. De servers zitten minimaal 1 keer aangesloten op die 25gbit switches en 1 keer op de gbit switches. En alle switches zijn met minimaal twee kabels aangesloten op minimaal twee andere switches. Er zitten ook een aantal servers (zoals database en loadbalancers) aangesloten op beide 25gbit switches met een MLAG configuratie waardoor die de volle snelheid kunnen blijven gebruiken als er een switch uitvalt.

[Reactie gewijzigd door Kees op 2 januari 2025 11:27]

tormentor1985 2 januari 2025 09:59

Leuk om weer eens te zien. Valt me echt mee wat jullie hebben draaien.

Wat ik mij afvraag gebruiken jullie ook applicaties waarom quorum based consensus nodig is? Of is alles op basis van replica's? Ik loop nog wel eens tegen applicaties aan waar 2n+1 nodig is en dan is zelf in dual dc opstellingen beter om zaken als elasticsearch in slechts 1 datacenter te plaatsen omdat je in een dual dc nooit een meerderheid kan garanderen.

Het is dan dus kiezen, of triple dc of alle nodes in 1 datacenter. Hoe gaan jullie eventueel met dit soort uitdagingen om of is het niet van toepassing omdat alles replica based is?

Kees BOFH

Netwerk en systeembeheer

@tormentor1985 • 2 januari 2025 10:10

Er zijn inderdaad een aantal applicaties met een quorum zoals Ceph en Mongodb. We verdelen die bewust wel over twee locaties. Mocht de verbinding tussen die locaties wegvallen, maar beide locaties wel doordraaien, dan zetten we 'gewoon' de backup locatie tijdelijk uit (als in: niet gebruiken, alles blijft wel draaien).

Mocht de hoofdlocatie permanent onbereikbaar worden, dan hebben we in elk geval alle data op de andere locatie en kunnen we daar het aantal members omlaag zetten als de hoofdlocatie niet binnen korte tijd terug is. Dat maakt de initiele recovery eenvoudigerer omdat je geen backup terug hoeft te zetten, maar het maakt de recovery als de hoofdlocatie terug komt wel iets lastiger. We gaan er dan ook van uit dat er wel een klein beetje dataverlies zal optreden op dat moment. Split brain is lastig om goed op te vangen en soms verlang ik wel terug naar de tijd dat alles op 1 locatie draaide, dat was een stuk eenvoudiger

tormentor1985 @Kees • 2 januari 2025 10:42

Lastig

Ondanks dat de kans klein is heb ik het eens meegemaakt dat een black-out test succesvol was en daadwerkelijk in een black-out resulteerde waardoor we het quorum verloren met downtime als gevolg

Is het voor jullie dan ook niet beter om nog een derde locatie te hebben? Mijn ervaring was in dit geval dat de kans op failures immers met een factor 2 is toegenomen gezien er twee keer zoveel kans was op outages.

Kees BOFH

Netwerk en systeembeheer

@tormentor1985 • 2 januari 2025 11:21

De grootste veroorzaker van downtime is toch wel menselijk handelen dus ik probeer mijn setups zo simpel en robuust mogelijk te houden. De tweede veroorzaker is stukke hardware, dus dat voeren we redundant uit.

Een derde locatie heb ik wel regelmatig naar gekeken en ook al een paar keer opgezet, maar de networking en routing word dan een stuk lastiger. Ook moet je kijken naar het risico dat een locatie volledig uitvalt, in mijn ervaring is die niet bijzonder groot en met de tweede locatie erbij kun je al een heleboel afvangen. En als laatste is er ook nog altijd het budget; Een beetje downtime met een goede reden is minder erg dan heel veel extra geld uitgeven met het risico dat er nog meer banen verdwijnen bij Tweakers.

@Kees • 2 januari 2025 13:38

Mee eens. In mijn ervaring spelen de kosten niet op tegen de baten. Met een goede risico-analyse kan je een boel zaken uitschakelen, én heb je inzichtelijk gemaakt dat het wel een risico is, maar is dat geaccepteerd.

De verzekeraar waar ik voor gewerkt heb, had ook maar 2 locaties met realtime synchronisatie en dagelijkse back-ups.
De rest was met een risico-analyse afgedekt

@metalmania_666 • 2 januari 2025 14:15

Inderdaad, op een gegeven moment wordt het een gecalculeerd risico. Hoe ver wil je gaan met 'high availability' en hoeveel mag het kosten? Als Tweakers er een keer vier uur uit ligt dan gaan er geen mensen dood en is er niemand die miljoenen aan inkomsten misloopt. De kans dat de boel er daadwerkelijk helemaal uit ligt is zo bijzonder klein dat investeringen niet economisch verantwoord zijn.

Scriptkid @tormentor1985 • 3 januari 2025 10:27

Een 3de locatie maakt de configuratie dermate complex of het moet echt 3 eilandjes zijn waar de meeste DC momenteel niet op ingericht zijn.

immers moeten alle connecties naar het 3de data center direct verlopen als een mesh waar je bij heel veel bedrijven ziet dat de data verbining van het 2de DC via de eerste loopt tot dat er een outage is omdat dat veel goedkoper is.

en dan werkt je 3de qourum locatie alleen maar tegen je want de convergence tijd killed je cluster

tormentor1985 @Scriptkid • 3 januari 2025 11:22

Het gaat denk ik vooral om het doel wat je wil bereiken. Het voorkomen van downtime of het voorkomen van data verlies.

In dit geval is de keus gemaakt data verlies te voorkomen en is downtime acceptabel omdat de kosten voor een cross connect fabric te duur is en het risico beperkt. Prima keus verder. Het is immers een nieuws website en geen infrastructuur waar mensenlevens van afhankelijk zijn

Rambolinie 2 januari 2025 13:33

Bedankt voor de video, ooit weleens gezien maar nooit zo een korte uitleg over gekregen.

Wat ik me wel afvraag, waarom hebben die SSD's allemaal afwijkende groottes t.o.v. de huis tuin en keuken SSD's?

@Rambolinie • 2 januari 2025 14:23

Wat ik me wel afvraag, waarom hebben die SSD's allemaal afwijkende groottes t.o.v. de huis tuin en keuken SSD's?

Server-SSD's geven ruim betere performance-garanties dat gewone consumenten-SSD's. Daar waar een consumenten-SSD flink trager wordt als je er een langere tijd een hogere (vooral schrijf-intensieve) belasting op plaatst, vertragen server-SSD's niet of nauwelijks. Dat komt niet alleen doordat er een controller op zit die meer energie kan/mag verbruiken en betere koeling, maar ook omdat een deel van het NAND 'achtergehouden' wordt. Dat geeft de controller extra speelruimte om op een 'volle' schijf direct met volle snelheid te kunnen schrijven, omdat er gewoon nog ruimte beschikbaar is, en er niet eerst daadwerkelijk nog blokken gewist moeten worden. Ook biedt het de ruimte om 'overschreven' of gewiste data pas echt weg te halen op een moment dat het handig uitkomt.
Praktisch gezien kom je daarmee vaak uit op dat er eenzelfde hoeveelheid flashopslag in zit als een consumenten-SSD, met de capaciteit van de server-SSD afgerond naar boven.

Kees BOFH

Netwerk en systeembeheer

@Rambolinie • 2 januari 2025 14:51

Gereserveerde ruimte. Een 1.6TB enterprise ssd is "gewoon" een 2TB ssd met 20% extra ruimte gereserveerd voor 'bad blocks' en performance verlies als je hem te vol schrijft.

0siris 2 januari 2025 13:44

Hallo Kees,
Ik heb door de jaren heen gesmuld van de .plans, waarin grote en in theorie goede plannen nogal eens werden neergesabeld door de prakijk: oplossingen die in de praktijk niet goed werkten, een gammele netwerkkaart ergens, OS dat niet wilde meewerken, iets dat net niet past, noem het maar en je hebt er wel eens last van gehad. De IT waarin ik mij in die tijd begaf, was eigenlijk hetzelfde. Vraag aan jou: hoe is jouw werk veranderd? Ik neem aan dat je stukken minder dan in het begin bezig bent met fysiek ijzer passend te krijgen met spuug, duct tape, paperclips en finger-crossing?

Kees BOFH

Netwerk en systeembeheer

@0siris • 2 januari 2025 14:50

Klopt, vroeger was ik veel meer bezig met bijvoorbeeld een database die bokte, of een storage server die er willekeurig mee ophield. Bovendien was vroeger lang niet alles toolless, en ik heb toch best wat bloed verloren aan diverse kooimoeren

Tegenwoordig ben ik de meeste tijd kwijt aan het up-to-date houden van software, het monitoren van de servers (om te zien of er geen gekke dingen gebeuren), de deploy-pipelines in gitlab in de gaten te houden en nieuwe zaken uit proberen.

@Kees • 2 januari 2025 15:21

Hardware tuning is waarschijnlijk iets uit het verleden? De werkzaamheden zitten meer in de abstracte lagen?

Kees BOFH

Netwerk en systeembeheer

@FrankHe • 2 januari 2025 15:40

Klopt, vroeger was hardware tuning nog veel belangrijker. Als je van 1 cpu/core naar 2 cpu/2cores ging dan was dat een gigantische upgrade, maar van 32 cores naar 64 cores merk je veel minder dat het iets sneller is.

Ook geheugen upgrades waren veel belangrijker, als je van 8GB naar 16GB ging en je 'working set' paste ineens in het geheugen, dan was de site gewoon in eens twee keer zo snel. De working set is niet heel veel groter geworden, en van 256GB naar 512GB deden we gewoon omdat het in het budget paste en geheugen op dat moment goedkoop was

@Kees • 2 januari 2025 15:53

Wat betreft resources is het tegenwoordig echt heel erg luxe. Te veel geheugen bestaat eigenlijk niet, zoals je zegt, je koopt wat het budget toelaat en daar doe je het mee. Vroeger was het duwen en persen en tegenwoordig zwemmen de servers in het geheugen. Best wel prettig!

Kees BOFH

Netwerk en systeembeheer

@FrankHe • 2 januari 2025 15:55

Klopt helemaal. Zo hebben sommige servers bijvoorbeeld 64G geheugen, maar word er standaard minder dan 30G gebruikt. Maar het verschil tussen 32 of 64G geheugen was tientjeswerk, dus dan kopen we ze maar op de groei

@Kees • 2 januari 2025 16:17

Zeker met de wetenschap dat prijzen van geheugen en SSD's nog wel eens kunnen fluctueren is het een gemakkelijke beslissing om op een relatief laag prijsmoment je server meteen helemaal vol te stouwen. Zelf heb ik voor m'n homelab in 2023 een Intel NUC aangeschaft en daar direct de volle 64 GB in gestoken. In de parktijk gebruik ik nog niet eens een kwart daarvan maar je denkt er niet bij na omdat het zoals je zegt om een paar tientjes gaat. Een SSD die ik in der tijd heb gekocht was vorig jaar trouwens in prijs verdubbeld. Dingen kan gek lopen.

2 januari 2025 15:49

Leuke video die weer een up to date beeld geeft van de build

Tijdens de video was ik al benieuwd of er ook met server GPU's wordt geëxperimenteerd voor bijvoorbeeld beeldherkenning (immich bijvoorbeeld). Maar toen @WoutF zijn inner YouTuber aanzette kreeg ik al mijn antwoord

Wel benieuwd of daar plannen voor zijn of is er juist nog geen logische use-case?

Kees BOFH

Netwerk en systeembeheer

@mailis • 2 januari 2025 15:59

Wij hebben nog niet echt een goede usecase gevonden waar wij gpu's nodig voor hebben.

@Kees • 2 januari 2025 17:05

Thanks! Puur hypothetische vervolgvraag (en wellicht ook niet te beantwoorden omdat er geen use case is), maar mocht je dit willen opzetten, hoe zou je dit aanpakken? Dedicated server of ergens bij prikken, welke GPU, welk budget, andere overwegingen?

Kees BOFH

Netwerk en systeembeheer

@mailis • 2 januari 2025 17:08

Dat zal dan waarschijnlijk quotes opvragen worden. Grote kans dat het dan "gewoon" een nVidia H100 word, dat lijkt toch wel de meest populaire kaart om te gebruiken volgens mijn 1-minuut durende google search

Octium 2 januari 2025 16:27

Waarom zie ik geen ESD polsbandjes gebruikt worden?

@Octium • 2 januari 2025 16:51

Misschien buiten het shot staan ze natuurlijk op een ESD vloer @Kees en @WoutF hebben een ESD schoenbandje om. Dan is dat bandje wat altijd in de weg hangt niet nodig.

Octium @RobbyTown • 2 januari 2025 19:29

2:01 meneer met rode trui lijkt geen ESD schoenen aan te hebben en al zeker geen ESD jasje (net als andere persoon, die heeft ook geen ESD jasje aan)
3:01 blauw kartje zeker geen ESD veilig karretje
6:36 geloof niet dat dit ESD veilige tafels zijn, zie namelijk geen aansluitbutton zitten voor polsbandje.
9:57/10:27/11:51: zou nooit zo open en bloot componenten uitnemen zonder polsbandje en geen ESD jas / schoenen e.d.

Misschien toch een keer een special over ESD op tweakers? Zie daar heel veel fouten mee gemaakt worden in de praktijk en veel te veel nonchalantie.

PaulHelper @Octium • 3 januari 2025 09:32

Geen expert maar is het echt nog nodig. Bij LTT doen ze daar eigenlijk ook niet echt aan, hij heeft wel eens getest wat het kan doen en daar kwam uit bijzonder weinig. Daar was de conclusie dat nieuwe componenten en hardware daar grotendeels opgemaakt zijn en dit geen probleem is. Als het wel een probleem zou zijn zou tweakers hier toch ook veel voorzichtiger mee zijn

Scriptkid @Octium • 3 januari 2025 10:23

ik denk dat we met een groep van 40 engineer , 10 jaar lang server maintenance gedaan hebben inc hardware swappen,

nog nooit heeft iemand maar iets aan ESD safe aangehad of gewerkt en nooit ook maar een storing hier door gehad.

Belangrijkste is denk ik geen wollen trui hebben of uitdoen net voordat je begint verder zijn er weinig sources die je zo statische laden dat het niet ontladen is zodra je een server aan raakt en dus aarde maakt.

FastFred @Octium • 3 januari 2025 14:49

Heel eerlijk, op school werd dat ESD er bij mij ook ingehamerd. Ik moet de eerste computer nog tegen komen die ik gesloopt heb door geen ESD bandje te dragen/schroevendraaier met magnetische kop te gebruiken en ik doe dit inmiddels 17 jaar ofzo. Is iets van de boomer/geitenwollensokken generatie van IT'ers als je het mij vraagt die angst voor static discharge.

Goed, als ik op het werk een server open trek om een fan of RAM latje te wisselen, dan doe ik wel een ESD bandje om, server is dan ook iets duurder dan mijn pc thuis, maar eigenlijk vind ik het onzin.

[Reactie gewijzigd door FastFred op 3 januari 2025 14:51]

Om te kunnen reageren moet je ingelogd zijn