> I'd love to see if squid plays well with this...
>
> http://www.mosix.cs.huji.ac.il/
>
> Probably no perf benefits, but it might make redundancy fairly
> transparent.
No.
Mosix has problems with I/O. When a process is moved to another
box in the cluster, it leaves behind itself some 'stubs' that manage
network and other I/O.
So basically what would happen is that if squid is moved from box
A to box B, and a client connects to box A, then a stub on box A
takes all traffic and redirects it to box B, where it is handled
(it is possible that upstream links are opened on B via a stub on A,
I'm not sure), thus you are at least doubling the network traffic
and increasing latencies and CPU overhead with no benefits.
Other things might be interesting from a squid point of view.
For instance, having clustered squids with a frontend managing
HTTP and a storage backend accessed by the frontend over the network,
or backends that are accessible by multiple frontends.
Imagine something like this:
Frontend A Frontend B Frontend C Frontend D
\ | | /
--------------------------------------
| TCP/IP with some simple app. protocol
/--------------\
Ediskd A Ediskd B (failover)
\ /
\ /
Shared FC-based storage
Probably overkill and maybe better doable by other ways,
but definitely cool :-)
-- /kinkieReceived on Tue May 08 2001 - 00:52:40 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:00 MST