Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 164 reacties, 222.753 views •

Toekomstige uitbreidingen

We proberen onze servers vlot te vervangen. Dat betekent niet dat ze altijd precies drie jaar na aanschaf worden ingeruild, maar dat is wel waar we ons op richten. Een enkele keer komt het beter uit om een server wat eerder te vervangen, zodat we bijvoorbeeld een nieuwe aanpak voor een bepaalde service kunnen uitwerken.

Ook dit jaar gaan we weer flink wat vervangen. Het belangrijkste is de centrale storage. Het liefst zouden we een omgeving opzetten met multi-master-replicatie, zodat er naar een willekeurige fileserver in een van de beide locaties geschreven kan worden en de clients transparant omgezet kunnen worden bij problemen.

In de praktijk blijkt dat dit soort systemen erg zeldzaam is. Zelfs ruim boven ons budget is het nog niet gebruikelijk dat fileservers elkaar via een tcp/ip-netwerk actueel kunnen houden. Het is meestal één kant op, in een variant op een master-slave-opstelling. Omdat het systeem voor ons niet alleen storage moet bieden, maar ook beheersbaar en flexibel moet zijn, gaan we hier waarschijnlijk weer simpelweg aan de slag met ZFS. Op welk besturingssysteem of welke appliance dat dan komt, weten we nog niet. Het liefst wordt dat natuurlijk Linux, maar helaas is ZFS op Linux geen officieel ondersteund bestandssysteem. Dat maakt de combinatie daardoor automatisch een minder goed recept voor stabiliteit en continuïteit.

Naast de storage staan er nog diverse servers op de agenda om vervangen te worden. Daaronder bevinden zich de 'slave' MySQL-server, de VM-hosts en de videowebservers. Aangezien die in hun huidige vorm vrij goed werken, zullen dat domweg varianten op dezelfde soort server zijn. Alleen dan uiteraard drie jaar nieuwer.

Op het gebied van software willen we ook nog verder met nieuwe versies en zullen we diverse aspecten tunen. Zo wordt het https-verkeer nu direct naar Apache verzonden. Dat is zonde, want daardoor wordt Varnish overgeslagen. Aangezien onze loadbalancers ook zelf https kunnen 'terminaten', gaan we onderzoeken hoe we dat het efficiëntst kunnen inzetten. Helaas is dat typisch een wijziging die simpel lijkt, maar in de praktijk allerlei haken en ogen met zich meebrengt. Op het moment van schrijven wordt dit daarom alleen nog voor tweakimg.net gedaan.

Zoals eerder gemeld willen we onderzoeken waarom MongoDB relatief slecht met de hoeveelheid queries en updates overweg kan. Wellicht is een nieuwere versie beter of stappen we over op een van de alternatieven. Vooral Redis lijkt een goede kandidaat. Verder moeten we nog hard aan de slag om al onze oude code na te pluizen op compatibiliteit met PHP 5.4 en 5.5.


Door Arjen van der Meijden

- Lead Developer

In oktober 2001 begonnen met als voornaamste taak het technisch beheer van het forum. Daarna doorgegroeid tot senior developer en software architect. Nu lead developer, met een leidinggevende taak aan het team van programmeurs en systeembeheerders van Tweakers.net.

Reacties (164)

Reactiefilter:-11640164+1134+226+30
Moderatie-faq Wijzig weergave
1 2 3 ... 8
Misschien nog een handig weetje in het kader van Java en garbage collection - de CMS garbage collector faalt als er te veel fragmentatie in de heap space van je JVM is. In tegestelling tot de standaard parallel GC kan de CMS niet defragmenteren. In geval van zo een "concurrent mode failure" gaat de JVM de standaard parallel GC aanroepen en staan nogsteeds je threads stil. Je kan dit zien als je garbage collection logging aanzet in je JVM.

Hoe los je dit op? Tja, kan lastig zijn. Als je vanuit je applicatie veel kleine objecten aanmaakt die in de tenured generation terecht komt dan fragmenteert je heap space veel sneller dan dat je veel grote objecten aanmaakt (immers grote objecten zorgen ook weer voor grote gaten in je heap space). Een mogelijk antwoord zijn TLABs. Ik ben zelf geen Java programmeur dus mijn kennis houdt hier ook een beetje op. Zie https://blogs.oracle.com/...sizing_an_annoying_little voor details.
Sinds we van Parallel naar CMS zijn gegaan hebben we geen noemenswaardige vertragingen meer gezien. Althans, ze vallen in ieder geval niet zo meer op als toen we nog de Parallel collector gebruikten, toen was het meerdere keren per dag dat een hele serie requests naar zo'n Tomcat (die dan dus bezig was met zijn full garbage collect) dan als traag werden gelogged. Veel daarvan waren langer dan 2 seconden.

Dus zelfs als het nu nog af en toe voorkomt, is het in ieder geval veel minder erg dan voorheen :)
"Ook dit jaar gaan we weer flink wat vervangen. Het belangrijkste is de centrale storage. Het liefst zouden we een omgeving opzetten met multi-master-replicatie, zodat er naar een willekeurige fileserver in een van de beide locaties geschreven kan worden en de clients transparant omgezet kunnen worden bij problemen."

DRBD kan tegenwoordig volgens mij ook over tragere WAN links geconfigureerd worden. We gebruiken dit in onze Vmware omgeving al jaren naar tevredenheid. Failoveren gaat vlot (er is "amper" impact op de virtuele machine's). Het voordeel ervan is dat het synchroniseerd op block niveau en je er dus elke FS op kunt draaien :)
Poeh, wat een artikel, maar ik heb het helemaal gelezen. Ofschoon ik mezelf niet als IT-Pro kan beschouwen, en dat met een artikel als dit ook duidelijk merk :+ was ik toch wel nieuwsgierig naar jullie afwegingen die de keuzes hebben bepaald voor de omgeving zoals de momenteel draait. Zoals in iedere server omgeving is ook bij Tweakers een factor "historisch gegroeid" aanwezig. En dat is prima, want dat duidt op een een voortdurend gecontroleerd omvormen. En met serveromgevingen willen we niet anders.

Ik ben betrokken in het beheer van een PDM database (Product Data Management). De PDM software gebruikt een Oracle omgeving als database. In deze configuratie zijn in het afgelopen decennium ook de nodige omzwervingen gedaan. In dit kader vond ik, ondanks mijn gebrek aan diepgaande IT-kennis, twee frases opmerkelijk en meende ik uit mijn ervaring te herkennen:
Geen van die kerntaken draait op virtuele machines, we vragen doorgaans voldoende van dergelijke servers om ook daadwerkelijk bare metal te kunnen verantwoorden. Daarbij moet wel gezegd worden dat we soms bundels taken op een server combineren, maar daarvoor is uiteraard geen virtualisatie nodig.
Deze uitspraak vond ik opmerkelijk. Ik vond het verfrissend om te lezen dat voor de kern activiteiten fysieke servers zijn gekozen. Voor de bovengenoemde PDM database gaan wij de servers wel virtualiseren (ook de Oracle environment), maar het was een duivels dilemma. Het is natuurlijk appels en peren vergelijken, maar wij verwachten dat virtualisatie wel mogelijk zou moeten zijn. Waarom dan toch nerveus? Ten eerste claimt Oracle een sloot aan RAM geheugen voor stacks over de recente activiteit. Ten tweede zou Oracle gevoelig kunnen zijn voor timing issues die door de virtualisatielaag net niet meer real time genoeg zijn. Qua CPU belasting stelt de server activiteit echter weinig voor, en dat is het grootste verschil met de Tweakers omgeving.
Ondanks snelle 1Gbit-switches en -nics is het nog altijd veel sneller om met localhost te communiceren dan over het netwerk te gaan.
Dit lijkt ook ons voortschrijdend inzicht, ofschoon ook weer een gevalletje appels en peren. In de eerste jaren van onze installatie stonden de PDM applicatie en de Oracle omgeving op dezelfde fysieke server. Enkele jaren geleden is vanwege het zware beslag dat Oracle legt op het werkgeheugen een aparte fysieke Oracle server opgericht. Wij hoopten toen op een sneller acterende database. Als ik mij niet vergis waren beide servers onderling met 2x1Gbit verbonden, aan bandbreedte lag het dus niet. Nou, van die snelheidswinst hebben we niet veel gemerkt. Eigenlijk is ten gunste van het Oracle geheugengebruik een veer gelaten door een netwerk verbinding tussen de PDM en Oracle omgeving te introduceren. De slag die komend jaar gemaakt gaat worden is om een andere netwerkverbinding minder belangrijk te maken. De PDM applicatie bevat ook Java componenten en heeft een serverproces dat nog lokaal op clients (client-side) en op de PDM applicatie server (server-side) draait (2-tier). Deze situatie wordt omgezet naar een configuratie waarbij zowel de client-side processen als het server-side proces lokaal op de PDM server draaien (4-tier). Op de PDM clients rest dan nog alleen een echt client proces. De trade off is wel dat de PDM server een fors uit de kluiten gewassen systeem gaat worden, en onze huidige generatie client werkstations een ietwat overgedimensioneerd zullen zijn ;). Onze verwachting dat dit een snellere database response oplevert is gebaseerd op het gegeven dat de database momenteel ook een webomgeving bedient die voor de webclients het client-side proces al op de webserver heeft draaien. Deze client-side processen hebben, zo leggen wij uit, door de innige koppeling tussen web-, Oracle- en PDM-server een snellere database response dan de royaal uitgelegde (niet-web)client werkstations met hun eigen lokale client-side proces. Kortom, een totaal andere omgeving waar ook de tendens is om de invloed van het door andere taken vervuilde netwerkverkeer op de database responsiviteit te minimaliseren.

edit: taal

[Reactie gewijzigd door teacup op 9 maart 2013 22:39]

1 gokje: CATIA/ENOVIA?
Nginx is niet inflexibel of een omgeving die 'een probleem' heeft.

Apache heeft sowieso als groot voordeel dat we het goed kennen en al jaren stabiel draait. We maken onder andere gebruik van de MultiViews-functionaliteit (dus dat je een bestand genaamd pricewatch.php hebt en dan tweakers.net/pricewatch kan gebruiken zonder dat je dat expliciet voor elke url moet lopen mappen) en allerlei andere features. Zoals ondersteuning voor .htaccess, mod_rewrite, php geintegreerd in de omgeving (dus niet een losse daemon hoeven te beheren), de mogelijkheid om naar een remote-server te loggen, etags uit kunnen schakelen (dit kon Lighttpd niet goed, Nginx wellicht wel), remote-ip's vanuit varnish gebruiken ipv de eigen remote-ip (en dus geen 127.0.0.1 als ip in de access logs loggen), ssl met virtual hosts en allerlei andere kleine dingetjes.

Ieder van die features is mogelijk wel een tegenhanger voor in Nginx, maar het is allemaal niet domweg een drop-in replacement. We hadden dan steeds opnieuw op zoek gemoeten naar dat alternatief. Nginx+PHP-FPM was in onze tests overigens niet sneller dan Apache+PHP voor pure php-requests. Dus het bood dan vooral de nadelen van een nieuwe configuratie uit moeten vogelen en een extra daemon te moeten beheren.

Alleen maar een omgeving vervangen "omdat het kan" is niet zo'n beste reden. Van Apache weten we dat het werkt en voldoet aan wat we willen

De vraag is voor ons dus niet "Wat heeft Apache beter dan Nginx?", maar "Wat heeft Nginx zodanig beter, dat het een goed idee is om Apache+Varnish erdoor te vervangen?".

Het antwoord daarop is, voor zover wij dat hebben beoordeeld: "niets". Wat overigens niet zegt dat het niks beter doet dan Apache of een slecht alternatief is :) Het zegt zelfs niet dat als we het met de huidige stand der techniek allemaal over zouden moeten doen, dat we dan niet Nginx zouden kiezen (overigens ook niet dat we het per se wel zouden kiezen :P ).

Daarbij zal je dus moeten accepteren dat doordat wij Apache en Varnish draaien, we automatisch bevoordoordeeld zijn en elke feature die Nginx niet of minder praktisch aanbiedt snel als een minpunt zullen zien terwijl jij het niet zou opnoemen als pluspunt van Apache/Varnish :P
Bovendien houden we sowieso wel bij dit soort dingen het "If it ain't broken, don't fix it"-adagio aan :)
Wat me bij T.net opvalt is dat jullie een allegaatje hebben aan merken.

Dell, Sun, IBM etc. waarom niet 1 merk icm met gemirrorde storage? En waarom geen VMs? met de huidige technoligie kan je toch veel meer doen dan met zoveel fysieke machines?

3 of 4 flinke stukken hardware icm cached SSD en iSCSI storage. tegenwoordig is 10Gbit in servers redelijk mainstream aan het worden en betaalbaar. Dan kan je ook makkelijker backuppen dmv replicatie en dedup erbij naar de andere locatie.

Kan het misschien helemaal verkeer zien maar dat moet toch haalbaar zijn met jullie omgeving.
We hebben gemixed Dell (en voorheen Sun) en IBM omdat de beste offertes nou eenmaal niet elke keer bij dezelfde partij vandaan kwamen. Standaardiseren op hardware heeft natuurlijk wel wat voordelen, maar een scherpe prijs krijgen ook...

Voor wat betreft virtualisatie; mijns inziens werkt dat vooral goed als je veel relatief lichte taken hebt die je over een verzameling (zware) machines kunt uitsmeren en waarbij ze bij voorkeur niet allemaal tegelijk evenveel belast worden.
Wij hebben vooral een beperkt aantal zware taken en die worden bovendien allemaal op dezelfde momenten zwaarder belast (als het drukker is op de site).

Bovendien hebben we er ook niet zo'n zin in om een server af te stemmen op alle taken tegelijk en er dan achter te komen dat het toch nog niet goed werkt. Dat twee applicaties elkaar negatief beinvloeden.
We hebben bijvoorbeeld een tijd lang MySQL en MongoDB op dezelfde servers gedraaid (zonder virtualisatie), veel RAM, dikke cpu's, ssd-storage... En toch werd MySQL negatief beinvloed door MongoDB en vice versa. Daarna toch maar op losse servers gezet en ze presteerden beide gelijk een stuk beter, ondanks dat de servers zowel ervoor als erna niet tot hun maximum werden belast.
Voor wat betreft virtualisatie; mijns inziens werkt dat vooral goed als je veel relatief lichte taken hebt die je over een verzameling (zware) machines kunt uitsmeren en waarbij ze bij voorkeur niet allemaal tegelijk evenveel belast worden. Wij hebben vooral een beperkt aantal zware taken en die worden bovendien allemaal op dezelfde momenten zwaarder belast (als het drukker is op de site).
Virtualisatie hoef je niet alleen te gebruiken om CPU utilization omhoog te krijgen. Je kan het ook gebruiken voor om je server portable te maken, zodat je het kan migreren in geval van onderhoud of uitval. Of om VM's te klonen zodat je snel capaciteit kan bijschalen. (Op eigen hardware of 3rd party cloud provider.)
We hebben bijvoorbeeld een tijd lang MySQL en MongoDB op dezelfde servers gedraaid (zonder virtualisatie), veel RAM, dikke cpu's, ssd-storage... En toch werd MySQL negatief beinvloed door MongoDB en vice versa.
Met virtualisatie kan je dat juist voorkomen, omdat je limieten aan de VM stelt. Je kan tegenwoordig SAP draaien als monster VM tussen je andere enterprise applicaties. Als je toch bare metal wil draaien is stateless computing een optie. Met service profiles kan je daarmee de identiteit van een server bepalen. (Zoals BIOS & RAID settings, boot from SAN opties, MAC adressen, etc.) Faalt de server hardware, dan boot je het server OS op een andere server, met dezelfde server settings.

Maar als rackspace, dataverkeer en stoomkosten gratis zijn dan speelt dit natuurlijk veel minder. En T.net heeft natuurlijk een systeembeheerder. Dus op beheer is ook niet veel te winnen.
Bedankt voor je uitleg.

Mee eens vwb de 2 databases op 1 server is sowieso niet optimaal. Maar met virtualisatie ( wat al gezegd is) ben je veel flexibeler. Ook met zware taken kan virtualisatie prima over weg. Misschien wel beter ivm makkelijke schaling. Het hoeft niet meteen VMware te zijn er zijn ook andere leveranciers die dit prima kunnen.

SSD kan hier ook een goedesnelheids bepaler zijn. Zoals hybride SAN oplossingen die SSDs gebruiken voor caching van veel gebruikte pages. daarmee kan je snelheden halen van dik over de 20 tot 30K IOPS. Zeker bij databases goed. Maar eigenlijk wil je niet dat een database leunt op schijven maar om memory. Wij hebben enkele klanten die met 600 man werken op een database server met 96GB aan memory (ok wel een SSD SAN). De snelheid is perfect. Ook prijs speelt een rol natuurlijk. Niet ieder bedrijf of stichting heeft zoveel op de plank liggen. Dat is ook begrijpelijk.

Als T.net hebben jullie toch ook wel de mogelijkheid om bij bijv Dell of IBM loaner hardware te krijgen om zulke zaken te testen? Het is voor zo`n bedrijf ook goede marketing dat een site zoals T.net op de hardware van die fabrikant draait.
Ik zie af en toe (OS) disken van 1x X Gb voorbij komen. Is dat dan het logische aantal disken of zit er echt maar een in? (Dat laatste lijkt het geval op sommige plaatjes). Ben benieuwd waarom daar voor gekozen is en niet voor een RAID 1 opstelling. Van alles wat fysiek kapot kan gaan staan disken samen met fans en voedingen toch bovenaan mijn ervaringslijst.
De kans dat een harde schijf uitvalt is nou ook weer niet zo heel groot. Het is niet zo dat we er dagelijks een moeten vervangen... Sterker nog, ik kan me de laatste keer nauwelijks herinneren. Zeker van OS-disks weet ik eigenlijk niet of er uberhaupt een in de afgelopen 10 jaar stuk is gegaan. En ook zwaarder belaste datadisks houden het over het algemeen prima hun geplande 3 jaar vol.

Soms is het dan domweg niet de extra investering in extra redundantie in een server waard. Dat doen we alleen als de bijbehorende taken al heel erg redundant opgezet. Het beste voorbeeld zijn onze webservers. Daar hebben we er 6 van, als er een of twee van uitvallen merk je daar weinig van.

Het is dan domweg zonde van het geld om 6x een extra disk en raid-controller aan te schaffen. Voor servers en taken die niet zo eenvoudig te vervangen zijn kiezen we er uiteraard wel voor om ook de risico's rond de OS-disks nog verder te beperken.
die server zal toch wel een standard controller met raid-1 hebben
Nee, niet per se standaard. Over het algemeen kost een eenvoudige raid-1 controller een paar tientjes per server extra. Al met al heb je het met dit soort servers al gauw over 100-200 euro per server extra - en soms moet je dan ook een hot-swap chassis kiezen en wordt het nog wat meer - als je een 2e disk en een raidcontroller toevoegt.
Ik vind 100-200 euro voor een server extra niet echt iets om meteen op te besparen. Ik snap jullie overweging, ik zou het zelf alleen niet doen. Alles redundant uitvoeren maar dan 100-200 euro besparen op een raid-1 opstelling voor je OS.
Zoals ik hieronder ook al noemde. Mijn schatting is dat we op normale momenten aan 1 webserver genoeg hebben en op drukke momenten aan 2.
Dus dan wil je er minimaal 3 hebben, zodat een complete server kan uitvallen (bijvoorbeeld door een kapotte voedingverdeler of moederbord) en je nog steeds al het verkeer aankan.

We hebben echter 6 webservers. Dus volgens die schattingen zijn het er 3x zoveel als strict noodzakelijk en 2x zoveel als ons minimum comfort-niveau. Aangezien die raid-controllers en extra disks ons niet gaan helpen tegen een uitvallende locatie (bijv stroomuitval of netwerkverbinding die eruit gaat), moesten we toch wel minimaal 3 per locatie hebben (en dus 6 in totaal) :)

Er is een moment dat extra redundatie, duurdere support, etc allemaal niet genoeg meer toevoegt om daadwerkelijk tegen de risico's op te wegen.

Doordat we natuurlijk meestal twee werkende lijnen hebben en (OS-) harde schijven in onze ervaring vrij zelden stuk gaan, vonden we het niet nodig om ook nog eens weer extra te investeren in raid-controllers en extra schijven :)
De trend is eigenlijk zo bij alle grotere websites -- simpelere machines met zelf minder redundancy, maar dan wel de servers redundant uitvoeren.

Tweakers zit een beetje op de ondergrens van waar dat nuttig is, maar het zal in deze opstelling niet veel meer kosten dan minder, grotere servers die van alles tegelijk doen.

Consolidatie op grote bakken (evt met virtualisatie) versus large-numbers COTS bakjes is al zeker de afgelopen tien jaar een van de grote spanningsvelden in de hele IT. Het voordeel (ook voor kleinere websites) van het tweede systeem is vooral de schaalbaarheid, voor relatief weinig investering tegelijk. Een of twee (of vier) servertjes vervangen is betaalbaarder dan 1 grote VM bak met 4 sockets en 384GB ram. Met name als je rackspace en power gratis is natuurlijk :P

Opvallend is BTW dat door technische limits juist in de DB servers wel nog de grote-geconsolideerde filosofie wordt gebruikt, omdat replicatie van mysql blijkbaar nog steeds zuigt :)
Je vergeet dat RAID controllers ook kapot kunnen, of fouten kunnen bevatten. Leuk dat je je schijven dubbel hebt uitgevoerd, maar je krijgt er een ander spof voor terug. Plus dat er extra beheer nodig is, en er door de dubbele hoeveelheid schijven ook vaker iets kapot gaat, wat je wel weer moet vervangen.
ik geloof dat er11 of 12 jaar geleden een grote crash was. Veel reactie's waren alleen nog te achterhalen door gebruikers die het nog in hun cache hadden of zoiets.
Ja das zeker, Hier is het gedeeltelijk allemaal nog eens na te lezen

reviews: Tweakers.net 10 jaar: De hostinggeschiedenis 2001- 2004

Gelukkig wel, Alle noob posts van mij waren toen allemaal meteen mooi opgeschoont :D

Ook leuk te zien is in deze post van toen hoe tweakers begonnen is met een leuke P!!! opstelling en hoe ze gegroeid zijn van zelfbouw knutsel servers tot leuke apparaten ;)

En voor nog meer geschidenis :P
reviews: Tweakers.net 10 jaar: De hostinggeschiedenis 1998 - 2001

Kan je meteen lezen waar dat MiniSQL vandaan komt haha

[Reactie gewijzigd door Professor_Botje op 14 maart 2013 00:32]

ik gok dat dit de reden is voor de redundantie van de servershet risico kan daarom genomen worden, en is de aanschaf per server wel lager (1 disk, geen raid controller)
Het overstappen zou namelijk veel werk geweest zijn, onder meer omdat een groot deel van de SQL-statements herschreven zou moeten worden om ze te vertalen van MySQL's eigen SQL-dialect in het dialect van de nieuwe database.
In hoeverre is een oplossing als PDO hier een mogelijkheid? Niet dat het mij noodzakelijk lijkt om over te stappen naar PostgreSQL of iets anders, maar waarom geen flexibiliteit inbouwen?
Vziw zijn er maar heel weing omgevingen die je daadwerkelijk afschermen van de specifieke SQL-smaak. Dan kom je al gauw bij de ORM's uit.
Bij PDO schrijf je uiteindelijk ook gewoon SQL-statements, dus zal je gebruik (kunnen) maken van MySQL-specifieke functies, statements en datatypen. Denk aan LIMIT's of UNIX_TIMESTAMP() of unsigned data-typen of de INSERT ... SET (analoog aan de UPDATE), INSERT .. ON DUPLICATE KEY UPDATE, REPLACE en al dat soort zaken.

Als je puur vanilla SQL92 (of 99 of 03) zou schrijven, dan kan je met PDO (maar ook met onze eigen wrapper-bibliotheek) relatief eenvoudig switchen naar een ander type database die vergelijkbare of betere SQL92-ondersteuning heeft.

Maar we hebben lang niet alle statements in puur SQL92 geschreven, al is het alleen maar omdat cursors niet bestonden in MySQL en LIMIT sowieso veel beter werkt voor paginering in webapplicaties. Maar ook andere dingen zijn er doorgesijpeld of zelfs vrij bewust gekozen (of omdat er geen alternatief was).
Nu breekt UNIX_TIMESTAMP() je query cache, dus die wil je natuurlijk sowieso liever vermijden ;)

Having said that, ik moet de eerste ORM nog zien die geen performance verlies oplevert. Het is jammer (zeker gezien sommige van MySQL's eigenaardigheden), maar specifieke SQL schrijven is ook niet zo'n ramp. Zeker met de recentere MySQL versies mis ik de mogelijkheid om over te stappen niet zo.
We gebruiken geen query cache, met onze hoeveelheid queries en updates zagen we er niet heel veel heil in. Sowieso proberen we data waar het wel lang in de cache zou blijven al via memcached te cachen :)
2 vragen:
- Waarom is dataverkeer gratis op jullie primaire locatie?
- Zou het wat betreft kosten en schaalbaarheid niet interessant zijn om de website in een cloud onder te brengen bij een grote aanbieder (google e.d.)? En zou het uberhaupt mogelijk zijn voor een website als tweakers?
- Omdat dat nou eenmaal een sponsordeal is met True (zie ook het logotje rechtsboven), die we al heel lang hebben :)
- Omdat onze bandbreedte nu grotendeels gratis is, zijn er maar verdraaid weinig cloudberekeningen die uberaupt op 'break even' uitkomen, laat staan goedkoper zijn.


Bedenk een paar punten mbt cloud:
- Je hebt nog altijd minstens een systeembeheerder nodig (en daar hebben we er nu ook een van, dus minder kan niet)
- Als je een cloudserver 3 jaar lang, 24x7 laat draaien is ie doorgaans flink duurder dan zelf een server met dezelfde specificaties aanschaffen en dezelfde tijd aan te laten staan (maar je kan evt wel delen van servers huren natuurlijk)
- Je moet moeite gaan doen om "krap bemeten" servers te plaatsen en zodra ze te krap worden, ze verhuizen naar een ruimere server.
- Het liefst doe je dat continu en meerdere keren per dag en zonder dat gebruikers daar last van hebben
- Je moet allerlei omgevingen ombouwen om de meest (kosten)efficiente cloud-variant te pakken (denk bij Amazon aan ElastiCache, S3, SQS, SimpleDB, DynamoDB, etc ipv memcached, Varnish, ActiveMQ, MySQL en MongoDB).

Cloudoplossingen zijn daarom moeilijk om kostenefficient uit te rollen, zeker als je al bestaande hardware hebt.
Al met al kan je een cloudoplossing wel net zo goedkoop of goedkoper krijgen als een oplossing met normale servers, maar het is niet zo makkelijk als men nog wel eens pretendeert.

En aangezien in ons geval de kosten voor hosting heel laag zijn door die sponsordeal, wordt het wel heel moeilijk om een cloudoplossing goedkoper te laten zijn. Want naast de vaste aanschafkosten voor een server die relatief laag belast zal zijn (en dus meestal duurder dan nodig) en het systeembeheer (je hoeft niet meer mensen te hebben die fysieke dozen versjouwen) zou je vooral ook op kosten voor bandbreedte, rackhuur en energie moeten kunnen besparen :P

Overigens hebben diverse grote cloudomgevingen het afgelopen jaar slechtere uptimes gehad dan wij.
• Colocator True sponsort het verkeer sinds jaar en dag.
• Wil jij afhankelijk zijn van een derde, de complexiteit van dit park "zomaar even" verplaatsen? Bovendien is Google een Amerikaans bedrijf. Waar wordt de data bewaard, kunnen de regeringsdiensten er bij? Wat als er problemen zijn zoals bij een andere cloudaanbieder Amazon een tijdje geleden?

De public cloud is niet heilig. Doe mij maar een interne zodat je controle hebt over het park.
Je kan wel kijken naar iets als CloudFlare. Mocht het ooit voorkomen dat alle locaties tegelijk gebombardeerd worden (zeer goed mogelijk!!111one!one1!) of om een andere reden lle servers down zijn, kun je nog altijd op een gecachte kopie van Tweakers browsen.
Cloudflare != heilig:

Storing 4 maart (800.000 sites plat): http://www.ispam.nl/archi...dduizenden-websites-plat/
Eind vorig jaar: http://techcrunch.com/201...e-went-down-this-morning/

Ach tja, alles kan plat :9

[Reactie gewijzigd door pietermx op 9 maart 2013 19:06]

In hoeverre heeft Tweakers dan interessante data voor de US government? In principe staat alle data vrij toegankelijk op het web, dus lijkt me niet echt een issue.
Bovendien zou je ook een Europese cloud provider kunnen kiezen (toekomstmuziek wellicht nog)

Overigens zou ik de cloud in zo'n geval alleen gebruiken voor 'cloudbursting': het terugvallen op extra capaciteit in tijden van grote drukte. Als ik het verhaal begrijp, is er sprake van een enorme overcapaciteit om ook op dat soort dagen te performen. Dat is redelijk prijzig en precies de use case van cloud. Voor je standaard workload kun je zelf een betere prijs of kwaliteit regelen in principe.
Aller eerste... mijn complimenten voor dit verhelderende artikel. Weinig sites geven zoveel interessante data en gegevens prijs, maar jullie _O_.....

Maar dan rest me nog n vraag:

Stel, wat nu als op de primaire locatie de stroom uitvalt (en de stroom-redundantie niet werkt)?
Is de secondaire locatie bij Telecity dan groot genoeg om de bezoekers op te vangen? En zijn er dan services die niet zullen werken dan? Ik kan me voorstellen dat de zoekserver dan even niet van belang is om in te zetten...
En die repliceert MySQL zich dan uiteindelijk als de primaire locatie weer up komt?

Hoe reageert het serverpark hier dan op?

[Reactie gewijzigd door AW_Bos op 9 maart 2013 16:34]

Zodra euNetworks uitvalt wordt het inderdaad even spannend. De capaciteit bij Telecity is overigens ruwweg gelijk aan die bij euNetworks, dus wat dat betreft zit het wel goed.

Het belangrijkste dat momenteel nog echt weg zou vallen is de videostreaming.

Wel is het zo dat een aantal aspecten (nog) niet automatisch een fail-over zullen doen, waaronder storage, MySQL en Mongodb. Die laatste twee zullen in read-only modus terugvallen. Daarnaast zullen cronjobs en queue-consumers niet direct werken.

We werken er wel naar toe alle taken naast redundant ook automatisch of bijna-automatisch (na een druk op een 'knop') te laten omschakelen. Daar werken we in de meeste gevallen nog aan, maar de site zal dan dus niet gelijk goed werken. Wel is alle data dan al beschikbaar, dus het opbrengen van taken en het tot master promoveren van services is daardoor een stuk eenvoudiger :)
We hoeven in ieder geval niet direct nieuwe servers te kopen of backups in te laden als een van de twee locaties eruit gaat :P
Even over power, op bijna elke server/Router ed. zijn continue twee Power sources aangesloten (220V of -48V afhankelijk van waarmee de apparatuur is uitgevoerd) dat is in je local rackspace, indien de externe power uitvalt is er altijd eerste instantie nog een batterij backup, en binnen een (paar seconden) zullen er generatoren opstarten die het datacenter een aantal dagen van stoom voorzien of zoals waar ik werkte twee weken kon laten doordraaien, dus power is mi. niet echt een probleem, dat je hoopt dat je apparatuur op de juiste wijze Switched dat lijkt me spannender…
maar 25 servers? valt me tegen dan is tweakers nog een tamelijk klein project?
Ik vind 25 overigens best een hoop, maar als je goede performance wilt hebben.... ;)
Ik noem het niet bepaald een klein project, als ik dit zo lees....

[Reactie gewijzigd door AW_Bos op 12 maart 2013 00:48]

25 server valt toch best wel mee? is niks schrikbarends ofzo..
Voor 1 website? Ik vind het juist veel.
'Google' en 'Facebook' zijn ook beide 1 website... toch? Zou je van hun ook minder dan 25 webservers verwachten? :)

Het aantal benodigde servers hangt onder andere af van het aantal bezoekers, de hoeveelheid data en de complexiteit (en dus benodigde rekentijd per bezoek). Het aantal 'websites' is niet zo relevant :P
1 2 3 ... 8

Op dit item kan niet meer gereageerd worden.



HTC One (M9) Samsung Galaxy S6 Grand Theft Auto V Microsoft Windows 10 Apple iPad Air 2 FIFA 15 Motorola Nexus 6 Apple iPhone 6

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True