Nieuwe databaseserver - Development-iteratie #146

Onze developers hebben dinsdag development-iteratie #146 opgeleverd. Tijdens deze sprint hebben we een nieuwe databaseserver in gebruik genomen en de duiding van gesponsorde gebruikersreviews verbeterd.

Nieuwe databaseserver

Afgelopen maandag hebben wij een nieuwe databaseserver in gebruik genomen. Dankzij de replicatie van MySQL ging dit vrijwel zonder overlast voor de gebruikers.

Traditiegetrouw herhalen we bij een nieuwe databaseserver de specs van de voorgangers vanaf de eerste Artemis uit 2000. In ongeveer achttien jaar hebben wij de databasesever geüpgraded van twee singlecore PIII's op 733MHz naar twee zescore-3,4-4,0GHz Xeon 6128 Gold-cpu's. Ook het geheugen is aardig gegroeid sinds de eerste Artemis en de nieuwe server heeft met 512GB geheugen maar liefst 341 keer meer dan zijn tegenhanger in 2000.

Om ervoor te zorgen dat de database na een reboot ook nog data bevat, hadden we in de eerste iteratie de beschikking over drie 18GB-Cheetah's in raid-5 die 15.000 keer per minuut een rondje draaiden. De laatste databaseserver heeft uiteraard geen ronddraaiende platters meer, maar heeft de beschikking over vier 960GB Intel S4500-ssd's in raid-10. De volledige lijst met servers die trouw jullie reacties en forumposts hebben opgeslagen, staat hieronder.

Naam	Cpu	Geheugen	Opslag
Artemis 1	2x PIII 733MHz-1GHz	1,5GB-4GB PC133 sdr	1x 20GB ata 3x Seagate Cheetah X15 18GB
Apollo 1	2x PIII 1GHz	2GB-4GB PC133 sdr	2x Quantum Atlas 10K II 18GB
Artemis 2	2x Athlon MP1600+ 1,4GHZ	2GB ddr-266	1x 20GB ata 5x Seagate Cheetah X15 18GB
Apollo 2	2x Athlon MP 1900+ 1,6GHz	3,5GB ddr-266	1x 20GB ata 5x Seagate Cheetah 36XL 36GB
Artemis 3	2x Opteron 246 2,0GHz	4GB ddr-266	2x Seagate Cheetah 18XL 9GB 4x Seagate Cheetah 10K.6 36GB
Apollo 3	2x Opteron 242 1,6GHz	6GB ddr-266	6x Seagate Cheetah 10K.6 36GB
Artemis 4	2x Opteron 254 2,8GHz	8GB ddr-333	2x Seagate Cheetah 10K.6 36GB 6x Seagate Cheetah 15K.3 36GB
Apollo 4	2x Opteron 244 1,8GHz	8GB ddr-333	2x Seagate Cheetah 10K.6 36GB 6x Seagate Cheetah 15K.3 36GB
Artemis 5	2x Xeon X5355 2,66GHz	16GB ddr2-667	2x Seagate Savvio 10K.2 73GB 15x Seagate Cheetah 15K.5 73GB
Apollo 5	2x Xeon 5160 3,0GHz	16GB ddr2-667	2x 73GB 10K SAS 15x Fujitsu MAX3036RC 36GB 15K sas
Artemis 6	2x Xeon X5570 2,93GHz	72GB ddr3-800	2x Seagate Savvio 10K.3 300GB 6x Samsung-ssd 50GB
Apollo 6	2x Xeon 5660 2,80GHz	48GB ddr3-1066	2x Seagate Savvio 10K.3 300GB 6x Samsung-ssd 50GB
Artemis 7	2x Xeon E5-2643 3,3GHz	256GB ddr3-1600	2x IBM 250GB sata 6x Intel 256GB-ssd
Apollo 7	2x Xeon E5-2643 3,3GHz	256GB ddr3-1600	2x IBM 500G sata 6x Intel S3500 240GB-ssd
Artemis 8	2x Xeon E5-2643 v3 3,4GHz	256GB ddr4-2133	2x HP 80GB Value-ssd 6x HP 240GB Value-ssd
Apollo 8	2x Xeon E5-2643 v4 3,4GHz	256GB ddr4-2400	2x 1TB sata 6x Intel S3510 800GB
Artemis 9	2x Xeon 6128 Gold 3,4GHz	512GB ddr4-2666	2x 240GB m2-ssd 4x Intel S4500 960GB-ssd

De oude databaseserver krijgt een nieuw leven als onderdeel van onze developmentomgeving.

De nieuwe (boven) en de vertrekkende databaseserver

Duiding van gesponsorde gebruikersreviews

Om de achtergrond van een reviewer beter te duiden, tonen we bij productreviews van gebruikers die regelmatig gesponsorde reviews schrijven, hoeveel reviews zij in het afgelopen jaar hebben geproduceerd en welk percentage daarvan gesponsord was. Deze informatie wordt alleen getoond bij users die twee of meer volledig of gedeeltelijk gesponsorde reviews hebben geschreven.

Switchen tussen uitvoeringen op mobiel

Op mobiele devices hebben we het makkelijker gemaakt om te wisselen tussen uitvoeringen van een product door een selectbox met de uitvoeringen onder de productnaam weer te geven. Voorheen was het niet mogelijk om op mobiel snel naar andere uitvoeringen van hetzelfde product te navigeren.

Ingebruikname Thumbor voor afbeeldingen in Vraag & Aanbod

In Vraag & Aanbod maken we nu net als in redactionele artikelen en de Pricewatch gebruik van Thumbor voor het verkleinen van afbeeldingen. Dit levert een sneller uploadformulier op, omdat het maken van verkleiningen op verzoek en asynchroon plaatsvindt.

Reacties (130)

[Balance]

@Kees @ACM
Leuke update! Waarom dual socket? Is dat een stukje redundancy, of hebben jullie de geheugenbandbreedte nodig? Qua CPU performance zou je bijvoorbeeld ook met een Xeon Gold 6136 uit de voeten komen.

Is AMD Epyc ook overwogen? Bijvoorbeeld 2x Epyc 7261 of 1x Epyc 7351P lijkt best vergelijkbaar voor een stuk minder geld.

Anyway, mocht iemand tijd hebben om een achtergrond artikel(tje) te schrijven denk ik dat veel Tweakers dat tof zouden vinden!

[ACM]

Als je verwacht dat we een heel uitgebreide analyse hebben gedaan van de cpu's en willekeurig welke combinatie andere van onderdelen, dan moet ik je helaas teleurstellen.

We hebben sowieso onze keuze beperkt tot Dell, omdat ons moederbedrijf daar een voorkeur voor heeft (en bijbehorend scherp kan inkopen), onze meeste hardware al Dell is en we ook geen andere redenen hebben om iets anders te willen (ervaring met support is bijv ook prima). Zo te zien heeft Dell trouwens geen 2x Epyc servers in 1U en zou je dan uitkomen op de R7425 die als chassis zelf iig duurder is dan deze R640.

Verder heeft Kees al in andere reacties aangegeven dat we in de praktijk met name baat hebben bij hele snelle cores en niet zozeer bij cpu's met meer cores die uiteindelijk cummulatief meer 'rekenkracht' hebben, maar per core niet. We hebben normaal gesproken lang niet alle kernen tegelijk continu belast, meestal zijn het er maar een paar die bezig zijn.
Maar die paar die bezig zijn, hebben dan natuurlijk wel lineair met hun rekenkracht invloed op de laadtijd voor de specifieke gebruiker die dan een pagina opvroeg

Om die reden zijn al die 'brede' cpu's niet per se interessant, we vermijden er zelfs eventuele bottlenecks in MySQL en het OS mee (geen idee hoe goed MySQL op Linux overweg kan met 32 cores). Dan blijf je natuurlijk over met de discussie of een 12-core cpu met dezelfde turbo-frequentie als de twee 6-core cpu's die we nu hebben dan niet een beter (en goedkoper) alternatief zou zijn.

In dit geval hebben we ons denk ik meer op de worst-case situatie van volledige belasting gericht en daarbij natuurlijk sowieso gekeken wat er in het door ons gestelde budget viel. Dan hebben we nu dus 12x 3.4Ghz ipv 12x 3.0Ghz, maar in hoeverre dat profijt heeft van het feit dat het 2 losse cpu's zijn of juist nadeel zou ik eigenlijk niet eens weten.

Het simpele antwoord is: we weten niet wat daadwerkelijk de perfecte oplossing is. We gaan er wel van uit dat deze ruim voldoende krachtig is voor onze situatie en ik geloof best dat er varianten op deze configuratie een vergelijkbare performance hadden gegeven voor (net) wat minder geld

[kdekker]

Er zijn helaas - ik kon ze niet vinden - niet of geen reviews van de dual socket AMD Epyc Dell Poweredge R7425 (die idd 2U is ipv 1U). Maar mogelijk is de volgende review nuttig: https://www.phoronix.com/...tem=amd-epyc7601-2p&num=5 en specifiek voor Postgress https://www.phoronix.com/...tgreSQL-11-JIT-Benchmarks. Misschien zal MySQL op een soortgelijke manier schalen als Postgress?

Sowieso zijn er erg weinig reviews die bijv. een Xeon Dell Poweredge R640 vergelijken met de R7415 , of R6415.

Ik kan wel een beetje begrijpen waarom een 2-socket AMD in 2U zit. Die 2x 180W TDP vereisen een zware voeding (950W of meer, aldus de Dell site als je dit configureert). Die warmte moet ergens heen, en zal in 1U misschien een probleem vormen.

[DennusB]

Gewoon interesse, maar zou het voor Tweakers niet heel handig (schaalbaar) en vet (innovatief) zijn om het hele spulletje ergens in een cloud neer te plempen? Verder : Toffe update Goed bezig!

[Kees]

Nee.

Ten eerste is dat veel duurder met onze load (van de cloudprijs voor alleen al de dbserver kunnen we elk jaar een nieuwe dbserver kopen) en verder krijgen we van onze sponsor True de hosting gratis waardoor het al helemaal niet uitkan.

Daarnaast schalen wij niet lekker. Van 7:00 tot 1:00 hebben wij een vrij constante load bezoekers, dan kun je niet echt servers afschalen. We zijn geen evenementen site die eens per jaar veel bezoekers heeft, we hebben een constante stroom. Scaling heeft dus weinig zin.

Verder: wij zoeken specificaties voor de nieuwe server zorgvuldig uit en stemmen dat af op wat we nodig hebben, bij de cloud krijg je een one-size-fits all in het algemeen. Dus qua performance is dit veel beter.

En qua innovatie: je ziet ook steeds meer mensen zich realiseren dat de cloud helemaal niet zo heiligmakend is en die halen weer (een aantal) servers terug naar hun eigen datacenter. Wat dat betreft lopen wij dus al voorop door nooit naar de cloud te migreren

De cloud heeft zeker wel voordelen en ook zijn toepassingen, voor ons vallen die voordelen heel erg mee, zijn er veel nadelen en is onze applicatie niet geschikt voor cloud toepassingen, en de applicatie geschikt maken kost teveel tijd voor te weinig 'gain'.

[itlee]

En qua innovatie: je ziet ook steeds meer mensen zich realiseren dat de cloud helemaal niet zo heiligmakend is en die halen weer (een aantal) servers terug naar hun eigen datacenter. Wat dat betreft lopen wij dus al voorop door nooit naar de cloud te migreren

Dat gezeur over die azure, aws bla bla cloud moet maar is over zijn...mark my words, eigen ijzer, zelf controle over je stack (en zeker als je techneut bent en meerdere servers hebt) is en op termijn goedkoper en veel beter beheersbaar.

Als je lekker veel wilt betalen ga je naar azure, aws of transip (vooral die laatste, als t draait is het prima maar als je issues hebt, sjesus wat moet je dan ver weg blijven van die lui ....

[morphje]

Ja en nee. Kosten zijn er op verschillende vlakken. Hieronder volgt een rekenvoorbeeld waarbij de kosten voor een cloud oplossing iets hoger liggen dan fysieke hardware. Het is puur een beslissing op basis van eigen eisen en wensen.

Ik heb direct en indirect beheer over [veel] instances. In totaliteit geven we iets meer dan een ton per jaar uit. Wij hebben wel een paar eisen:
- meerdere datacenters ivm geografische redundantie (dit heeft ons in het verleden uit de brand geholpen)
- 24/7 support. Door cloudboer afgehandeld door engineers ter plaatse en engineers on-call.
- redundant netwerk/power/everthing.

Wil ik dit zelf opzetten kost me dat grofweg een ton aan hardware (alles 2 keer want 2 datacenters). Vergeet ook niet de reserve hardware die ik voorraad moet houden. Dit kan ik in 3 jaar afschrijven. Laat ik het afronden op 30K per jaar aan afschrijving en dan heb ik het niet over de initiele investering die een klap is. Hardware: 6 KVM dozen 4 storage dozen, 10gbit netwerk apparatuur, ATS, powerswitches, reserves (en dan doe ik het nog rustig aan). Backup? Kost geld, dus doe maar niet.

2x colo kwart rack huren. Laat ik het even afronden op 10K per jaar.

Dan heb ik nog zeker een halve FTE extra nodig met de juiste kennis en een rijbewijs. Kost ook nog even 40K per jaar extra. En iedereen van ons team krijgt vervolgens ook een piketdienst toeslag (+10k) omdat je meer afhankelijkheid hebt van je hardware dus sneller moet fixen. Huidige teamleden moeten extra training krijgen (laat ik aannemen dat dat gratis is)

Dus alles bij elkaar opgeteld: 90K per jaar aan kosten (optimistisch)
Is het dus goedkoper: Nee. Het is hooguit gelijkwaardig qua kosten, want het stopt niet bij 90K. Meer hoofdpijn? Jazeker!

Ja in theorie zou ik m'n hardware kunnen downscalen en misschien voor de helft kunnen verkrijgen, maar dan ga ik realistisch worden qua andere kosten. Dus om hier voor te zijn:
60K hardware, 20k per jaar afschrijving
colo: 15K per jaar
personeelskosten: 60K per jaar (0,6 FTE), piketdiensten
training: 20K initieel
opbouw en testen hardware: 30k (salaris, productieverlies, dubbele kosten voor huidige cloud)
Inhuur consultant voor opbouw hardware: 20k
Totale kosten: 50K initieel, 95K per jaar.

[Reactie gewijzigd door morphje op 23 juli 2024 07:37]

[ACM]

't Is maar net waar je mee vergelijkt en welke eisen je hebt. Voor Tweakers lijkt het vooralsnog een flink stuk duurder;
- We zijn gestopt met KVM-switches en op afstand beheerbare stroomvoorziening sinds de remote management kaarten van de servers echt goed begonnen te worden. O.a. Dell's drac werkt prima voor vrijwel elk scenario. Er zijn vast uitzonderlijke situaties waar e.a. toch buiten die remote management cards om moet, maar dan heb je inderdaad de "remote hands" of een auto om het te fixen.
- 't Grootste deel van ons netwerkverkeer en racks wordt door True gesponsord. Was dit niet het geval geweest, dan was de berekening vast al wat anders uitgevallen.
- Wij houden geen reservehardware aan, daar zijn de supportcontracten met de leverancier voor (in de meeste gevallen NBD omdat de redundantie veel opvangt)...
- Omdat onze primaire storage behoorlijk veel redundantie heeft (met Ceph hebben we effectief elke file al 3x opgeslagen verspreid over 6 servers) hebben we inderdaad geen 'backup' storage. We maken wel backups van die opslag.
- Waar staat ATC voor?
- Wij hebben niet het idee dat we minder FTE zouden hoeven hebben met cloud, Kees is nauwelijks met de hardware bezig en vooral met de typische 'devops' taken die je ook bij een cloud-omgeving zou hebben.
- Onze eisen op het vlak van uptime zijn waarschijnlijk lager dan wat jij impliceert, maar doordat allerlei uitvalscenario's worden opgevangen door diverse vormen van redundantie, is de uptime in de praktijk alsnog behoorlijk hoog.
- We hebben ondertussen voldoende interne ervaring met hardware kopen en 'opbouwen' (en testen) dat we daar lang niet zoveel tijd mee kwijt zijn als jij nodig lijkt te hebben. Ook is consultancy door onze relatief eenvoudige structuur nauwelijks nodig. Wat dat betreft zal het vast schelen dat we in beginsel nog steeds een LAMP-stack hebben (maar wel bij de A, M en P meerdere varianten en componenten)

Kortom, van jouw samenvattingslijst hebben wij vooral de afschrijving van de hardware en een beperkt deel van de colo-kosten ivt de cloud-kosten.

[morphje]

Het klopt inderdaad dat het verschil uitmaakt waarmee je het vergelijkt. Voor een databasebak van deze orde van grootte heb je eigenlijk gewoon geen enkele andere keuze dan fysiek. Sponsoring van True is uiteraard ook erg leuk, zeker met jullie hoeveelheid apparatuur.

Ik bedoelde overigens ATS (automatic transfer switch). Tikfoutje, ga het corrigeren

Het was meer een algemene reactie. De uitspraak "de cloud is duurder" gaat niet altijd op. Zelfs niet op de schaal van een 100k+. Dat was voornamelijk mijn vergelijking. Het verschil zit ook in de soort business waar je in zit. Tweakers kan putten uit een enorme bron van potentiele kees vervangers. Ik kan dat niet. Ik zit in een team van 2, dat is voor eigen hardware te weinig fallback, dus ik heb een derde persoon nodig in het team. Het is ook niet onze core business, dus dat is ook een factor die meespeelt.

Daarom begon mijn reactie met "Ja en nee"

[ACM]

Dan zijn we het eens

[morphje]

Ik was het nooit oneens met jullie

edit: ik wil eigen mezelf downvoten met deze reactie zet maar op -1

[Reactie gewijzigd door morphje op 23 juli 2024 07:37]

[itlee]

@ACM , je snapt t,...enige wat stuk gaat aan hardware is een keer disk of een RAM module. en fysiek beheer heb je bijna niet meer, heel af en toe op je DRAC of ILO inloggen om te kijken of alles nog hobbelt. heb je geen KVM voor nodig.

Als je ziet hoe goed de MERK hardware is tegenwoordig koop je 1x een server en draait ie 5 jr vlekkeloos in het rek van je datacentrum.

En al die onzin verhalen met dikke FTE's voor hardware beheer enz. hey, als er een disk stuk is bel je bijv. True op, wisselen hun een disk die je op je plankje klaar legt in je rek, en ze sturen een bonnetje van 100 piek heb je dus 0 FTE voor nodig @morphje. dus al de bla-bla-duizenden kosten voor redundant hardware enz. is een interne sales pitch om je cloud oplossing te pushen naar de directie.

Dure onderhoudscontracten is tegenwoordig ook redelijke onzin, als je 3 of 4 servers van hetzeflde type hebt leg je 1 of 2 ram modules en een disk op spare. en als ie er mee stopt kan je tegenwoordig op elke hoek van de straat spare parts kopen en met een koerier dezelfde dag nog laten bezorgen.

en t allermooiste is dat de economie nu tot aan de hemel gaat, en iedereen helemaal mal doet met de meest exotische oplossingen maar wacht maar tot dat er een economische dip aankomt, zit je met je al je dure cloud spullen want even migreren is er niet bij want je hebt geen invloed op niks. Een FTE kan je bezuinigen, een eigen servertje kan je nog een jaartje doordraaien als t moet, en dus je investering kan uitstellen, maar als je dure maandabonnementen hebt en je omzet keldert om wat voor reden kan je zo je spullen pakken en je faillisement aanvragen. (gaat gebeuren straks...nog een paar jaar hebben we weer een recessie).

[Reactie gewijzigd door itlee op 23 juli 2024 07:37]

[morphje]

Edit: Hier stond een uitdaging, maar boeie, ga er niet eens op in. Ik ken mijn eigen motivaties om iets te doen en iemand die alleen maar zijn eigen verhaal wil horen/zien gaat er toch niks mee doen.

[Reactie gewijzigd door morphje op 23 juli 2024 07:37]

[wica]

Mag ik weten bij welke Nederlandse cloud provider je zit?

Wij hebben de keuze gemaakt voor de cloud (AWS), omdat het DC niet meer kon voldoen aan onze bandbreedte behoefte en ze hadden te vaak storingen. Maar ook omdat we een stuk flexibeler wouden worden.

Maar wij zijn niet over gegaan van wegen de kosten.
Met nog steeds het zelfde aantal FTE's

Maar de kosten zijn wel ongeveer in de gelijke lijn blijven stijgen.
Ondanks dat we zoveel mogelijk op spots draaien.

En dan de initiële investering, die heb je bij de cloud ook.
Je DB's reserveer je voor een periode van 1 of 3 jaar (vooruit betalen) om de kosten te drukken.
En zo heb je nog wat zaken, wat toch voordeliger is, als je vooruit betaald.

Maar als ik puur naar de kosten kijk, kan ik niet echt zeggen dat het goedkoper is, dan zelf HW te hebben en onderhouden.
Het enigste voordeel van de Cloud ten opzichte van HW, is niet de stress hebben, dat er iets op HW niveau stuk gaat.
Nu is het gewoon een support ticket inschieten en afwachten

[morphje]

Wij zitten momenteel bij CloudVPS, we hebben inmiddels een vrij langdurige relatie met ze en hoewel ze wat ups en downs hebben gehad denken ze altijd wel met je mee. We hebben ook bewust onze infra zo gebouwd dat we volledig op 1 datacenter kunnen draaien.

Maar kijk eens naar mijn berekeningen. Je ziet dat de cloud in mijn geval ook duurder is, laat ik het mooi afronden op 20% duurder en dat is voor ons een bewuste afweging.

- Het is niet onze core business. Ik heb dus beperkte humane resources. Met 2 man fysieke hardware onderhouden waar semi kritische applicaties op draaien is op z'n minst niet verstandig.
- zelfs als ik initiele investeringen niet meetel, ben ik nauwelijks goedkoper uit.
- onze kosten zijn direct te koppelen aan projecten en door te belasten aan afdelingen/klanten. Interne doorbelasting van hardware en afschrijving op hardware zou voor ons veel veranderingen kosten.
- Eenvoudig schalen van hardware is onmogelijk, snel schakelen daarom dus ook.
- Wij hebben niet de IOPS nodig van fysieke hardware.

Pas bij 3 ton per jaar gaat het (voor ons) interessant worden voor ons om (gedeeltelijk) over te schakelen op fysieke hardware. Want dan zijn er voldoende FTE's beschikbaar die fysiek beheer kunnen uitvoeren. Want hardware beheer is eigenlijk totaal niet interessant, maar je moet nou eenmaal wel het personeel met de juiste kennis beschikbaar hebben.

[Intrepidity]

Ligt er helemaal aan of je de cloud ziet als een soort virtueel rack in de wolken, of dat je vol in gaat zetten op cloud native tooling. Als je een gedeelte van je workload bijvoorbeeld overzet naar lambda functies in AWS druk je de kosten echt heel erg, daar valt geen eigen EC2-instantie tegenop te draaien.

[CH4OS]

Beetje vreemde berekening; de ene keer er wel van uit gaan dat de training inbegrepen is en de andere keer niet?

[morphje]

Het zijn 2 soorten berekeningen. De eerste is wat enthousiaster op hardware en wat optimistisch op bepaalde operationele kosten (salaris, training)

De tweede berekening was een situatie waarbij een tweaker zou stellen dat ik niet zoveel hardware nodig zou hebben. Dat klopt overigens, want ik ga uit van flexibiliteit in de eerste berekening en dat kost geld. Maar daar ben ik wat meer realistisch met de overige kosten. Het netto resultaat is ongeveer hetzelfde kostenplaatje.

Je kan ook optimale hardware combineren met realistische operationele kosten en misschien wat externe inhuur om het een en ander op te zetten (wij hebben immers niet de juiste ervaring). Alleen komt dat de berekening extreem ongunstig uit. Ik denk dat in de praktijk voor ons het kantelpunt tussen 2 a 3 ton/jaar zit.

Overigens is dit slecht een klein deel van onze IT gerelateerde uitgaven. Dit gaat slechts over een "klassieke" IaaS waar ik zelf het meeste mee te maken heb binnen de organisatie. Verder hebben we ook nog de nodige Office365 cloud spullen, een paar applicatiespecifieke clouds en best nog flink wat hardware lokaal staan. Uiteindelijk kom het neer op "best fit", wat past het beste bij een bepaalde toepassing. Voor mijn afdeling is dat cloudspulletjes.

[itlee]

Mooi rekensom hou ik van...
Ik wilde een hele reactie terug typen maar toen zag ik dat het geen zin heeft weet je waarom?

Ik las je reactie onder aan je profiel, en toen dacht ik, laat maar (no offense, andere wereld.)
De baas blij maken met je oplossingen, goed bezig Als iets je eigen geld is lijken lijstjes heel leuk maar de realiteit zit echt wel anders in elkaar. Geld van de baas uitgeven met lijstjes deed ik ook 10 jr geleden.

Ik kom nog wel is op de vloer op een paar meter van de racks van tweakers vandaan en geloof me als je dat allemaal in de cloud moet doen heb je 1 die performance niet, 2 die garanties niet en 3 je bent heel veel meer geld kwijt @ACM snapt t met zijn reacties...

ps. straks ga je ook nog zeggen dat lease autos goedkoper zijn als kopen, en dat lenen goedkoper is als zelf geld hebben,...kan nog wel ff doorgaan, waarom denk je dat iedereen vpsén aanbiedt omdat het een fukking cashcow is, en wordt grof geld verdient....hey lekker alles naar de cloudprovider brengen, ik vind m prima

[Reactie gewijzigd door itlee op 23 juli 2024 07:37]

[morphje]

En toch tik je een reactie. Maar je wijst keer op keer op het feit dat het duurder is in de cloud. Lees mijn reacties dan nog eens een keer. Mijn huidige cloudoplossing IS DUURDER (ongeveer 20%) en wij kiezen daar BEWUST voor. Het is voor ons de beste oplossing op het moment. Het is een oplossing die voor ons in onze situatie acceptabel is. Het is niet een absolute waarheid dat cloud altijd beter is, net zo min dat hardware altijd beter is. Hieronder geef ik ACM juist ook gelijk. Het is slechts een voorbeeld, ons voorbeeld. Ik zeg ook "ja EN nee".

Die extra FTE heeft te maken met het feit dat wij als bedrijf niet willen vertrouwen op 2 man om in noodgevallen op terug te vallen. Piketdiensten op onze schaal wil je niet met 2 man doen, daar heb je een derde voor nodig. Of je moet extern inhuren.

Maar verlicht me eens waar je zo graag over valt? "die andere wereld". Overigens heb ik mijn profiel al jaren niet meer bijgewerkt, of denk je dat ik bewust windows 98 op mijn tweakers CV heb staan?

ps. Leasen is overigens in veel gevallen goedkoper. Maar dat gaat jouw en mijn salaris te boven

[Reactie gewijzigd door morphje op 23 juli 2024 07:37]

[Yzord]

Als tweaker krijg ik altijd de bibbers van het woord ‘cloud’ brrr. Ik wil me spul kunnen zien shinen. Digital moonshining zeg maar

[Upquark]

Precies. Bij Tweakers horen gewoon eigen servers.

[Verwijderd]

Onzin, Tweakers denkt gewoon na over kosten en baten. Als cloud echte voordelen had in hun situatie dan hadden ze dit echt wel gedaan.

Cloud heeft zijn use-cases en zoals het hier al vele malen is uitgelegd is het voor tweakers.net gewoon niet de beste keuze.

[Upquark]

Ja ja, dat snap ik allemaal wel, maar met de geschiedenis van Tweakers in het achterhoofd is het toch ook gewoon leuk dat alles nog gewoon op eigen servers draait?

[Verwijderd]

Inderdaad, ik had je reactie verkeerd begrepen, mijn excuses.

[Upquark]

Geen probleem! Wij oudgedienden begrijpen elkaar wel.

[NiGeLaToR]

Ben het helemaal met je eens Kees. Er gebeurt nog iets vreemds: we hebben onze DB omgeving uit Azure naar een eigen platform gehaald en ondanks dat dit nieuwe platform lagere specs heeft qua mem, cpu en disk/IO presteert het bijzonder veel sneller. Het lijkt wel of die losse componenten extreme latency kennen of op een andere manier veel overhead genereren in een cloud-config.

Dus nu hebben we een snellere oplossing, bij een NL bedrijf, voor een lagere prijs - met in theorie minder specs.

[Cergorach]

Ja, zware databaseservers heb ik ook altijd grote vraagtekens bij neergezet qua kosten/prestatie. Gebruikte je een VM met daar je database op of de SQL database service uit Azure? Azure is voor heel veel dingen heel goed en handig, maar het is nooit echt een IOPs monster geweest, alles behalve eigenlijk. Dat betekend niet dat het geen uitstekende oplossing is voor veel andere toepassingen...

[fastedje]

Mysql met Innodb is wel een rotsvaste keuze. Veel hippe cloud en/of gedistribueerde databases kunnen echt niet tippen aan de stabiliteit hiervan.

Wat kan helpen bij het schalen is dat je replica's gebruikt voor read queries.

Verder is backup, restore en replicatie goed goed geregeld. Vaak hoor je over cloud oplossingen: backups, wie heeft die nodig als je in de cloud zit? Totdat er een corruptie is of een fatale admin fout...

[Cartman!]

Alle dingen die je noemt zijn uitstekend geregeld bij n dienst als AWS RDS (Relational Database Service). Al die dingen met n paar kliks geregeld

[Reactie gewijzigd door Cartman! op 23 juli 2024 07:37]

[burne]

'cloud' is andermans computers. En dus deel je je computer met anderen, of, als je exclusief gebruik van die hardware wilt: kost het je hetzelfde als de hardware jou zou kosten, plus dat wat de cloudprovider wil verdienen er nog bovenop.

'cloud' is interessant als 1 enkele computer in een datacenter teveel voor je is. Dan kun je een twintigste of dertigste deel van een computer huren voor een tientje per maand. Ik weet niet hoe groot het huidige park is maar een of twee racks vol machines aan capaciteit bij een cloudprovider kost je een hele stapel geld.

(Mijn context: ik heb Femme een jaar of 18 geleden aan een gesponsord rack geholpen bij mijn toenmalige werkgever.. Toen moest 'ie zich nog door z'n moeder naar de serverruimte laten rijden, want geen rijbewijs..)

[Piemol]

Rekenkracht in de cloud is heel duur, dus wat je zegt klopt ook niet helemaal.
Uit ervaring weet ik dat als je elke dag een importscript (tekstfiles naar database) van 10 minuten laat draaien en verder geen cpu nodig hebt, je met ~€120,- (alleen voor de cpu cycles!) in de maand toch aardig veel duurder uit bent dan dat je een willekeurig ander gebakje koopt of shared hosting afneemt. Oké, het neemt je verder wel veel uit handen, dat moet ook onderdeel zijn van je afweging.

[Intrepidity]

Waarom zou je dat dan ook op bijvoorbeeld EC2 draaien? Een server de hele dag in de lucht houden voor een import? Verschuif dat naar een lambda en je betaalt er *misschien* 10 cent per dag voor. Als je de cloud inderdaad ziet als een soort omgeving waar je gewoon je fysieke hardware naartoe slingert en dan verwacht dat je goedkoper uit bent, tsja. Pak een API gateway, zet er een lambda achter, en je hebt het echt over een heel ander kostenplaatje.

[Cartman!]

Precies, degenen die "cloud is een ander z'n computer" roepen hebben veelal weinig kennis van alle mogelijkheden die er zijn bij de grote cloud providers.

[burne]

'De cloud' bestaat omdat de doorsnee server in een datacenter van een hostingprovider voornamelijk niets doet. slagerijjansenuitkudelstraart.nl krijgt 150 bezoekers per dag en is daar heel blij mee, maar als je dat op een goedkope Xeon draait is het bizarre verspilling. Zet 50 of 100 van zulke sites bij elkaar op een machine en het kan wel uit.

[CH4OS]

'cloud' is andermans computers. En dus deel je je computer met anderen, of, als je exclusief gebruik van die hardware wilt: kost het je hetzelfde als de hardware jou zou kosten, plus dat wat de cloudprovider wil verdienen er nog bovenop.

De cloud is natuurlijk niet per definitie bij een third party. Niks mis met een private cloud bijvoorbeeld, maar dan ben je wel een heel grote partij. Wellicht dus als de Persgroep alles in 1 IT-omgeving wil hebben voor alle sites die zij draaien.

[slijkie]

Waarom zou je dat willen, dan komt onze data ook lekker in de 'cloud' terecht. Plus tevens is het woord 'cloud' overhyped, net als 'blockchain'. Je kan zo zelf je eigen 'cloud' kunnen bouwen, eigenlijk zou je alle Tweakers Servers al als een cloud kunnen zien.

OT: Leuk database bakkie, zal weer voor heerlijke performance zorgen. Heb bij Tweakers echter nooit een trage ervaring op wat voor verbinding dan ook (Even los van de ddos'jes in het verleden).

[DennusB]

Deels met je eens, maar niet helemaal. Ik ben voor een klant van ons nu bezig hun hele spul in een DC te verhuizen naar de cloud. En het geeft ze echt enorm veel flexibiliteit, veel minder nadenken over hardware, uplinks enz en gewoon lekker functioneel bezig zijn met je app.

Edit : En idd, Tweakers is altijd snel, wel echt heel knap!

[Reactie gewijzigd door DennusB op 23 juli 2024 07:37]

[mkools24]

Eens, gewoon openstack ofzo, werkt perfect en je kunt veel flexibeler op -en afschalen. Nu heeft eigen hardware natuurlijk ook wel voordelen, vaak is het wat goedkoper op de lange termijn.

[Martinspire]

Ze hebben nu alles al prima staan én nog een nieuw databeest. Waarom zou je dan nu dat besluiten? Dat hadden ze beter kunnen doen voor deze upgrade lijkt me. Bovendien zou het weggegooid geld zijn van de andere zaken die ze in de voorgaande jaren hebben aangeschaft.

Daarbij: hier is natuurlijk veel meer en makkelijker aan te tweaken. Bij een cloudhost zit je wel redelijk vast aan wat zij willen gebruiken en vrijgeven.

Overigens zou ik best een artikel willen zien van hoe Tweakers nu achter de schermen eruit ziet qua hardware en infrastructuur. Misschien een mooie eindejaars rapportage?

[morphje]

Zo jammer alleen dat er zo weinig Openstack leveranciers zijn in nederland Verder geweldige techniek (behalve als je je Openstack versie wilt upgraden)

[Engineer]

Het enige verschil tussen “in de cloud c.q geen omkijken naar” en “een eigen DC hebben”, is dat derde partijen het onderhoud aan de hardware uitvoeren.

Dan zou het heel veel voordeliger zijn voor Tweakers.net om gewoon mensen in te huren voor dat onderhoud i.p.v. alles te verkassen. Dan zijn ze hun investering in al die hardware niet kwijt (ongebruikte hardware die achter blijft). Maar waarom zouden ze? Het onderhoud gaat ze prima af en het is ten slotte het management van Tweakers.net (!). IT kennis en bijbehorende CV houd je op pijl door het te gebruiken i.p.v. uit te besteden.

[Reactie gewijzigd door Engineer op 23 juli 2024 07:37]

[ViperXL]

Tweakers draait al in de cloud, maar niet zoals jij de definitie kent. Een cloud is een verzameling van sites, hardware en software, meestal aangeduid als Software-Defined ........
T.net heeft 2 locaties en hebben het beheer compleet zelf in handen, alle hardware specs kunnen ze zelf bepalen, problemen kunnen ze zelf direct oplossen, geen afhankelijkheid van derde partijen in 95% van het geval.
Ik vindt het tevens wel sieren dat Tweakers zoals een tweaker betaamt alles zelf draait en mbt de performance kunnen VELEN een voorbeeld nemen aan hun. Ook een cloud van x aanbieder kan problemen hebben en ik heb toch echt het gevoel dat de huidige setup minimale downtime heeft.

[Verwijderd]

Ik zie performance als overweging eigenlijk nergens terugkomen in dit draadje.

Cloud is per definitie virtualized (aws bied ook non-virtualized maar dat is een enorme uitzondering). Soms draait daar dan nog eens een abstractie-laag bovenop. En netwerk technisch is het ook niet altijd feest.

Mensen zijn tegenwoordig slechte performance gewend van web diensten. Het is niet super traag maar allemaal een beetje laggy, dit cloud spul.

Je wilt niet weten hoe verfrissend het is om een fonkelnieuwe hardware server te hebben waar je het OS en software kaal op het metaal draait. De performance is ongekend, alsof reactietijden gewoon nul zijn.

[Cartman!]

Hoe kom je daarbij, heb je statistieken? Ik heb services gebouwd op AWS met response tijden van enkele miliseconden. Apps die getest zijn tot 1 miljoen concurrent users en realtime hun data ontvangen over websockets en dat n paar uur per week, de rest van de week kost dat platform dus niks. Zulk soort scenario's bewijzen dat cloud niet zomaar "een ander z'n computer is".

[Reactie gewijzigd door Cartman! op 23 juli 2024 07:37]

[Verwijderd]

Gaan we hier echt de discussie hebben of native performance superieur is aan virtualized performance? Lijkt me gewoon een simpel feit.

[Cartman!]

Als geld geen enkele rol speelt heb je gelijk maar in praktijk moet er kosten efficiënt gewerkt worden. Moet je wel de beste mensen hebben ook die t in elkaar kunnen steken. In zekere zin beweer je dat je meer performance kunt genereren dan AWS of Google, dat is gewoon onrealistisch.

[Reactie gewijzigd door Cartman! op 23 juli 2024 07:37]

[Verwijderd]

Je hebt gelijk over het kosten aspect en efficient werken. Zeker in grotere organisaties wint cloud daarin vrijwel altijd. Oneens over het performance stuk, wat een totaal ander onderwerp is.

De uitdrukking "on metal" bestaat niet voor niets, het is een koud kunstje om een server op te leveren die sneller is dan welke virtual server dan ook, maakt niet uit of je daar een grote naam achter plakt, on metal is gewoon fundamenteel sneller dan virtual.

[Cartman!]

Ik snap niet waarom dat relevant is. Als je 2 identieke machines neerzet en op de ene iets via virtualisatie draait is dat langzamer ja, natuurlijk. Echter kun je niet in je eigen datacenter zeggen "zet er binnen n paar minuten nog even 5 bij want we hebben wat meer read replicas nodig" terwijl in bijv AWS dit wel kan en dan ben je toch in die paar minuten ineens veel meer performant dan je metaal. Of verticaal schalen "geef die bak even een upgrade van 64GB naar 128GB", wacht een paar minuten en het wordt geregeld zonder downtime. Cloud is zoveel meer dan "een ander z'n virtuele machine", het gaat erom dat je niet hoeft na te denken over de infrastructuur die zij hebben en dingen als onderhoud van hardware vervallen gewoon. Als er n machine uitvalt wordt dat zonder downtime allemaal voor je geregeld zonder dat je t doorhebt.

[Verwijderd]

"Als je 2 identieke machines neerzet en op de ene iets via virtualisatie draait is dat langzamer ja, natuurlijk"

Stop hier. Dit is het enige wat ik zeg. De 20 zaken zie je daarna bijhaalt trekken het zo breed dat iedere uitkomst mogelijk is.

[Cartman!]

Je beweert "Het is niet super traag maar allemaal een beetje laggy, dit cloud spul." zonder verdere onderbouwing en daar ga ik graag op in.

[Verwijderd]

Ik niet. Het is hetzelfde als moeite steken in het aantonen dat de aarde een bol is.

[Cartman!]

Als je puur op onderbuikgevoel roept dat cloud laggy is zonder onderbouwing dan houdt discussie op ja en hou ik t er maar op dat je te weinig ervaring hebt met cloudhosting.

[Verwijderd]

Beledigingen zijn altijd het teken dat de argumenten op zijn, dank voor het bevestigen.

[Cartman!]

Als je dat als een belediging ervaart is dat niet m'n bedoeling, excuus daarvoor. Ik vind het alleen zeer zwak als iemand dingen roept en daarna het niet wil/kan onderbouwen.

[Verwijderd]

Een algemeen geaccepteerd feit hoeft niet onderbouwd te worden. Als de consensus is dat de aarde rond is, hoef ik geen moeite te steken om dat aan te tonen, degene die het betwijfeld mag de moeite doen om het feit te weerleggen.

On metal is sneller dan virtual. Dat is het enige wat ik zeg. Je geeft zelf toe dat dat zo is. Daarna haal je er 20 andere factoren bij waar ik het niet over heb.

Overigens, vind jij ook dat gourmetten superieur is aan fonduen?

[Cartman!]

Het is een feit dat iets zonder virtualisatie sneller draait maar je zegt ook dat cloud laggy is en dat is geen feit maar jouw mening en dat kun je niet onderbouwen.

[Verwijderd]

Laggy tov on metal. Jezus gast, probeer eens tussen de regels te lezen.

[Cartman!]

Mensen zijn tegenwoordig slechte performance gewend van web diensten. Het is niet super traag maar allemaal een beetje laggy, dit cloud spul.

Lees het nog eens na anders wat je schreef...dat heeft niks met tussen de regels lezen te maken. Als jij dit zelf zo ervaart is dan kan dat natuurlijk maar dat maakt het geen feit.

[johnkeates]

Om dat je dan niet meer bezig hoeft te zijn met hardware en kan optimaliseren op basis van load.

[Horatius]

Het zou mij niks verbazen als de hele backup in de cloud staat, je eigen backup hosten op een andere plek is meestal vele malen duurder.

[fo0]

'The cloud' is just someone else's pc.

[DennusB]

Maar wel 'managed'

[Laloeka]

"Managed" hosting oplossingen zijn over het algemeen aardig wat duurder dan unmanaged. Dus als je niet te veel geld kwijt wilt zijn, en zelf slimme mensen in dienst hebt, kies je voor unmanaged. Als je project dan ook nog eens zo groot is dat je een volledige server kunt bezetten, dan kun je hem net zo goed zelf in beheer nemen. Dat scheelt de extra winst van de hostingmaatschappij, en verhelpt inefficienties in de communicatie van een extra partij.

Dus zo'n gek is het besluit van Tweakers om het in eigen handen te houden nog niet.

Daarnaast is het voor de mensen bij Tweakers natuurlijk een excuus om met duur speelgoed te spelen

[Reactie gewijzigd door Laloeka op 23 juli 2024 07:37]

[burne]

Daarnaast is het voor de mensen bij Tweakers natuurlijk een excuus om met duur speelgoed te spelen

Het is zelfs veel gekker dan dat: ze spelen er niet alleen mee, ze verdienen ook het brood voor 55 mensen met hun 'gespeel'. Je zou bijna denken dat ze serieus werk verrichten.

[Cergorach]

Het handje vol techneuten bij Tweakers.net zouden dat aardig zelf kunnen managen, die hoeven daar specifiek geen dure beheerders voor aan te trekken. En gezien het webservers zijn en dat Tweakers.net geen 24/7/365 uptime hoeft te hebben is geo-redudantie ook niet direct noodzakelijk.

[batjes]

Niet helemaal.

Cloud is meer dat de data niet op een vaste locatie staat. De ene keer als je data gebruikt staat de data op server W in datacenter X, access je die data een dag later, kan het zo zijn dat de data op server Y in datacenter Z staat. Als eindgebruiker zie en weet je niet waar je data staat, want het zweeft over de servers/het internet heen. Vandaar de term cloud.

[morphje]

Dat geldt misschien voor sommige cloud storage, maar voor Infrastructure kan ik je garanderen dat het nooit uit een datacenter verhuist tenzij er een zeer goede reden is. Zelfs amazon instances blijven in hun regio (waarbij het woord "regio" simpelweg vertaald naar een datacenter). Cloud is ook zoveel meer dan alleen storage.

[CH4OS]

Ook niet helemaal waar, want bij een private cloud is het gewoon eigen hardware.

[dmantione]

De cloud is over het algemeen duur als het om veel data gaat en ook niet snel. De cloud is vooral flexibel. Als je die flexibiliteit niet nodig hebt, koop je toch echt best je eigen server.

[DennusB]

Mwah, men realiseert zich vaak niet dat je echt goede deals kan maken met cloudproviders als je er veel neerzet. Het project waar ik nu opzit gaat over 1000+ servers, 200+ "managed databases" en 100TB+. En dat is echt goedkoper dan wat er stond in het DC!

[dmantione]

Merkwaardige keus van de processor: Het voornaamste voordeel van de Xeon 6000-serie is de tweede FPU. Maar een database is nu net een toepassing waarbij de FPU amper gebruikt wordt. En dan is specifiek de 6128 een model dat gemaakt is voor codes die niet kunnen schalen: Voor ietwat extra MHz krijg je veel minder kernen tegen veel meer geld.

[Kees]

Onze database draait in het algemeen niet heel erg veel threads gelijktijdig (op een normale dag maximaal tussen de 5-10 threads gelijktijdig). Het heeft dan geen zin om voor een cpu met heel erg veel threads te gaan als daardoor elke thread langzamer is (maar je dus wel meer threads gelijktijdig kan afhandelen). Dus dan kiezen we voor een cpu die met onze workload alle threads gelijktijdig kan afhandelen met een zo'n hoog mogelijke snelheid.

Dat zou je in theorie kunnen afvangen met de turboboost, maar mijn ervaring is dat de threads te kort leven om de turboboost te kunnen gebruiken.

[dmantione]

Dat klopt op zich, doch in dat geval is het ook doorgaans onzin om twee processoren te nemen. Een Xeon W kan in zo'n geval dan een hoop geld (en stroom!) besparen. Ook een Epyc kan in single socket behoorlijk wat rekenkracht leveren.

De Xeon 6128 wordt vooral in de markt gezet voor mensen die software gebruiken waarbij per rekenkern een dure licentie afgerekend moet worden, de rekenkracht per kern daarom maximaal dient te zijn (vandaar dus de 2e FPU van de 6000-serie). Dat is waarom hij zo extreem duur geprijsd is voor een 6-kerner: Als je dure software moet kopen, kun je ook wel wat meer voor de processor betalen, denkt Intel.

[fastedje]

Wellicht kan je ook nog aardig wat performance winnen door de juiste indexen te gebruiken of de Innodb bufferpool size te vergroten. MySQL 5.7+ heeft ook MySQL workbench waarmee je makkelijker trage queries kan opsporen.

[Verwijderd]

heeft de nieuwe DB nog wat te maken met de hikup van de "oude"db server vorige week?

[Kees]

Nee, maar die oude db voelde vast zijn einde komen en dacht even leuk te zijn door te laten merken dat hij er nog was...

Was trouwens wel vervelend, want daardoor lag de replicatie ook weer in de war waardoor ik daar een paar dagen aan heb moeten besteden, anders had ik hem vorige week maandag al vervangen. Door de kamikaze reboot van de 'oude' dbserver heeft die zijn leven dus met een week verlengt

[burne]

want daardoor lag de replicatie ook weer in de war waardoor ik daar een paar dagen aan heb moeten besteden

Een van mijn klanten heeft een percona database (master/master) van bijna een terabyte. We hebben gelijk met een OS-upgrade wat fancy nieuwe dingen er tegenaan geplakt. Herstellen van de replicatie, het maken van een kopie naar de schaduw-omgeving voor functioneel beheer en de backups doen we nu met xtrabackup en zfs snapshots. Lokaal een kopie maken kost een half uurtje, remote een kopie maken kost net geen twee uur, vooral omdat we nog geen 10G netwerk uitgerold hebben voor de storage. Voorheen was de dump iets van 8 uur en het inlezen op de slave 18 uur..

[Kees]

Inderdaad, zfs snapshots kunnen daar best handig bij zijn. Overigens kost het maken van een (logische) dump mij ongeveer 3 kwartier met een db van ~350GB, het inlezen duurt 4 uur (waarbij na 2 uur de meeste data al wel weer terug is). Het probleem daarbij is dat je zonder snapshots dan downtime hebt, en dat wil ik niet. Dus gebruik ik pt-table-sync en pt-table-checksum om kleine verschillen weg te werken.

Dat het twee dagen kost is niet perse de dump inladen, maar gewoon andere dingen tussendoor doen en dan veel later erachter komen dat de checksum allang klaar is bijvoorbeeld

[wmkuipers]

Naast de RAID-configuratie, is er nog ergens een slave voor backupdoeleinden of een dedicated read-replica? Hoe groot is op dit moment de DB in gebruik? Is er iets meer te vertellen over de migratie, hoe is de replica opgezet, is dit gedaan met native SQL tooling, of met Percona tooling? En op welk niveau is op een gegeven moment de switch gemaakt, dns omgegooid of endpoint in de applicatie aangepast?

[Kees]

Yep, de 'Apollo' server is de slave server, Artemis is de hoofddatabaseserver. Ze draaien overigens wel in een master-master configuratie, waarbij Artemis de preferred master is. De db is momenteel zo'n 350GB groot.

De replica is ooit lang geleden opgezet door een file-copy, maar word sindsdien door de standaard mysql-tooling (row-based binlogs) bijgehouden. Backups maak ik dan door de slave te stoppen, een logische backup te maken, de slave status te outputten en de slave weer te starten. Een nieuwe server toevoegen is dan een kwestie van die logische dump inladen, de slave te starten om het juiste moment (wat je uit de slave status haalt) en dan bij te laten werken, slave updates worden gelogged, dus daarna is het een kwestie van de slave omzetten naar de nieuwe master ('slave start until xxx' helpt daar enorm bij) en dan langzaam applicaties over te switchen.

De switch is uiteindelijk gemaakt door eerst de read-only applicaties naar de nieuwe master te laten wijzen (dus idd endpoint in de applicatie aangepast) en daarna (bijna atomair) de webservers (write) over te zetten naar de nieuwe master. In de tussentijd zijn er wel wat crons en queue-consumers uitgezet zodat er niet al te veel gerepliceert hoefte te worden. Voor de zekerheid in het geval dat ik nog iets vergeten was heb ik achteraf ook nog even het ip adres van de oude master aan de nieuwe master gegeven en gemonitored welke connecties nog op het oude ip binnen kwamen.

[burne]

Backups maak ik dan door de slave te stoppen, een logische backup te maken, de slave status te outputten en de slave weer te starten.

Je kunt met --master-data (en --single-transaction) in je dump een positie in je binlogs vastleggen (het exacte moment waarop je de dump maakt, vanzelfsprekend..). Als je de bijbehorende binlogs niet automatisch opruimt weet een nieuwe slave wat 'ie nog uit de binlogs van de master moet halen. Wat je nu doet, maar dan automatisch. Het commando om de nieuwe slave te starten staat als laatste regel in de dump. (hoewel je dit hopelijk niet regelmatig hoeft te doen..)

[Kees]

--single-transaction werkt echter alleen op innodb tables, en wij hebben genoeg myisam om dat te verpesten dus heb ik een iets robustere versie gemaakt.

En verruit de meeste backups die ik terugzet gaan niet naar een slave maar moeten een 'oopsie' fixen, waarbij de data uit de binlogs niet erg nuttig is en ik slechts een single table moet restoren. Vandaar dat ik liever ook de dump per database en table split zodat ik makkelijk 1 tabel kan restoren

[Mr_gadget]

Waarom eigenlijk SATA SSD's voor de database? Gaan PCIe SSD's niet fijn in een raid array? Kan me voorstellen dat vier van die M2 SSD's nog veel sneller zijn. Of passen ze fysiek niet?

[CAPSLOCK2000]

Misschien omdat IO toch geen bottleneck was omdat de hele database in RAM past?

Ik zie dat 4 data disks van 1TB, als ik uit ga van een standaard RAID1 configuratie dan is er dus effectief 2TB voor data. Het systeem heeft 512GB RAM.
Als we uit gaan van een klassiek 80/20 verhouding tussen data die aanwezig is, en data die actief wordt gebruikt, dan is er zo'n 400GB actieve data. Met wat overhead er bij past het mooi in 512GB.
En dat gaat er nog van uit dat die schijven vol staan, terwijl het waarschijnlijk minder dan de helft is. Je koopt zo'n systeem uiteraard wel op de groei en SSDs moet je toch niet helemaal vol zetten. Het zou me dus niet verbazen als er in werkelijkheid minder dan 1TB data is waarvan maar 100G actief wordt gebruikt.

Bovenstaande is uiteraard allemaal speculatie. Aangezien het een 1U servers is zou het best kunnen dat gewoon niet past.

[Kees]

De volledige dataset is momenteel zo'n 350GB (lang leve de gdpr waardoor we mochten opruimen ).

De ssd's zijn puur als storage voor reboots e.d. want normaal gesproken zit alles in het geheugen. We zouden prima overweg kunnen met minder geheugen, maar dat was goedkoop genoeg om weer eens te verdubbelen.

[ACM]

Het is vooral veel duurder, hoe dat met raid werkt weten we eigenlijk niet eens

We hebben een zodanige hoeveelheid geheugen dat de storage relatief weinig aangesproken wordt. Dus het moest vooral 'ruim voldoende' storage bieden en het is natuurlijk fijn als je dan op die momenten dat het wel aangesproken wordt het alsnog wel behoorlijk snel is.

PCI-e based SSD's voor servers betaal je bij Dell voor 1,6TB zo'n 3800 euro list price. De hier gekozen SSD's hebben (nu) een list price van 1000 euro.
Zo te zien is met de huidige prijzen NVMe nog wel interessant, die hebben zo te zien met een vergelijkbare Intel P4500 een list price van 1400 euro; dus "maar" zo'n 40% hoger (en je moet er een iets duurder chassis voor nemen).
Maarja, hoewel we wat minder dan die list price hoeven te betalen, is dat uiteindelijk nog best wat extra geld.

[nextware]

Die nieuwe server is van Dell (toch) ? Terwijl de oude van HP is zo te zien.
Is er een reden dat er voor een ander merk is gekozen (muv de prijs wellicht) ?

Voor de rest is dit wel een mooie upgrade Die oude server zal wel mooi mee kunnen in de development omgeving.

[Kees]

En de dbserver daarvoor was van IBM

We hebben niet echt een voorkeur voor een merk dus de prijs geeft meestal de doorslag, het is vrijwel altijd dezelfde hardware: raidcontroller van LSI met een eigen sausje, remote control kaart van avocent, geheugen van een generic geheugenprovider, cpu's van intel, ssd's van intel/samsung etc. Het enige verschil is de prijs, behuizing, moederbord en support.

[soepkip]

Bij Dell mag je je eigen SSD's erin gooien, HP wil graag HP branded (die wel erg veel meer kosten voor hetzelfde)

[kdekker]

Waarom gebruiken jullie SATA (Intel S4500) SSDs? En geen NVMe (bijv. Intel DC P4500 of Samsung PM1725)? Nu gaat (hardware) RAID en NVMe niet samen (wel software raid), maar daar zouden recente Dell en HP servers overweg mee moeten kunnen. Juist met een database met veel random read/write is een lage latency en IOPS belangrijk (al neemt dat belang ook af als de database voldoende geheugen voor cache heeft).

[dmantione]

NVMe is en blijft een lastige keus voor servers. Inderdaad gaat niemand betrouwbaarheid voor snelheid uitruilen en derhalve is RAID een heet hangijzer. Daar bestaan inmiddels oplossingen voor, betekent nog niet dat die oplossingen aantrekkelijker zijn dan "gewoon" SATA nemen. Een ander heet hangijzer is het fysiek kunnen aansluiten van de SSD's: Op desktops is M.2 erg aantrekkelijk, bij servers kom je vaak uit op speciale servers met U.2-aansluitingen. Dan heb je én een duurdere server nodig én duurdere SSD's.

Verder doet RAID keurig zijn op SSD's: Veel SSD's in RAID leveren hoge snelheden op. Je moet echt een bizarre werklast hebben wil zoiets een flessehals gaan vormen. En als de flessehals er niet is, waarom dan moeilijk doen?

[kdekker]

Ik weet niet of het bij ons de flessenhals is. En omdat - in ieder geval op ons testsysteem - RAID niet nodig is, wilde ik experimenteren met een NMVe SSD.

Op welke oplossingen doel jij? Intel VROC? En heb je ervaringen met servers, NVMe, RAID (RAID-1/mirror)? Ik ben benieuwd naar je ervaringen (en mogelijk meer lezers hier).

Overigens eist onze IT afdeling wel dat er of SAS SSDs in de server komen of U.2 SSDs. In ieder geval is dat voor Dell PowerEdge servers wel zo logisch (al biedt Dell ook SATA aan, zoals ze ook bij tweakers gebruiken).

[dmantione]

Intel VROC is één van de mogelijke oplossingen, maar die heb ik tot nog toe niet toepast. Ik heb waar NVMe nodig is tot nog toe de Broadcom trimode-controllers ingezet. LSI/Broadcom heeft veel langer ervaring met RAID dan Intel; in de firmware zit heel veel functionaliteit en die heeft Intel nog lang niet nagebouwd. Het blijft bovendien een soort software-RAID. Ik kan me evenwel voorstellen dat VROC voor simpele RAID-klusjes een goedkope oplossing kan zijn.

Ik werk in de HPC en in die hoedagheid ontwerp ik regelmatig complexe storagesystemen, waar de servers onderdeel van zijn.

SAS SSD's vind ik soms zeer nuttig: Met 12 gigabps en 2 poorten heb je 4 keer zoveel bandbreedte per SSD als bij SATA. Geen SSD wordt daar door afgeremd. De SAS-SSD's passen echter naadloos in klassieke storage-infrastructuur met backplanes en RAID-controllers. Een databaseserver op basis van SAS-SSD's kan een retesnelle jongen zijn.

[kdekker]

Bedankt. Maar met een klassieke RAID controller doe je de lage latency van NVMe teniet. Of dat werkelijk een bottleneck is, weet ik niet, wel dat een paar serieuze SAS SSDs de prijs opdrijven. Waar geen RAID nodig is, overweeg ik een NVMe SSD.

Mijn probleem zit niet zozeer in de bandbreedte, maar veel meer in latency/IOPS. Ons versiebeheersysteem is zwaar afhankelijk van netwerk(latency). Bij IT zien ze nooit een bottleneck, maar als ik de database server op een VM zet, stort de performance van clients (die dus steeds het netwerk gebruiken om bij de sources te komen) in elkaar. Voor testen willen we graag single threaded performance, maar omdat er zo veel testen zijn (1000-den) die parallel draaien, zit ik ook aan parallelliteit te denken. Budget is (uitteraard) beperkt to ca 10K list price. En AMD Epyc biedt weliswaar lagere single-threaded performance, maar door de massale parallelliteit (van 2x 32 cores) is het wellicht toch een mogelijke oplossing (voor een client test systeem). De database server van het versiebeheer systeem kan met 1 socket uit de voeten, maar heeft i.v.m. database, wel RAID nodig.

Van VROC (i.c.m. Dell) is weinig te vinden. In de default configurator staat het niet. Ik ken onvoldoende de (UEFI) BIOS opties van Dell om te weten wat voor RAID daar standaard in beschikbaar is (dit is ook een vorm van software RAID, maar zonder de kosten van een licentie key, zoals VROC heeft). De prijzen van VROC zijn mij niet bekend.

Ik weet niet welk deel van de firmware door Dell (of de BIOS maker) of door Intel gemaakt wordt. Zo heel veel spannends is er toch niet aan een 1:1 mirror (met 2 schijven)?

Mijn contactpersonen bij Dell waren niet echt enthousiast over NVMe, maar ik kreeg niet helder waarom niet. Marges? Of wat anders?

[Reactie gewijzigd door kdekker op 23 juli 2024 07:37]

[dmantione]

RAID veroorzaakt latentie, maar geen RAID is geen optie: Het is dan kiezen tussen software- of hardware-RAID. Dan is de firmware van Broadcom-controllers vele malen volwassener dan VROC en ook met Linux software-RAID komen er vaak allerlei prestatieproblemen om de hoe kijken die je met een hardware-RAID-controller niet ziet. Zo'n controller is dan ook naar mijn mening de beste optie tussen de beschikbare alternatieven. Bovendien zijn de laatste generaties toch echt wel snel. Een LSI3516 kan 1,7 miljoen iops per seconde verwerken, doe dat maal bijvoorbeeld 4 kilobyte en je zit nog steeds op vele gigabytes per seconde: Doe je best om storage bij elkaar te krijgen die de RAID-controller kan verzadigen.

VROC is een functie van de processor en is één in een lange reeks plannen die Intel in de loop der jaren heeft gehad om het geld dat in servers aan RAID-controllers wordt uitgegeven te verminderen. Mensen gaan dan automatisch meer in processoren steken. De serverfabrikant moet et activeren in de BIOS/EFI: Je kunt dan vaak een optie om "volume management devices" te configureren vinden. Niet iedere fabrikant doet er aan mee, mogelijk Dell niet. Je moet bedenken dat Dell ook al langer ervaring heeft dan vandaag en ook drommels goed weet dat RAID-controllers in servers gewoon belangrijk blijven, dat is dan ook wat ze aanprijzen.

Je zegt dat een 1:1-mirror niet spannend is. Maar je RAID-kaart doet behoorlijk veel: Hij zorgt voor een coherente cache, monitort de gezondheid van de schijven, toetst van tijd tot tijd de integriteit van de array en onderneemt preventieve actie. Voor de snelheid worden I/O-verzoeken gesorteerd en waar mogelijk gebundeld om maximale snelheid te bereiken. Dat is in praktijkomgevingen hele belangrijke functionaliteit die in een triviale implementatie kan ontbreken.

Dan netwerklatentie. De de HPC hebben we daar het magische wapen infiniband voor: Latentieprobleempje? Gooi er infiniband in en alle latentieproblemen verdwijnen als sneeuw voor de zon. Infiniband werkt, omdat niet alleen het netwerk zelf retesnel is, maar ook het besturingssysteem uit de latentieketen gehaald wordt. Of dat in jouw situatie bruikbaar is weet ik niet, als het om de verbinding van server naar client gaat (desktops), dan is het vaak lastig om daar infiniband uit te rollen, je desktops wil je vaak toch gewoon op ethernet hebben.

[kdekker]

Bedankt voor je reactie. Twee kanttekeningen:

• de RAID controller zelf is een single point of failure (maar dat is niet erger dan software RAID, en het is heel lang geleden dat ik een gecrashte RAID controller had). Je CPU en moederbord is ook single point of failure.
• ik heb geen beschikking tot Infiniband in de systeemruimte. Wel 10Gpbs. Maar dan moet ik wel een losse NIC bestellen.

Ik zal me eens verdiepen in de Dell PERC controllers (wat volgens mij ook gewoon rebranded LSI is) en toch SAS overwegen. Alleen is - op papier en in benchmarks - een SAS schijf veel minder snel dan een PCI NVMe variant. Maar dan zal ik RAID + SAS alleen op de database server doen en op de test/build server (waar RAID niet nodig is) een NVME schijf. Kjiken of dat gaat lukken binnen het budget.

[dmantione]

Een RAID-controller is inderdaad een single-point-of-failure, maar dat is de hele server. Dat is oplosbaar met externe RAID-controllers die met meerdere servers verbonden zijn, maar hier begeef je je op het terrein van hele sjieke, maar vaak ook dure, oplossingen. Precies wat ik beroepsmatig bouw.

Vaak is het evenwel zo dat een uitvallende server snel opgelost dient te worden, maar het uitvallen op zich geen kwestie van leven of dood is. De data dient evenwel te allen tijde veilig dient te zijn. Dat is wat een RAID-controller verzekert.

10-gigabps lost structureel niets op t.o.v. inifniband. Het is sneller t.o.v. gigabps, maar heeft niet de lage latenties in het netwerk en ook het besturingssysteem. In getallen: Latentie van applicatie naar applicatie ligt bij infiniband onder de 1 microseconde, bij 10GE is in het beste geval 8 á 9 te halen, maar dat is na intensieve tuning van de netwerkstack.

PERC-controllers zijn inderdaad LSI-controllers, op kleine details kunnen ze afwijken. De PERC740 bevat de LSI3508 en is de kaart die je nodig hebt als het snel moet gaan.

[kdekker]

Bedankt. Ik zie alleen dat Dell, NVMe en single socket 1U server niet voorkomt (niet bij de R340 of R540). Dan maar een R640 met de juiste RAID controller. Er is kennelijke een Xeon Scalable (E5) processor nodig. Ik ga in het nieuwe jaar in de materie duiken. Het kan nog zelfs zo zijn dat we wachten op het uitkomen van Epyc-2 (die komt wel in 2019) en de Intel opvolgers (de R640 zit al even in het gamma, eigenlijk verwacht ik ook wat nieuws op Xeon Scalable gebied), maar dat is nog even koffiedik kijken. Tenslotte zijn in de lagere Xeon servers al wel nieuwere generaties (Skylake EP).

[Terr-E]

Mooie specs !
Dank wederom voor de openheid, altijd leuk om te zien wat er zoal gebruikt wordt.

Vraagje: gebruiken jullie nog steeds Percona Server for MySQL ?

[Kees]

Yep, we zitten nu op Percona server 5.7.24. Helaas is versie 8.0 nog niet lang genoeg uit voor deze server.

[NIMIC]

Op mobiele devices hebben we het makkelijker gemaakt om te wisselen tussen uitvoeringen van een product door een selectbox met de uitvoeringen onder de productnaam weer te geven.

Mooie toevoeging.
Ook voor op de desktop, daar kon ik volgens mij ook niet makkelijk wisselen. Of heb ik heel lang iets over het hoofd gezien.

[Femme]

De dekstopweergave heeft al heel lang een selectbox met de uitvoeringen. Je vindt 'm onder de specificaties in de productheader.