> It shouldn't be any worse write performance than RAID-5, and read
performance
> 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
not
> 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
goal).
--
To UNSUBSCRIBE, email to debian-isp-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org