You are here

Overthinking server design

So, Elliquiy's Ajax Chat finally got the better of it, size wise, and nearly brought down the server while I watched. You might ask why I'm running what amounts to IRC on the web and I will probably respond to that in some future article. E's silliness is beside the point, here.

I've been discussing server specifications with my webhost, going over hard drives, RAID configurations, and so on, eventually expressing a desire for a battery-backed cache unit and asking about RAID 6.

So, the salesman responded:

Well, if you want my opinion. You're WAY overthinking this. Just go with 4x 10k RPM SATAs in RAID10. There is no reason to get twin RAID1. RAID5 or RAID6 are only things you should be getting if you have a good reason to be getting them - if you don't know why you *should* get them, chances are you shouldn't be getting them. Skip the BBU on the RAID card, you're a website - not a hospital storing priceless medical documents.

Don't get me wrong, I'll sell you whatever you want to buy

Sometimes I just need to let people smack me. A bit more reading about RAID 5 and 6 has put to rest any intention of using those in the future. I feel ashamed to have put the question.

A bit of background is in order.

My intent is to slave Elliquiy's current server to the new one, meaning that I can take snapshots, nearly live, off of the current server. This means forums can still run during the backup and members don't have to be shown it is occurring at all. E's current machine will perform nameserver duties, backups, static webhosting and other such things. Peachy.

So what happens during a catastrophic failure on the new server?

Ideally, everything is being synced over a closed network link, so I lose next to nothing - a post, if that. Most communities are lucky to have an admin who does regular backups - though this is more common as the site grows larger.

The idea behind a twin raid 1 is that since I can split i/o usage evenly, I could have one 'losable' set storing various logging and redundancy features, while the main pair held critical data. If both disks on the losable set failed, I could remount and be going with little fuss.

There is no avoiding down time, however. Even if only one drive fails, every single write during use entails another write to the rebuilding drive. Rather than subject my communities to days of horrible performance, it's easier to put up a status page for a few hours explaining the situation.

The case against a battery backed unit is even more plain - for someone to lose a post in the event of a power outage or PSU failure, the data actually has to be in cache but not yet committed to disk. And the person in question would also have to not have any way of recovering it on their own.


I can dream about having a completely reliable setup, of course. That does not make it sane at this point - more to the point, I can neither afford nor justify the cost. The backup-from-slave at least does the courtesy of keeping my forums up 24/7 on top of it all.

Add new comment

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <abbr> <acronym> <address> <bdo> <blockquote> <del> <hr> <img> <ins> <pre> <q> <sub> <sup> <dl> <dt> <dd> <ul> <ol> <li> <h1> <h2> <h3> <h4> <h5> <h6> <table> <caption> <col> <colgroup> <tbody> <td> <tfoot> <th> <thead> <tr> <b> <big> <cite> <code> <dfn> <em> <i> <kbd> <samp> <small> <strong> <tt> <var>
  • Lines and paragraphs break automatically.
  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.