From owner-freebsd-isp Wed Oct 2 06:28:51 1996 Return-Path: owner-isp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA06207 for isp-outgoing; Wed, 2 Oct 1996 06:28:51 -0700 (PDT) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA06185 for ; Wed, 2 Oct 1996 06:28:48 -0700 (PDT) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id IAA05083; Wed, 2 Oct 1996 08:27:44 -0500 From: Joe Greco Message-Id: <199610021327.IAA05083@brasil.moneng.mei.com> Subject: Re: RAID Controller Product To: cassy@loop.com (Cassandra Perkins) Date: Wed, 2 Oct 1996 08:27:44 -0500 (CDT) Cc: freebsd-isp@freebsd.org In-Reply-To: from "Cassandra Perkins" at Oct 1, 96 04:05:41 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-isp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Hello.... > > Does anyone know of a good scsi-to-scsi RAID controller that can do RAID > level 5 and that would be great for a file server application. I'm > presently using disk ccd for our news servers. Each server carries the > same information, so I'm looking to consoladate the information on one > fileserver. I am curious as to why you would choose to do this. If you currently have your I/O spread amongst several machines, you gain from having the data replicated. If you have N machines, you have approximately N times the I/O bandwidth available as compared to a solution where you only have the main system's I/O bandwidth available. Put another way: Consider a system with redundant disks (let's say two). For read operations, each disk is allowed to perform operations simultaneously - and they certainly do not have to be participating in the _same_ operation. Assuming that you are using GigaWonder disk drives capable of fetching 1000 articles per second.. You have essentially: 1) increased your potential I/O transfers per second (2 drives = 2000 articles per second). 2) Reduced your average time to complete a request ("latency") by reducing contention. One drive would be busier than two and ultimately gets saturated. 3) The saturation point essentially doubles. These are all important factors in news processing. Now... this on the surface should appear to have no real relation to your problem. However... I contend that if you currently have two complete news servers with two complete sets of disks, you have the _exact_ _same_ _advantages_... but you have even replicated the hardware, so you gain a hidden bonus - reliability. If one news server fails, you still have fallback ability with the second one. Therefore: I do not think what you are trying to do is a particularly good idea. Easier, yes, better, well I remain unconvinced. Incidental: I have set up a client with such a distributed news system and it works extremely well, is very scalable, and it is really cool to be able to take a machine out of the DNS roundrobin when it needs to be serviced, etc... (the cluster is carefully overengineered so that they have 'N+1' news servers where N is the number they really need). Can you say 'zero service interruption'. ... JG