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 , , reacties: 114, views: 38.521 •

In oktober installeerden we Artemis 6, onze huidige primaire databaseserver, en op 23 juni nemen we ook een nieuwe secundaire databaseserver in gebruik: Apollo 6. Deze server neemt de replicatiefunctie van Artemis 5 over. We gaan op woensdagochtend 23 juni om 08:00 aan de slag en we verwachten ongeveer vier uur nodig te hebben.

Omdat MySQL's replicatie-omgeving niet fail-safe is, willen we met een consistente backup en de bijbehorende binlogs beginnen. Nu kan in MySQL met MyISAM-tabellen alleen een consistente backup worden gemaakt als de database geen nieuwe data aangeleverd krijgt, dus MySQL moet worden stilgelegd.

Het stoppen en starten van onze MySQL-server duurt een aantal minuten: er moeten tenslotte tientallen gigabytes aan ram-cache worden verwerkt. Omdat we MySQL liever niet te vaak platgooien, nemen we de gelegenheid te baat om enkele wijzigingen in grote tabellen aan te brengen en een minor upgrade van de op Artemis draaiende MySQL uit te voeren.

Omdat we tegenwoordig over een read-onlymodus beschikken, kan de site gedurende het onderhoud grotendeels online blijven, al kan er uiteraard niets naar de database geschreven worden. Dat betekent dat je niet kunt reageren of modereren, niet kan inloggen, geen nieuwe topics kan starten, enzovoorts. Zolang de read-onlymodus actief is, wordt bovenaan de pagina een gele waarschuwingsbalk getoond.

Apollo 6 Dell PowerEdge R710 behuizing dicht

De nieuwe machine is een Dell PowerEdge R710, die naar het voorbeeld van Artemis 6 is gemodelleerd. Apollo 6 krijgt een tweetal Xeon X5660-hexacores en 48GB geheugen, en net als zijn primaire broertje beschikt hij over een zestal 50GB-ssd's en twee 300GB grote sas-schijven.

Daarmee is Apollo 6 onze vierde machine met solid state drives: naast Artemis 6 zijn ook de zoekmachine en de nieuwe fileserver hiermee uitgerust. De fileserver gebruikt de flashdisks overigens alleen als cache en voor logs, in aanvulling op een array van normale sata-disks.

  Artemis 6 (24-10-2009) Apollo 6
Processors 2x Xeon X5570 2,93GHz 2x Xeon X5660 2,80GHz
Geheugen 72GB DDR3-800 48GB DDR3-1333
Raid-controller Dell Perc 6/i Dell Perc H700
Opslag 2x Seagate Savvio 10K.3 300GB
6x Dell / Samsung MCCOE50G5MPQ 50GB
2x Seagate Savvio 10K.3 300GB
6x Dell / Samsung MCB4E50G5MXP 50GB

De oplettende lezer zal zien dat de nieuwe Apollo toch behoorlijk wat reken- en i/o-capaciteit heeft. Voor het maken van de eerder genoemde consistente backups heeft Apollo nog wel wat spierballen nodig, maar wat MySQL betreft blijft het daarbij. Artemis heeft het normaliter niet heel erg druk, waardoor het weinig zin heeft om het MySQL-leeswerk over beide machines te verdelen.

Wel hadden we al langer de wens om de sessies en de voorkeuren van gebruikers flexibeler op te slaan, zodat een gebruiker zijn instellingen zowel per sessie als voor al zijn sessies kan opslaan. Ook zou het prettig zijn als we de database niet elke keer hoeven te verbouwen als we een instelling willen toevoegen.

De starre MySQL-tabelstructuur die we nu gebruiken, sluit niet aan bij die wensen. We stonden daardoor voor de keus om een flexibelere MySQL-database te bouwen of om alternatieve databases te bekijken.

Aangezien de flexibele variant in MySQL zou betekenen dat we extra queries moesten introduceren en de overzichtelijkheid van de code zou afnemen, hebben we een inventarisatie van NoSQL-databases gemaakt. Daarvoor hadden we een aantal eisen geformuleerd.

  • We hebben geen zin of tijd om het beheerwerk zelf te schrijven. Cassandra en Hadoop vielen daardoor af.
  • We willen de instellingen per gebruiker logisch gegroepeerd houden, zonder concessies te doen aan het aantal en het type van de instellingen. Hierdoor viel een hoop software af, waaronder MemcacheDB en Tokyo Cabinet, en bleven vooral document databases over.
  • We willen niet verplicht zijn om meer hardware toe te voegen als er meer data dan ram is - dus moesten we Redis en Terrastore schrappen.
  • Query's als 'geef de instellingen behorende bij sessie X', 'geef alle sessies voor gebruiker Y' en 'hoeveel sessies zijn er voor Firefox-gebruikers' moeten efficiënt en snel worden uitgevoerd. De mapreduce-only document databases, zoals bijvoorbeeld CouchDB en Riak, waren daarom ongeschikt.
  • We slaan slechts een paar gigabyte aan data op, dus rauwe performance is voor ons belangrijker dan uitgebreide schaalbaarheid.
  • Aangezien we met PHP werken, moet daar eenvoudig mee gecommuniceerd kunnen worden.

Uiteindelijk is de keus gevallen op MongoDB. Apollo 6 gaat, naast MySQL-replicatie, dus MongoDB draaien om de flexibele opslag van voorkeuren te faciliteren. Als Apollo 6 onverhoopt uitvalt, zou deze constructie wel betekenen dat bezoekers niets meer mogen doen, ook niet als de primaire MySQL-server nog wel goed werkt. Daarom hebben we Artemis 6 zo ingericht dat hij de MongoDB-backupserver wordt. Kortom: Apollo is de backup voor de MySQL-database en in ruil daarvoor is Artemis de backup voor de MongoDB.

Ook deze wijziging gaan we woensdagochtend doorvoeren. Als het goed is merken jullie daar in eerste instantie niets van: we implementeren de infrastructuur, maar niet de toepassingen. Het is dus niet zo dat er ineens allerlei nieuwe instellingen beschikbaar komen - dat komt allemaal later wel ;)

Conceptuele weergave van de Tweakers.net (web)servers

Aangezien we ondertussen een behoorlijk complexe variant op LAMP hebben opgebouwd, zie je hierboven een overzicht van wat we ondertussen aan logische onderdelen hebben. De twee rode blokken representeren respectievelijk Artemis 6 en de nieuwe Apollo. Verder zie  je de memcached- en ActiveMQ-services en de diverse web- en applicatieservers die we naast Apache geïntroduceerd hebben. Deze laatste zijn gegroepeerd in het bruine blok en deze groep is op vier identiek ingerichte webservers geinstalleerd. Uiteraard geven de lijntjes aan hoe de communicatie ongeveer loopt.

Update, 12:32: ondertussen zijn de werkzaamheden achter de rug: de upgrade is om 11:30 voltooid. Ondanks een paar kleine tegenslagen verliep een en ander volgens schema. Het voornaamste probleem was wel dat de MySQL-replicatie door Artemis 5 een grote achterstand had opgebouwd, waardoor de data op deze server onbruikbaar was. Omdat de data op Apollo 6 nu volledig consistent met de primaire databaseserver is, zou dat probleem een volgende keer niet meer mogen optreden.

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 (114)

Reactiefilter:-11140113+199+214+31
Ah handig om te weten. Gelukkig ook met een gele balk te zien, is zeker handig want anders vergeet ik het ook zo weer...

Wel super trouwens dat jullie de gehele omschrijving geplaatst hebben hierzo, erg informatief. Zeker voor mensen die in het serverpark niet zo veel ervaring hebben (behalve MKB in mijn geval). Succes met het omzetten maar daar heb ik wel vertrouwen in ;)
inderdaad een super artikel voor mensen met weinig kennis daaromtrent. Good luck
Leuke tekening.

Een kleine vraag. Waarom worden de werkzaamheden nooit in de nacht verricht, hebben de meeste mensen er toch het minste last van :)?
Waarschijnlijk omdat ze zelf ook willen slapen en om deze tijden bijvoorbeeld ook helpdesken bereikbaar zijn: als er iets mis is lijkt me dat ze zo Dell kunnen bellen die een mannetje paraat hebben, waardoor problemen makkelijker opgelost kunnen worden (en als je fit bent zul je ook minder snel fouten maken lijkt me).
Dell mag ik 24/7 bellen hoor, en dan moeten ze binnen 4 uur een oplossing verzinnen. Feit is gewoon dat je 's nachts minder scherp bent, dus vandaar dat we liever overdags aan de servers klussen :)
Just admit it je wil er je nachtrust niet voor opgeven ;)

Hebben jullie overigens misschien uitgebreidere documentatie over bovenstaande dingen? Ben wel geinteresseerd in dit soort spul. Snap de tekening namelijk wel maar ik vind hem niet echt logisch (wat waarschijnlijk komt door mijn gebrek aan kennis maar toch... :P).
Ik vind de tekening ook niet logisch.

je hebt 4 verbindingen naa de prim mysql+sec mongo liggen, maar maar 2 naar de sec mysql en prim mongo. Denk dat je 2 servers vergeten bent nl.: die met die cd bij en de ActiveMQ messaging server
Begin er zelf langzaam wat meer logica in te zien. Maar de lijntjes zijn geen verbindingen, het gaat hier om de logische componenten binnen de verschillende servers.

Snap alleen het hele idee van die loadbalancer niet echt... hij load balanced naar verschillende onderdelen binnen de apache server? Dus tussen de apache server die de php serveert, de lighttpd server die videos streamt en de proxy (die ik niet weet wat hij doet)?

Die apache server die trekt vervolgens gecachede info bij memcached weg. Bestanden van de fileserver en "apps van de tomcat server" (al zie ik dat niet helemaal voor me). En achter de apache server hangen straks dus ook 2 db server met mysql en mongodb.

Maar wat doet die activemq messaging? met alleen een verbinding richting artemis 6? Ik snap sowieso niet helemaal wat het is (vergelijkbaar met msmq onder windows ofzo?). En waarom heeft hij geen verbinding met de apollo 6 straks?

Zooow dat lijken me wel weer genoeg vragen :+
Ach dat valt toch reuze mee, als ik deze plaat lees;

Loadbalancer zal iets doen zodat je zowel apache als lighttp kan draaien, de varnish proxy zal waarschijnlijk voor apache draaien.

Apache draait vooral php en betrekt & deelt via verschillende bronnen informatie, oa.
  • Fileserver
  • Memchache:
  • Database (mysql)
  • MongoDB
  • Java App Server
  • ActiveMQ
Ik verwacht dat de MQ wordt gebruikt voor delayed inserts, zoals topic counters, stats etc, die heb je niet direct nodig en een DB insert is relatief duur in tegenstelling tot een fire and foreget MQ bericht. Maar als je main server tijdelijk eruit ligt, dan wordt de queue gewoon groter, en als je echt een failure hebt knoop je MQ gewoon aan de andere DB.

Daarnaast zal die Java app server gewoon via http informatie beschikbaar stellen, ACM heeft daar een heel plan voor geschreven (plan: Tweakers.net introduceert snellere Pricewatch-engine) Enige wat een beetje inconsequent is dat de JavaApp server niet connect naar de failover DB Server.

Maar deze opzet is inmiddels redelijke gemeengoed, vooral bij wat grotere enterprise oplossingen zie je dit soort hybride oplossingen steeds meer. Het beheer wordt wel complexer, maar gezien de reacties en onderbouwing heb ik wel het idee dat men er goed over na heeft gedacht.
Ahh dus de tomcat serveert java meuk en de activemq is een soort van buffer tussen de db en apache. Duidelijk. Maar waarvoor zorgt die proxy dan? apache kan toch ook gewoon direct naar de loadbalancer?
Klopt, de Apaches kunnen inderdaad direct met de loadbalancers communiceren. En dat doen ze ook :)
Alleen de resources op 'tweakimg.net' gaan via Lighttpd en 'ic.tweakimg.net' via Varnish. Het leek ons niet heel zinvol om processingtijd, en dus latency, te verspillen aan Varnish als we van bepaalde requests toch zeker weten dat ze nooit gecached gaan worden. Dat is dus zo'n beetje alles wat je nog vanaf 'tweakers.net' krijgt.
Varnish haalt overigens wel zijn data weer uit Apache, vooral omdat sommige afbeeldingen in potentie eerst gegenereerd moeten worden (zoals de prijsgrafiekjes bij producten), maar met een cachehitratio ergens in de buurt van de 99% zijn dat er relatief weinig.
In de praktijk is het dus vooral de php-request (en dus de html die je terug krijgt) en de Ajax-requests die gedaan worden ivm de diverse dynamische onderdelen van de site wat nog bij Apache terecht komt. De rest gaat via Lighttpd voor de vaste layout-componenten en via Varnish voor de semi-dynamische content-afbeeldingen.

ripexx had het dus bijna helemaal goed :)

Dat de tomcat-engine's nog niet met de readonly database kunnen verbinden is een stukje achterstallige configuratie. Die kunnen dmv de jdbc-driver natuurlijk ook vrij eenvoudig (readonly) met de slave-database verbinden en dat gaat ook vandaag nog zo ingesteld worden :)
[edit]
En ondertussen is dat aangepast.

[Reactie gewijzigd door ACM op 22 juni 2010 12:40]

Ja, maar de ervaring leert dan mensen 's nachts een stuk minder scherp zijn. Er worden fouten gemaakt, het werk duurt langer en erger nog: Als het klaar is gaat iedereen zijn bed in. Mocht het dan nog een keer fout gaan heb je een probleem, want ieder relevant persoon ligt dan op 1 oor. Dan beter 's ochtends aangekondigd down gaan. Iedereen is dan lekker fris en als het uitloopt of fout gaat na het weer online brengen is er geen probleem qua beschikbare mankracht.
zou dat niet andersom zijn? bijna iedere ITér die ik ken werkt liefste snachts.
Ik lig liever op 1 oor in de nacht en werk gewoon doordeweeks. Onderhoud doe je (dubbel betaald) in het weekend als iedereen thuis zit.

Verder mooie ontwikkeling. Leuk om te zien hoe tweakers blijft groeien. Van home made servers naar krachtpatsers waar ik alleen maar van kan dromen :)

Keep up the good work!
zou dat niet andersom zijn? bijna iedere ITér die ik ken werkt liefste snachts.
Hoeveel ITers ken je dan? :+ ik ken er geeneen. Allemaal dagmensen die ik ken.
tsja, je kan dan misschien beter zaterdag- of zondagochtend pakken?
Voor gewone bedrijven wel, maar ik neem aan dat Tweakers meer bekeken wordt op zaterdag en zondag.
Alhoewel ze er niet zo uit zien, zijn de admins hier ook maar mensen... :P

Die hebben ook graag hun slaap, en aangezien dat de site nog bereikbaar blijkt (weliswaar read-only) is de downtime imho niet ZO ingrijpend...

[Reactie gewijzigd door HyperBart op 21 juni 2010 15:47]

Die discussie is al meerdere keren gevoerd bij downtimes. Hierboven staan al wat redenen daarvoor.
Een kleine vraag. Waarom worden de werkzaamheden nooit in de nacht verricht, hebben de meeste mensen er toch het minste last van :)?
Een vraag die elke keer terugkomt en hetzelfde antwoord krijgt:

De kans op fouten is het kleinst, ook kun je via leveranciers dan het snelste support krijgen. En dan nog: jij werkt toch ook niet 's nachts of wel dan? ;)
Ooit wel eens changes in de nacht gedaan? :)

Goed als jij zo als de meeste mensen een normale kantoor ban hebt dan is je lichaam gewent aan het slapen van af een uur of 23:00 tot ongeveer 07:00 als jouw werkgever dan besluit dat het een goed idee is om van 23:00 tot 07:00 even een redelijk complexe en risicovolle operatie uit te gaan voeren dan kun je daar vast wel extra voor betaald krijgen en zo maar je lichaam is niet minder gewend aan slapen rond die tijd en dus is je concentratie een heleboel minder.

Ik heb dat soort dingen zelf mogen doen en geloof me het is echt heel erg veel moeilijker om s'nachts je concentratie er bij te houden dan om dat overdag te doen. Daar naast komt er ook nog eens bij kijken dat ondersteuning van andere partijen zo als hier boven al genoemd heel erg veel makkelijker te regelen is overdag dan midden in de nacht. Ook al moet ik wel zeggen dat de radio midden in de nacht vaak leuker is om naar te luisteren dan overdag maar dat komt voornamelijk omdat er dan iet wat meer volwassen onderwerpen voorbij komen. ;)


Wat ik niet helemaal begrijp is dat de twee machines niet gewoon gelijk zijn. Als de primaire database server met 72GB draait waarom de failover server dan niet? Als je nu een failure hebt op de primaire server dan zijn alle gebruikers gelijk de dupe van een veel minder ruim bemeten failover server, als de de failover al lukt omdat er gedurende de jaren natuurlijk het een en ander zal groeien en het nu nog ruim bemeten geheugen op de primaire server wel eens krap kon zijn over een jaar of 2 a 3 op het moment dat de server wat ouder is en sneller zal falen dan op het moment dat het ding net aan een jaartje aan staat.
Ik kan zo een tiental problemen bedenken waar ik de afgelopen paar jaar mee te maken gehad heb waar dit soort ongelijkheden na een paar jaar tot grote problemen hebben geleid op het moment dat de primaire server voor het eerst na lange tijd faalde...
Ik hoop dan ook dat jullie ook een (minimaal) jaarlijkse failover test hebben gepland niet omdat het nu niet werkt maar wel om de procedures scherp te houden en zo wel mensen als machines te testen op het moment dat dit soort procedures uitgevoerd moeten worden. Want als Jantje ziek is en Kees op vakantie dan klapt die doos er natuurlijk uit en dan is het op eens aan de stagiaire en de voormalig koffie dame om de failover te begeleiden en dat kon nog wel eens vies tegen vallen omdat Kees bepaalde punten niet heeft opgeschreven want dat weet toch iedereen en Jan natuurlijk ook niet wist dat na de laatste change iedereen vergeten was die ene versie van die andere lib te updaten en dus het hele ding nooit kan werken...

Het klinkt vast gek maar het kan helemaal geen kwaad om zo af en toe gewoon de stekker er eens uit te trekken en te kijken hoe men reageert zeker als men nog redelijk nieuw is kan de opwinding van een echte outage en nu komt alles op jouw neer wel eens te veel zijn voor ze om zich op de werkelijke problemen te concentreren, en dat soort dingen kun je beter oefenen als het een gecontroleerde situatie is dan wanneer er echt stront aan de knikker is. ;)
Basically is de keus uit 12x betaalbare modules die op 1333Mhz draaien of 18x en dan 800Mhz. Dus wat je wint aan extra ram verlies je deels weer aan snelheid ervan.
Bovendien is de huidige master behoorlijk overgedimensioneerd, waardoor we niet verwachten tijdens een uitval ervan om performance verlegen te zitten met de failover-machine.

Overigens zijn de SSD's van de slave ook een generatie nieuwer (en dus sneller) met als gevolg dat een cache-miss relatief gezien goedkoper is. Naast dus het feit dat een cache-hit ook sneller is.

Failover (iig de automatische readonly-modus) hoeven we niet te testen, dat komt weliswaar sporadisch, maar vaak genoeg voor om daar niet een vaste test voor in te richten. Daarna is het overstappen naar de slave een kwestie van de master helemaal uitzetten en de configuraties aanpassen dat ze de slave als master behandelen... Niet iets wat een hoop werk is. Desalniettemin is het, zeker bij meer complexe opstellingen, inderdaad verstandig af en toe te testen of je nog weet hoe het moet :)
Dat snap ik niet. mySQL ondersteund gewoon automatische failover. Ook het gebruik van configuraties met een read/write server aangevuld met read only servers waarbij de readonly servers een deel van de leesopdrachten van de master overnemen is niet ongebruikelijk. In die situatie krijg je ook automatisch een read only systeem als de master uitvalt. Waarom is daar niet voor gekozen ipv dat iemand 's nachts uit zijn bed moet worden gebeld om een configuratiescriptje te draaien bij een probleem?
't Verbinden met een andere databaseserver is iets dat de driver moet doen. Php's standaard mysql-driver doet dat niet vanzelf, maar de readonly mode, die in deze aankondiging genoemd wordt, doet juist wat jij denkt dat we niet doen. ;)

De reads verspreiden over de master en slave vinden we niet erg zinvol, de master heeft het daar lang niet druk genoeg voor en dan zorgt het er alleen maar voor dat je moeilijk moet doen met kijken of je stiekem toch een writable-connectie nodig hebt.
En dat op alle plekken in de, vaak relatief oude, code goed te verwerken is gewoon domweg de moeite niet waard. Nog afgezien van het feit dat het dus niet nodig is vooralsnog.
Leuk weer om te lezen hoe jullie het opzetten. Nou is dit natuurlijk ook wat een groot deel van de community leuk vind, maar het is ook wat ik mis bij bijvoorbeeld online spelen die ik speel.

De topfeatures van T.net zijn in mijn ogen het vooruitstrevende en gewoon fatsoenlijk functionerende: hier zijn allerlei leuke dingen mogelijk en als je een feature request indient dan wordt daar ook serieus naar gekeken.

Keep up the good work!
@vandeMeulenhof:

De server admins mogen ook wel genieten van de nachtrust :D
Ik ben benieuwd naar de ervaringen van MongoDB. Ik heb net even zitten kijken naar de Java client, maar dat ziet er niet echt heel erg geweldig uit. Ze missen een behoorlijke stuk goede OR mapping, en doen alles nog met Maps. Dat is eigenlijk wel erg jammer. Er zijn zo te zien wel wat 3rd party tools die het wel kunnen. Eens kijken./


Edit... ondertussen gedaan: conclusie: 't suckt voor onze toepassing. diskspace verbruik is factor 4 hoger t.o.v Postgresql (resultaat is een database van meerdere TB's i.p.v honderden GB's)), en het ophalen van veel records is in verhouding tot Postgresql hierdoor ook trager.

Bepaalde queries zijn/lijken dan wel weer heel snel, en je kunt er vast heel erg leuke dingen mee doen als je de juiste toepassingen bedenkt :)

[Reactie gewijzigd door voodooless op 23 juni 2010 13:51]

Wij willen er buckets met data in opslaan, waarbij elke bucket dus een stelletje key-value paren heeft. En daarvoor is het communiceren met JSON uiteraard zeer geschikt, wat met de native-client in PHP dan ook nog eens transparant gebeurd. Ik kan me voorstellen dat je dat voor Java wat minder handig vindt (hoewel je daar effectief ook gewoon met een collection of maps zal werken?)
Dit komt omdat MongoDB een "Document store" database is, hierdoor is er altijd een vertaling ( maping) nodig. Ik denk je beter naar een object georiënteerde db kan kijken. Zie http://nosql-database.org/ en scroll naar beneden. Waarom zou je immers vertalen (mappen) als niet hoeft.

Tevens, ik dacht dat OR stond voor Object-relational ( http://en.wikipedia.org/wiki/Object-relational_mapping ) en relationeel is nou juist wat ze niet willen. zie hiervoor de definitie op http://nosql-database.org/ .

<off topic>
Overigens ben ik het niet eens de definitie, omdat ik geen reden zou kunnen bedenken waarom je in een NoSQL database geen relaties zou mogen leggen. Overigens bedoel ik hier niet mee, dat dit niet onverstandig is. Een papegaai kan je laten kakelen als een kip, maar misschien is dat niet het verstandigst omdat ze veel meer kan. Zie http://www.xaprb.com/blog...esnt-mean-non-relational/

Ook het woord NoSQL vind ongelukkig om er niet van hou als de definitie wordt afgeleid van iets wat het niet is. Gelukkig ben hier niet de enige in: http://www.thevirtualcirc.../sql-or-nosql-you-choose/ . Immers gaan we straks blogs definiëren als NoMessageboard?
</off topic>

edit: url toegevoegd.

[Reactie gewijzigd door wallyberk op 21 juni 2010 21:48]

Go Mongo!
MongoDB is echt fantastisch. Zeker voor webapps.
Het is wel een aanpassing om het typische relationele denken weg te laten en in documenten te denken.

vb: traditioneel heb je een object "artikel" met "comments" die elk van een "user" zijn. In een genormaliseerde SQL db zou je daar 3 tabellen voor gebruiken en met een join query'en. In een document store zou je één "artikel" document hebben met embedded "comment" documenten. En waarschijnlijk zou je de naam van de "user" bij elke commentaar opslaan (de-normalised). Zo kan je met 1 query alles ophalen.
Is dan toch wel leuk om te zien dat Tweakers.net, met hun mooie, uitgebreide BBG discussie topic's dan een DELL machine aanschaffen :P
Volgens mij is Dell op de servermarkt gewoonweg heel goed ;)
Dell business support is erg goed hoor, vaak genoeg gebruik van moeten maken.
uhhh, als ik support NODIG heb, is het dus niet goed.
hebben hier 10 dell's R9xx, 25+ HP DL380Gx, drie maal raden waar we meer storing aan hebben...
Mijn ervaring zijn tot nu toe anders heel positief. Oke, heb in het verleden heus weleens problemen gehad, maar dat is toch al behoorlijk lang terug.

We hebben sinds een paar maanden een stel R610's draaien (1U) en die zitten echt goed in mekaar vind ik en ze doen precies wat ze moeten doen.
dan een DELL machine aanschaffen
In plaats van zelf een machine samenstelling uit onderdelen (zoals "vroegâh")? Of bedoelde je dat jij een ander merk aan zou raden??
Nou ja, de configuraties die in de BBGs langskomen zullen niet een van de grootste websites van Nederland en België (met het veeleisendste en kieskeurigste publiek? ;) ) hoeven draaien. Apollo 6 moet dat wel gaan doen, dus is het belangrijk om downtime tot het absolute minimum te beperken. Een servicecontract bij DELL kan daarbij prima helpen en tja, die contracten kun je niet afsluiten op een bak die je zelf gebouwd hebt.
ik zou niet graag zut uit de BBG in de colo willen hebben. Sowieso mis je dan support en 4U grafbakken til ik persoonlijk liever uit een rack dan erin ;)
7U grafbakken, daar weten we wel raad mee.... }>

[Reactie gewijzigd door zeef op 21 juni 2010 23:36]

dat was een 7U machine
Probeer jij maar eens een 1u 19" rackmount te kopen/bouwen die goedkoper is en vergelijkbaar is aan een Dell R210. Zo goed als onmogelijk volgens mij. Dat plus dat dell 1 jaar garantie geeft op het geheel, zorgt er voor dat Dell toch niet heel duur meer is.
Beknopt m'n ervaringen:
- werken onberispelijk
- zeer degelijk gebouwd
- wel gezeur met trays voor harde schijven die standaard niet worden meegeleverd voor de sleuven die je niet bezet hebt. Is gedoe met uitbreiden omdat je alleen via Dell kunt bestellen.
- Linux support is er wel, maar is niet bepaald inzichtelijk.


Laatst een RAM module kapot. Dat wist de machine mij op afstand nog keurig mee te delen. En dat scheelt een enorme hoop gedoe, als je meteen met het juiste reepje naar het datacentrum kunt rijden.
Mee eens.
Heb hier een Equallogic PS4000 hangen. Laatst schijf van kapot, case aangemaakt. Binnen 1,5u stond er een koerier voor de deur met een vervangend exemplaar :)
Echter betaal je bij zo'n SAN ook wel een groot deel voor dit soort support natuurlijk.
Zeer nette server, leuk dat hij op mijn verjaardag in 't datacenter word gehangen :)
Hopelijk gebeurt er dan ook iets om 9:08 :P
Hij hangt stiekum al een week in het datacenter hoor ;) Een migratie doen we liever vanuit onze luie stoel met alle tools die op onze pc's staan dan in een datacenter gehurkt achter een laptopje terwijl je gek wordt van de vuvuzela's servers die een vuvuzela na doen.
Dat heb je toch weer snel gedaan :P

Migratie uit je luie stoel is natuurlijk beter ;)
Zeer netjes, duidelijke uitleg ook (zelfs ik snap het, denk ik :p )

Goed om te zien dat jullie continu vernieuwen,
Succes voor de mensen die ermee aan de slag gaan, hopelijk zit er niet teveel tegen (ik kan nie al te lang zonder mn verslaving haha)
Wat een feestelijke server weer. En flinke wijzigingen in het systeem, Succes ermee!

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBTablets

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013