Squidを利用して画像をキャッシュする構成を検討、検証してます。
俺がやりたい構成は、こんな感じ。

というのも、Squidはシングルプロセスで稼動するので、最近のサーバのようにマルチコアのCPUはもったいない。。
だからといってSquidをマルチコア対応にしてもCache領域がボトルネック（IOもしくは容量）になる為、意味が無い。。。
じゃー、どーしたら一番サーバを有効に活用できるか？って考えて、上記の構成を考えました。
デュアルコア以上のCPUを使っているので、Squidを2インスタンス/サーバにして、1インスタンスをCARP専用インスタンス。もう1インスタンスをCACHE＆CARP用にする。
これで、第1層目のキャッシュヒット率も上がるし、サーバのリソースを最大限に利用できる。
CARP部分でCPUリソースを大量消費するようなら、CACHEと分けても良いが、CARPのみで負荷試験を行ったところ 12000tran/sec 50Mbps （ボトルネック：CPU） , 8000tran/sec 800Mbps (ボトルネック：トラフィック) というすばらしい結果を出したので、CARPでCPUリソースを食いつぶすことは考えにくい。
CACHEのみで利用している場合でも、ボトルネックはIOもしくは容量になる為、CPUリソースが足りなくなることは無い。
ということで、運用面も考慮し、2インスタンス構成案が俺の案☆

実際に現在検証している構成は、こんな感じ。

この構成だと第1層目のキャッシュヒット率は上がらないが、1インスタンス/サーバなので管理が楽。
第2層目でヒット率が高いため、第3層目へのトラフィックは少ない。
第1層目からCARPする先を上記図では、Server直にしているがそこにVIPを立ててバランシングした3セットを用意すれば第2層目の一台が壊れても第3層目への影響は皆無になる。

俺の案だと、第1層目の一台が壊れた場合、第1層目の他サーバのヒット率も下がるし、第2層目のヒット率も下がる。必然的に第3層目のApacheサーバへのトラフィックも増えてしまう。

本当にどの層のどのサーバが何台壊れたらどんな影響があるのか？これはわからないが、どんな軽微であれ影響がApacheサーバに出てしまうとその下に隠れているNFSへの負荷にもつながるので、慎重に進めなければならない。
と。。考えてまーす。