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: 68, views: 1.754 •

Tweakers.net zal binnenkort beginnen met het configureren van een nieuwe database-server voor het forum. De upgrade is onderdeel van een plan waarbij het huidige aantal van twee database-servers zal worden uitgebreid naar drie machines. Het derde systeem zal gaan dienen als backup en spare server. De afgelopen maanden hebben we aan den lijve kunnen ondervinden hoe kwetsbaar Tweakers.net is als er een ernstig probleem op één van de twee database-servers optreedt. In de huidige situatie kunnen defecten niet op een adequate wijze ondervangen worden. Enerzijds omdat er geen vervangende hardware beschikbaar is die voldoende performance heeft om de taak van Tweakers.net of GoT database-server te vervullen en anderzijds omdat we niet verzekerd kunnen zijn van een snelle levering van spareparts. Uiteraard is dit probleem op te lossen door een flinke hoeveelheid SLA in te kopen, maar aangezien wij goed in staat zijn om onze eigen servers te servicen is het economischer om wat componenten in reserve te houden.

Vanwege een sterke toename van de disk I/O op de Apollo (database-server van het forum) en onopgeloste problemen met het adresseren van meer dan 4GB geheugen is gekozen voor een oplossing waarbij Apollo wordt vervangen door een nieuw en beter presterend systeem en de huidige configuratie om te bouwen tot reserve-server. Tot op heden zijn we er niet in geslaagd om Apollo betrouwbaar met meer dan 4GB te laten werken. Het probleem wordt mogelijk veroorzaakt door de door ons gebruikte combinatie van moederbord, processor en RAID-adapter. Het vinden van een oplossing is nauwelijks mogelijk zolang de machine in productie is. Door een nieuw systeem te bouwen kan er zonder druk worden gezocht naar een oplossing.

Appro 2128Hs barebones voor Artemis en Apollo
Tweemaal Appro 2128Hs

De nieuwe Apollo, geleverd door onze huisleveranciers Melrow en Informatique, zal evenals zijn collega's gebaseerd zijn op een Appro 2128Hs barebone, en wel het nieuwe model met 4+4 in plaats van 4+2 DIMM-slots. Hiermee kan een maximum van 8GB geheugen worden geadresseerd bij gebruik van 1GB DIMMs, wat op de forumdatabase zeker geen kwaad kan. De Appro-behuizing zal bevolkt worden door twee Opteron 244-processors, acht 1GB DIMMs, een LSI MegaRAID 320-2X en een achttal Seagate schijven. Zodoende ontstaat de volgende configuratie:
  • Dual AMD Opteron 244 (1,8GHz)
  • 8GB PC2700 ECC Registered DDR SDRAM
  • Tyan Thunder K8S Pro
  • LSI Logic MegaRAID SCSI 320-2X
    • LSI BBU3 battery backup unit
    • 512MB PC2100 ECC DDR SDRAM cache
  • 2x Seagate Cheetah 10K.6 36GB 10.000rpm (RAID 1 voor boot)
  • 6x Seagate Cheetah 15K.3 36GB 15.000rpm (RAID 5 + hotspare voor data)
  • Appro 2128Hs barebone
  • SuSE Linux 9 AMD64
De MegaRAID SCSI 320-2X leverde zeer goede prestaties in onze test van SCSI RAID-adapters. Deze nieuwe RAID-adapter van LSI Logic is in staat om met vijf 15.000rpm harde schijven sequentiële transfer rates van 240MB/s en cache transfer rates van 400MB/s te bereiken in RAID 5. De cache optimalisaties van de MegaRAID SCSI 320-2X zijn bovendien erg goed. In database workloads met veel gelijktijdige lees en schrijf activiteit presteert de MegaRAID SCSI 320-2X daardoor veel beter dan de in Nederland populaire RAID-adapters van Adaptec. Het nieuwe systeem zal dankzij de snellere RAID-adapter, de snelle 15.000 toeren schijven en het grote aantal schijven per RAID 5 array veel betere I/O prestaties kunnen leveren dan de huidige configuratie. De verdubbelde hoeveelheid geheugen zal zorgen voor een vermindering van disk I/O.

LSI Logic MegaRAID 320-2X 512MB (groot)

* Update 27-04

De nieuwe server is inmiddels gearriveerd op kantoor. Inmiddels hebben we gemerkt dat de bijgeleverde riser, die niet passend is voor de Appro 2128Hs, ervoor zorgt dat de Intel SRCU42X (geOEMde MegaRAID 320-2X van Intel) niet optimaal functioneert, ongeacht de kloksnelheid van de PCI-bus. Een passende en hopelijk beter functionerende riser zal toegestuurd worden zodra deze beschikbaar is. De prestaties van de 320-2X / SRCU42X met zes Cheetah 15K.3-harde schijven in RAID 5 zijn wel bizar goed. Deze setup haalt een sequentiële read transfer rate van 375MB/s tot 260MB/s aan het begin tot het eind van de array. De write transfer rates liggen rond de 200MB/s. De read transfer rate schaalt lineair met het aantal schijven: 75MB/s * (6 - 1) = 375MB/s. Wie nu nog zegt dat RAID 5 niet presteert heeft de verkeerde adapter geen MegaRAID 320-2X in zijn systeem .

Een meevaller is dat het bijgeleverde geheugen door de processors als DDR400 CL3 in plaats van DDR333 CL2.5 herkent blijkt te worden. Hiermee ligt de geheugenbandbreedte op circa 5,1GB/s in 32-bit Windows XP. Onder een 64-bit NUMA-geoptimaliseerd besturingssysteem moet meer dan 10GB/s mogelijk zijn.

* Update 17-05

Na enige tijd van stilte weer een update. In de afgelopen weken hebben we nogal wat te stellen gehad met de nieuwe server. Het blijkt dat de standaard 500 watt power supply niet voldoende is om een server die tot de nok is volgestampt met hardware stabiel te houden. De beschikbare stroomsterkte op de 3.3V en 5V-lijnen is aan de lage kant en dat uit zich onder zware belasting in vreemde symptomen zoals het spontaan uitvallen van één van de SCSI-schijven en bij bepaalde tests zelfs compleet uitschakelen van de server. Hoewel Appro's tech support bij hoog en bij laag blijft ontkennen dat de oorzaak bij de voeding zou liggen bleken de problemen na het plaatsen van een tweede voeding opgelost (dit enigszins tegen de verwachting in omdat deze voeding normaliter enkel voor redundancy zorgt). De vervangende riser zal als alles goed gaat morgen arriveren, waarmee we hopelijk het configureren zo snel mogelijk af kunnen ronden.

Reacties (68)

Reactiefilter:-168065+157+210+31
Het enige wat deze server beter maakt is dat er meer geheugen in zit en dat jullie nu eerst kunnen checken of het systeem stabiel loopt in tegenstelling tot server die nu draait... toch?

Waarom wordt deze server straks dan niet als db server gebruikt en dan bij de huidige server de config problemen opgelost? Zo heb je ten eerste een snellere (4 GB verschil) server plus dat je dan ook een goed geconfigde backup-server hebt draaien.

just my thoughts
dat wordt ook gedaan?

deze server is wel sneller, snellere aid controller + schijven. En de backupserver gaan we dan eerst nauwgezet bestuderen waar de problemen vandaan komen :)
De nieuwe server heeft snellere processors, dubbel zoveel geheugen en veel snellere storage. De problemen met de huidige server gaan we ook zeker aanpakken maar daarvoor moeten we die server eerst uit productie kunnen halen, wat alleen gaat lukken als deze nieuwe doos hem kan gaan vervangen.
Hoi Femme,

Was een loadbalanced cluster met SAN niet sneller geweest? Ik vind de snelheden die je met een OS-op-je-storage haalt maar matig vergeleken met een SAN met dezelfde setup. True, San is duur(der), maar wel versatile (onafhankelijk van je serversystemen, raid is hotchangeble etc). Tevens kun je dan een mooi optisch San netwerk achter de servers maken :)

Of is dat weer een stapje te ver? Ik denk dat een onderdeel van jullie probleem is dat de machine in kwestie zowel de I/O afhandeling doet als het uitpluizen van de records etc, verder is er zo nog steeds een single point of failure, die je met een SAN misschien wat kan spreiden.
Ten eerste kan je voor het geld van een (simpele) SAN kan je een leuke middenklasse auto voor kopen, dus ik geloof niet dat dat binnen het budget van tweakers.net ligt. Met een iSCSI oplossing is het al het wat vriendelijker geprijsd, dat kan nog steeds een aardige duit kosten.

Ten tweede, dit soort netwerkstorage oplossingen zijn geen wondermiddel voor performance. Per applicatie zal bekeken moeten worden of het zinvol is om deze op een SAN te plaatsen. Vooral databases hebben vaak meer performance op lokale (RAID-1) storage vanwege de hoeveel I/O die gedaan wordt. SANs hebben vaak weer RAID-5 storage, wat weer funest is voor DBs.

Enne, alle servers aan 1 SAN hangen, is dat niet juist creëren van een single point of failure? SAN weg, tweakers.net weg....
Prima zet! Tweakers heeft uberhaubt al een razendsnelle database, een goede backup kan daarom nooit kwaad. Het is inderdaad verstandig om de 'oude' server te vervangen met dit beest :-)
Wat ik me altijd af vraag: is het echt nodig, of is het ook gewoon uit tweak-opzicht dat er tegenwoordig wel iedere maand een server bij komt of word geupgrade? :) Ik kan me namelijk niet aan de indruk onttrekken dat er de laatste tijd heel veel geupgrade wordt aan het serverpark. Natuurlijk is dat cool, want tweakers.net is de snelste site die ik ken, maar is het ook echt nodig? :)
het tnet-serverpark is ook vrij uitgebreid inmiddels, dus op zich is het wel vrij logisch dat er regelmatig wat aan geknutseld wordt :)
Uitbreiden en Upgraden zo veel en zo vaak je kan denk ik dan. Als IT site heb je een beetje een voorbeeld functie en kun je jezelf niet veroorloven met hele oude hardware te werken.
Het is gewoon zo dat we jarenlang door financiële beperkingen genoodzaakt waren met een niet echt optimale setup te werken, of noodgrepen toe te passen. Nu we wel de financiële ruimte hebben om de boel goed op orde te krijgen proberen we dat ook zo snel mogelijk voor elkaar te krijgen. Inmiddels zijn we behoorlijk tevreden over de config van het serverpark an sich, en kunnen we gaan werken om het beter te maken dan strikt noodzakelijk is voor het draaien van de site, zodat we beter bestand zijn tegen onverwachte gebeurtenissen.
LOl, verwacht je een /. ??
Zo vreemd is dat toch niet ? Is al eens eerder gebeurd, en aangezien T.net toch redelijk vooraan staat met nieuwe ontwikkelingen spotten zou het zomaar kunnen dat je geslashdotted wordt vroeg of laat.
tweakers.net is de snelste site die ik ken
google is volgens mij echt sneller, niet dat je veel hoeft te laden voor google maar ach.

ontopic:
ik denk dat voortijdig upgraden een goede zaak is, het past iig in de lijn van tweakers professioneler te worden en het hobbyisten imago achter zich te laten. een te laate upgrade is een risico voor de snelheid en betrouwbaarheid

je kunt ook zien dat de 100% zelfbouw servers al enkele upgrades niet meer gebruikt worden
Je zegt het zelf, de frontpage van google is nou niet bijster ingewikkeld, vergeleken met de frontpage van tweakers.
Als je het hebt over de snelheid van de zoekfuntionaliteit van google: ooit gezien wat voor renderfarm ze hebben staan daar?
Renderfarm? Wat renderen ze bij google dan? ;->
google heeft bij mij altijd een ping van rond de 200 nou dat heeft echt wel invloed op de snelheid. En daarbij is idd de frontpage heel gemakkelijk te laden!
Gezien de architectuur van de site en de opbouw van de pagina is een snelle weergave waarschijnlijk veelal te danken aan de snelheid van je eigen PC...
Knap werk wat jullie leveren hoor, ook dit is weer een lekker initiatief! Het enige wat ik me afvraag is, hoe weten jullie nou zeker dat deze server met 8GB wel I.C.M. de megaraid als een zonnetje gaat draaien. Het is natuurlijk wel zo dat je met andere hardware te maken hebt waardoor je de problemen die je nu hebt en waarvan je zeker weet dat ze daar mee te maken hebben in theorie kan wegvinken. Hoewel je wel met een nieuwe config te maken hebt waarvan ook niet zeker is of het lekker draait? Toch zou ik wel willen weten hoe jullie zo zeker zijn, denk eraan, dit is zeker geen aanval. Sterker nog ik ben alleen benieuwd naar HOE de research is gedaan, en ik vind het zoals altijd uitermate leuk dat dit soort dingen voorkomen.

Succes iig!

(PS. Wel weer zo'n kwijl bak he, gaat lekker!)
Als deze niet lekker draait kunnen ze er rustig aan werken omdat hij nog niet meteen in productie hoeft.
Mooi om te zien dat T.Net door gaat met het verbeteren van het server parkt. Onder andere door de plaatsing van de consoleserver en nu ook de aanschaf van een backup database server.

Momenteel zijn er twee grote/belangrijke database de T.Net en GoT db. Hoe willen jullie die backup dan gaan regelen. Gewoon dmv een inport in het geval van een crash of echt een live spare die direct alles kan overnemen?

Verder heb ik ook gelezen dat er een nieuwe development server is (Compaq DL140) en dat jullie nog altijd twee firewalls/loadbalancers willen installeren ipv de huidige loadbalancer.

Als laatste heeft dit alles nog gevolgen voor de userbase merge of is die voor onbepaalde tijd uitgesteld. Apollo is inmiddels toch stabiel genoeg.
In eerste instantie zal de reservedoos niet meer dan dat zijn, gewoon een doos die zodra ie nodig is ingezet kan worden. Een hotspare levert je in sommige gevallen net zoveel downtime op (of meer!) als je weer je originele (snellere) server in wilt zetten om verder te gaan.

Maar als we verwachten of bang zijn dat we veel downtime hebben bij een bepaalde server (cpus verbranden en nemen het moederbord mee ofzo), dan zullen we de reserveserver uiteraard zsm inzetten. Waarschijnlijk in eerste instantie dmv het inladen van backups, later misschien als een "semi-hot-standby" of zelfs "hot-standby".
Mooie config. Waar zit de knop: Plaats in winkelmand?

Okay, nu nog constructief:

1. Hoe weet je zeker dat deze config wel meer dan 4 Gb kan adresseren?

2. Wij doen ook altijd het volgende:
- probleem met server? (geheugen, instabiel etc.)
- niet moeilijk doen, nieuwe config regelen, opbouwen en de oude weghalen. Die wordt dan gebruikt als donor, devbak of backup.

Imho is het altijd lastig om met zulke problemen in een productie server te gaan zoeken. Nieuwe inzetten, oude offline halen en klaar.
Reactie verwijderd
Ik neem aan dat dat een reply op mij was :)

De adresseringen e.d. per component zijn toch afzonderlijk? Maar ja, als dat inderdaad het enige 32bits comp. is, dan is het uiteraard de moeite waard om deze a.s.a.p. uit het systeem te trappen.
Mochten er dan nog steeds problemen zijn, dan ben je verder van huis imho. Probeer het dan nog maar eens bij zo'n voor de hand liggend iets te zoeken.

Verder ging ik er ook wel vanuit dat er flink getest gaat worden :) Zulke geintjes trap ik inderdaad ook niet meer in :)

En zoals ik al zei: het is ondoenlijk om op een productiesysteem zulke problemen/oorzaken/fouten op te gaan sporen. > nieuwe config > oude offline. Dat is het makkelijkst en imho het snelste.

Wat voor testen ga je er eigenlijk op los laten? Natuurlijk db gerelateerd, maar hoe? Gewoon stresstesten? In de trend van: simuleer x gebruikers en doe iets?
De Elite 1600 zou in theorie 64-bit adressering moeten ondersteunen. Het kan ook een driver probleem zijn, of het zijn gewoon het moederbord en de processor die niet met 6GB willen werken (schijnt meer voor te komen bij de Thunder K8S en de Opteron 242). Het is allemaal nogal onduidelijk.
s2885? Bedoel je niet de s2881?
Als ik naar de stats kijk dan heeft de huidige Appie het niet echt heel erg zwaar. Ik kan me voorstellen dat jullie dit doen voor de redundancy maar voor de prestaties?

Begrijp me niet verkeerd: het is een ontzettend geile bak, die zeker sneller zal zijn dan de huidge Appie (Nieuwe opterons, LSI controller, 8GB) maar is die pure brute snelheid wel nodig?
De LSI Logic MegaRAID SCSI 320-2X ondersteunt toch maar 256mb geheugen? Of heb ik het nou weer mis?
De I/O processor ondersteunt maximaal 1GB geheugen. De firmware gebruikt in de huidige versie maximaal 256MB als cache. Het is waarschijnlijk dat deze limiet in komende firmware releases wordt opgeschroefd.
Euh... misschien een hele stomme vraag... Maar misschien snap ik het gewoon niet; is 5x36 gb niet een beetje weinig voor een Database server? of is er een speciale file server voor de databases?

edit: ah... dacht dat het echt onwijze hoeveelheden opslagruimte zou gebruiken... Maar valt mee dus...
Maar deze krijgt toch raid 5 met 5dataschijven en 1 hotspare... Das dan toch 5x36gb?
Effectief krijgt de nieuwe server 144GB diskruimte (RAID5 van 5 disks, dus 4 x 36 GB effectief). De huidige Apollo heeft effectief de helft daarvan (RAID5 van 3 disks, dus 2 x 26 GB effectief) en dat zit niet eens vol. Met 144GB moeten we dus nog wel even vooruit kunnen.
Er wordt alleen tekst opgeslagen in de database. 140GB tekst is echt verschrikkelijk veel. Op dit moment hebben we 60 procent van de huidige array van 70GB in gebruik. 22,1GB wordt gebruikt door de GoT database. Daar zitten circa 12 miljoen posts in verdeeld over 850.000 topics.

Bij een RAID 5 array van vijf schijven mag je de opslagcapaciteit van één schijf aftrekken ipv parity en hou je dus 4x 36GB over. De hotspare komt alleen in actie als er een schijf stuk gaat.
Bij een RAID 5 array van vijf schijven mag je de opslagcapaciteit van één schijf aftrekken ipv parity en hou je dus 4x 36GB over.
Tenzij je 3+2 draait (3 data, 2 parity) :)
Dat is Raid 6. Dat is misschien een ietsje overdreven.
Vraagje :

Wordt samen met die UpGrade ook de nieuwe lay-out voor GoT in gebruik genomen waar nu Crisp en de rest mee bezig zijn ??

Vind hem namelijk erg mooi O+ :Y)
Het is niet te verwachten, crisp heeft al meerdere malen aangegeven dat hij weinig tijd op dit moment heeft. Verder bestaat GoT eigenlijk uit een aantal onderdelen; de database, de react-forum software en de templates.

Hier en daar zijn er wel wat kleinen aanpassingen in de tabellen of templates nodig als er in react wat veranderd is maar het zal nog wel even duren voordat de templates definitief af zijn. :)

Op dit item kan niet meer gereageerd worden.



Populair: Desktops Samsung Smartphones Privacy Sony Microsoft Apple Games Consoles Politiek en recht

© 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