Re: Squid: ccd oder nicht ccd?

From: Oliver Fromme <olli(at)dorifer.heim3.tu-clausthal.de>
Date: Mon, 1 Feb 1999 11:35:20 +0100 (CET)

Gerd Bitzer wrote in list.de-bsd-questions:
> Oliver Fromme wrote:
> > Wir werden hier demnächst einen Squid als Proxy/Cache aufsetzen
> > (Cache-Größe so ca. 10 bis 15 Gb). Als OS kommt FreeBSD zum
> > Einsatz. Der Cache wird voraussichtlich über drei Platten ver-
> > teilt (alle SCSI-U2W).
> >
> > Wenn man dem Squid drei Partitionen gibt, verteilt er seine Ob-
> > jekte automatisch gleichmäßig darüber. Die Squid-Leute behaup-
> > ten, daß dies bei aktuellen Squid 2.0 ziemlich effizient sei.
> > Mein Frage ist nun: Kann man sich darauf verlassen? Oder wäre
> > es besser, die drei Partitionen mit ccd zusammenzustripen und
> > dem Squid "am Stück" zu überlassen? Hat da jemand Erfahrungs-
> > werte?
>
> Hmm, Striping mit Parity (kann das ccd ?) hätte zumindest den Vorteil,
> daß eine Platte ausfallen könnte, ohne daß das Gesamtsystem stehen
> würde.

Ich glaube, RAID5 ist den Aufwand eher nicht wert. Wenn mal
eine Platte ausfällt, muß halt erstmal eine neue her, bevor es
weitergeht. Das geht eh nicht anders, da auf den Platten
nicht nur der Cache, sondern auch das System ist. (Evtl. wäre
es eine gute Idee, nur zwei Platten für den Cache zu nehmen,
und die dritte für das System... hmm...)

Im Moment tendiere ich eher dazu, nicht ccd zu benutzen, son-
dern das Verteilen der Daten dem Squid zu überlassen.
Mal schauen, wie sich das dann in der Praxis verhält...

> Was sagt denn http://squid.nlanr.net/Squid/ zu dem Thema ?

Da hatte ich schon nachgeschaut, aber nichts gefunden. :-(

Gruß
   Oliver

-- 
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:olli(at)dorifer.heim3.tu-clausthal.de)
"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
                                         (Terry Pratchett)
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 01 Feb 1999 - 11:35:45 CET

search this site