Inleiding
In de tien jaar van het bestaan van Tweakers.net hebben onze knutselavonturen in en rond de colo altijd op veel belangstelling kunnen rekenen. De huidige snelheid en beschikbaarheid van de site waren in de vroege dagen van Tweakers.net alles behalve vanzelfsprekend. Tot het voorjaar van 2000 maakten we gebruik van shared hosting- en dedicated hosting-diensten die een nogal grillig beschikbaarheidspatroon vertoonden. Toen we vervolgens op onze eerste eigen machines gingen draaien moest er nog veel ervaring opgedaan worden met het beheer van servers en netwerken en het optimaliseren van serverapplicaties, databases en php-code. Zowel wat leeftijd als ervaring betreft waren we een stel optimistisch ingestelde broekies. Het beheer van het serverpark werd bemoeilijkt doordat het groeitempo van de bezoekersaantallen nauwelijks met betaalbare serverupgrades beantwoord kon worden.
Naar aanleiding van ons tienjarig bestaan zullen we in een aantal artikelen terugblikken op de geschiedenis van het serverpark van Tweakers.net. Dit eerste artikel is gebaseerd op een stuk over de prille jaren dat we in de donkere krochten van ons archief aantroffen en dat oorspronkelijk bij de verhuizing naar Trueserver in juni 2001 online zou komen, maar nooit is verschenen. Lees hoe het beheer van de site in 2001 werd beleefd en laat je rondleiden langs inmiddels nostalgisch geworden hardware.
De conceptie van Tweakers.net
In 2001 werd de zevende Tweakers.net-server geplaatst, maar ooit is deze site begonnen op een simpel shared hosting-account. Sinds die ene memorabele dag in juni 1998 is er veel gebeurd. Wat ooit begon met een vrijblijvende overclocking-site is uiteindelijk uitgegroeid tot één van de drukst bezochte sites van Nederland. Gelijktijdig met de groei van de bezoekersaantallen vond een explosieve groei plaats in de capaciteit van het serverpark.
Het begin
De oorsprong van Tweakers.net loopt terug tot een eenvoudige overclocking-site die ik in juni 1998 online bracht naar aanleiding van de aanschaf van een Abit BX6 en een Pentium II 233. Die PII deed 360 miljoen kloktikken per seconde en dat was indrukwekkend voor die tijd. Op dat moment zat ik net aan het eind van m'n eerste jaar Interaction Design en had ik al enige maanden een domein bij Pair Networks voor mijn webdesignbedrijfje. Aangezien er nog volop bandbreedte over was (100MB per maand!) werd de overkloksite onder hetzelfde account geplaatst. De keuze voor Pair Networks was het gevolg van de toen nog hoge kosten voor hosting in Nederland en de bekendheid die Pair genoot als hostingprovider van Tom's Hardware Guide.
Dankzij Diederik Meijer - mede Interaction Design student en voormalig redactiemedewerker van Planet Internet - kreeg mijn overkloksite een vermelding op Slashdot. Destijds was /. weliswaar een veel minder massale aangelegenheid dan het nu is, maar toch kreeg mijn site op één dag het onvoorstelbare aantal van 3.000 bezoekers te verwerken. De traffic-limiet van mijn eenvoudige hostingabonnement werd hierdoor binnen 24 uur volgeserveerd. Dat deed mij ertoe besluiten om een dikker account te nemen met 400MB traffic per dag en ondersteuning voor PHP, Msql, Mysql en Perl. 400MB leek aanvankelijk een onbereikbare limiet. Vandaag de dag wordt die hoeveelheid bandbreedte binnen no time opgestookt.
Het nieuw verworven privilege om perl-scripsels te mogen draaien gaf mij de mogelijkheid om de freeware versie van Ultimated Bulletin Board uit te proberen. Destijds was ik samen met een aantal andere oldskool tweakers actief op het Webwereld Forum. Helaas (of achteraf gezegd 'gelukkig') waren we niet helemaal tevreden met de gang van zaken daar. Dit was de aanleiding om een forum te openen dat voor de gevorderde tweaker meer uitdagingen kende dan het eindeloos beantwoorden van newbievragen. Het forum had geen enkele policies omdat er bij de -vijf vaste- bezoekers geen behoefte bestond om ongewenst gedrag te vertonen - hoe utopisch!
Het idee om een Nederlandstalige hardware-site te beginnen speelde al enige tijd toen, geïnspireerd door grootheden zoals Tom's Hardware Guide, Anandtech en AGN Hardware, in september 1998 'World of Tweaking' van start ging. WoT begon als een reviewsite en later kwamen daar de dagelijkse nieuws updates en de Pricewatch bij. In de begintijd werd gebruik gemaakt van losse perl-scripts en server side includes. Hoewel redelijk geavanceerd voor een tijd waarin veel sites nog puur op statische html draaiden, was de oplossing met server side includes verre van ideaal en bovendien moeilijk te managen.
In november 1998 begonnen mijn eerste php- en sql-experimenten. Niet wetende wat het verschil was tussen Msql (Minisql) en Mysql, koos ik bij het upgraden van mijn account per ongeluk voor Msql. Mijn account moest als gevolg hiervan verplaatst worden naar een andere webserver met ondersteuning voor Msql. Omdat kennelijk niemand geïnteresseerd was in het gebruik van Minisql kwam ik op een machine met slechts tien gebruikers, waarvan het merendeel nauwelijks actief. WoT en het forum draaiden praktisch dedicated.
Mijn gestuntel met PHP resulteerde eind november in een soort van databasedriven nieuwspagina. Het werkte allemaal niet optimaal en de code was dermate ranzig dat het met geen mogelijkheid ooit door een intelligente levensvorm gereproduceerd zou worden, maar het deed (meestal) wat het moest doen.
De groei van WoT en Tweakers.net
World of Tweaking, aanvankelijk bereikbaar onder www.webmagix.net/tweaking, begon te groeien. Het 'Webmagix forum' werd als vanzelf het forum van WoT en kreeg later de naam 'Gathering of Tweakers'. De domeinnaam Tweakers.net werd in februari 1999 geregistreerd. Het forum is sindsdien bereikbaar onder gathering.tweakers.net en WoT werd bereikbaar onder world.tweakers.net.
Door de toenemende populariteit van WoT en GoT nam de traffic dermate toe dat de 400MB grens van het Pair-hostingpakket werd overschreden. Omdat WoT en GoT nog steeds geen cent in het laatje brachten, was het zaak om het verkeer zoveel mogelijk te beperken. De pics werden voortaan ondergebracht op mijn studentenaccount bij de HKU en op de webspace van een gratis verkregen dialup-account van Talkline. Het traffic-gebruik kwam dankzij deze maatregelen weer tijdelijk in een acceptabele zone terecht.
Met de groei van de site bleef het trafficgebruik stijgen en op een gegeven moment was de enige oplossing het opsplitsen van WoT en GoT naar verschillende hostingaccounts. Bij de restyle van WoT in april 1999 paste ik alle mogelijke technieken toe om het traffic-gebruik terug te dringen. Het effect was behoorlijk dramatisch: een afname van het verkeer van 40 procent. Tegelijkertijd werd overgeschakeld van Msql naar Mysql. Een hele verbetering, want ik kon nu bijvoorbeeld eindelijk gebruik maken van auto increments. Met de restyle vond tevens de officiële naamsverandering van World of Tweaking naar Tweakers.net plaats.
In augustus 1999 werd het contract met Webads gesloten. Na een jaar leverde Tweakers.net eindelijk structureel inkomsten op. Een maand later kreeg de restyle van april een facelift, waarna Tweakers.net het uiterlijk kreeg zoals we dat vandaag de dag nog steeds in grote lijnen kennen. De html-code werd verder geoptimaliseerd zodat wederom een forse trafficbesparing werd gerealiseerd. Dit kon niet voorkomen dat eind september moest worden uitgeweken naar een 'developer account' met 500MB traffic per dag. Pair bood op dat moment geen betaalbare pakketten met een hogere trafficlimiet.
Fok! en de eerste dedicated server
Met het begin van de eerste Big Brother ging Fok!zine in september 1999 (officieus) online. Danny & co werden evenals Tweakers.net gehost bij Pair Networks. Door de enorme hype rond Big Brother en de BB-scoops die op Fok! verschenen, kreeg Fok! voor die tijd gigantische hoeveelheden traffic te verwerken, tot 2GB per dag. Tegenwoordig stookt Tweakers.net alleen al het honderdvoudige op, maar toendertijd vonden we het best wel heftig. Tegelijkertijd liep Tweakers.net tegen de beperkingen van de Pair-servers op. Dankzij de inkomsten van Webads en de bundeling van krachten werd het mogelijk om een dedicated server te leasen - een droom ging in vervulling.
Na een vergelijking van diverse webhosters werd gekozen voor Rackspace. Tweakers.net werd niet langer geserveerd vanuit Pittsburgh, maar vanuit het nog verder gelegen San Antonio. Webhosting in Nederland was sowieso geen optie vanwege de destijds torenhoge kosten voor traffic. In de VS betaalden we 150 dollar per 25GB terwijl in Nederland voor dezelfde hoeveelheid dataverkeer al snel een bedrag van 2500 gulden werd gevraagd.
Rackspace gaf de redelijk unieke mogelijkheid om leaseservers grotendeels naar eigen voorkeur te configureren. Er werd gekozen voor een no-nonsense configuratie met een dual PIII-450, 768MB RAM, 2x 3GB ata raid en 175GB traffic per maand. De voor die tijd grote hoeveelheid geheugen was gewenst omdat 'Sebulba' zowel Apache als Mysql ging draaien. De server draaide op Freebsd en werd onderhouden door Maarten Moerman en Jeroen Bulten.
In de praktijk was de snelheid van de Rackspace-verbinding voldoende, soms zelfs akelig snel op een Surfnetlijn. Hoewel de hardware prima presteerde was de configuratie niet bepaald subtiel in elkaar gezet. De bootlogs liepen vol met irq-conflicten en ook het feit dat onze mooie server was voorzien van een 10Mbit isa-netwerkkaartje deed twijfels rijzen over het vakmanschap en de professionaliteit van Rackspace.
Helaas bleek Sebulba verre van stabiel. Toen ik aan de vooravond van de HCC Dagen 1999 - de dag waarop Tweakers.net werd overgezet naar de nieuwe server - een 400MB grote tarball van het forum uitpakte, crashte de server spontaan. Later namen de problemen verder toe, zo erg dat Sebulba tegen mei 2000 om de vier dagen plat lag.
Een zo mogelijk nog groter probleem was de laksheid van de helpdesk. Het kwam regelmatig voor dat een support-ticket werd vergeten, waardoor de server na een simpele crash een halve dag plat bleef en wij in Nederland niet meer konden doen dan machteloos afwachten. Tot twee keer toe was Tweakers.net hierdoor meer dan 24 uur niet bereikbaar en in mei 2000 deed zich zelfs een downtime van twee dagen voor. Door een ongelukkige samenkomst van omstandigheden crashte de server net toen het Rackspace-netwerk onder vuur lag van een syn-flood DoS-attack. Ons support-ticket werd afgewimpeld met de opmerking dat de downtime werd veroorzaakt door de aanval. Een paar tickets later nam een medewerker van Rackspace eindelijk de moeite om te kijken wat er werkelijk aan de hand was, om vervolgens tot de conclusie te komen dat onze server écht op zijn gat lag.
Het moge duidelijk zijn dat leasing en hosting op grote afstand zijn nadelen heeft. Je bent deels afhankelijk van de softwaredistributie die door de webhoster wordt gedicteerd, je hebt geen controle over je eigen hardware en je bent volledig afhankelijk van de goede wil van de supportafdeling. Bij Rackspace bleek dat, ondanks fantastische claims over "the most experienced and responsive support in the industry", allemaal niet goed geregeld. Na het dedicated serveravontuur bij Rackspace werd een nieuwe droom waargemaakt: hosting op eigen co-located servers in Nederland.
Co-location en de Vuurwerk deal
Zoals eerder geschreven was hosting in Nederland nooit een haalbaar alternatief vanwege de hier geldende torenhoge traffictarieven. De enige oplossing zou sponsoring zijn. Via Realgamer werd in februari 2000 contact gezocht met Vuurwerk Internet. Deze Haarlemse hostingprovider had net een supersnelle dubbel uitgevoerde 622Mbit-verbinding van Versatel opgeleverd gekregen, waardoor hen een enorme overdaad aan bandbreedte ter beschikking stond. Een sponsor-contract werd snel geregeld en over de wens om Tweakers.net, Gamer.nl en Fok! op twee servers te hosten werd niet moeilijk gedaan.
Met de hulp van Comptech World werd voor weinig geld twee snelle servers in elkaar geschroefd. AMD Benelux werd bereid gevonden om twee processors te sponsoren. Een Athlon 800 ging destijds voor 1500 piek over de toonbank en dat was zeker een mooi bedrag om in de knip te houden voor andere hardware zoals scsi-harde schijven. Onze keuze voor het te gebruiken moederbord viel op de MSI K7 Pro omdat deze als stabiel en betrouwbaar te boek stond; het was ook de enige Irongate-plank die een fsb van 115MHz ondersteunde. De VIA KX133 kwam niet in aanmerking omdat moederborden met deze chipset nog maar net op de markt waren ten tijde van het bouwen van de servers. Nieuwe VIA-chipsets hadden wat ons betreft vlak na hun release net iets te vaak mankementen vertoond.
Beide servers werden voorzien van een Adaptec 29160 Ultra160 scsi-controller met een enkele 7200 toeren IBM Neptune-schijf in de webserver en drie van dergelijke disks in de database-server. Ata-raid was destijds nog niet zo ingeburgerd en bovendien hadden we slechte ervaringen met de ata-schijven in de Rackspace-server: daar was er namelijk in december 1999 eentje van dood gegaan. Het snelheidsvoordeel tussen ata en scsi was vrij beperkt op 7200rpm, maar in ieder geval hadden de scsi-schijven het voordeel van een lagere toegangstijd en dat is zeker voor een database server van groot belang. Omdat een scsi raid-controller destijds nog ver buiten ons budget lag, werden de drie Neptunes in de database-server middels software raid-5 aan elkaar geregen.
De configuratie van de twee servers werd gecompleteerd met een 4U-rackmount, een pci-videokaartje en twee 3Com 100Mbit nic's. Eentje voor communicatie met de buitenwereld en de tweede om tussen web- en database-server te babbelen. Dit voorkwam dat de Mysql-queries over dezelfde switch als het internetverkeer moesten en dat kon zeker tijdens de drukke uren schelen in roundtrip latencies. De servers kregen de Griekse namen Aphrodite (Godin van de schoonheid en de liefde) en Athena (Godin van de wijsheid). Slackware Linux werd als besturingsysteem gebruikt omdat de beheerders (Rick Jansen en Reinder Gerritsen) onbekend waren met Freebsd. Uit het Rackspace avontuur was gebleken dat het niet verstandig is om met een vreemd besturingssysteem te gaan werken, ook al zijn er kleine technische voordelen boven de besturingssystemen waarmee de beheerders wel ervaring hebben.
Verder bleef de softwareconfiguratie grotendeels bij het oude, hoewel uiteraard wel de laatste versies van Apache, PHP en Mysql werden geïnstalleerd. Vooral de overgang van PHP3 naar PHP4, die tegelijkertijd plaats vond met de ingebruikname van de servers bij Vuurwerk, was een grote stap voorwaarts.
| | Aphrodite | Athena | | OS | Slackware (Linux 2.2) | Slackware (Linux 2.2) | | CPU | Athlon Classic 800 | Athlon Classic 800 | | Mobo | MSI K7 Pro | MSI K7 Pro | | RAM | 512MB PC100 ECC | 384MB PC100 ECC | | I/O | Adaptec 29160 | Adaptec 29160 | | Storage | IBM Neptune 9,1GBOnstream 30GB IDE | 3x IBM Neptune 9,1GB | | Video | ATi Rage3D | Diamond Viper V330 | | Netwerk | 2x 3Com 100Mbit | 2x 3Com 100Mbit | | Kast | 4U | 4U |
|
| | Aphrodite | Athena | | DNS |  | | | HTTP | | | | IRC | | | | Mail |  | | | MySQL | | | | SSL | | |
|
Aphrodite deed dienst als webserver, terwijl Athena zich bijna volledig kon toewijden aan haar taak als Mysql-server. Athena draaide tevens ssl voor de admin-interface. De content op Tweakers.net wordt volledig webbased beheerd vanuit een in eigen huis ontwikkeld content management systeem. Om die reden serveerde Athena tevens de afbeeldingen die in de nieuwsposts en reviews werden gebruikt. Deze afbeeldingen worden namelijk webbased geupload.
Met slechts twee servers (waar we destijds overigens erg blij mee waren 
) was de netwerk topologie bijzonder eenvoudig:
De keuze voor Athlon-processors was een interessante gok waar we geen spijt van kregen. AMD had zich destijds zeker nog niet bewezen als fabrikant van serverprocessors, maar het leek ons toch een verstandige keus omdat de Athlon afgezien van wat niet-relevante issues met agp-videokaarten en voedingen geen stabiliteitsproblemen had. Als een cpu wekenlang stabiel kan werken in een desktopsysteem dan moet dat ook in een server mogelijk zijn, zo was de gedachte.
Zoals viel te verwachten, zorgde de keuze voor Athlon-processors voor controversie bij mensen die van mening waren dat een server uitsluitend op Intel kon draaien. Vuurwerk kende nogal wat verbindingsproblemen vlak na de ingebruikname van hun nieuwe serverruimte met Versatel-verbinding. Deze downtimes zorgden in het begin regelmatig voor halve hartverlammingen. Telkens bleek het probleem bij Versatel te liggen en keerden Appie en Athena ongeschonden terug na de netwerkdowntimes. Uiteindelijk bereikte Aphrodite eind augustus een uptime van 92 dagen voordat zij gereboot moest worden in verband met de belangrijke Linux 2.2.14-kernelupdate. Het Athlon-experiment was geslaagd. Zeker vanuit het perspectief van Tweakers.net als hardwaresite was het iets dat uitgeprobeerd moest worden.
Een zware bevalling: nieuwe dbserver
Op 19 mei 2000 werden Aphrodite en Athena in de serverruimte van Vuurwerk geplaatst. Op 21 mei werd het forum overgezet naar Vuurwerk en drie dagen later was de rest van Tweakers.net aan de beurt. Dat er sprake was van een vooruitziende blik blijkt uit het feit dat al op 13 juni de eerste plannen werden aangekondigd voor de bouw van een derde server. Niemand had kunnen voorspellen dat de voltooiing van dit plan bijna zes maanden in beslag zou nemen...
Het uitgangspunt bij het samenstellen van de derde server was het bereiken van een hogere redundancy en betrouwbaarheid alsmede het vergroten van de capaciteit van de webservers. Athena zou na de komst van de nieuwe server dienst gaan doen als webserver en de taken van Athena zouden overgenomen worden door de nieuwe server, Artemis genaamd.
De configuratie van de nieuwe database-server werd diverse keren verbeterd gedurende de zes maanden dat Artemis in aanbouw was. Reeds vanaf het begin was het de bedoeling dat Artemis voorzien zou worden van hardware scsi-raid met drie of vier snelle 10.000 toeren schijven. Aanvankelijk zouden een Thunderbird 800 en een MSI K7T-Master als processor en moederbord dienst doen en het geheugen was op 640MB begroot.
Wat uiteindelijk in december bij Vuurwerk werd geplaatst was een aanzienlijk steviger configuratie. Tegen onze stoutste verwachtingen in bleven de bezoekersaantallen van Tweakers.net snel toenemen. Zelfs in de zomer, een periode waarin de pageviews normaal gesproken afnemen, bleef de site groeien. Door deze groei en de overschakeling op een database-driven forum nam de belasting van de servers binnen enkele maanden met een factor drie toe. Het werd duidelijk dat een eenvoudige Mysql-machine niet lang op zijn taak berekend zou zijn.
Processor
Het oorspronkelijk plan om een simpele Thunderbird-processor te gebruiken, werd al snel aan de kant geschoven vanwege het feit dat de kosten van een dual-processor-configuratie in geen verhouding stonden met de totale prijs van het systeem. Als je 15.000 gulden aan een server uitgeeft kan er ook nog wel 1500 gulden bij om 'm dubbel zo snel te maken met twee cpu's. De noodzaak van een dual processor-systeem was aanvankelijk niet aanwezig. Tot september 2000 draaide Tweakers.net op een relatief simpele database met een omvang van minder dan 200 megabytes. Het forum maakte nog gebruik van UBB, die zijn gegevens in platte tekstfiles beheerde. De belasting van de Mysql-server was nooit een probleem geweest.
UBB had grote nadelen. De search veroorzaakte een gigantische serverbelasting en moest daarom uitgeschakeld worden. UBB kon door zijn ranzig gescripte Perl-code nauwelijks aangepast worden en verder deden zich regelmatig vreemde verschijnselen voor waardoor soms complete subforums corrupt raakten. Om die reden werd UBB vaak als 'organisme' omschreven. Een oplossing voor het UBB-probleem was in ontwikkeling door Arjen Schol, de PHP-developer van Fokzine. Zijn op PHP en Mysql gebaseerde Topix-software ging voor het eerst live op het Fokforum en werd vanaf september 2000 ook op de Gathering of Tweakers gebruikt. Dankzij Topix werd de load op de webservers veel beter beheersbaar, maar een onvermijdelijk gevolg was een hogere load op de database-server. Dit betekende een nieuw factor in ons 'database upgrade'-plan en was tevens de tweede reden om een dual processor-configuratie te rechtvaardigen.
Er werd gekozen voor twee PIII-733's omdat deze ten tijde van de levering in oktober 2000 de beste prijs/prestatie-verhouding boden. De PIII-933 en PIII-1000 waren op dat moment nog behoorlijk duur. Een processor-upgrade is een simpele handeling die altijd op een later tijdstip, als de noodzaak van een snellere processor daadwerkelijk aanwezig is, uitgevoerd kan worden. AMD kwam dit keer niet in aanmerking omdat een dual Athlon-configuratie destijds niet mogelijk was en Xeons waren geen optie vanwege de hoge prijs. Een quad-plank kostte al achtduizend gulden en dan dan zouden we nog minimaal 2500 gulden per cpu kwijt zijn. De goedkopere dual processor-Xeons met 256KB L2 cache boden geen prestatievoordeel ten opzichte van de Pentium III en waren daarom ook kansloos om een plekje in de database-server te bemachtigen.
Artemis configuratie: Storage
Links: Cheetah X15 - Rechts: Barracuda 180
Het was van meet af aan klaar dat we voor een high-end scsi-setup zouden gaan met minimaal 10.000rpm-schijven. Seagate had in juli 2000 net de eerste 15.000 toeren harddisk op de markt gebracht. De overgang van UBB naar Topix en de daardoor ontstane toename in de belasting van de database maakte duidelijk dat we voor de opslaghardware met de hoogst mogelijke (betaalbare) performance moesten gaan. Dit was mede belangrijk omdat het upgraden van de schijven op een later tijdstip een kostbare en niet-eenvoudige aangelegenheid zou zijn.
Aanvankelijk was het plan om drie Cheetah's X15 in een raid 5-configuratie te gebruiken. Toen bleek dat de raid 5-prestaties van de raid-controller beneden peil waren, werd in allerijl een vierde X15 aangerukt zodat raid 0+1 gedraaid kon worden. RAID 0+1 (striping én mirroring) is de snelst mogelijke raid-variant en garandeert na raid 6 (striping met dubbele verdeelde pariteit) de hoogst mogelijke redundancy.
Zonder controller geen raid, dus ook hier moesten de nodige keuzes gemaakt worden. Ondersteuning voor 64bit-pci was een belangrijke voorwaarde omdat we gingen werken met een moederbord dat over dergelijke sloten beschikte. Mylex en DPT waren de eerste kandidaten, maar toen bleek dat beide merken slecht leverbaar waren, werd er uitgeweken de 3200S van Adaptec. De 3200S is een dual-channel Ultra160 scsi-controller met 32MB cache, PCI-64 en een 100MHz i960RN I/O-processor. Ondanks beloftes over ondersteuning voor Red Hat lukte het niet om de controller onder Linux bruikbaar te maken. Daarom werd uitgeweken naar Freebsd 4.2.
Artemis configuratie: Mobo & chipset
De keuze voor de te gebruiken chipset was snel gemaakt. De 440BX kwam niet in aanmerking vanwege het ontbreken van officiële ondersteuning voor PC133 sdram en PIII's met 133MHz fsb. De i815 was geen optie omdat deze chipset officieel geen dual processing ondersteunde en bovendien de belachelijke geheugen limiet van 512MB had. De i820 met sdram verdween vanwege zijn traagheid buiten beeld. Bovendien zat er een bug in de Memory Translator Hub, waardoor ook meteen de i840 met dualchannel-sdram als kandidaat afviel. Een chipset voor Rambus-geheugen was per definitie geen oplossing vanwege de hoog geprijsde geheugenreepjes. Tenslotte was er nog de VIA Apollo Pro133A. Op het moment dat de configuratie werd samengesteld, waren er nog te weinig ervaringen bekend over de stabiliteit van dual Apollo-plankjes.
De kandidaat die overbleef was de ServerWorks ServerSet III LE-chipset. ServerWorks, tot februari 2000 bekend onder de naam Reliance Computing Corporation, had al jaren ervaring met de ontwikkeling van high-end x86-serverchipsets. De RCC-chipsets werden door grote oem's zoals IBM, Compaq, Dell en HP verkozen boven Intels eigen Xeon- en Pentium Pro-chipsets. Als er één chipsetfabrikant is waarvan we stabiliteit mochten verwachten dan was het Serverworks. De ServerSet III LE heeft alle features die op ons verlanglijstje stonden. De chipset heeft ondersteuning voor maximaal 4GB PC133 sdram en kan gecombineerd worden met een 64bits pci-bridge. De afwezigheid van agp was geen punt, aangezien Mysql geen baat heeft bij hardwarematige 3d-acceleratie.
Nadat de keuze voor de chipset was bepaald, moest er een geschikt plankje uitgezocht worden. Supermicro had net de 370DLE aangekondigd en dat bord voldeed aan al onze wensen. Het verhaal werd helemaal mooi toen Supermicro bereid werd gevonden om een 370DLE te sponsoren.
Geheugen
Aanvankelijk zou de database-server voorzien worden van 768MB geheugen. Later werd dit uitgebreid naar 1GB. De bezoekersaantallen groeiden zo snel dat Athena en Aphrodite halverwege november van 2000 noodgedwongen een geheugenupgrade moesten krijgen. Artemis kon nog steeds niet geplaatst worden door vertraging in de levering van de hardware. De servers kregen een extra reep van 256MB, goed voor een totaal van 768MB in Appie en 640MB in Athena. Vooral Athena had een gebrek aan geheugen. Dit probleem werd zelfs met de toevoeging van de extra module nauwelijks verholpen en daarom werd besloten om de hoeveelheid geheugen in de nieuwe database-server nogmaals uit te breiden. Zodoende werden voor een redelijke prijs twee 512MB Corsair-modules op de kop getikt, zodat Artemis op een totaal van 1,5GB werd gebracht - voldoende om de complete databases van Tweakers.net en Fokzine.net in RAM te cachen.
Netwerk
De onboard ethernetcontroller op het SuperMicro-bord kreeg gezelschap van twee 3Com's, die via een crosslink met Athena en Aphrodite werden verbonden. Op die manier was het niet nodig om een extra switch voor het interne netwerk aan te schaffen.
Behuizing
Tenslotte moest er een behuizing gevonden worden waarin we onze prachtige collectie hardware konden onderbrengen. Aanvankelijk viel de keuze op een standaard 4U-rackmount met drie 5,25" drive bays. Deze bood net voldoende ruimte voor drie Cheetahs. Daar was dan ook meteen alles mee gezegd, want ruimte voor uitbreiding in de toekomst zou er niet zijn.
De noodzaak om een vierde Cheetah te kopen (vanwege de lage raid 5-prestaties) betekende tevens dat er een andere kast moest komen. We hadden de keuze uit een aantal 8U-rackmounts van Procase en Bon Chic en een extra diepe 4U-kast van CI Design. Het kastje van CI Design was niet alleen veel lager dan een 8U-rackmount, maar was tevens voorzien van vijf geïntegreerde hotswap scsi-bays. Dit maakte het gebruik van losse swapbays overbodig, wat een flinke smak geld scheelde. Verder beschikte de behuizing over vijf normale 5,25 inch drivebays, zodat er voldoende uitbreidingsmogelijkheden waren.
Artemis final specs en installatie
Begin september werd de bestelling geplaatst voor de hardware, halverwege oktober kwamen de eerste spullen binnen en pas eind november was de configuratie compleet. De voornaamste reden voor de lange vertraging was de slechte leverbaarheid van de raidcontroller. Eerst werd ongeveer een maand gewacht op een Mylex Extreme raid 1100, maar toen dat niet wilde opschieten werd gekozen voor de Adaptec 3200S. Ook die was niet snel verkrijgbaar. Gelukkig konden we van CompTech World, door wie de server gedeeltelijk werd gesponsord, tijdelijk een Adaptec 2100S te leen krijgen. De vertragingen gaven ons wel de gelegenheid om de verbeteringen aan de configuratie aan te brengen. Dit resulteerde uiteindelijk in een zeer snel systeem met louter en alleen high-end hardware:
| | Concept | Beta | Final | | OS | Linux 2.2 | Linux 2.2 | FreeBSD 4.2 | | CPU | Thunderbird 800 | Dual PIII-733 | Dual PIII-733 | | Mobo | MSI K7T Master | SuperMicro 370DLE | SuperMicro 370DLE | | RAM | 640MB PC133 | 1GB PC133 ECC Registered | 1,5GB PC133 ECC Registered | | I/O | DPT SmartRAID Decade | Adaptec 3200S | Adaptec 3200S | | Storage | 4x Seagate Cheetah 18XL 9,2GB | 3x Seagate Cheetah X15 18,4GB | 4x Seagate Cheetah X15 18,4GB | | Netwerk | 2x 3Com 100Mbit | 1x Intel 100Mbit2x 3Com 100Mbit | 1x Intel 100Mbit2x 3Com 100Mbit | | Kast | 6U / 8U | 4U Highlight | 4U CI Design |
|
Op de vorige pagina heb je al kunnen lezen dat de plaatsing van Artemis vooraf werd gegaan door een geheugenupgrade van Aphrodite en Athena. Deze upgrade werd op 9 november 2000 uitgevoerd en was de eerste sinds de servers in mei bij Vuurwerk in gebruik werden genomen. Al die tijd hadden Athena en Appie vrijwel probleemloos hun werk gedaan. De hardware functioneerde feilloos, hoewel in november duidelijk werd dat de bestaande setup een ernstig gebrek aan capaciteit had. Dit manifesteerde zich in een regelmatige bokkende Mysql en bij tijd en wijlen liet zelfs Apache het afweten. De extra geheugenmodules boden wat verlichting, maar een structurele oplossing was pas mogelijk met de toevoeging van de nieuwe database-server.
De geheugenupgrade verliep niet bepaald van een leien dakje. Nu is het bijplaatsen van een extra reep in principe een erg eenvoudige klus. Zo ook bij Aphrodite, maar de situatie wordt anders als de weg naar de beoogde lege dimmbank wordt geblokkeerd door een scsi-bay waarvan de schroeven alleen met bruut geweld losgedraaid kunnen worden. Met wat knutselwerk en getouwtrek aan een rebellerende scsi-terminator kon Athena uiteindelijk toch van de 256MB-reep voorzien worden. De onderste harddisk werd overgeplaatst naar de floppy bay en de floppy drive mocht mee naar huis - die wordt toch nooit gebruikt. Met een vertraging van een uur kwam Athena weer online.
Bijna een volle maand later - 8 december om precies te zijn - kreeg Artemis eindelijk zijn plekje bij Vuurwerk. Vier tweakers (Daniel, Femme, Floris, Rick) en een server gingen op weg naar de serverruimte van Vuurwerk om daar - te midden van zoemende airco's en peperdure netwerkapparatuur - de database-server operationeel te maken. Tegelijk met de installatie van de database-server kreeg Aphrodite een egoboost van Athlon 800 naar Thunderbird 1000 op een MSI K7T Pro2A moederbord. Daniël en Floris hadden het voor elkaar gekregen om tussen het regelwerk voor de database-server ook nog een paar mobo's en processors bij MSI en AMD los te weken. Opnieuw verliep een ogenschijnlijk simpele upgrade niet bepaald vlekkeloos, toen bleek dat Appie nogal willekeurig reageerde op het schakelen van de powerbutton. Soms ging ze aan, vaak bleef ze dood. De oorzaak werd uiteindelijk gevonden in een brakke voedingskabel of iets wat daar mee te maken had. De upgrade kon alsnog doorgang vinden toen ter plekke een voeding uit een Vuurwerk server werd getransplanteerd.
Appie en Athena werden samen met Artemis in een leeg kabinet geplaatst, zodat we in totaal 42U rackspace tot onze beschikking kregen. Omdat CI Design te laks was vijf drive bay-klepjes bij een rackmount van 2000 gulden te leveren, werd een instant tape-mod uitgevoerd die de binnenkomende lucht van de vijf 8cm case fans geforceerd langs de vier Cheetahs laat stromen. Niet erg sierlijk, maar zeker wel effectief. Ondanks hun toerental van 15.000rpm waren de hdd's zelfs onder dagelijkse belasting cool to the touch. Bij installatie van de hdd's deed zich nog wel het issue voor dat wij destijds nog te naïef waren om het verschil tussen sca- en lvd-scsi te kennen. Derhalve hadden we een rackmount met een mooie sca-backplane, maar lvd-schijven. Met behulp van een Dremel werd de backplane vakkundig gesloopt, waarna we de schijven alsnog met een ouderwetse kabel aan elkaar konden knopen.
Athena ging na de komst van Artemis dienst doen als webserver. Artemis nam naast de taak van database server tevens het werk van mailserver over van Athena. Het serverplaatje kwam er hierdoor als volgt uit te zien:
| | Aphrodite | Athena | Artemis | | OS | Linux 2.2 | Linux 2.2 | FreeBSD 4.2 | | CPU | Thunderbird 1000 | Athlon Classic 800 | Dual PIII-733 | | Mobo | MSI K7T Pro2A | MSI K7 Pro | SuperMicro 370DLE | | RAM | 512MB PC133 | 768MB PC100 ECC | 1,5GB PC133 ECC Registered | | I/O | Adaptec 29160 | Adaptec 29160 | Adaptec 3200S | | Storage | IBM Neptune 9,1GB | 3x IBM Neptune 9,1GB | 4x Seagate Cheetah X15 18,4GB | | Netwerk | 2x 3Com 100Mbit | 2x 3Com 100Mbit | 1x Intel 100Mbit2x 3Com 100Mbit | | Kast | 4U Highlight | 4U Highlight | 4U CI Design |
|
| | Aphrodite | Athena | Artemis | | DNS | | | | | HTTP | | | | | IRC | | | | | Mail | | | | | MySQL | | | | | SSL | | | |
|
SMP-problemen en nieuwe raid-controller
Artemis bracht een versterking die meteen effect had. Tweakers.net liep in de maand december vrijwel perfect. Eind januari ontstonden er voor het eerst opnieuw problemen, toen de site naar aanleiding van de Itanium preview van Wouter werd geSlashdot. Het 'Slashdot-effect' is het fenomeen dat zich voordoet wanneer een site wordt gelinkt vanuit een artikel op de frontpage van Slashdot.org en daardoor in korte tijd enorme hoeveelheden traffic te verwerken krijgt. De stijging in pageviews die tijdens het begin (tevens hoogtepunt) van het Slashdot-effect wordt veroorzaakt is niet eens zo heel groot, maar wel wordt een site in korte tijd door een enorm aantal unieke bezoekers bezocht.
In het geval van Tweakers.net veroorzaakten de vreemdelingen per individu weliswaar minder pageviews dan de vaste Tweakers.net-aanhang, maar omdat elke unieke bezoeker naast de reviewpagina tevens vele afbeeldingen, javascripts en stylesheets kwam ophalen, neemt het aantal gelijktijdig draaiende Apache-childs in korte tijd enorm toe. Een Apache-child opent vaak ook een Mysql-verbinding en daardoor was er tevens sprake van een forse stijging in het aantal gelijktijdige Mysql-connecties. Het resultaat was een vloedgolf die het spreekwoordelijke emmertje deed overlopen.
Ondanks de verdubbeling van de capaciteit van de web- en database-servers ontstonden er kort na de serverupgrades van december nieuwe capaciteitsproblemen. Ons voornaamste probleem was het gebruik van Freebsd 4 op de database-server. Mysql weigerde om met Freebsd's native threads tegelijkertijd van beide processors gebruik te maken. De Mysql-daemon speelde wel haasje over maar zat nooit op de beide cpu's tegelijk. Linuxthreads als alternatief ging niet werken en zodoende liep de database feitelijk op één schamele 733MHz PIII. Freebsd 4, Mysql en SMP waren duidelijk geen ideale combinatie.
De reden waarom deze ongelukkige configuratie er was gekomen, was de Adaptec 3200S raidcontroller. Deze ging niet werken onder Linux en omdat eind november sprake was van grote tijdsdruk kon niet gewacht worden op een vervangende controller. Destijds was er vrijwel dagelijks sprake van serverproblemen en een andere raidcontroller zou op zijn vroegst pas na twee tot drie weken geleverd kunnen worden. Meer vertraging was absoluut het laatste wat we op dat moment konden gebruiken.
In de weken na de Itanium-preview begon het ontbreken van échte SMP steeds regelmatiger een beperking te vormen. Verder kreeg Aphrodite aanzienlijk meer load op haar bordje toen het forum werd uitgebreid met een functionaliteit voor uploadbare usericons. Forumgebruikers konden hiermee hun icoontjes naar de server uploaden, zodat het gebruik van eigen webspace niet langer noodzakelijk was en een beperking gesteld kon worden aan de grootte van de user icons. Een bijkomend effect was een toename in traffic en server load. Het serverpark was na twee maanden alweer aan een nieuwe uitbreiding toe.
Nieuwe raidcontroller
In de eerste plaats moest er een nieuwe raidcontroller voor Artemis uitgezocht worden, zodat de database server overgezet kon worden naar een besturingssysteem waar Mysql wel op kon multi-threaden. Linux was de voornaamste kandidaat, maar ook Solaris x86 kwam als alternatief in aanmerking. Een zoektocht op usenet wees uit dat er onder Linux-gebruikers goede ervaringen waren met de controllers van American Megatrends. Dit bedrijf is in Nederland vooral bekend van zijn bios-software, maar timmerde met zijn scsi-raidcontrollers al jaren aan de weg. Na het raadplegen van de AMI-website werd de Megaraid Elite 1500 uitverkoren als de nieuwe raidcontroller voor onze database-server. De Elite 1500 voldeed aan al onze wensen, namelijk dual channel Ultra160 SCSI, 64bit pci en flexibele driverondersteuning voor onder andere Solaris x86, Freebsd en Linux.
Artemis processorupgrade
De prijs van de 1GHz Pentium III was in februari inmiddels tot een aanvaardbaar niveau gekelderd en daarom werd besloten om de twee 733MHz PIII's bij CompTech World in te ruilen voor 1GHz-exemplaren. Met deze eenvoudige upgrade werd de maximale cpu-performance bereikt die op dat moment mogelijk was met een voor ons betaalbare configuratie.
Uitbreiding van het webservercluster
Aanvankelijk was het de bedoeling dat Athena en Aphrodite tijdens de plaatsing van Artemis beide een 1GHz Thunderbird en een KT133-mobo-upgrade zouden krijgen. Verder waren er plannen gemaakt om een derde webserver te bouwen, tevens draaiend op een 1GHz Thunderbird. De upgrade van Athena kon in december geen doorgang vinden omdat de processor niet op tijd was geleverd. In februari 2001 werden deze plannen uit de ijskast getrokken. Wegens de relatief lage kosten van een vierde webserver werd besloten om het serverpark meteen met twee nieuwe webservers uit te breiden.
Het uitgangspunt bij de bouw van de nieuwe servers was een simpele configuratie met een snelle processor en voldoende geheugen. De webservers doen immers niets anders dan de hele dag php-scripts parsen en plaatjes het net op helpen. De I/O-prestaties boeien weinig omdat alle statische data dankzij de efficiënte cache van het bestandssysteem in RAM wordt gezet. Het gebruik van scsi, raid, ecc-geheugen en andere kostbare availability-verhogende hardware kon achterwege gelaten worden omdat de webservers afzonderlijk al redundant waren. Mocht een machine onverhoopt uitvallen dan zouden zijn taken overgenomen kunnen worden door de overblijvende webservers. Met vier webservers zou de capaciteit meer dan voldoende zijn om bij een doodvallende server zonder merkbaar prestatieverlies verder te werken.
AMD leverde opnieuw de processor, in dit geval een 1,2GHz Thunderbird. Twee 1GHz Athlons en twee MSI K7T Pro2A mobo's waren al in ons bezit en hier werd dankzij MSI een K7T Turbo aan toegevoegd. Verder kregen de twee nieuwe webservers elk 512MB geheugen, een 7200rpm Maxtor ata-harddisk en twee 3Com nic's. Gezien de groei van Tweakers.net en het bijbehorende serverparkje was het geen slecht plan om vroegtijdig rekening te houden met een efficiënt gebruik van de ons beschikbare rackspace. Voor het eerst maakten we daarom gebruik van 2U-rackmounts. 2U-kastjes waren altijd vrij duur geweest in vergelijking met standaard 4U-rackmounts, maar begin dit jaar kwam daar geleidelijk verandering in. Wij kozen voor de IPC-C2S van Procase, een no-nonsense kastje voorzien van een twee interne 3,5" drive bays, een 250W-voeding en een pci-risercard met drie slots. Dit was net voldoende voor twee netwerkkaartjes en een videokaart. Hoewel AMD voor desktop Athlon-systemen het gebruik van een 300W-voeding adviseerde, vormde de krappere voeding van de Procase-behuizing geen probleem vanwege de bescheiden configuratie van de webservers. Zo ontbraken standaard desktopgoederen zoals een cd-romdrive, cd-brander, geluidskaart, usb-randapparatuur en een stroomvretende videokaart.
In een situatie met vier webservers was het niet langer praktisch om elke machine via een crosslink aan de database-server te knopen. Een 8-poorts 3Com OfficeConnect ging dienst doen als switch voor het interne sql-verkeer. De internetverbinding werd bij iedere server verzorgd door een 100Mbit-lijn naar de Cisco-switch van Vuurwerk.
In een volgend artikel wordt de hostinggeschiedenis van Tweakers.net: vanaf begin 2001 beschreven.
:strip_icc():strip_exif()/i/2003096314.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/2001246513.jpeg?f=fpa_thumb)
:strip_exif()/u/26632/dosprompt2.gif?f=community){kind=small}
/u/33139/crop61a880c2eab36_cropped.png?f=community){kind=small}
/u/1/femme.png?f=community){kind=small}
/u/64204/crop5e333d1575fff.png?f=community){kind=small}
/u/24937/crop65fe1ebc2efd0_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/29534/moto-icon.jpg?f=community){kind=icon}
/u/8/oog3.png?f=community){kind=small}
/u/4024/burne.png?f=community){kind=small}
:strip_icc():strip_exif()/u/38865/syq_666.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/137946/logolosklein.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/9440/patriotic_eagle.jpg?f=community){kind=small}
/u/18933/beeldmerk.png?f=community){kind=small}
:strip_icc():strip_exif()/u/4795/pics_18_ziza.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/132443/crop62deab1dcf2c6.jpg?f=community){kind=small}
:strip_exif()/u/56159/archer.gif?f=community){kind=small}