|
|
Advertisement:
|
|
OCAU Server Upgrade |
|
Join the community - in the OCAU Forums!
|
Intro, Ragnarok Takes Shape
A quick prologue: My apologies for the lateness of this article. As you may know, we've been running on the servers covered by this article for a few months now and I think everyone is aware of how much difference they've made to OCAU. This article ended up getting buried for a long time and it's only recently that I've gone through and tidied it up enough for publication. I hope you'll still find it interesting.
OCAU has come a long way since it was a hosted on my free webspace on an ISP back in 1999. Over the years as we've grown the site has moved around - firstly an abortive attempt to host it on a so-called "unlimited" hosting plan in the USA, but quickly returned to a dedicated server in Sydney. This first server, Odin, was hurriedly built around my desktop machine at the time, a dual Celeron system using ABIT's BP6 motherboard. Two years later we moved onto Thor, a dual P3-1GHz machine using ABIT's VP6 board.
Thor served us well for another two years, but as the site - and particularly the forums - increased in traffic, we began to overpower it. Much tweaking extended the life of the server, but during very busy times the single SCSI drive was causing the database server to back up requests and in some cases slow the entire machine to a crawl, corrupting database tables and causing other problems.
Ragnarok Takes Shape
Clearly, it was time to upgrade. I mentioned our dilemma to OCAU Major Sponsor Plus Corporation who were keen to get involved and help us build a new server. We bounced around some specs for a while and eventually a pile of goodies arrived:
We'd decided on a dual AthlonMP system - at the time (a year ago now) this platform offered the best bang-for-buck. That equation went out the window a little bit when we used the top-dollar MP2800+'s, the first Barton-cored AthlonMP's, because their 512KB of L2 cache should help with server-type tasks. For the motherboard, PlusCorp recommended Tyan's Thunder K7X Pro based on AMD's 760MPX chipset, with onboard 100Mb and Gigabit Ethernet, dual-channel onboard SCSI, ECC memory support etc. This is a true server-class motherboard and definitely the direction we want to be looking.
  
These CPUs and other components in the system will draw a fair amount of power, so a decent PSU is essential. The Tyan motherboard provides the larger EPS12V connectors - you can use a normal ATX PSU, but it's recommended to use an EPS one for heavy server work. Given we're using the fastest CPUs this motherboard supports it seems sensible to provide decent power. PlusCorp arranged a Macron MPT-460E, a 460W EPS unit that should easily meet our needs.
We obviously had to address the storage side of the server as a priority, as the storage subsystem on Thor seemed to be what was letting us down. A RAID array for the databases was mandatory, with a separate drive for system files, static data and webserver logs. A large IDE drive for backup is again a sensible idea that worked very well in Thor. I've had good experiences with Western Digital's WD1200JB drive (PATA, 7200rpm, 8MB cache) so that was chosen for backups. The machine boots off a single Seagate Cheetah ST336607LW (10k-rpm, U320) SCSI drive attached to the onboard controller and this drive will contain web data, weblogs etc. Remember that almost all static data will be immediately cached and we'll be using a PHP accelerator program which keeps most of the website scripts stored in executable form in RAM - instead of being parsed each time they are loaded.
For the databases, we used Adaptec's SCSI RAID 2120S controller. This is a single-channel RAID card using a 64-bit PCI slot with 64MB of cache onboard supporting Ultra320 SCSI devices. We connected two Seagate Cheetah ST336753LW (15k-rpm, U320) drives in RAID1. RAID0 would provide more performance, but it would greatly increase the risk of losing data if either of the drives dies. RAID1 provides a full mirror of the data on both drives, which gives us the opportunity to organise a replacement drive if one fails, gracefully shut the machine down and rebuild the array. Reading from a RAID1 array is striped, so there will be a speed increase there too.
You might be wondering why we didn't go the whole hog and get RAID5? Because our database usage is lots of small random accesses. RAID5 with its parity calculations does not perform well under this kind of load. It's great for streaming large chunks of data back and forth, but it's not ideal for busy database work of this kind. There's also the additional expense, space and cooling required for the (at least one) extra drive. Bear in mind that Thor's single drive had to handle everything, whereas we have split the load up for the new server. Web logs, system logs, in fact ALL data read or written by the server was coming from one drive in Thor. In the new server we have this RAID array just for the databases, with logs and other data on a totally separate drive.
  
15k U320, 10k U320, 7200rpm ATA100
|
|
Advertisement:
All original content copyright James Rolfe.
All rights reserved. No reproduction allowed without written permission.
Interested in advertising on OCAU? Contact us for info.
|
|
