[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RAID Suggestion for webserver

Hi All

RAID 0 gives the best read and write performace as the data is striped across the drives. RAID 1 gives the same write performace as a single drive but read performance is faster than a single drive (as there are always 2 drives that the data can be read from, hence the controller can choose the drive not being accessed / with it's head closest to the needed data. RAID5 give read performance a boost for the same reason as RAID0, but write performance is only slightly faster than a single drive as the array must 'stop' while the controller calculates the parity bit and writes that to a drive.

Overall the chances of 2 drives failing at the same time a very small and if they do you look to your backup. Also running all your services on one box will be fine for a small setup, but if you have big plans you will quickly run our of processing power (especially with a database on the box). It would seem unlikley that the HDD transfer speed will be the bottleneck.

At 02:53 14/02/2002 +0800, Jason Lim wrote:

> It shouldn't be any worse write performance than RAID-5, and read
> should be good!

With RAID 5, isn't the data distributed (along with parity data) to the
various disks, while with RAID 1 the whole data is written to all disks?
I'm guessing that each disk writing only part of the data to each disk
would lead to faster performance (as long as the controller can handle
sending the data to all the disks that fast).

Read performance... if it is RAID 1 i suppose it would depend on how good
the read algorithm is? Worst case it would be the same as a single disk.
But if it is RAID 5, wouldn't it only need to read a bit of the data from
each disk (to build up the complete data)?

(I may be wrong with the above information, i'm no raid expert).

> Instead of having one server for 50 accounts which does everything, why
> have different servers for different services?  Then you could have
three web
> servers for several thousand domains instead of getting a new server for
> every 50...

I could see a lot of headache doing it that way, including user
authentication and how to tie all the services together in a nice neat
package that is easy to manage/maintain. Virtually all the publically
available solutions (Plesk, Hostplus, etc.) do it on a per-server basis,
and that would include Cobalt's Raqs.

I suppose if we have many thousands of accounts it would be more
economical to do it your way (seperate mail server, ftp server, auth
server, www server, database server, etc. each specialized in both
software and hardware) but we don't have THAT many customers ;-)  Mostly
we put lower-end clients on servers with 100-200 or so clients, with
higher end clients on servers with 50 or less. Works out pretty well that
way, as you can then artificially "manage" the performance you give
clients (of course, this is not direct control, but it achieves the same

To UNSUBSCRIBE, email to debian-isp-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: