Derde database-server in aanbouw

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.

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.


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)

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

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!

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.

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...

Over die MegaRAID SCSI 320-2X, ik heb nu al een paar keer op tweakers.net gelezen dat 'een' raid adapter de hele array stuk heeft gemaakt nadat er een disk kapot ging.

Was dit toeval, of is dit een vervelend bugje in de LSI controller? Aangezien tweakers.net veel met LSI raidcontrollers doet lijkt me het toch een goede koop.

Ik ben namelijk op zoek naar een stabiele raid5 controller die goed onder linux werkt, en ik zit te twijfelen tussen 3ware en LSI.

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.

Kom op, wat een onzin. Het gaat hier om database servers waarin STR nauwelijks/niet van belang is.

Voor het dagelijkse werk is de IO belasting heel wat anders dan een STR maar voor je backups en eventuele restores is het wel vedomt makkelijk. Verder denk ik dat men hier niet zo zeer verwijst naar een DB server icm een hoge STR maar dat de proformance van een RAID 5 config nog best behoorlijk kan zijn, dit in tegenstelling wat soms wordt beweert. Wacht met spanning op de SCSI-review van Femme

Niet geheel toevallig was de MegaRAID SCSI 320-2X veruit de snelste kaart in mijn workstation- en servertests van SCSI RAID-adapters. Dat is te danken aan de snelle I/O processor, de grote cache en de efficiënte RAID software stack van LSI Logic. De zeer goede schaalbaarheid van de STR's (lineaire schaling in RAID 5 ben ik op geen andere adapter tegen gekomen) is een resultante van de snelle RAID implementatie van de 320-2X.

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

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....

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

Waarom hebben jullie niet een moederboard dat 12 / 16 GB ondersteund genomen? Gegeven de lage geheugen prijzen en de erome prestatiewinst die een database haald met het verdubbelen van het geheugen zou 12GB of 16GB helemaal optimaal zijn?

Er kan 16GB in deze plank als je 2GB DIMMs gebruikt.

en kijk maar es wat ze kosten

Dit bord ondersteunt toch gewoon 16G (8x2G)?
Er zijn btw niet echt veel dual-opteron borden met 16 geheugenbankjes.

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".

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?

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.

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.

Betekent dit dat als er één voeding uit valt, je het hele redundancy verhaal kan vergeten en de server dus alsnog op z'n bek gaat? Dus dat je eigenlijk misschien zelfs nog beter drie voedingen erin kan zetten?

Sterker nog, het systeem is zelfs minder bertouwbaar geworden, omdat je nu 2 voedingen hebt die kapot kunnen gaan en het systeem down kunnen halen en dus precies de tegenovergestelde situatie van wat je met 2 voedingen normaal wilt berijken d.m.v. redundancie!

Ja en neen, twee voedingen in redundante opstellingen worden een pak minder belast dan een voeding die over zijn max wordt belast... Daardoor is de kans dat 1 van beide voedigen veel kleiner dan de kans dat een overbelast exemplaar eruit vliegt

Als ik ervan uitga dat huidige voeding niet defect is kan alleen tot de volgende conclusie komen. Bij Appro hebben ze de berekeningen voor de capaciteit van de voeding alleen op de tekentafel uitgevoerd. Men heeft naar alle waarschijnlijkheid geen live test uitgevoerd met een system dat "fully loaded" was.
Ik denk dat er naast de Tweakers servers niet zo veel systemen tot de nok toe gevuld zijn. Veel systeembeheerders zullen bij de datavereisten van een site als Tweakers.net kiezen voor dedicated diskservers (die duurder en trager zijn dan de Tweakers oplossing ). Kortom de problemen die Tweakers nu aantreft zijn voor Appro ook nieuw.

Waarschijnlijk hebben ze het wel een keer getest, maar als ze dan net ander geheugen en andere harde schijven (over de cpu nog maar niet te spreken...) hebben kan het al weer anders uitvallen.

Ik vind het alleen wel raar dat ze het probleem niet toe willen geven. Maar wat ik me nu afvraag, is er niet een systeem waarmee je heel simpel het huidige opgewekte vermogen van een voeding kan meten? Dan kun je kijken of
a; de voeding 500 watt levert -> dan is dit dus te weinig
b; minder levert -> dan levert hij misschien niet wat beloofd? Probeer op een andere manier uit waar er uit te krijgen is.

edit:
Hebben de huidige problemen op de fp hier mee te maken? Krijg steeds fouten van bestanden die niet geinclude kunnen worden of van een mysql server die niet gevonden kan worden...welke meestel met een ctrl+F5 opgelost zijn, maar toch....

Hebben de huidige problemen op de fp hier mee te maken?

Lijkt me sterk dat die komen door een server die nog niet in productie genomen is